I have tens of devices installed in different places working with OS 0.7.0 version since almost half a year. Since ~last month I had some devices that stop publishing data without any apparent reason. It seems that the connection is OK (diagnostics show all fields green), and ping reaches the device successfully. The only solution seems to restart the device.
Is there any clue to how to debug it? All local devices that I test doesn’t show this error, and the code was working sucessfully since a long time ago. Maybe some change in the Particle cloud might prevent some events to be published?
Still searching for this error, and update with new information.
After the connection problems, I just added some extra reliability in the communications, so now, after publishing the message, it waits until the matching webhook fires and got the webhook reply. The thing is that sometimes this doesn’t work well.
Finally, I’m try to understard the low level communication using SerialLogHandler, the problem is that I think that the data send through uBlox is encripted somehow so need to know what is the content of the messages to really understand what is going on, and why some replies from the Particle cloud doesn’t reach the module with no aparent reason.
So, how can I interpret messages like:
31804.181 AT read + 14 2 “\r\n+USORF: 0,“184.108.40.206”,5684,104,”\x17\xfe\xfd\x00\x01\x00\x00\x00\x00\x00\\x00[\x00\x01\x00\x00\x00\x00\x00\\xdb\xce\xb6\xdc\xed\xe7\x8de\x9e\xd3\x9b\x8fk\xe0\xce\xe4Q\\x87U…
You should add one thing to your failure handing code. If you are missing your response events, you should not only reset the mode (either AT+CFUN=16 or SLEEP_MODE_DEEP) but you may also want to reset your cloud session. The code to do that is here:
In fact, I’m using the electronsample as a basic schema. SessionCheck is working, but it never fires (every time waitToSendState sends the check it works).
There are different incidents, all related to connectivity (software watchdog, losing sporadic webhook replies, losing webhook replies for a long time, etc). If I run the application without any connectivity, it NEVER has any problem, so I’m not sure I can do anything else to improve that.
Maybe I can show you privately how it works (or the logs) to check if there are some hidden bug? I’m using 0.7.0, and waiting for the stable 0.8.0 version before changing to it.
This is probably due to FreeRTOS and sharing the same serial interface between multiple threads.
While one thread may have had its timeslice to created the string it might lose control before actually sending it to the interface and when it regains control will have to wait for the shared resource to become available which may well take more than a millisecond.
With up to 5 concurrent threads an out-of-order log of 5ms wouldn’t give me bad dreams.