I have 3 reed switches connected to a NodeMcu. For ages i had my own arduino code running on it, using MQTT and some mqtt binary_sensors in HA.
I decided to switch this over to EspHome, and got it working.
However, it keeps going unavailable. It drops off wifi, and doesnt respond to ping.
It seems to happen when a state change is triggered, but only after there has been no state change for a while. Eg the doors were all closed overnight, and when i opened one this morning, the state changed and then esphome went offline.
yes, I am noticing this on one of my esp8266 nodemcu I am using D1 for the pir sensor. There are a few others around the home that use the same D1 pin and not drop when it trigger, but it does lose wifi every so often. That is another issue yet to be solve from the community. I will try D5, though I had tried D4 in the pass and it would not connect.
binary_sensor:
- platform: status
name: $name dht Status
- platform: gpio
pin: D1
name: 'motion sr occupancy'
device_class: motion
I have 4 NodeMCU connected to 25+ reed switches throughout the house and noticed that on ESPHome the board(s) goes offline (just like you noted). But I also found that when I click on “Logs” for the offline boards the logs are populated immediately and the reed switches seem to work (status changes in the UI) even when ESPHome is showing the board as offline.
Since the functionality does not seem affected and the reed switches works fine so I’m less concerned about the status on ESPHome page.
But I also found that when I click on “Logs” for the offline boards the logs are populated immediately and the reed switches seem to work (status changes in the UI) even when ESPHome is showing the board as offline.
That is most fortune for you. My case isn’t the same, when it goes offline, the pir and the dht22 connected to it does not register at all until it goes back online and this could be anywhere between few seconds to 1 minutes.
I have changed the pin to D5. I will monitor it for a few days. I did saw it went offline once, but it wasn’t because the pir was triggered.
I have added most in the FAQ, but didn’t try reboot_timeout: 0s. Will add now. This node is the closes to the router (next room) than others that doesn’t seem to have this problem.