Hey there @balloob, @bieniu, @chemelli74, @bdraco, mind taking a look at this pull request as it has been labeled with an integration (shelly) you are listed as a code owner for? Thanks!

The only draw back with this change si that it may take way too long to mark a device as unavailable.
If it's something important, linked to security ( motion, door, flood ), this change may compromise the result.

It's definitely expected that UDP-based protocol will drop packets over Wi-Fi. I expect that is one of the reasons Shelly moved away from COAP with Gen2/Gen3 devices.

This a difficult problem as its never going to be as stable as we want it to be as there are no guarantees with UDP. All the potential options here are compromises.

It's reasonable never to fix this if the consensus is that the device is more important to be shown as unavailable after a single packet drop instead of reflecting an old state. It's always hard to know the correct action here because there will be opinions on both sides of this.

As an alternative, we could clearly state in our documentation that it's normal for Gen1 sleepy devices to experience periodic unavailability under standard conditions (nobody will ever have a perfect network), particularly when updates are occasionally dropped. That would allow us to close the linked issues and point them to the docs instead. i.e. wontfix

I have to reiterate this was listed above as a fix for

#119002

...and that 119002 is referring to a GEN 2 device, however the above statement seems to imply this (118969) may be closed without any change being made. Please note that the above link I have supplied is to an issue that is NEW which came up due to a change to the Shelly integration and needs to be fixed as these Shelly Motion 2 units are used for an alarm system as well as a smart home for disabled older folks that require them to work properly instead of just becoming "unavailable" on a constant basis (which never used to happen).

So if this (118969) is closed without making any changes, 119002 which is referenced above as being fixed by this - and was posted with logs - should stay open and 119002 still needs to be worked upon as soon as possible.

Thank you -

It's definitely expected that UDP-based protocol will drop packets over Wi-Fi. I expect that is one of the reasons Shelly moved away from COAP with Gen2/Gen3 devices.

This a difficult problem as its never going to be as stable as we want it to be as there are no guarantees with UDP. All the potential options here are compromises.

It's reasonable never to fix this if the consensus is that the device is more important to be shown as unavailable after a single packet drop instead of reflecting an old state. It's always hard to know the correct action here because there will be opinions on both sides of this.

As an alternative, we could clearly state in our documentation that it's normal for Gen1 sleepy devices to experience periodic unavailability under standard conditions (nobody will ever have a perfect network), particularly when updates are occasionally dropped. That would allow us to close the linked issues and point them to the docs instead. i.e. wontfix

I not understand this is already going on since 2024.5 #116948 and mentioned in few other issues as well with #119002 as the latest it already several times is implied that it are connecting problems, and even now is suggested to simple ignore this and write it of as won't fix. This issue NOT WAS THERE AND NEVER HAVE BEEN THERE BEFORE 2024.5 so something did change to make this happen, and the focus should be on finding out what this is to my opinion. And yes I understand most of you do this out of hobby and for free, what is highly appreciated so I apologize for my frustrated reaction, but I hope it also is understandable if all the time is assumed this issue is not caused by the integration (or other changes within 2024.5 causing the shelly intgration to have this behavior) while it not existed before update 2024.5

EDIT: also it not is logical that this "becoming unavailable" only happen after a restart of HA and that ONE time reloading the device within the Shelly integration solves this for as long there is no other HA restart. If it was network related it also would occur on a more regular basis and not only at a HA restart.

I am no code writer and my knowledge is far from expert level, but I would say, make the Shelly integration reload all it's devices by itself for example 1 minute after restart of HA is completed would solve this issue also. Just thinking out loud as this is what I am doing manually now each time after I did do a HA restart.