@paddy0174
- first question about env, HASSIO VM image
Home Assistant 2023.7.3
Supervisor 2023.07.1
Operating System 10.3
Frontend 20230705.1 - latest
- Shellys communicate via integration. I have multiple vlans avahi handling mdns (but this is only for HomeKit, because Shelly’s and Home Assistant are all on the same subnet), but even between different vlans everything’s working and tuned to perfection. Any new Shelly or anything else connected to the IOT network is immediately recognised by HA. I just have to add confirm the integration, and in this case add the authentication and everything is correctly setup. No custom firmware or any changes other than periodically updating their firmware when new versions are available.
- Changing the location is irrelevant since I have 1DW2 per each window + front door, so it’s 9 windows and the front door, some are closer to the antenna, some are further from the antenna, direct view to the antenna and not, etc. So even disregarding the H&T device, I consider all locations considered there wouldn’t be another place to put any that would make it differently. Unless I actually glued one to the AP. And for example the DW2 all fail at the same time (prolly in regard that I reload them at the same time too) so it’s hard for me to understand how the WIFI and placement of device would be be a factor.
I have to see how to enable debug logging and do the tests with some more time than … well, when I should be working
I have 30 Shelly devices, of these 11 are giving these problems and what they have in common is being (originally) battery powered devices. The H&T are “no longer” battery devices but their configuration is kind of still built around that principle, I’ll explain a bit further down.
@petro
Allow me to put this to you in another way
Initially and at the first times after I added them to HA, this didn’t happen. This started happening at some point in time I didn’t pay much attention then. I am sorry I honestly have no idea what was the last working of HA Core.
- The devices:
- 10 Shelly DW2 (Door Window sensors)
- 3 Shelly H&T (Humidity & Temperature)
The Shelly DW2 are battery powered and there’s not much you can do about it, the H&T sensors originally came with the battery bottom but I purchased the USB bottoms.
You say shelly integration doesn’t poll, waits for a response from the device. Ok, then if a device doesn’t get back, how long it takes for it to become unresponsive? Because with the H&T I’m accounting a few minutes, and DW2 around a few hours. I only noticed the DW2 because over night they stop responding.
The wake cycle for the H&T is when a value crosses a threshold, either humidity or temperature. If the H&T is on battery, the thresholds that can be selected are further apart than if by usb. (eg, on battery you can only select 1.0 intervals, and usb enables 0.5 intervals). Other than that doesn’t have a preset time interval to report.
The DW2 are battery only but actually last long. They report if the window state changes (open/closed), have luminosity and temperature sensors, which also work by thresholds. No setting to periodically wake and call home.
The devices have the IP statically configured on the device itself & a static mapping in the router.
If I wake any of the devices I get immediate connection with them, they have a stable connection, don’t drop (unless they go idle). I can see the signal strength for any device individually on my antennas management.
I read the issue you shared there, the resolution was:
Solution: If you are running HA in docker and your network is configured as 'bridge' you have to add port 5683 in the container:
Local port 5683; Container port 5683; Type UDP
Now it works for me!
I am not using docker type install. Home Assistant and the devices are on the same subnet. this doesn’t apply to me.
Now I’m going to describe a behaviour with the DW2 sensors that I have tested repeatedly:
Everything is ok the integration is active. You open a window you close the window HA reports accordingly.
You go to sleep, next morning the device is unresponsive. You go to the integration and reload.
It reloads successfully and loads the last recorded values. Did HA contact the device on the reload? Impossible, the device IS asleep. But the integration shows reloaded and reports values. OK.
You open the window. In HA the sensor doesn’t change state. You close the window. HA doesn’t change state. And so on. But not showing unresponsive. Leave the window open.
You manually wake the DW2 sensor (put a pin to it). Access its management interface via http. The state is correctly reported (as open in the case). You go to HA. Nothing.
While the DW2 is awake, you reload the HA integration. State is now correctly reported in HA. The DW2 goes idle. You close the window. HA reports correctly. You open the window. HA reports correctly. Until the next “unresponsive” event, where you have two options, either you simply reload all the integrations alone and it clears the errors, but if you really want it functional you have to wake every device before the reload event.