Once you have restarted the MQTT server did you wait a few minutes or did you went directly to the web page.
The web page as a timeout of 120s, once these 120s elapsed it should reconnect automaticaly to saved settings.
I actually waited for a few hours as I didn´t immediately realize it hadn’t connected back. After realizing I was not receiving mqtt updates from OMG I restarted it (didn’t check if the ad-hoc wifi was up). A few minutes after restarting it I checked and it had brought up the wifi portal. On accessing the portal and configuring the wifi ssid and password (it had forgotten my wifi, but mqtt parameters were preloaded), all was fine.
Could this be related to me having hardcoded the mqtt parameters (as I rarely change those), but left the Wifi ones to be managed?
If you restarted OMG board and the broker was not started, OMG will automaticaly erase all the settings after several ten of attempts, this is to enable user that entered bad credentials to be able to set them again.
If OMG stay ON and the wifi or the broker is down it should reconnect automaticaly when all is going back to normal.
I don’t think so
I only restarted hours after the mqtt broker was up - unfortunately didn’t think to check if the wifi portal was showing at the time already before that restart, so can’t be more precise.
I’ll keep an eye, but I do recall I’ve had to reconfigure this particular one a couple times on the portal - not sure if it has always coincided with issues on the broker or network.
I’ve got another OMG on 0.93 and same ESP32 setup (but without BT ) which was fine all through this same period, and required no restart or reconfiguration and lived straight through the broker downtime
Interesting, thanks for the info.
What I can do to avoid the popup of wifimanager portal is to store the fact that the gateway connected once on the memory. If it has been the case the portal will never popup and we will never reset the board.
It will prevent user for having a way to reset the board but it will enable to avoid this kind of issues.
Sounds great! We can always bring up the portal by holding the button on startup if needed, I believe.
Anyway, maybe you could add it as a config option, so we can either keep it as currently (for people who move the board from place to place often) or keep it fixed to a network once it has connected once.
Also, have you considered adding a config for a secondary wifi profile as a backup in case the first is down? The portal on tasmota has this and it’s quite useful.
1 Like
I will do it like that.
Indeed it can be a good idea.
If you don’t mind I’m going to mark this topic as resolved and we can continue discussing about these separate requests on a new one.
Sure - I did go off topic from the original issue anyway, unless a momentary glitch to the broker connectivity can actually trigger the original “BLE dying every x days”. In any case I’ll do some tests. Thanks!
Not sure if the WiFi is completely fixed in 94 beta. Tried with two esp32, one of them an original dev board 3 to see if it’s the clone esp32 that has the issue. Both, original and the clone stops working after a couple of days with the red and blue led both lid up.
Tried to disable the WiFi manager as I don’t wanted it to go back to that.
Seems like the default action it can’t be soft reset, just by pulling the plug.
Could you precise when you picked up the development branch please?
The latest 0.9.4 beta in the GitHub release. Tried the beta cause of the home assistant class issue fix.
Might be an issue with the beta?
ok, when you get the 2 led on the wifi manager portal was available?
No, I don’t think so because I set the WiFi credentials manually in the code so I assumed it would disable the captive portal.
I can double check next time if it delete the credentials even if they are hard set.
Is it possible to make the esp do a hard reboot if it can’t connect instead of going into the captive portal? Now I let home assistant reboot it every 6 hours via mqtt, but that’s not enough
You’ve uploaded the binaries or you build it yourself?
I built it myself in vscode. Only changes was enable ble, Home assistant discovery, mqtt and WiFi credentials
ok, could you download the latest code from the dev branch, build it and upload it, I have removed the autoreset on it.
We would see if it helps.
Added to that it contains also an important refactoring of the BLE gateway.
I will build thev dev branch tomorrow and try and report back
1 Like
Before you test it I would like to deactivate the TRIGGER_PIN, please wait for my go.
Lets see in the long run, but still a lot of wifi issues. The one with the official v4 dev board have a lot of reconnects, and when the software do a cpu reset it wont reconnect it seems, but with the button reset its a bit more luck
I see `abort() was called at PC 0x401b31cb on core 1
Backtrace: 0x40092408:0x3ffd0560 0x40092639:0x3ffd0580 0x401b31cb:0x3ffd05a0 0x401b3212:0x3ffd05c0 0x401b32bf:0x3ffd05e0 0x401b3342:0x3ffd0600 0x401b3359:0x3ffd0620 0x401cd7c3:0x3ffd0640 0x400dd798:0x3ffd0680 0x400d5b5e:0x3ffd06a0 0x400df5c1:0x3ffd06c0 0x4008eb51:0x3ffd06e0`
after it search for BT devices though and it seems to make it impossible to OTA as it crashes before the OTA reach 50%
Here is a snippet of the serial log https://pastebin.com/VSqfKAhW