Bus is only read sometimes because WiFi is not properly connected
Closed this issue · 10 comments
Listening to the bus is realy unreliable as I often (60% of the time) have no code in the log.
I can see the LED on the board react when picking up the phone or pressing the bell but no entry in the logbook.
I have reinstalled the mqtt-broker (as the device disappeared sometimes and I hoped to fix booth problems) and even installed a different one but no improvement for now for this problem (the esp stopped disappearing).
This is the wiring at the moment with external powersupply and without the parts for button and led.
Could this be the reason for the unreliability?
Gotta move my AP or get a second I guess, distance to the AP is only 5m (with wall between but realy bad wall) but with neighbours thats enough for bad signal it seems.
Very likely. I was going to suggest to check wifi signal.
If the led blinks it means it successfully reads the code. If you can't see a code in your broker it means it could either not connect to wifi or not connect to the broker. Wifi is probably the more realistic cause. In either case it will also block the main loop and if it takes to long the esp8266 might just reboot which means the read code will also be lost.
I have it on my todo list to handle wifi disconnects in a non-blocking way but haven't had time yet.
You can use Wifi Analyzer on Android to check if there might be a better channel for your 2.4 Ghz network to improve the performance without moving the router.
I already moved it, was supposed to be moved anyway, even if only a little but it worked for now, ping atleast has a 98% connectivity quote now, question would be what happens if the esp tries to send a code but cant reach the broker, will it even retry or lose that signal?
Already checked channel, sadly its realy full here, like every channel with 5-6 wifis and the fritzbox has strangely bad wifi (for its price, should have tried another router I guess). If it persists I guess I have to upgrade my wifi earlier than planned.
I already moved it, was supposed to be moved anyway, even if only a little but it worked for now, ping atleast has a 98% connectivity quote now, question would be what happens if the esp tries to send a code but cant reach the broker, will it even retry or lose that signal?
It depends a bit, currently it tries to reconnect. However I recently found out that you are not supposed to block the main loop for more than 6s. So it would probably just restart if it can't connect within 4s.
We could actually see if it restarts. Go into devices in Homeassistant, go to Doorman and under diagnostics check if the Restart counter increases over time even if you don't restart it on purpose.
If it looks like this it probably looses connection to WiFi frequently and restarts:
Already checked channel, sadly its realy full here, like every channel with 5-6 wifis and the fritzbox has strangely bad wifi (for its price, should have tried another router I guess). If it persists I guess I have to upgrade my wifi earlier than planned.
An upgrade probably won't help much as you are still limited to 2.4Ghz.
You could check if you can configure something for Fritzbox:
- Disable channel hopping if enabled and set a fixed channel
- Set bandwidth to 20Mhz instead of 40Mhz if possible (lower throughput but less cross talk)\
- Force 5Ghz wifi on your other devices where possible
@NonProgrammerCharacter would you mind trying #9?
I rewrote the WiFi and MQTT connect functions to be non-blocking for the main loop.
This might increase performance for you and should also reduce loss of codes.
I have uploaded it now to the esp and it atleast didn´t break it.
I dont know if I will see an improvement as it did not restart since moving the router and it was kinda complicated to move so I realy dont want to move it back only for testing this.
With upgrading I meant getting a mesh repeater or trying D-LAN-AP, have to do it anyway propably as I have some bandwith problems in some rooms which didn´t bother me enough to upgrade it.
I will inform you if I see the restart counter increasing (without me killing the power).
But this patch seems to have fixxed another problem I stumbled upon which im not sure realy was one.
When picking up the phone multiple times in a row the led on the esp seemed to stop reacting and stayed on, after multiple seconds it would shut off and start working again. I dont know if that was a restart as I did not know about the counter and dont know the exact time I did it last time.
I could not reproduce the "stop reacting" but I can reproduce the LED staying on and now it still blinks when reading the bus.
Not a huge problem but maybe at the end of the loop shut the led off.
@NonProgrammerCharacter That's not a bug, it's a feature. When you lift the handset 3 times with less than 2 seconds time inbetween, it will switch Party mode on (sends buzzer signal when somebody rings at the downstairs door). To show that party mode is on the led signal is inverted. On esp32 with rgb led I switch to a different color
It's the same as setting party mode to on in homeassistant.
Maybe it would be more reasonable to use a button for this :D
I think I will merge the wifi handling anyway as the code is a bit cleaner and also the configuration web page seems to load faster.
Ahh, I missed that in the README.
Well then I dont know why it didn´t work before, maybe it didn´t like not having any codes configured but getting switched to party mode.
Button I wouldn´t say is needed, this system works fine, maybe give the option to switch it to a different code (a more intuitive way than changing the "Handset Liftup Code" to a different one, I have a button to switch on the lights on the staircase, I think it would be a better choice to use that button (if possible) instead of the handset.
LED, well I guess we still need that one output if someone want an LED for partymode, I most likely wont use it.
I had some questions regarding the pattern-codes, should I open a new issue for that? There isnt realy much written in the README and the description on the config page (directly on the esp) makes it even more complicated.
Open a new issue please. I haven't written much about it because currently it's just hardcoded and I was not motivated enough to find an intuitive way to configure or record a pattern.
For the led: I currently just use the led on the controller itself. Party mode on = led is on. On esp32 with rgb led it has different colors.
I'll close this issue as reading is currently fine after stabilizing wifi.