@afzal_m Srry fr the delay, I have been out a couple of days. But good news. Everything seems to be working fine again!

Thank you Afzal.

@afzal_m Srry fr the delay, I have been out a couple of days. But good news. Everything seems to be working fine again!

Thank you Afzal.

Yes, they are still coming at our application, and it is only a problem in the t-mobile portal. Last messaged received there is on the 26/10/2020.

For us it is not a huge problem atm, but I can imagine for new users, it can be frustrating.

No change, we tried alrdy with multple IMEI’s

We noticed that the data is coming in our own api but is not displayed in the t-mobile api.

The 26th and now today, no more messages are comming into the portal. Do more people have this problem? We tried with multiple devices, and multiple modules, all sending the messages, but none appearing in the portal.

For anyone intrested, you can check the commands by using inspect page on the elements in the gray boxes. Due to some “” ''it is probably not in the containers.

I found the problem, I use an arduino leonardo with a dragino nbiot shield. For incomming/outgoing messages i use SoftwareSerial.h, to change the tx/rx pins to pins 10/11.

I fixed the problem by using the normal rx/tx pins and it works. Hence the library seems to be my problem.

Hope this helps anyone.

@Eric-Barten Just checked, sending to 172.27.131.100 Port 15683, which is UDP. Also, I get my messages correctly in my api. Only the donwlink messages are going wrong.

@Eric-Barten can I see this somewhere in the api? I havent vhanged it since it worked.

Downlink messages used to work fine with:

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

I could receive them and decode them to ascii, recently i noticed that the downlink messages became gibberish.
Does anyone else have this same problem?
Where the incomming message should look like: 0,172.27.131.239,15683,5,68616c6c6f,0
Now I receive this: Hb⸮⸮⸮r⸮⸮r⸮⸮⸮r⸮⸮⸮b⸮⸮⸮šb⸮b⸮²⸮⸮⸮C6F,5

Seems there is some encoding via api calls which turned sour…