Posts made by Roalnd Baldin

@Lauwie007 Can you please send your IMEIs to support@iotcreators.com? I like to analyse the problem in more depth and fix it.
Many many thanks for your support!
Regards, Roland

@Hans-Liefting: Can you please send me the IMEI of your device to support@iotcreators.com? I will check the logs to understand when uplink and downlink messages are received and when downlink messages are sent by the udp server.

Regards, Roland

@Hans-Liefting Hi,
I am not sure if I understood your process correctly …

Process ?

1. Device wakes up and connects to the network
2. Device send uplink message
3. Application receives the message and response with a downlink acknowledgment
4. Device waits for 10 seconds
5. Device closes the connection and shuts down.
6. After one hour process is repeated at 1.

Problem ?
Downlink message isn’t received by the device reliable.

If you send a non-eDRX downlink message our UDP broker queues the messages until it receives the next uplink message from the device. This means your application acknowledgement message requires an additional uplink messages to let UDP broker deliver the queued downlink message to your device.

In case you send an eDRX downlink message you can try to extend the 10 secs wait to e.g. 30 secs and see what happens. As you know eDRX messages are not queued by the UDP broker. eDRX messages are immediately pushed to your device by the UDP broker. In case you device sleeps the downlink messages are queued by the mobile network. If you are using eDRX downlinks it could be possible that 10 secs not enough for the network to deliver the message and 1 hour of buffering is to long. Maybe this is reason why it works if you wakeup every 5 minutes.

Regards, Roland

@magnatron Did you already send me your account, the project and the imei of the device. I like to check the logs. You can send it to roland.baldin@telekom.de.

Regards, Roland

@magnatron In case you still not able to send downlink messages to your device please provide your account, project and the device imei to our support@iotcreators.com . I will take a look on it.

Regards, Roland

Last comment …

This is valid only for non eDRX downlink messages. eDRX messages are sent directly into the network and will be buffered by the mobile network until the device is available.

Unfortunately I don’t know how long the downlink message is buffered by the mobile Telekom network

Regards, Roland

In case of UDP our middleware manages for each device an out-queue for downlink messages.
The max. size of the queue is 10 messages.
After an uplink messages has been received all queued downlink messages are delivered to the device 1 messages / sec.
If the devices never sends an uplink messages the downlink message stays in the out-queue for ever.
If the device is deleted the out-queue for downlink messages is deleted as well.

Hope this info helps.

Regards, Roland

@magnatron Hi, I double checked our “Elastic IPs” and found out, that the 18.195.119.162 as documented in the documentation library is wrong

The correct IP is 18.197.119.162. It was a typo. Sorry!

I checked it with my application and I could see the IP in the x-forwarded-for header field of my Azure function.

Thanks for let us know this!

Regards, Roland

We integrated a broker for standard CoAP devices with the middlware platform of IoT Creators.
Even when the portal application of IoT Creators doesn’t support standard CoAP yet we want to provide you the possibility to play arround with it and do some tests.
In the following I describe the steps to register a standard CoAP device and subscribte to it with the API. By this the messages of the device can be forwarded to your application URL in the same way like it is done by the portal application.

As UDP or the Neul protocol standard CoAP requires the usage of an IoT Creators SIM card and you can reach the CoAP server at IP 172.27.131.180 and port 5683 only by setting APN: cdp.iot.t-mobile.nl (or scs.telekom.tma.iot if you use SIM card from Magenta Austria)

1. Register your application URL for the API user
You need to register at least a dummy application URL for the
API user because otherwise it will not be possible to create
new devices via the API.

You find the username and the password of your API user in the
page “YOUR APPLICATION SERVER” of your IoT Creators Projects.

REQUEST PUT https://api.scs.iot.telekom.com:443/m2m/applications/registration
REQUEST HEADERS: {
  'Content-Type': 'application/json', 
  'Accept': 'application/json', 
  'Authorization': 'Basic <base64(API-USER:API-USER-PASSWORD)>'
}
REQUEST BODY: {
    'url': 'https://dev.scs.iot.telekom.com/scs-callback-dummy', 
    'headers': {
      'key1':'value1'
    }
}

RESPONSE BODY: {
    "msg": "Success",
    "code": 1000
}

2. Create the Std. CoAP device in IoT Creators
You find the username and the password of your API user in the
page “YOUR APPLICATION SERVER” of your IoT Creators Projects.
You find there also the “groupName” for the request body in
this page as well.

You can add a list of key/value pairs as addtional “customAttributes”
to the device. Those key/value pairs are passed along with each
message of the device to the configured application URL.

REQUEST POST https://api.scs.iot.telekom.com:443/m2m/endpoints

REQUEST HEADERS: {
  'Content-Type': 'application/json', 
  'Accept': 'application/json', 
  'Authorization': 'Basic <base64(API-USER:API-USER-PASSWORD)>'
}

REQUEST BODY: {
  'serialNumber': 'IMEI:512668894698385', 
  'groupName': 'CON_0000002299', 
  'protocol': 'HTTP', 
  'additionalParams': {
    'adaptationLayerName': 'STDCOAP_TEST'
  }, 
  'address': '', 
  'identifier': '', 
  'customAttributes': {
    'deviceType': 'Efento'
  }
}

RESPONSE BODY: {
    "msg": "Device added successfully",
    "code": 3000
}

3. Create subscription for the Std. CoAP device
Because the support for Standard CoAP devices are not 100%
finished in the IoT Creators portal I recommand to
add the suscription also with the API.

REQUEST POST https://api.scs.iot.telekom.com:443/m2m/subscriptions?type=resources

REQUEST HEADERS: {
  'Content-Type': 'application/json', 
  'Accept': 'application/json', 
  'Authorization': 'Basic <base64(API-USER:API-USER-PASSWORD)>'
}

REQUEST BODY: {
  'subscriptionType': 'resources', 
  'groupName': 'CON_0000002299', 
  'deletionPolicy': 0, 
  'resources': [
    {
      'conditions': {}, 
      'resourcePath': 'uplinkMsg/0/data'
    }, 
    {
      'conditions': {}, 
      'resourcePath': 'downlinkMsg/0/data'
    }
  ], 
  'criteria': {
    'serialNumbers': ['IMEI:512668894698385']
  }
}

RESPONSE BODY: {
    "subscriptionId": "8974985d-fa8c-472d-8ae3-202e18143e1d",
    "msg": "Success",
    "code": 1000
}

Have Fun

Regards, Roland

Hi,

instead of creating and deleting complete subscriptions after you added or deleted devices you can add or remove the device to or from from the existing subscription.

In the following the Nokia IMPACT API samples

• to get the devices of an existing subscription,
• list itemto add a devices to an existing subscription,
• list itemto delete a devices from an existing subscription (important: if the last device of a subscription is delete the subscription it-self is deleted as well).

Get devices of an existing subscription

GET https://iot.netwerk.t-mobile.nl:443/m2m/subscriptions/f37b094d-307f-4d43-82c5-73f81104e22f/serialNumbers
HEADERS: {
 "Content-Type": "application/json", 
 "Accept": "application/json", 
 "Authorization": "Basic QVBJX0NPTsl8wMDssAswMDAbxNcTU4XzNlZmEzOkpySS9YOC45Y19CrrRmI0OEY="
} 
BODY: {
 "serialNumbers": [
 "IMEI:452749630137052", 
 "IMEI:351938100191440"
 ]
}

RETURN STATUS CODE: 200
RETURN BODY: {
  "serialNumbers": [
    "IMEI:454596441983713",
    "IMEI:351938100191440",
    "IMEI:866425033313638",
    "IMEI:452749630137052",
    "IMEI:352656100979544"
  ]
}

Add devices to an existing subscription

POST https://iot.netwerk.t-mobile.nl:443/m2m/subscriptions/f37b094d-307f-4d43-82c5-73f81104e22f/serialNumbers
HEADERS: {
  "Content-Type": "application/json", 
  "Accept": "application/json", 
  "Authorization": "Basic QVBJsX0NPTl8wMDsssswMDAbxNcTU4XzNlZmEzOkpySS9YOfgC45Y19CRmI0OEY="
}
BODY: {
  "serialNumbers": [
    "IMEI:452749630137052", 
    "IMEI:351938100191440"
  ]
}

RETURN STATUS CODE: 200
RETURN BODY: {
  "subscriptionId": "f37b094d-307f-4d43-82c5-73f81104e22f",
  "msg": "Success",
  "code": 1000
}

Delete devices from an existing subscription

DELETE https://iot.netwerk.t-mobile.nl:443/m2m/subscriptions/f37b094d-307f-4d43-82c5-73f81104e22f/serialNumbers
HEADERS: {
 "Content-Type": "application/json", 
 "Accept": "application/json", 
 "Authorization": "Basic QVBJsX0NPTl8wcMDssAwMDAbxNabcTU4XzNlZmEzOkpySS9YOC45Y19CRmI0OEY="
} 
BODY: {
 "serialNumbers": [
 "IMEI:452749630137052", 
 "IMEI:351938100191440"
 ]
}

RETURN STATUS CODE: 200
RETURN BODY: {
  "subscriptionId": "f37b094d-307f-4d43-82c5-73f81104e22f",
  "msg": "Success",
  "code": 1000
}

@magnatron It was never possible to store the application url if the application didn’t return 200.

In the old version the inital request contained an empty body to test if the URL is valid. This has actually changed. No an empty dictionary structure is put as payload.

Regads, Roland

Hi,

for your information:

IoT Creators platform (SCS) times out the message forwarding POST request to the application URL if the application doesn’t response within 5 seconds.

In case of timeout SCS tries to re-POST the message 5 times. Every minute one retry is performed.

While the systems trys to re-send the message no new messages are POSTed to the application. There are queued.

Hi Peter,

I just contacted you via our support channel so I can do some additional tests to your connection.

Can you please send my your IMEIs as a response to the email which you just got.

Many thanks!

Regards, Roland

Currently the API supports the following for functions/URLs to send downlink messages to the device

• downlinkMsg/0/data
  Sends regular queued downlink messages to device when uplink is received.

• downlinkMsgBase64/0/data
  Sends queued binary data blob message to device when an uplink is received. The function expects base64 encoded payload from the applaction as input into this function. Before the message is sent to the device it is decoded back to binary and sent to the device.

• downlinkMsgDrx/0/data
  Same like downlinkMsg/0/data but without queuing.

• downlinkMsgBase64Drx/0/data
  Same like downlinkMsgBase64/0/data but without queuing.

@Lauwie007 For my understanding there is no difference if the function transfers “hi” or “01AB” as value.
Regards, Roland

Hi guys,

after we integrated the connectivity from Magenta Austria in the last days with IoT Creators/SCS platform succesfully I tryed with my devkit Quectel BG96 not only NB-IoT but also LTE-M and GSM - unfortunately pure LTE is not supported by the devkit.

It worked immediatly

With following AT commands I could connect to our Telekom network in Germany and send UDP messages to our server:

# Set frequency band for Telekom Germany
AT+QCFG="band",0,0,80,1					

# Set our APN
AT+CGDCONT=1,"IP","scs.telekom.tma.iot"

# Use 0 for GSM  ...
AT+COPS=1,2,"26201",0

# ... or 8 for LTE-M
AT+COPS=1,2,"26201",8

# ... or 9 for NB-IoT
AT+COPS=1,2,"26201",9              

# Connect to our UDP server
AT+QIOPEN=1,1,"UDP","172.27.131.100",15683,1001,0

# Send "hello world" as hex
AT+QISENDEX=1,"48616c6c6f20576f726c64"

This is really cool !!

Cheers, Roland

@Lauwie007 Hi,

If I send “hi” with

PUT https://iot.netwerk.t-mobile.nl:443/m2m/endpoints/IMEI:867997031341158/downlinkMsg/0/data
and
BODY {
“resourceValue”: “hi”
}

I receive

AT+QISENDEX=1,11,48656c6c6f20576f726c64
OK
SEND OK
+QIURC: “recv”,1
AT+QIRD=1,100
+QIRD: 2
hi
OK

on the device.

Regards, Roland

Hi,

we just published in our Documentation Library the description how to integrate development kit SODAQ SARA AFF R410M with LTE-M network and send and receive messages via MQTT.

It is located at https://docs.iotcreators.com/docs/sodaq-sara-r410m.

If you find bugs please let us know by sending an email to doclib@iotcreators.com.

Many many thanks to Erik!!

Regards, Roland

@Gijs-Mos
I checked the UDP logs for your device and I agree. Your device doesn’t send the messages twice.

If your application end-point doesn’t return to our platform within 1 second we go into a re-try loop to re-deliver the message. We re-try max. 5 times. Every minute ones. If within the period of re-trieng additional messages from other devices arrive they are put into the same post request and delivered as an additional element of the “reports” array. But in this case you would see different serialNumbers and timestamps.

Is it possible that your callback returns sometimes slower than 1 second. In this case our platform would re-deliver the message a second time.

I saw cases where the application end-point didn’t publish the message into a queue for asynchronous processing. It processed the message directly and stored it away into a DB. Sometimes the DB blocked. By the this the response time was bad and the messages have been delivered a second time.

Regards, Roland

Hi,

many users ask via which IP address IoT Creators SCS forwards received uplink messages to the registered application callback URL:

IoT Creators SCS forwards the uplink messages to your application callback URL via one of the two IPs

• 18.195.119.162
• 18.195.17.174

Hope this helps you to configure the IP whitelists of your application.

Regards, Roland

• Before activating radio module Set APN with AT+QCGDEFCONT rather than **AT+CGDCONT
• Set frequency band explicity with AT+QBAND
• Configure first APN, fequency band and mobile operator ID before switching on automatic attachment

As you know the very-first-attachment to the network can take multiple minutes. Sometimes this creates problems in the production process.

Out of this reasons we are looking for possible measures to improve the very-first-attachment time.

Regards, Roland

@Rasyid Do you have a valid network connection ?

For Quectel BG96 you can verify the network connection with the following AT commands

AT+CGPADDR                    //check IP address
AT+CGATT?                     //check if attached to network
AT+COPS?                      //check current set MNO
AT+COPS=?                     //scan network for mobile operators
AT+CGDCONT?                   //check APN
AT+QPING=1,"172.27.131.100"   //ping UDP server

Regards, Roland