Best posts made by Eric Barten

@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.

@andre-rodenburg

Hi @hoekynl do you have this problem still? I am afraid we should ask ATT about this. Could it be due to reregistration of your device at ATT? Do you have the possibility to test with a new device?

Hoi Arie,
Je hebt inderdaad verbinding met ons netwerk.
Zou het kunnen dat jouw device zich al geregistreerd heeft door het verzenden van een bericht?
Je kan het even opnieuw proberen.
En als het nog niet lukt kan je me dan je IMEI nummer sturen in een DM?

Eric

Hoi @Jigs in de documentatie hier : https://docs.iot.t-mobile.nl/docs/using-the-api staat beschreven hoe dat gaat. In de body van de payload specificeer je extra headers naast de basic-authorization header die al in het voorbeeld staat.

curl -X PUT
–header ‘Content-Type: application/json’
–header ‘Accept: application/json’
–header ‘Authorization: Basic ZG9jdXNlcjpBc2RmMSM=’
-d ‘{
“headers”: {“authorization”:“Basic dWF0YWRlcDpBc2RmMSM=”},
“url”: “https://<callback_url>/callback”
}’ http://<base_url>/m2m/applications/registration’

Response Body:
{
“msg”: “Success”
}

Hi @alessandro-mirabella I have the same device and it works fine with both ther libraries and through AT commands.
Can you specifiy which command fails? Usually when the SIM card is not correctly inserted a lot of commands give an error, can you check this?

@afzal_m and @Marijn everything looks fine indeed the problem is in the socket creation.
Depending on the firmware version of the module it could be the case that the quotes are not required:
AT+NSOCR=“DGRAM”,17,7000,1 could be changed to AT+NSOCR=DGRAM,17,7000,1
Also try different port numbers (7000) and socket numbers (1)
And perhaps try to retype the quotes sometimes they get copied wrong

If your device has transmitted data it has "auto registered’ to the main account and can not be claimed by any project account anymore. Everyday at approx. 8 AM devices get cleared again from the main account and can be registered again.

Hi @Robin-Finkers ,
I have been reviewing our documentation and noticed that this might not be clear; in the att asset did you register the device connectivity with the IMEI: prefix? This should be the case otherwise the device is not found.

Sodaq just shared their NB-IOT based sniffer bike project on Hackster.io. Besides being an cool and ecologically relevant project, it includes one of the most elaborate NB-IOT libraries I have seen sofar. You can find the project here.