I've done some further troubleshooting and tried the following methods to get it to send consistently:
Change QoS to 1. I found that I still encountered the same issue before where it got stuck after a random amount of time. This also delayed each additional message by about 1 - 5 seconds so I removed the time.sleep(0.2)
Wait for ping message after every 10 publishes. I found that this also ended up getting stuck as well. Again I removed the sleep cause the delay was between 1-5 seconds on the ping.
Ping message after every publish. This didn't suffer the problem of freezing during the hour that I tried. I did find however that the duration for it to get a successful ping took longer as time went on. From about 1-3 seconds average to about 7-10 seconds average after about an hour.
Connect and disconnect the client after every publish. This seems to working the best, it hasn't frozen within the 30 minutes I've been testing it and each message is taking 3-5 seconds to send to the broker.
If anyone has any further suggestions it would be appreciated.
Before 1.20.rc4 I ran somtimes into i2c errors in setup_sleep. So I blamed it on i2c problems without an exception. Without the i2c error it happens really seldome. Board does not go to sleep and script stops. But I can't remember if I was really able to use the REPL
it depends .... on what board we use ... some almost never do ... like take days before it happens ... others ... do it every 2nd -- 3rd time around ....
I will try to run them all on the latest developmente verision ... and see if it happens there too
IIRC, i think there is a thread here talking about "py.go_to_sleep()" not always working ...
The watchdog shall help you to get out of this state.
Yeah, it does. It reboots it ... and we happen to get two close data points / intervalls next to each other ...
But this to is fixable ... just have to re-structure the app to become event-state driven ... and use NVRAM to store where it is .... so if WDT restes ... we can try again from last event-state .... ergo if we've come to the last event (go_to_deep_sleep) it would then just try to put the board in DS-mode ...
Fixable ... but not as neat if it worked out-of-the-box :-)