I could connect the charger through a sonoff or similar and automate a restart if the last timestamp on received temp/humi data is older than a few minutes… i.e.: reboot on freeze.
I would advise more a preventive restart every day by firing from your controller a restart command to MQTT (v0.9.3beta new function)
Does the restart clears the whitelist?
If the white list command is not published with a retain flag, yes. If you did it with a retain flag you should keep the white list. This should be added into the docs ; -)
I tried the restart when it froze again, and it seems to work. BT is again logging sensor values and the freeMem goes upto ~ 50k (from 39k when it freezes).
Any idea what might be causing the BT to stop responding? are there any known ESP32 BLE lib issues?
At least we have a bypass.
For the moment I’m trying to reproduce the issue. I know that other ESP32 users (with other firmwares) complains about BLE stability but to my knowledge nobody found the root cause. But let’s see how my test gateway will last.
I’m also suspecting disparities depending on the boards.
The restart doesn’t always work. Sometimes its freezes and doesn’t log anything and doesn’t accept any commands.
For now I added a smart plug to the m5 charger which resets if the logged temp timestamp is too old.
That is a workaround which I would gladly not have.
I will try another esp32 board instead of the m5 to see if the problems exists also when I have a bit of free time.
My esp32 dev kit is running fine since 9 days. During this duration it has encountered 2 restarts :
but no freeze as it is still reporting BLE sensor values.
I will conduct the same test with the m5stack to see if I get a different behaviour.
What kind/amount of BLE devices do u have in reach of this testing board? I suspect the amount of BLE traffic might have some kind of influence on the freezes. I have ~ 6-7 mijia temp sensors + 6-7 eq3 heating valves
FYI:
my other esp32 board ( ESP32 DEVKIT V1 doit) which is running eq3 controlling code (https://github.com/softypit/esp32_mqtt_eq) just froze BLE functioning, meaning it responds on html web server, but receives no BLE responses from the eq3 valves.
So I’m more and more convinced that some kind of BLE device in my house is causing such traffic amount or some weird message that causes both m5 and devkit esp32 to freeze BLE functioning…
And you restart it by the web server ?
reboot ESP by web server doesn’t seem to do anything…at least BLE is still not working
only after physical reboot it start working again
I don’t have so much sensors but I have a lot of BLE devices passing by my street that are caught by the gateways.
Maybe I could setup a special configuration to have a better biew of what’s going wrong with your environement?
That would be great, what do you need to know?
I need to think on the different values to trigger, in particular I’m thinking on increasing the freemem monitoring and maybe find a way to restart regularly the BLE module.
Similar issue here. Got a couple ESP32s running latest version of OMG. Only one of them has BLE active and it is the unstable one, dying after a few days. In my case it drops off the wifi completely, and I need to power-cycle the ESP.
By latest version you mean v0.9.3.
If it is the case you may try v0.9.4beta, the problems regardings wifi reconnection on esp32 has been solved on it.
Note also that v0.9.4beta add also an optional low power mode. The esp32 restart every BLEinterval. And reconnect to the wifi at each restart.
Right, I’m on 0.93 - but I’ll give the beta a go.
Thanks!
1 Like
Running fine for a week now on 0.94 beta, without optional low power mode
1 Like