I’m not sure there is a “solution” in that issue, but the issue contains alot of information about how shelly works with HA.
As an aside, if your shelly devices can output to MQTT, that would be a suitable solution in the interim. You can have the devices output to MQTT, and those will persist regardless how long it takes for a message to appear.
Cheers @petro let me just ask this if you can answer
You mention “you can have the devices output to MQTT, and those will persist regardless (…)”
When I reload the Shelly integrations, it goes from unresponsive to previous recorded values. Aren’t them already persisting somewhere?
I will look into MQTT. My thought about running a new HASSIO was simply because this is my first HASS installation, has years, I’ve added, removed, replaced, added, removed, replaced, lots of stuff since I first started this journey, and looking at the files on the server I see references to stuff that isn’t for years. And that kinda creeps me.
Yes, with MQTT, as long as HA is connected to the broker, things won’t go unavailable because the connection is static. That means all the states of MQTT entities persist unless you mark it stale. It gives you more control over how HA treats states.
You don’t get this level of control outside MQTT. Keep in mind that MQTT is yaml heavy.
That is the restore state functionality built into HA.
Alright I’m going to test MQTT with these a bit and see how it goes. The config is fairly simple and straightforward.
I have a question if you may know, I read from some blog post on configuring mosquitto:
For this to work reliably the broker needs to be configured with a persistent data store.
persistence true persistence_location /var/lib/mosquitto/
Is this so? I don’t see anything about it neither on HA docs nor GH, so I’m asking as I’ve only seen this mentioned on one place and would like to know what the optimal config is.
If running bare-bones mosquitto, yes
# Place your local configuration in /etc/mosquitto/conf.d/
#
# A full description of the configuration file is at
# /usr/share/doc/mosquitto/examples/mosquitto.conf.example
persistence true
persistence_location /var/lib/mosquitto/
include_dir /etc/mosquitto/conf.d
password_file /etc/mosquitto/passwd
listener 1883
If running the add-on, it probably is configured like that.
Ok so in the meanwhile I ended up moving them all to mqtt and go on with it. It’s working great. Also used the python_script for shelly devices quite solid.
Now one thing I notice is all the devices actually call home quite frequently based on the mqtt updates, based on how often these devices update I definitely do not understand why Home Assistant was failing so with the native integration.
@petro
since you mentioned you’re an HA dev, I honestly would recommend that someone would look over the native Shelly integration code.
What I can see after changing to MQTT is that the devices are all soundly alive and wake to call home quite frequently.
I believe that, if the native integration is becoming “unresponsive”, and according to logic, given that the devices are working properly, and being them all battery powered (or at least in nature) which means THEY wake up and call home, they are not awaken, there’s no WOL, so it’s Home Assistant that on some random check for device availability finds it off and changes the state to Unresponsive.
Looking around in the internet you’ll find dozens or hundreds of people that complain of the exact same ISSUE, however the resolutions are always like something else is the issue, but it’s not. The issue on HA is consistent enough for the realisation where the problem is.
I am experiencing the same issue. I have 10 battery-powered Shelly H&T sensors that have been rock solid for months. Several weeks ago I noticed they started showing in Home Assistant as “unavailable”. After researching, I see that a lot of people, and the official Home Assistant Shelly integration documentation, suggest that the Shelly’s CoIoT settings from ‘mcast’ to unicast by setting the IP_address:port in the Shelly settings. I made these changes, updated the firmware and rebooted all of the devices. Now all devices are showing ‘unavailable’ and no longer tracking statistics in Home Assistant. When I log into the Shelly device’s web portal, everything looks fine. I really want to avoid moving these to MQTT, since they have been working so well until the last few weeks. The only thing I can think of that changed was updating from 2023.6 to 2023.7, but I can’t guarantee that the two are related.
Info:
Any ideas?
Hi there,
Sorry haven’t been around. Honestly since I moved these to MQTT they are working quite well. Don’t regret it.
Now I’m having an issue with grid powered devices, namely Shelly 1 PM, Shelly 2 PM, Shelly Smart Plug S and Shelly GAS.
All of the sudden I get 7 devices saying “Shelly device (…) push update failure”.
If you go to “read more” you also get that “unicast” preach on the HA website.
If I access a device, everything shows updated on the device.
If I open the cast descovery app, I see all the devices and multicast present.
So why is this happening? Should I have to be forced to move to unicast because of a problem of HA?
Honestly this doesn’t differ much from the issue that forced the battery powered devices to have to be moved to MQTT. Home Assistant has bugs in this implementation and no one gives a f* because people think being forced to move to another technical solution is a “fix”.
For a reason. It works. I have zero issues with my PMs, EM and SW1s using unicast. It takes seconds to set up without much effort or knowledge,
Why are you insisting on using multicast when it is known to not work as well?
Multicast is incredibly inefficient and spams your entire network. Unicast does not.
#1 : Multicast WORKS
If in some setups it works with unicast but not multicast then there is an underlying problem that needs to be addressed.
I’ve had all my non-battery powered devices working flawlessly with mcast for years. Now whatever issue was underlying is poping out.
Also, please notice people are not responsible for your lack on networking, and if your network is behaving poorly with multicast that is likely a problem of the network administrator.