Posts made by JeroenD

@Stefan-de-Lange IMHO is it possible to do HTTP(S) over NB-IoT, however T-Mobile decided to limit the messages to 512 bytes, use UDP and not to allow connections to the public internet. I think it would be nice to do HTTP(S) over NB-IoT

@afzal_m said in Add subscriptions via api:

Thanks a lot @JeroenD. Maybe you are not aware of it but last month with did a major update on the document library after two years. But we only focused on the devices part.

In August we will update the API part as well
@Roalnd-Baldin is already working on it.

Nice @afzal_m

I also found out how to remove a device. It is indeed the postman call but with a different method, not GET but DELETE. This is wrong in the postman collection also…

curl -X DELETE ‘https://<username>:<password>@iot.netwerk.t-mobile.nl/rest/device/14053’

The only thing I am still looking for is how to remove a device. According to the postman collection this should be:

curl -X GET ‘https://<username>:<password>@iot.netwerk.t-mobile.nl/rest/device/14050’

But this shows device information and does not delete it.

@afzal_m This one is also already solved. I took a look at the postman collection and distillated the curl command from it. This works! To those that are interested, it is possible to add a device using:

curl -X POST ‘https://<username>:<password>@iot.netwerk.t-mobile.nl/impact/m2m/endpoints’ -H ‘Content-Type: application/json’ -d ’ {“additionalParams”: {“adaptationLayerName”:“TMNL_UDP_AL”},“address”: “”,“groupName”: “<group name>”,“identifier”: “”,“protocol”: “HTTP”,“serialNumber”: “IMEI:zzz”} ’

In this way the device is also shown in the portal

Maybe it is a good idea to update the (invalid) documentation!

@afzal_m I just checked again, for me the downlink is working (again?)

But I have to admit, for it it was just clicking a button on a GUI.

Lucky you, I used a HTTP PUT request to downlinkMsgBase64Drx

@afzal_m Also thnx Afzal!

@afzal_m Thnx Afzal!

@trick2011 Ik heb overigens nu ook de indruk dat een downlink niet werkt. @afzal_m @Eric-Barten kan het inderdaad zijn dat downlinks niet werken op het moment?

As promised the results of my test to try to register a brand new modem using API calls instead of using the portal. This was unsuccessful btw…

Using the API, I was successful in registering an IMEI of a brand new modem. If I used the API to return the registered IMEIs it was reported in the same way as the IMEIs that I did register through the portal. I was able to send messages but the messages where not forwarded to my cloud server.
Next I removed the IMEI from the subscriptions using the API and curl, and registered the IMEI in the portal. This was possible, however also now no data was forwarded to my cloud server. I think this is the already known issue that first you need to register and next to send the first message, and I already send messages in the first test as descibed above.

My question is: could T-Mobille please provide working API calls for registering IMEIs?

This is in detail what I did. Username, password, subscription Ids, group name and IMEIs have been removed from the logs below for obvious reasons.

Check my registered IMEIs
curl -X GET ‘https://<username>:<password>@iot.netwerk.t-mobile.nl/m2m/subscriptions?type=resources&groupName=<group name>’
Response
{“subscriptions”:[{“subscriptionId”:“<subscription 1>”,“resources”:[{“resourcePath”:“uplinkMsg/0/data”},{“resourcePath”:“downlinkMsg/0/data”}],“groupName”:“<group name>”,“criteria”:{“serialNumbers”:[“IMEI:xxx”,“IMEI:yyy”},“deletionPolicy”:0},{“subscriptionId”:“<subscription 2>”,“resources”:[{“resourcePath”:“uplinkMsg/0/data”},{“resourcePath”:“downlinkMsg/0/data”}],“groupName”:“<group name>”,“criteria”:{“serialNumbers”:[“IMEI:xxx”,“IMEI:yyy”},“deletionPolicy”:0}]}

I am surprised that TWO subscriptions exists, with exactly the same list of IMEIs. Why?

Above call gave me two subscription Ids that I used in the following calls

Register a new IMEI in <subscription 1>
curl -X POST ‘https://<username>:<password>@iot.netwerk.t-mobile.nl/m2m/subscriptions/<subscription 1>/serialNumbers’ -H ‘Content-Type: application/json’ -d ’ { “serialNumbers”: [ “IMEI:zzz” ] }’
Response:
{“subscriptionId”:“<subscription 1>”,“msg”:“Success”,“code”:1000}

Register a new IMEI in <subscription 2>
curl -X POST ‘https://<username>:<password>@iot.netwerk.t-mobile.nl/m2m/subscriptions/<subscription 2>/serialNumbers’ -H ‘Content-Type: application/json’ -d ’ { “serialNumbers”: [ “IMEI:zzz” ] }’
Response:
{“subscriptionId”:“<subscription 2>”,“msg”:“Success”,“code”:1000}

Check if it is registered with the API (yes it is):
curl -X GET ‘https://<username>:<password>@iot.netwerk.t-mobile.nl/m2m/subscriptions?type=resources&groupName=<group name>’
Response
{“subscriptions”:[{“subscriptionId”:“<subscription 1>”,“resources”:[{“resourcePath”:“uplinkMsg/0/data”},{“resourcePath”:“downlinkMsg/0/data”}],“groupName”:“<group name>”,“criteria”:{“serialNumbers”:[“IMEI:xxx”,“IMEI:yyy”,“IMEI:zzz”},“deletionPolicy”:0},{“subscriptionId”:“<subscription 2>”,“resources”:[{“resourcePath”:“uplinkMsg/0/data”},{“resourcePath”:“downlinkMsg/0/data”}],“groupName”:“<group name>”,“criteria”:{“serialNumbers”:[“IMEI:xxx”,“IMEI:yyy”,“IMEI:zzz”},“deletionPolicy”:0}]}

If I check in the portal at https://portal.iot.t-mobile.nl/projects the IMEI is NOT shown

If I put in a brand new T-Mobile sim card I was able to register with T-Mobile, and to send messages, using the regular AT commands. The messages where accepted by the network. I think this is expected behavior, even without registration.
HOWEVER: the messages where not forwarded to my cloud server, leading to the conclusion: registering IMEIs using the API does not work.

Next I removed the IMEIs from the subscriptions, for completeness I also give the commands for this:

Delete from subscription 1
curl -X DELETE ‘https://<username>:<password>@iot.netwerk.t-mobile.nl/m2m/subscriptions/<subscription 1>/serialNumbers’ -H ‘Content-Type: application/json’ -d ’ { “serialNumbers”: [ “IMEI:zzz” ] }’
Response
{“subscriptionId”:“<subscription 1>”,“msg”:“Success”,“code”:1000}

Delete from subscription 2
curl -X DELETE ‘https://<username>:<password>@iot.netwerk.t-mobile.nl/m2m/subscriptions/<subscription 2>/serialNumbers’ -H ‘Content-Type: application/json’ -d ’ { “serialNumbers”: [ “IMEI:zzz” ] }’
Response
{“subscriptionId”:“<subscription 2>”,“msg”:“Success”,“code”:1000}

Now I tried to register the same IMEI in the portal. This was successful but messages are again not forwarded to my cloud server. Also no IMSI, no first message, no last message nor payload is shown in the portal. This is probably because I sent messages in my test without a prior proper registration (this is a known issue)

@afzal_m Maybe related indeed. I am going to do some tests and if that leads to interesting insights I will post them here

@afzal_m Yeah you’re right :), however the ‘refresh table’ button works correctly, so it is not related to cookies

Check je username en wachtwoord. Als je een “Unauthorized” krijgt zou het daar ergens kunnen zitten. Check de IMEI, volgens mij staat deze ook in de reply op je downlink. Heb je speciale tekens in je wachtwoord? Dan kan je ook het eerste voorbeeld gebruiken en bij de xxx de Base64 encoding van username:password zetten.

Je kunt ook naar
curl -X PUT -H “Authorization: Basic xxx” -H “Content-Type: application/json” -d “yyy” https://iot.netwerk.t-mobile.nl/m2m/endpoints/IMEI%3a868333030xxxxxx/downlinkMsgBase64Drx/0/data

sturen. De data die je vesrtuurd (bij yyy) moet dan Base64 encoded zijn. Als ik het me goed herinner kan je met deze 2e call ALTIJD data versturen, en met de eerste call alleen in combinatie met een uplink

@trick2011 said in Graag downlink voorbeeld door rechtstreeks de api te gebruiken:

curl -X PUT -H “Authorization: Basic xxx” -H “Content-Type: application/json” -d “{ “resourceValue” : “Hallo” }” https://iot.netwerk.t-mobile.nl/m2m/endpoints/IMEI%3a868333030xxxxxx/downlinkMsg/0/data

Probeer
curl -X PUT -H “Content-Type: application/json” -d “{ “resourceValue” : “Hallo” }” https://username:password@iot.netwerk.t-mobile.nl/m2m/endpoints/IMEI%3a868333030xxxxxx/downlinkMsg/0/data

Vul bij username en password je eigen username en password in die staan bij API credentials. Na IMEI%3a moet je het IMEI nummer invullen van het device waar je hetbericht naartoe wilt sturen

@afzal_m Hi Afzal, thnx for the response. I do not use the browser, I use curl, so no cookies, nor logins at all

I am a step further, sending the following:
curl -X POST https://[username:password]@iot.netwerk.t-mobile.nl/m2m/subscriptions/[subscription ID]/serialNumbers -H ‘Content-Type: application/json’ -d ’ { “serialNumbers”: [ “IMEI:451229637658708” ] }’

gives:
{“subscriptionId”:“[subscription ID]”,“msg”:“Success”,“code”:1000}

The IMEI is a valid random IMEI in this example. If I list all subscriptions, the IMEI is added. But if I go to my account and look at ‘Projects’, the IMEI is not shown…

Why?

What is the correct syntax for adding a device using the API? I can delete a device using the API, but how to add is not specified (correctly) in the documentation.

@Noah-Marx said in Max message length:

https://forum.iot.t-mobile.nl/topic/504/maximum-number-of-messages-per-day/6

Thnx Noah, but no. My experience is that messages can not exceed 512 bytes from CDP to device and 1024 bytes from device to CDP. I would like this constrained by relieved, at least to one UDP frame of 1460 bytes, but even larger if possible. In the message you refer to I read that larger messages should be split up, but since with a CDP communication is message based and not frame based, you have to sort and glue those messages to one yourself on both sides. That is a waste since TCP/IP was designed to do this for us! So next best to an ordinary TCP/IP connection directly to the backend server (or any other IP address) would be a larger message IMHO.

@afzal_m Yes and I like it! How can I send you a direct message? I tried going to your personal page and then a chat, but pushing the send button doesn’t do anything (even in a new private session)

While experimenting with a modem library I entered a SIM PIN too many times. The SIM card needs a PUK now to release it. However, I can not find a PUK on the card. Is it still possible to release this SIM?

It seems that there is a maximum message length. From device to CDP 1024 bytes and from CDP to device 512 bytes. I get a:
{
“requestId”: “21823204-ee2e-4b8f-a787-f9577fe7dcb1”,
“msg”: “Accepted”,
“code”: 1002
}
even when I send more than 512 bytes.

• Is there indeed a restricted message length?
• Is it possible to remove this contraint? Possibly in a payed option?
• I would love 65,535 bytes message length, but would expect at least 1,460 byes (one UDP packet)

@eric-barten dank voor je reactie. UDP heb ik al langere tijd werkend. De officiële informatie over CoAP, ook de link die je geeft, is heel beperkt. Als ik CoAP initieer op mijn device verwacht ik dat ik per UDP frame een JSON van CDP krijg op mijn applicatieserver, omdat UDP onder CoAP ligt. Echter, CoAP is een connectie, en verwacht dus data terug. Dat lijkt mij onmogelijk op deze manier. Toch is dat wat ik zoek: een full duplex stream naar mijn applicatieserver. Kan dat met CoAP? Of is er een andere manier? Zo ja welke?

@afzal_m Hoi Afzal, ik zie nog geen nano sims in de webshop. Wanneer zijn ze te bestellen?