Recently, like a month or so, started having a issues with grid powered devices, namely Shelly 1 PM, Shelly 2 PM, Shelly Smart Plug S and Shelly GAS. - it’s 8 devices total. None is battery.
Happens that all of the sudden I these 8 devices saying “Shelly device (…) push update failure”.
If you go to “read more” you get to go to the Home Assistant website where close to a paragraph that instructs you to change to “unicast” and all that preach.
Now, is there any problem with multicast? No.
When I enter a device in home assistant, every output is updated. State, temperature, etc all sensors reporting correctly.
If I open the discover app, I get all the shellies there _shelly._tcp and _http._tcp everything is right there always.
So exactly what is Home Assistants problem? How does HA report “Shelly device (…) push update failure” and yet everything is always being updated? If I change the state of a light for example, from HomeKit → HA → switch, everything works, even with the mentioned error.
I’m fed up of having to change the technical option chosen because some people must think being forced to chose some other option is a “fix”. Well, it’s not. All I see is these problems that haven’t been addressed and just keep piling up.
It’s really amazing how instead of addressing the real issue, you should instead exchange multicast for unicast, enable web sockets because, kill a chicken and perform a ritual bent over backwards.
The native integration is really an outstanding integration, for the two minutes after setup when it works.
This is precisely what has dragged us so far. Unfortunately I did see your spree of forcing people to unicast when there’s an underlying problem, tho it surprises me even more how can you be constantly sending people to “unicast” and still saying the “native integration works flawlessly” - it doesn’t. If it did, no unicast config would need to be changed.
This move to the configuration section is an abuse that only matches your workaround for the problem, it is not a fix, and it is not a configuration problem.
Inviting people to participate about this issue here:
The underlying “problem” is that multicast spams your network. It’s fine for initially discovering the device but you do not want that sort of traffic on your network permanently. Moving to unicast would take a lot less effort than you have put into cross-posting all over the forum (please don’t do that).
As I just responded on the other thread, multicast does work. If you have any issue specifically related to multicast vs unicast, get a proper network administrator or something alike.
Moving to unicast is a workaround, not a fix.
There is no problem with multicast, even tho you have a really hard time comprehending this.
You are the one incorrect here. Actually it only exposes your ignorance on the matter.
Multicast is very present today at any network. Your computers, windows, Macs or linux will communicate over multicast,
Apple devices communicate over multicast all the time for years - never seen anyone at Apple blaming “the chatter” for poor programming, had to come here to make it a first,
Multicast is widely used in IPTV, video conferencing and many other stuff.
Of and another eg. the Matter Protocol. Maybe we should address them all dumb people making those protocols on mcast, they haven’t been briefed multicast doesn’t work and unicast is the way to go. I mean, c’mon.
Multicast WORKS. I believe it is extremely sad and a bit brutal to have to be here explaining multicast is a well established network method of communication. Surreal.
Also, and against your “opinion” - which is nothing more than that and has absolutely no fundament what so ever, I’m starting to believe you’re the one who contributed with the “unicast” bit in the HA website -, but anyway even despite the push update error, all the sensors are reporting correctly and it is working fine - over mcast. So mcast doesn’t work, only it does.
Then despite everything being working, you have once again the pesky nasty HA crap sending errors and making people lose time. However, if instead someone had addressed this issue years ago, today there would be no issue likely. Instead, I’m here talking about mcast. what an absurdity.
No, I did not contribute to the Shelly Documentation. People much smarter than me with a deep understanding of the Shelly API wrote that. For a reason.
As I said, workaround is not a fix.
Did that with MQTT on battery powered, that shouldn’t have, when users who use Shelly Cloud app say the devices update just fine.
We have a different approach to the recognisance of an issue and how to deal with it.
Years of sending people to change to unicast are enough already no?
It’s not a workaround. It is a more reliable protocol. Why?
IDK enough about the API to say.
No. If people would like to have their Shelly devices work as well as possible I will keep recommending what the documents say to do. The recommendation is there for a reason. It works.
You did not have to use mqtt (though it too is a very good protocol. I used it for years before the core integration was available). Unicast is required for battery powered devices. Again as recommended in the docs.
This is the second time you’ve blown up when getting advice. The next time you partake in a discussion here, make sure you check your ego at the door. The way you are responding to people is against the code of conduct. Consider this a warning.
I will be reporting you to the code of conduct email address.
I just got confirmation from Github this issue has nothing to do with multicast, and all that happened here was I was trolled and insulted by a moderator, who abusively moved a relevant issue to a configuration section, and trolled my topic endlessly with his “unicast” view.
I won’t qualify it, it is what it is and evidence speaks volumes.
If you’re demanding respect, you better respect first. I didn’t go to school with you buddy.
You arent going to get very far without configuring any wifi device. Do you expect them to magically know your network SSID and password?