sendMessage returning true, but resulted in error at ATT

Today during tests I noticed no incomming messages from my shield (at AllThingsTalk and through MQTT my own server). Apparently it lost the connection (it was installed in my car so that is possible). After some time it picked up the signal and messages where comming in again.

All sensor states during that time were lost and I decided to buffer them for a period if the connection is dropped and then send them all quickly after eachother when the connection is restored.

During this implementation I dit something wrong with some pointers :grinning: so my message was send incorrectly. I noticed in ATT there were errors in the incomming messages such as these:
Nothing parsed from payload 0b 18 13 db. Errors:
ABCL: End 6 is not a valid ending boundary
Input not a dict.

But the Sodaq_nbIOT was returning a true return value with the sendMessage method which to me seemed to be an indication of an succesfully send message. Diving deeper into the Sodaq_nbIOT library I saw the response of the ATT server is being parsed and (partly) depending on this parse result the ultimate result of the sendMessage method is determined.
In my case I would have figured the result would be something else then “ResponseOK” and sendMessage would return a false instead of a true, so I could handle my buffered messages correctly. At first they were (wrongfully) popped from the buffer because the result of sendMessage was true.

I understand implementing a more complex parser for the result messages from ATT may be to much as it are two seperated things (and would mean implementing some sort of agreement/protocol) but maybe it is something easy to be done?

I do not know what ATT is returning in this case but maybe their result could give us a hint something went wrong at ATT’s side?

1 Like

All messages are send with CoAP to the CDP. You do NOT send anything to All Things Talk.
You can queue messages from or to the NB-IoT end device.

The T-Mobile CDP is responding to the NB-IoT shield if the packet has been received.
The shield will give OK, when it has transmitted a valid CoAP packet.
The T-Mobile CDP will forward the messages to your destination, ATT in this case.
From your end destination you can queue messages to send back. (Feature in ATT not implemented yet).

At this moment it is not possible to check on the NB-IoT shield if ATT has properly received and decoded your message.

Thanks for the clarification. It makes sense it works this way, I am still stuck in the “connected with the internet” mindset although this is a level lower.

My problem occured because of my misuse of pointers, that was already fixed so I don’t have any issues anymore but I was wandering in how these messages/communications were implemented and you gave me a satisfying answer.

How will this work after the pilot? I assume always through the CDP but without restrictions?

Yes, you will always have a CDP with T-Mobile.
In the CDP you can have multiple applications. Every application sends to one single endpoint.
The messages from the devices within this application will be forwarded to this endpoint.

Contact T-Mobile if they can provide you with a personal Ocean Connect account.

Hi @Jan, I’ve a similar problem. I have a succefull connection thanks to stretching the delaytime :slight_smile:. In ATT at the debug tab I receive data, but ATT cannot handle it towards my assets. For setting the assets, I followed the guide on And have checked again if name assets in the payload is the same as the assets itself. I get the following errors:

Binary Conversion 2017-09-29 06:23:15.345718 ERROR
Nothing parsed from payload 08 11 1d a5. Errors:
ABCL: End 6 is not a valid ending boundary
Input not a dict.

Binary Conversion 2017-09-29 06:23:05.115256 ERROR
Nothing parsed from payload 08 08 1d c7. Errors:
ABCL: End 6 is not a valid ending boundary
Input not a dict.

Binary Conversion 2017-09-29 06:22:55.502910 ERROR
Nothing parsed from payload 07 89 20 1c. Errors:
ABCL: End 6 is not a valid ending boundary
Input not a dict.

Do you know what’s going wrong or what I have to change (and where)? Thanks in advance again!
KR, Roel

Hi @roel,

It looks like you send 4 bytes and ATT is expecting 6.
What is the example you use? Then I can check if I can get the same results.

The sketch I just tested works fine :slight_smile:


Hi @Jan,

These are the examples I’m testing:



I downloaded them directly from Github.
KR, Roel

Hi @Jan, did you had the chance to have a look to the sketches? I don’t know what I’m doing wrong, but I’m using the examples provided and followed the guide for seting up ATT. Thanks in advance!
KR, Roel

Hi Roel,

The sketches are working fine.
I could have a look with teamviewer to check the ATT settings.
Please send me a personal message with the details.