Most of our current sensors transmit to HA based on ESPHome, which means that HA must know the address of ESPHome. There are a number of reasons why this might be the case, but the most basic one is that the HA is unable to obtain the presence of the sensor.
- Typically, as long as they are on the same LAN, after the HA binds the devices, they will carry on a long-lasting relationship with each other. This includes a discovery protocol where SCREEK sensors (standard ESPHome devices) broadcast their presence on the LAN, and if used on a Mac (dns-sd -B _esphomelib._tcp) you can see which esphome devices are currently present. What can go wrong at this stage is that if the router (some unifi devices had been fed back) disables services such as mdns (usually for privacy) then HA will not be able to auto-discover the sensor.
- Another scenario could be that the sensor is in a subnet such as the current network and HA can't communicate with it directly, but it can be accessed using an IP such as the sensor to establish a connection. In this case, if the IP is stable unchanged, but the default sensor is a DHCP auto-assigned IP, if the router is rebooted, or the IP is reassigned for some other reason, the HA will lose the connection to the sensor. For sensors and HA on different network segments, be sure to use the router to fix the IP of ESPHome.
- When an invalid attribute occurs, there are two possible causes (HA cannot establish communication with the sensor, sensor cannot connect to the wireless router).
In order to investigate such a situation, obtaining the IP of the sensor and pinging it, or visiting its web page, can determine that the sensor is working fine and is simply out of contact with the HA, which allows you to go on to rule out a possible IP change, caused by a restricted auto-discovery service on the LAN.
Conclusion:
- The key to HA auto-discovery of sensors is to have a discovery service working on the LAN.