Hi Dave,
Could you try this branch please, it resets the ESP after several connection lost:
https://github.com/1technophile/OpenMQTTGateway/tree/wifi-fritzbox
I will give it a try and report back.
Here is a short update:
I flashed one of my RFbridges with the new branch and left the other as it was. I had no disconnects now for about 1,5 days, but I’m not sure if changing the WiFi (to “bgn”), the updtate of the developtment-branch or the fritzbox-branch made it better. Maybe the WiFi is just more stable now, I can’t tell for sure.
What i had 1,5 days ago was 2 brief disconnects (one about 30 sec the other 1,5 min) with the one flashed with the fritzbox-branch. At about the same the other one (with the dev-branch) was connecting and disconnecting over the duration of about 3 hours, but stayed online after that. Even after restarting the WiFi on my FRITZ!Powerline-adapter the RFbridge came online after about 1,5 minutes.
Edit: I just realized, it was the other way round. The RFbridge flashed with the fritzbox-branch was the one that went online and offline for a duration of about 3 hours.
If I got it well, the one with v0.9.5 is working correctly with the wifi configured as bgn?
And the one coming from the fritzbox branch not.
Sorry for the confusion. The initial issue (that I had to reflash) is gone for both of them. My WiFi is now configured as bgn, what may have solved this. Until now I had no issue with either one of them going offline and staying offline. The last time they went offline was over 2 days ago. The on with v0.9.5 came back after a minute or so. The one with the fritzbox branch came online, stayed online for some time, went offline, came back,… This process repeated for about 3 hours, but in the end it stayed online. Since then I had no issues.
This is the grafana-chart for the time of that process:
I can try to put the fritzbox version on both of them, or switch places (the v0.9.5 connects to the powerline-adapter the other one to the fritzbox), but I think the changes in the fritzbox branch are working and are not causing any other issues (at least for me).
At final there is no added value with the Fritzbox branch as the v0.9.5 is behaving normally with the wifi bgn?
I wouldn’t say that. Although it looks like it is working out for me with just v0.9.5 for now, it doesn’t mean it works for others as well. Also I think it’s not a bad idea to reset the ESP if there are repeating errors. I honestly would prefere, that this code stays in there. Perhaps you can add an option to activate/deactivate it.
Indeed I could add it as an option (deactivated by default)
Sorry for reactivating this thread, but my problems with fritz!box Wifi are still present.
I tried to get my AVATTO working today, but get no connection to my Wifi, it was lost nearly two month ago (not time at all :().
after power cycle I get this entry in the wlan log.
So I opened a mobile hotspot on my Windows 10 machine and the AVATTO was immediately connected.
This opened the way to do some ota updates without open the case.
1st. I merged the fritz branch into the 0.9.5 release but got no reconnect to the Fritz Box Wifi.
2nd I changed uint8_t wifiProtocol = 3; (WIFI_PHY_MODE_11N) in user_config.h. The AVATTO connected fine to the Fritz!Box Wifi. So the wifi-fritzbox brunch seems not to retry with 11g if it changed to lower connection rate.
1 Like
Thanks for the feedback, I will review the algorithm and propose a new branch for test
I have added protocol BGN attempt to the reconnection mechanism and also now it browse every 100 reconnections the list of protocols, if you have some time, you can test it below:
https://github.com/1technophile/OpenMQTTGateway/tree/recursive-protocol-change
I flashed the new branch, thanks for your lightning fast work. Will report 
1 Like
Great, mine is also rock stable