search

rospogrigio / airbnk_mqtt

MQTT control of Airbnk locks.
GNU General Public License v3.0
27 stars 6 forks source link

Stability improvements #1

Open rospogrigio opened 2 years ago

rospogrigio commented 2 years ago

Let's use this post to discuss ways to improve the stability of the connection: use a different firmware, rebuild tasmota, etc.

formatBCE commented 2 years ago

I tried it but it still shows the same behavior 😢 But I updated it using OTA and it kept the configuration so no need to set it up again, good job 👍 Any other ideas for the FFF3 issue?

That's really a bummer. I can try increasing delay for reading FFF3, or make it adjustable. Or make more retries. I guess, different locks write FFF3 with different delays. Could you maybe check approximately, how long does it take for your lock to change that characteristic after operation?

rospogrigio commented 2 years ago

It's almost instantaneous (less than 1s for sure), I operated it and read the data on nRF Connect as soon as it started rotating. So there's something weird going on here...

rospogrigio commented 2 years ago

Are you sure of your code? Or maybe there is some sort of data caching?

formatBCE commented 2 years ago

Are you sure of your code? Or maybe there is some sort of data caching?

There's definitely no caching. I have everything logged in console, and was checking logs precisely...

rospogrigio commented 2 years ago

I wonder whether there is some sort of bug. I always get the same value in the lockstatus: AA00040312001500000000000000000000000000. This never changes, however in nRF Connect I get very different values. I don't know if this might be of any help...

rospogrigio commented 2 years ago

OK now for a couple of times I received the correct data, but now I ended back receiving the fixed string...

formatBCE commented 2 years ago

OK now for a couple of times I received the correct data, but now I ended back receiving the fixed string...

So the problem is in delay, most probably. As I understand, your lock is more unstable with BT, than mine - e.g. I have advertisement found on almost each scan, and most of the times it happens really fast.

Can you check, how fast FFF3 is changing after you manually operated the lock? Gateway is waiting for meaningful data for 1 second in whole. That's perfectly enough for M300. But might be not enough for your lock.

rospogrigio commented 2 years ago

As I wrote earlier, it is almost instantaneous... And this is why I believe it's not a matter of delays. This is really really weird....

formatBCE commented 2 years ago

Yes, it's really strange... Hard to debug without actual device in hands. If you want me to add FFF3 reading, I will do. It'll take some time to write and debug though.

formatBCE commented 2 years ago

Could it be because of the fact, that I'm writing and reading in one client connection? It's perfectly fine with nRF for sure, I'm just trying to guess.

Sylvania2 commented 2 years ago

Hi

Today my Lock was unavailable when i got home. Restarted it no luck..

MQTTLens shows maybe 20 messages:

{"ip":"192.168.1.xxx","hostname":"airbnk_lock","scan_dur":10,"wait_dur":0,"wifi_restart_count":2}

lock is unavailable untill message (serial removed): {"mac":"xx:xx:xx:xx:xx:xx","rssi":-94,"data":"baba170f01010800000000000000000003790000002b5a000000"}

Is this the same issue ? Lock is a M521.

Best regards

rospogrigio commented 2 years ago

I don't know @formatBCE, I was thinking that the fixed string I was receiving was the response of the lock for the first of the 2 packets but I tried sending the commands with nRF Connect and FFF3 never shows those values. I really don't have a clue. Maybe before implementing the FFF3 request it could be worth trying to further extend the delay and number of retries but I'm quite not confident it will take us anywhere. Let me know your thoughts, bye

formatBCE commented 2 years ago

@Sylvania2 No, this is integration behavior: if there's no advertisement messages received for 30 seconds, lock becomes unavailable. After adv received (second line in your message) - lock should become available. To improve stability, try to move gateway (ESP32) closer to the lock. Your RSSI is pretty low (-94). I have values approximately -65 to -80, gateway is in 3 meters from lock, behind the drywall. Also you may try turn gateway in different directions to expose ESP32 antenna better to the lock. During this manipulation, you can check adv messages in MQTT explorer to see RSSI. Unfortunately, ESP32 lacks signal strength, it's well-known issue. I guess you might buy some chip with external antenna, there's plenty of variations :)

Issue we're trying to fix now is status reporting after operating the lock. Nothing to do with connection itself.

formatBCE commented 2 years ago

@rospogrigio give me couple minutes, i will post bin file with increased delay.

formatBCE commented 2 years ago

@rospogrigio check out this firmware: https://github.com/formatBCE/Airbnk-MQTTOpenGateway/blob/main/firmware_1.0.3_incr_delay.bin I made delay 1 sec between retries, and increased retries count to 10

rospogrigio commented 2 years ago

Tried several operations, worked 100% of the times!! Also very responsive. I don't know if you want to fine-tune the parameters now... Great job!

formatBCE commented 2 years ago

@rospogrigio I'm glad we sorted it out. I will decrease delay to 1/2 sec, leaving retries 10. Will be faster I hope, and should be enough for getting correct data. (Before it was 1/5 sec and 5 retries)

rospogrigio commented 2 years ago

Looks good, maybe change the version to 1.0.4 too 😉

Sylvania2 commented 2 years ago

@formatBCE i moved the gateway closer to the lock + OTA to last update. Response is much faster. But after a few lock open/close the gateway stop working ( no webpage, no wifi ? ), Maybe the TTGO board was a bad choice will try another board :-) Best regards

formatBCE commented 2 years ago

@Sylvania2 Hmm, it never happened to me. I use D1 mini. I believe the code is not very optimized, unfortunately. It's my first c++ program :(

formatBCE commented 2 years ago

Looks good, maybe change the version to 1.0.4 too 😉

Done. Posted to repo.

rospogrigio commented 2 years ago

It works perfectly. I have published a new release that introduces the parsing of the FFF3 data (with data type checking, taken from the app source code) and now the status update is very responsive. The data check makes it also robust, so if we happen to receive the wrong data it will just update the status when it receives the next advert message. I think we nailed it, I'm super happy 😃 , please test it also on your device and let me know how it goes. Thank you @formatBCE !

formatBCE commented 2 years ago

It works perfectly. I have published a new release that introduces the parsing of the FFF3 data (with data type checking, taken from the app source code) and now the status update is very responsive. The data check makes it also robust, so if we happen to receive the wrong data it will just update the status when it receives the next advert message. I think we nailed it, I'm super happy 😃 , please test it also on your device and let me know how it goes. Thank you @formatBCE !

That's fantastic! For me, previous version was already strong enough for everyday usage. Now, I think, we can call it "stable" :)

The only thing I can think of is: if sending is happening on gateway, all other commands will be dropped. Is there trouble for integration with this behavior? Also, while sending and checking FFF3, gateway cannot scan, so spamming button in HA could potentially lead to lock unavailability in interface. Can we prevent it somehow?

Anyway. The work, that was done by you, was so great, that it inspired me for this gateway creation. Thank you. Good job.

rospogrigio commented 2 years ago

I'm not sure I have understood clearly your 2 points, especially the first, can you explain better? For the second, I believe we can just ignore new operating commands until the one being executed has ended.

rospogrigio commented 2 years ago

@formatBCE Maybe I talked too soon: today, all of a sudden the ESP stopped communicating. When I got back home I finally realized it had lost its configuration, so it was exposing its Wifi AP. I re-configured it and now it's all back to normal but I didn't quite like this. I'll keep testing it and will tell you if this happens again, I don't know if you can explain what might have happened in the meantime...

Sylvania2 commented 2 years ago

Same issue today, got home from work and lock/gateway became unavailable after a unlock command. Gateway has no wifi connection to router, after a power cycle it runs again, no setup needed. Gateway is now a ESP32-CAM board with external antenna, signal is now -55dB / -62dB.

Sylvania2 commented 2 years ago

Made a stress test.. Connection issue begins arround: [16:47:45]Scanning... Log from gateway:

[16:47:33]Got command [16:47:33]{"command1": "FF00AA101A037943DC7095E75F39824EF910AA52", "command2": "FF0122AE059001434F9090485400000000000000", "sign": 1639669651}SH0 [16:47:33]Sending to Name: , Address: xx:xx:xx:xx:xx:xx, manufacturer data: baba170f010108XXXXXXXXXXXXXX00000373000000656a000000 [16:47:33]Sending try 1 [16:47:33]E NimBLEClient: "Client busy, connected to xx:xx:xx:xx:xx:xx, id=0" [16:47:33]Failed to connect to lock. [16:47:33]Scanning done.Telemetry sent [16:47:34]Sending try 2 [16:47:35]lld_pdu_get_tx_flush_nb HCI packet count mismatch (1, 2) [16:47:35]E NimBLEClient: "Connection failed; status=574 " [16:47:35]Failed to connect to lock. [16:47:36]Sending try 3 [16:47:38]Connected to lock. [16:47:38]Got service. [16:47:38]Got characteristic, writing. [16:47:39]Write successful, reading status. [16:47:39]Read status successful. [16:47:39]AA00040000060600000000000000000000000000 [16:47:40]Read status successful. [16:47:40]AA00040000060600000000000000000000000000 [16:47:40]Read status successful. [16:47:40]AA00040000060600000000000000000000000000 [16:47:41]Read status successful. [16:47:41]AA00040000060600000000000000000000000000 [16:47:42]Read status successful. [16:47:42]AA00040000060600000000000000000000000000 [16:47:42]Read status successful. [16:47:42]AA00040000060600000000000000000000000000 [16:47:43]Read status successful. [16:47:43]AA00040000060600000000000000000000000000 [16:47:44]Read status successful. [16:47:44]AA00040000060600000000000000000000000000 [16:47:44]Read status successful. [16:47:44]AA00040000060600000000000000000000000000 [16:47:45]Read status successful. [16:47:45]AA00040000060600000000000000000000000000 [16:47:45]Scanning...
[16:47:56]Scanning done.Error sending telemetry [16:47:56]Scanning...
[16:48:07]Scanning done.Error sending telemetry [16:48:07]Scanning...
[16:48:18]Error sending advertisement message.airbnk_lock/adv [16:48:18]Message: {"mac":"xx:xx:xx:xx:xx:xx","rssi":-62,"data":"baba170f010108XXXXXXXXXXXXXX00000373000000665a000000"} [16:48:19]Scanning done.Error sending telemetry [16:48:19]Scanning...
[16:48:30]Scanning done.Error sending telemetry [16:48:30]Scanning...
[16:48:40]Error sending advertisement message.airbnk_lock/adv [16:48:40]Message: {"mac":"xx:xx:xx:xx:xx:xx","rssi":-63,"data":"baba170f010108XXXXXXXXXXXXXX00000373000000665a000000"} [16:48:41]Scanning done.Error sending telemetry [16:48:41]Scanning...
[16:48:42]Error sending advertisement message.airbnk_lock/adv [16:48:42]Message: {"mac":"xx:xx:xx:xx:xx:xx","rssi":-64,"data":"baba170f010108XXXXXXXXXXXXXX00000373000000665a000000"} [16:48:52]Scanning done.Error sending telemetry [16:48:52]Scanning...
[16:49:03]Scanning done.Error sending telemetry [16:49:03]Scanning...
[16:49:14]Scanning done.Error sending telemetry [16:49:14]Scanning...
[16:49:25]Scanning done.Error sending telemetry [16:49:25]Scanning...
[16:49:36]Scanning done.Error sending telemetry [16:49:36]Scanning...
[16:49:37]Error sending advertisement message.airbnk_lock/adv [16:49:38]Message: {"mac":"xx:xx:xx:xx:xx:xx","rssi":-64,"data":"baba170f010108XXXXXXXXXXXXXX00000373000000665a000000"} [16:49:47]Scanning done.Error sending telemetry [16:49:47]Scanning...
[16:49:58]Scanning done.Error sending telemetry [16:49:58]Scanning...
[16:50:02]Error sending advertisement message.airbnk_lock/adv [16:50:02]Message: {"mac":"xx:xx:xx:xx:xx:xx","rssi":-64,"data":"baba170f010108XXXXXXXXXXXXXX00000373000000665a000000"} [16:50:09]Scanning done.Error sending telemetry [16:50:09]Scanning...

Is this your issue with Nrf vs Log ? If lock is not mounted it will turn for a while and log messages looks like this AA00040312001500000000000000000000000000. If lock is stopped while rotating, last message looks like this AA0011020400F00101080000006E036D4A000028.

LOG2: [17:10:00]{"command1": "FF00AA101A03B2B90E7211458E4159F8075CFBA2", "command2": "FF012270AE71AEAEAE7AF51EAC00000000000000", "sign": 1639671001}SH0 [17:10:01]Sending to Name: , Address: xx:xx:xx:xx:xx:xx, manufacturer data: baba170f010108xxxxxxxxxxxxxx0000036d0000006d5a000000 [17:10:01]Sending try 1 [17:10:01]Scanning done.Telemetry sent [17:10:01]Connected to lock. [17:10:01]Got service. [17:10:01]Got characteristic, writing. [17:10:01]Write successful, reading status. [17:10:01]Read status successful. [17:10:01]AA00040312001500000000000000000000000000 [17:10:02]Read status successful. [17:10:02]AA00040312001500000000000000000000000000 [17:10:03]Read status successful. [17:10:03]AA00040312001500000000000000000000000000 [17:10:03]Read status successful. [17:10:03]AA0011020400F00101080000006E036D4A000028 [17:10:03]Command result sent [17:10:03]Scanning...
[17:10:04]Lock advertisement sent. [17:10:04]Scanning done.Telemetry sent [17:10:04]Scanning...
[17:10:14]Scanning done.Telemetry sent [17:10:14]Scanning...
[17:10:18]Lock advertisement sent. [17:10:18]Scanning done.Telemetry sent [17:10:18]Scanning...

formatBCE commented 2 years ago

@formatBCE Maybe I talked too soon: today, all of a sudden the ESP stopped communicating. When I got back home I finally realized it had lost its configuration, so it was exposing its Wifi AP. I re-configured it and now it's all back to normal but I didn't quite like this. I'll keep testing it and will tell you if this happens again, I don't know if you can explain what might have happened in the meantime...

This may happen, if gateway lost connection to WiFi. Behavior is following:

If you can think on better approach to this, let me know please.

formatBCE commented 2 years ago

Same issue today, got home from work and lock/gateway became unavailable after a unlock command. Gateway has no wifi connection to router, after a power cycle it runs again, no setup needed. Gateway is now a ESP32-CAM board with external antenna, signal is now -55dB / -62dB.

This seems much trickier. This means gateway completely frozen. Can you tell, how much RAM and flash space this device has? It differs from chip to chip. Maybe, problem is there...

formatBCE commented 2 years ago

@Sylvania2 second log is ok. First one - I see several problems. First, MQTT started to return errors on sending messages this lines:

[16:48:42]Error sending advertisement [16:48:52]Scanning done.Error sending telemetry

They're indicating, that connection to MQTT broker established, but it returns errors on message sending.

Also, status response with 00000000 in the end are bad, that's why it tries to read that again. It may happen on jammed lock etc. After 10 tries it gives up and sends to MQTT that "bad" status string.

And finally, mixed scan and command sending around 16:47:33 is the worst one. That means, that scanning mechanism is incorrectly providing "isScanning" data. Ideally, we don't want to operate lock, while scan is ongoing - they both use BLE stack, and it might lead to radio stack freezing. I guess this is what happened here all-in-all. I will try to make manual locks on this behaviour, but in general this is weird. Moreover, never happened to me during tests or normal work. Also, I guess, I will introduce reboot on MQTT sending failures. It might help at least from disastrous troubles.

Sylvania2 commented 2 years ago

Reboot on MQTT failure would be great! Also failure seems to occure while operating the lock from home assistant so yes possible radio stack issue. Lock is not mounted at the moment, didnt want bad rssi while testing, so it rotates a few seconds.. This is it an unlock where lock isnt stopped or jammed and mqtt keeps working:

[17:47:57]Lock advertisement sent. [17:47:57]Scanning done.Telemetry sent [17:47:57]Scanning...
[17:48:06]Lock advertisement sent. [17:48:06]Scanning done.Telemetry sent [17:48:06]Scanning...
[17:48:15]Lock advertisement sent. [17:48:15]Scanning done.Telemetry sent [17:48:15]Scanning...
[17:48:23]Got command [17:48:23]{"command1": "FF00AA101A03AE6DB868844F91E9581AB1A75E95", "command2": "FF0188BFCEEACE68E7EA67FFB400000000000000", "sign": 1639673303} 81@& [17:48:23]Sending to Name: , Address: xx:xx:xx:xx:xx:xx, manufacturer data: baba170f010108xxxxxxxxxxxxxx000003790000006e4a000000 [17:48:23]Sending try 1 [17:48:23]Scanning done.Telemetry sent [17:48:24]lld_pdu_get_tx_flush_nb HCI packet count mismatch (1, 2) [17:48:24]E NimBLEClient: "Connection failed; status=574 " [17:48:24]Failed to connect to lock. [17:48:25]Sending try 2 [17:48:25]Connected to lock. [17:48:25]Got service. [17:48:25]Got characteristic, writing. [17:48:25]Write successful, reading status. [17:48:26]Read status successful. [17:48:26]AA00040311001400000000000000000000000000 [17:48:26]Read status successful. [17:48:26]AA00040311001400000000000000000000000000 [17:48:27]Read status successful. [17:48:27]AA00040311001400000000000000000000000000 [17:48:28]Read status successful. [17:48:28]AA00040311001400000000000000000000000000 [17:48:28]Read status successful. [17:48:28]AA00040311001400000000000000000000000000 [17:48:29]Read status successful. [17:48:29]AA00040311001400000000000000000000000000 [17:48:29]Read status successful. [17:48:29]AA00040311001400000000000000000000000000 [17:48:30]Read status successful. [17:48:30]AA00040311001400000000000000000000000000 [17:48:31]Read status successful. [17:48:31]AA00040311001400000000000000000000000000 [17:48:31]Read status successful. [17:48:31]AA00040311001400000000000000000000000000 [17:48:31]Command result sent [17:48:31]Scanning...

Simulating a mounted lock ( stopping its rotation ):

[17:56:45]AA00040311001400000000000000000000000000 [17:56:45]Read status successful. [17:56:45]AA00040311001400000000000000000000000000 [17:56:46]Read status successful. [17:56:46]AA00040311001400000000000000000000000000 [17:56:47]Read status successful. [17:56:47]AA00040311001400000000000000000000000000 [17:56:47]Read status successful. [17:56:47]AA00040311001400000000000000000000000000 [17:56:48]Read status successful. [17:56:48]AA0011020400F00101080000007103795A000047

Best regards

formatBCE commented 2 years ago

I understand. Well, we cannot wait for unmounted lock to stop rotate - it's too long. I tried to debug like this at some point, but found this way very unstable. Very, very unstable. :) I could introduce more retries for reading status characteristic (FFF3) - we were playing with it. If it's crucial for you, I'll do it. Anyway, this situation, when operation sending is starting while scanning is ongoing, is bad. I think, maybe it's possible to stop scan instead of waiting it ends. Will try it.

rospogrigio commented 2 years ago

This may happen, if gateway lost connection to WiFi. Behavior is following:

  • if connection lost, it tries to reconnect 10 times
  • if that failed, device reboots and tries from scratch (again 10 times)
  • if after 10 reboots it still doesn't have connection, it resets configuration, assuming that WiFi is lost, and we need to reconfigure.

If you can think on better approach to this, let me know please.

I see... but I don't like this approach. My gateway is behind a remote-controllable switch, so if for some reasons it can no longer connect to the Wifi I can still restart it remotely, but if in the meantime it has reset the configuration... it's gone for good. But I also understand we need to think of some way to be able to reset the configuration if the Wifi network is no longer available... but currently nothing comes to my mind, do you have any suggestion or any idea?

Sylvania2 commented 2 years ago

@rospogrigio If gateway can't send messages to mqtt server it should restart WiFi?

rospogrigio commented 2 years ago

@rospogrigio If gateway can't send messages to mqtt server it should restart WiFi?

I frankly don't know... it depends whether the situation is recoverable or not. I'd restart it only if for some reason the situation is not recoverable and it needs to reboot. But I don't know if there's a way to assess the situation and distinguish a temporary glitch from a harder issue.

formatBCE commented 2 years ago

@rospogrigio If gateway can't send messages to mqtt server it should restart WiFi?

I frankly don't know... it depends whether the situation is recoverable or not. I'd restart it only if for some reason the situation is not recoverable and it needs to reboot. But I don't know if there's a way to assess the situation and distinguish a temporary glitch from a harder issue.

It is actually reboots on disconnect from WiFi, or on MQTT broker unavailability. Reboot is fine. But on several retries to reconnect to WiFi, board should do something in order to provide user with interface. The only way to do it is to reset and start from scratch. I can think on prefilling old data on configuration page instead of erasing.

formatBCE commented 2 years ago

Pushed new version 1.0.5. Behaviour on resetting is the same, but i raised reboots counter (it was 5, now it's 10). Also introduced mqtt reconnect on error sending message. Try it and tell me how it goes.

rospogrigio commented 2 years ago

It is actually reboots on disconnect from WiFi, or on MQTT broker unavailability. Reboot is fine. But on several retries to reconnect to WiFi, board should do something in order to provide user with interface. The only way to do it is to reset and start from scratch. I can think on prefilling old data on configuration page instead of erasing.

Are you telling me that if I switch off my router, after a certain amount of time the gateway will reset to default? I understand the reason behind it but I still find it very unhandy, I still believe that the reset to default should be intentional. Maybe we can find a way to force it via USB? Or have 2 FW versions, one that resets the configuration and one that does not? Or again: my ESP has 2 buttons (one called Boot and one called Reset)... how about resetting the configuration after a long press of Reset? I don't even know if they are used, with your firmware... Edit: I don't even know if all the ESP boards have these buttons or only some... Just my thoughts, let me know what you think about these... I'll try the 1.0.5 in the meantime 😉

formatBCE commented 2 years ago

It is actually reboots on disconnect from WiFi, or on MQTT broker unavailability. Reboot is fine. But on several retries to reconnect to WiFi, board should do something in order to provide user with interface. The only way to do it is to reset and start from scratch. I can think on prefilling old data on configuration page instead of erasing.

Are you telling me that if I switch off my router, after a certain amount of time the gateway will reset to default? I understand the reason behind it but I still find it very unhandy, I still believe that the reset to default should be intentional. Maybe we can find a way to force it via USB? Or have 2 FW versions, one that resets the configuration and one that does not? Or again: my ESP has 2 buttons (one called Boot and one called Reset)... how about resetting the configuration after a long press of Reset? I don't even know if they are used, with your firmware... Just my thoughts, let me know what you think about these... I'll try the 1.0.5 in the meantime 😉

That buttons work to initiate flashing via serial. They don't work for already running firmware, only affect USB to Serial connection. Basically, there's two ways to reset configuration. First is to reset it from code itself:

rospogrigio commented 2 years ago

How does Tasmota work? I'm pretty sure it never auto-resets so I'd stick to a similar behavior. And are you really sure you have no access to the status of those buttons? I was kind of sure you could have it ... And how about shorting a couple of pins to trigger the reset?

formatBCE commented 2 years ago

How does Tasmota work? I'm pretty sure it never auto-resets so I'd stick to a similar behavior. And are you really sure you have no access to the status of those buttons? I was kind of sure you could have it ... And how about shorting a couple of pins to trigger the reset?

I guess I can try it :)

formatBCE commented 2 years ago

Ok, reset won't work: https://forum.micropython.org/viewtopic.php?t=7773

I could introduce some pin break. But maybe it's easier just to erase and reflash, than keep the button connected, or unintentionally connect wrong pins and burn down the chip.

formatBCE commented 2 years ago

I removed auto-reset in 1.0.6

rospogrigio commented 2 years ago

I removed auto-reset in 1.0.6

I flashed it but I no longer receive advert messages, only telemetry... 😢

formatBCE commented 2 years ago

I removed auto-reset in 1.0.6

I flashed it but I no longer receive advert messages, only telemetry... 😢

Umm It works perfectly for me, updated with OTA.

rospogrigio commented 2 years ago

It works now... don't know, maybe a glitch. Will keep testing...

Sylvania2 commented 2 years ago

I will test auto-reset in 1.0.5 ... Why not look at reset reason ? A gateway that enters wifi setup if router is rebootet is useless, but some kind of restart is needed unstill stability issues is found.

Best regards

formatBCE commented 2 years ago

I will test auto-reset in 1.0.5 ... Why not look at reset reason ? A gateway that enters wifi setup if router is rebootet is useless, but some kind of restart is needed unstill stability issues is found.

Best regards

Well, wiping flash always helps to start from scratch. :) That reset button is really easy to misclick. I wouldn't rely on it. I guess best way is to introduce pin shortening...

Sylvania2 commented 2 years ago

Hi

@formatBCE, 5days now, i have seen a few "unavailable" while using the lock, and only once the gateway didn't restart correctly and i had to find a key to get in the house. I don't see any problem with restart when there is a stability issue. If there is no wifi and gateway enters setup mode it should restart after 3min to see if router is up and running again ( think Tasmota is doing it this way ).

reset reason: https://github.com/espressif/arduino-esp32/issues/449

Best regards

formatBCE commented 2 years ago

So guys, gateway is working pretty good for me, reacting almost instantly in my use cases. Shall I add some README info to make it sudo-official?