Hi Rik,
can we have a conf-call about this topic. We are currently making customer interviews to understand your requirements better.
Yes, we can raise priority for this topic
I will send you and email to schedule a conf-call.
Regards, Roland
Hi Rik,
can we have a conf-call about this topic. We are currently making customer interviews to understand your requirements better.
Yes, we can raise priority for this topic
I will send you and email to schedule a conf-call.
Regards, Roland
Hi,
currently the customers split up firmware images into chunks of eg. 512 byte and push them to the device via downlink API requests (https://docs.iotcreators.com/reference/using-the-cdp-api).
We are currently working on a better support for FOTA in our IoT Creators portal. The portal will provide a capability to upload to and manage files in the device-download-space. From there the devices are able to download the files via e.g. HTTP or CoAP.
Regards, Roland
@GrandPep I had a look to your configurations. I saw that you registered for your API account an application URL but I cannot see any subscriptions. I will verify it and come back to youā¦
Regards, Roland
@grandpep The API response āAcceptedā with code ā1002ā doesnāt mean that the downlink message has been delivered to the device. It means the the message has been accepted and queued by the protocol specific IoT adapter.
Can you please send the IMEI of the device for which you try to send a downlink message with the API to our support box support@iotcreators.com?
Regards, Roland
@GrandPep Did you send an uplink message from the device after you posted a downlink message?
Downlink messages are not delivered immediately to the device. They are queued in the middleware.
Queued downlink messages are delivered to the device after the device has sent an uplink message.
The middleware queues up to 10 messages.
Regards, Roland
@GrandPep Hi, normally you should get the āInvalid Json formatā only if something is wrong with the JSON in the HTTP body.
Can you please provide the HTTP code snippet which you get displayed in Postman when you click the ā</>ā symbol on the very right side of the Postman window ?
Please make sure that you change the Authorization tokoen oand the IMEI before you share it with us.
Many thanks!
Roland
Hi,
the first version of documentation for SIMCom SIM7022 how to
is available now in IoT Creators documentation library.
https://docs.iotcreators.com/docs/simcom-sim7022
Would be great if you check it and give me some feedback for improvements and corrections.
Regards, Roland
@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 ?
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
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"
]
}
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 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