[Bug] plugin ignores true/false events when entering a buggy state (demo)

[altercation]

Describe the bug

homebridge-shelly will sometimes (reproducibly) enter a state where it fails to register either the true or false state events for shelly devices on the network. E.g. all shelly devices become stuck in an on/off state and either the on or off events from home app appear to be ignored. Restarting the homebridge-shelly child-bridge eliminates this until next occurrence.

I recorded a video of the bug in action (with live reproducibility of buggy state). https://youtu.be/ea0TrlUi0u8

Note that sometimes the locked state is inverted (i.e. it will "receive" only false events, not just true events as in this demo video).

Also, to be clear, when the homebridge-shelly plugin is apparently in this state, home app will toggle the state indicator on/off but the actual switch as controlled by homebridge-shelly does not toggle state in the real world (as one would expect since half the state changes are apparently being ignored by the plugin).

Log output

See demo at:

https://youtu.be/ea0TrlUi0u8

Environment:

• Shelly device(s): Shelly 1 (switch in video), but issue extends to other Shelly 1 switches and Shelly Plugs. Button in video demo is a Shelly Button 1 configured with a static IP.
• Plugin version: homebridge-shelly v0.19.1
• Device running homebridge: Raspberry Pi 4, homebridge-raspbian-image

[altercation]

Additional note: I believe this bug can also be triggered by accessing the web UI for an existing device (via IP address of the shelly device) and toggling state. I just did this with a Shelly 1 (standard setup, nothing unique about it, standard DHCP derived IP, etc.).

(just popping back into this comment to note that it seems very reproducible when I use the web ui of a shelly device to toggle state...)

[altercation]

Cautiously optimistic that the way to mitigate this in the case of the button is to disable ColoT and reboot. I tested ColoT in both mcast and unicast mode and both result in homebridge-shelly issue as demonstrated in video. Turning off ColoT and using a button action (set in the shelly device web ui) that calls a homebridge-webhook switch device is the only way i've found to address this.

EDIT/UPDATE: this ended up demonstrating the same issue where homebridge-shelly requires a restart to resume functionality.

[altercation]

Confirming that adding a new shelly to network causes same issue requiring bridge restart.

[StaX91]

Got same (similar) issue. Using Shelly 2.5 as a relay for my mechincal vent. The vent knows 2 stages. Got it running in Homekit by running HomeBridge in Docker on a NAS. I have a hue wall switch installed on a (dumb) switch in my home. Pressing it should trigger shelly in setting the stage of my vent. Which works properly the first few x times. But after a few times or after being in a certaine stage for to long (+10 min) it all of sudden stops working.

The (dumb) switch on the wall still triggers HomeKit but HomeKit seems to no communicate with Shelly no more... I can't figure out why it does not work and it drives me crazy as well.

[DarkWiggerl]

Got same (similar) issue. Using Shelly 2.5 as a relay for my mechincal vent. The vent knows 2 stages. Got it running in Homekit by running HomeBridge in Docker on a NAS. I have a hue wall switch installed on a (dumb) switch in my home. Pressing it should trigger shelly in setting the stage of my vent. Which works properly the first few x times. But after a few times or after being in a certaine stage for to long (+10 min) it all of sudden stops working.

The (dumb) switch on the wall still triggers HomeKit but HomeKit seems to no communicate with Shelly no more... I can't figure out why it does not work and it drives me crazy as well.

I have exactly the same issue’s!!! Is their a known Solution or Workaround available?!

[DarkWiggerl]

This was my Solution for my Problems!

https://github.com/alexryd/homebridge-shelly/wiki/Shelly,-CoAP-and-multicast

I set in the Webinterface of the Shelly the ColoT Peer to my Homebride-IP and this Port 192.168.xxx.xxx:5683 Saved it. Then a restart from my Shelly and Homebridge and now on the iPhone everything is working as expected now!!!

[StaX91]

This was my Solution for my Problems!

https://github.com/alexryd/homebridge-shelly/wiki/Shelly,-CoAP-and-multicast

I set in the Webinterface of the Shelly the ColoT Peer to my Homebride-IP and this Port 192.168.xxx.xxx:5683 Saved it. Then a restart from my Shelly and Homebridge and now on the iPhone everything is working as expected now!!!

Thanks a lot!! You my friend, are a true hero! Seems to work fine now for me as well using this solution!

[altercation]

Additional workaround that I'm using for the shelly buttons:

• I disable discoverability in the shelly button web UI
• I ensure NO ColoT Peer IP in the shelly button web UI
• I remove the button as a cached accessory in homebridge

This effectively isolates the button and it is no longer tracked by the bridge at all. Of course it is also invisible to homekit in that case, so the solution I use is:

• Set a static IP on the button via shelly button web UI (improves performance of button at wake-up)
• Install https://github.com/Djelibeybi/homebridge-button-platform plugin on homebridge
• Set the shelly button click action to something like http://192.168.0.100:3099/button-button1?event=click (see the button-platform plugin for examples)

This method (shelly button invisible to shelly plugin / homekit directly, instead triggering a button-platform device via web hook) is very fast and has eliminated the shelly plugin hang I was seeing before (or rather worked-around it).