Currently the API supports the following for functions/URLs to send downlink messages to the device downlinkMsg/0/data Sends regular queued downlink messages to device when uplink is received. downlinkMsgBase64/0/data Sends queued binary data blob message to device when an uplink is received. The function expects base64 encoded payload from the applaction as input into this function. Before the message is sent to the device it is decoded back to binary and sent to the device. downlinkMsgDrx/0/data Same like downlinkMsg/0/data but without queuing. downlinkMsgBase64Drx/0/data Same like downlinkMsgBase64/0/data but without queuing.

@Eric-Barten said in Downlink API dataformat: ary the device visualizes the received data for yo Okay, that my bad. Thanks for the answer

@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 Apologies, I may have spoken too soon. After playing with the payload formats on AllThingsTalk I do now see information coming in. Not quite exactly what i expected but I guess that’s down to misconfiguration on my part. So I’d say yes the connection works, parsing of data I need to look into. And yes changing the URL on the application server works which is good news!

Thansk Roalnd. Sorry for the delay… had another project. This works for me as well and now I can continue. regards, Paul

@Cees-Meijer I just got an error message that the email couldn’t be delivered to you email address. Could you please send an email to support@iotcreators.com to make sure I am using the right address? Thanks! Cheers.

If you save the URL the platform sends a request with an empty body to the URL to test it. If the URL doesn‘t exist or returns a code different than 200 you can not save the URL. Regards, Roland

@Roalnd-Baldin Thanks for helping, but not working. AT+CSOSEND=0,22,"48656c6c6f20576f726c64" OK Sim7020 working with hex length, not with the byte, so I tried with hex format, but the message not arrived the iotcreator and Beecaptor. Can you anything idea? Thanks all!

Unfortunately it didn’t work out, what we tried yesterday. Please follow this topic for new updates.

@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 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 I still get the extra messages delivered even after deleting all but one subscriptions. Any thoughts on how to tackle this? Could it have something to do with downlinks not arriving? for example how lomg should I wait after sending before receiving?

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.