@anup-bhattacharjee and @wesley-TOP thanks for your updates I will change the post accordingly

@Lauwie007 said in Downlink API dataformat:

Downlink data received: 00 (but this is ASCII, which translates to 3030 in HEX)

Your assumption here is wrong @Lauwie007 this is binary the device visualizes the received data for you in HEX so it received 0x00 binary 2 bytes which is what you want to achieve.

+CSONMI: 0,2,00 means I received 2 bytes both all zeros.

Regards,
Eric

@iotguy ik heb zitten lezen in de CoAp specificaties de CoAp header is toevallig 4 bytes lang maar dat is geen payload en lijkt niet te matchen, de ACK is anders gedefinieerd, dus ik zie nog niet wat is. Zodra ik een update heb laat ik het weten.

@cees-meijer this messagetype is an registration message. This event occurs when the device is seen for the first time after a certain period this depends on several factors for instance after the device is switched-on and transmits its first message from a new IP address. It allows you to capture the payload of the first message ever sent to the udp adapter, otherwise this event would be lost.
We plan to added some more information in the future to this message as can be seen from the empty data elements.

Hoi Andre voor de North application url maakt het niet uit onder welk protocol je device connect. Dit blijft hetzelfde.

Ik heb de settings gevonden in de configuratie file van deze protocol adapter. Bedankt voor het wijzen op deze feature!

@cees-meijer if you would like us to review the behavior you can contact me in a DM. There might be optimisations possible.

@andre-rodenburg bij deze call moet je het device id gebruiken en niet de naam / serialnumber. dus de call ziet er zo uit ; (DELETE / GET){{base_url_cdp}}/rest/device/187
Je kan devices en id’s opvragen met de call (GET) {{base_url_cdp}}/rest/device?iDisplayLength=-1

@bob-mooij het heeft even geduurd maar ik wil hier toch op reageren.

De SIM kaarten die we tot op heden verstrekken kunnen alleen gebruik maken van deze APN : “cdp.iot.t-mobile.nl”.
Dit is ongeacht welk netwerk er geroamed wordt. (Onze global SIM kaarten roamen altijd overal).

Wat wel aangepast moet worden is de netwerkselectie.

Automatische netwerkselectie:

AT+COPS=0

Of handmatig (is sneller de eerste keer) maar land specifiek:

AT+COPS=1,2,"PLMN" 

De lijst met codes is publieke informatie bijvoorbeeld hier: PLMN lijst
Voor NB-IOT kan er geroamed worden op alle Telekom netwerken waar NB-IOT beschikbaar is.
Er kan wel een aanpassing nodig zijn van de geselecteerde banden (B3, B8 of B20).
De AT commandos verschillen hiervoor per module.

@paul-koenen het registreren van een endpoint gaat met deze call.

curl -X PUT
https://api.m2m.t-mobile.nl/m2m/applications/registration
-H ‘Accept: application/json’
-H ‘Content-Type: application/json’
-d '{ “headers” : { “authorization” : “Basic xx”
},
“url” : “https://nodered.nbiot.io/SK_TMNL_02”
}
’

De auth header info in de body kan je gebruiken om je eigen authorsatie mee te geven aan het applicatie endpoint dat je registreert. Je kan ook andere headers definieren zoals bijvoorbeeld een API key, afhankelijk van welke jouw endpoint nodig heeft.

Met deze aanroep gaat ons platform jouw endpoint testen met een lege body en verwacht een 200 OK terug op deze call.

@Lauwie007 said in Downlink API dataformat:

Downlink data received: 00 (but this is ASCII, which translates to 3030 in HEX)

Your assumption here is wrong @Lauwie007 this is binary the device visualizes the received data for you in HEX so it received 0x00 binary 2 bytes which is what you want to achieve.

+CSONMI: 0,2,00 means I received 2 bytes both all zeros.

Regards,
Eric

Hi Erwin,
Unfortunately MQTT(-SN) over NB-IOT as of yet is still unavailable for the iotcreators SIM cards this will be available shortly.
The manual kindly referred to by @Stefan-de-Lange is not related to IOT creators but to cloud of things which is a different offering entirely.
MQTT over LTE-M is available with these sim cards as can be read here. But this won’t help you with your NB-IOT modem.
Alternatively if you don’t like to wait I would suggest a different type of SIM offering (prepaid) we have also with a free plan here this has the MQTT-SN capability.

Hi @Artur-S ,

@Stefan-de-Lange is correct public DNS is not reachable from the IoT creators sim cards. I didn’t see and DNS option available in NB-IOT only capable modems I must say. Indeed LTE-M gives access to public DNS and internet. You could try one of the prepaid cards some of the T-Mobile operators are offering for IoT.

@rogierlodewijks and @afzal_m
Thanks for the honors and the devkit.
First of all; indeed you cannot turn on the echo using the standardised commands also I have found no alternative.
So sharing logs is more difficult.

I think the example above has a small error in the order of things.
Due to AT+CFUN=0 (which is switch off phone functionality)
You cannot issue at+cops and at+cgdcont commands

So the correct order is;
AT+CMEE=1;+CSCON=1;+CEREG=5 (turn on some informative feedback)
AT+CFUN=1
AT+COPS=1,2,“20416”
AT+CGDCONT=1,“IP”,“cdp.iot.t-mobile.nl”

See if we are searching for a network
AT+COPS? (If answer is 2 we are still searching)
AT+CSQ (if first number is unequal to 99 we have a radiosignal)

And then wait for:
+CSCON:1 (RRC Connected)
+CEREG:5,5,###### (Registered roaming)

(I have updated the example above)

@Dirkie123 I would like to investigate this topic a bit more. Could you send me some logs I can’t see which device / SIM card you are using in your tests. You can DM me or send details to hi@iot.t-mobile.nl?

There is no option to query the status of a downlink message. Buffering of downlink messages may occur on different places in our solution it is hard to give an clear response to such a request due to the asynchronous nature of the protocols.

Note: after sending an uplink message we will try to downlink all buffered messages.

The correct syntax for deleting a subscription is

curl --location --request DELETE 'https://iot.netwerk.t-mobile.nl/m2m/subscriptions/98f7bf0b-0000-0000-000-e077030e42ae' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic xxx' \
--data-raw ''

The subscription Id to be used is the one of the packets that you receive!
And Basic Auth is your authorization header.

Hi @Jurriaan-Vollebregt could you check the protocol you used when you registered your device? The protocol selected determines the encoding for downlink. We didn’t have changes that I m aware of.

Hi @Martijn-Kooijman , I think that the extra messages that you receive might be related to the lifecycle events that our platform sends. Sometimes when your device sends a message an re-registration event occurs this generates an lifecycle message. Have a look at this text: https://docs.iot.t-mobile.nl/docs/device-data-reporting we create both a lifecycle and a resource subscription when you register a device.

@Crowdsourcer I see that the socket id of the created socket is 2. In the consecutive commands you should use that Id. All other steps seem fine.