turn off only works on second attemp if it was turned on a second before

[helbgd]

with the beta.5 update if you change the state of a device for example a dimmer to let's say on then off within a second it does not react you have to wait few more second's thenn turn it off again, thenn it works

a bit hard to explain if you hit klicking on a device on ios home app it react's only to the second klick while turning it off shortly afterwards you had turned it on, if you wait a bit it turns of instantly - might be a state that's not updated fast enough.

[alexryd]

Like you say, it sounds like the state is not updated fast enough. Have you ever noticed this before? I'll see if I can reproduce it.

[helbgd]

never noticed that before ... just during trying around here you know

[Trackhe]

Like you say, it sounds like the state is not updated fast enough. Have you ever noticed this before? I'll see if I can reproduce it.

i have the same problem. but it never update. only after restart or some things

https://github.com/alexryd/homebridge-shelly/issues/166

[Trackhe]

homebridge-shelly plugin v.0.14.0-beta.6 dosn't fix it.

[helbgd]

can I help in this case anyhow to troubleshoot ? or can you give me a hint how to do so ?

[alexryd]

@helbgd If you can run homebridge in debug mode (launch it with the -D flag) then provide some log output, that would be helpful.

[Trackhe]

@alexryd i had do this already https://github.com/alexryd/homebridge-shelly/issues/166

[helbgd]

I did klick on the Button of that device in the IOS Home APP multiple times It seems like the status change received by homebridge from shelly plugin takes too long

[8/18/2020, 5:13:07 PM] [Shelly] Setting relay0 of device SHSW-PM xxxxxA1d to false [8/18/2020, 5:13:08 PM] [Shelly] Setting relay0 of device SHSW-PM xxxxxA1d to false [8/18/2020, 5:13:08 PM] [Shelly] Setting relay0 of device SHSW-PM xxxxxA1d to false [8/18/2020, 5:13:09 PM] [Shelly] relay0 of device SHSW-PM xxxxxA1d changed to false <<<< feedback from shelly device through plugin [8/18/2020, 5:13:09 PM] [Shelly] Setting relay0 of device SHSW-PM xxxxxA1d to true [8/18/2020, 5:13:09 PM] [Shelly] Setting relay0 of device SHSW-PM xxxxxA1d to true [8/18/2020, 5:13:10 PM] [Shelly] Setting relay0 of device SHSW-PM xxxxxA1d to true [8/18/2020, 5:13:10 PM] [Shelly] relay0 of device SHSW-PM xxxxxA1d changed to true [8/18/2020, 5:13:10 PM] [Shelly] Setting relay0 of device SHSW-PM xxxxxA1d to false [8/18/2020, 5:13:11 PM] [Shelly] Setting relay0 of device SHSW-PM xxxxxA1d to false [8/18/2020, 5:13:11 PM] [Shelly] relay0 of device SHSW-PM xxxxxA1d changed to false [8/18/2020, 5:13:11 PM] [Shelly] Setting relay0 of device SHSW-PM xxxxxA1d to true [8/18/2020, 5:13:12 PM] [Shelly] Setting relay0 of device SHSW-PM xxxxxA1d to true [8/18/2020, 5:13:13 PM] [Shelly] Setting relay0 of device SHSW-PM xxxxxA1d to true [8/18/2020, 5:13:14 PM] [Shelly] Setting relay0 of device SHSW-PM xxxxxA1d to true [8/18/2020, 5:13:15 PM] [Shelly] Setting relay0 of device SHSW-PM xxxxxA1d to true [8/18/2020, 5:13:16 PM] [Shelly] Setting relay0 of device SHSW-PM xxxxxA1d to true

[alexryd]

What happens when you turn it on and off quickly with the physical switch?

[Trackhe]

I've tried it, but not a single message in Homebridge.

[helbgd]

tested as well if you do switch on and off "slowly" you get entries in homebridge, if you do it fast then no message appears in homebridge, might be 1.8.0 has some sort of debounce so that it does not report that frequently ... feature ?

[alexryd]

Yeah seems like that, but it's not working very well... I've opened a support ticket with Shelly, hopefully they can fix it.

[Trackhe]

even with slow switching on and off nothing happens to me :(

[alexryd]

That sounds more like a network issue @Trackhe

[helbgd]

I have verified with a tcpdump it only sends out packet's if you do change the switch slowly if you do it fast thenn nothing is sent out by the shelly ... can confirm seems to be a shelly FW problem

[Trackhe]

@alexryd if it is a network problem I don't understand why I can turn it on at least once. (via homebridge) how i test it? @helbgd how did you create a tcp dum with the wifi device?

[helbgd]

I did run a tcpdump on the homebridge server ...

[helbgd]

the shelly sends multicast UDP packet's if anywhere in your network this is not forwarded thenn it might not work.

you can do something like tcpdump -i eth0 -nnvvXSs 1514 host and not arp

then you have to see flowing packet's to 224.x.x.x in the trace output, and there I noticed that I only see packet's if I change the state of the switch attached to the shelly slowly, If I do them hit fast under 1 second no packet's are sent out of the shelly ...

[Trackhe]

i get this 12187 284.414722 192.168.178.85 224.0.0.251 MDNS 499 Standard query response 0x0000 PTR _http._tcp PTR shellyswitch25-10CB42._http._tcp.local SRV, cache flush 0 0 80 shellyswitch25-10CB42.local TXT, cache flush A, cache flush 192.168.178.85 NSEC, cache flush shellyswitch25-10CB42.local only if i change slowly like you. just that my homebridge doesn't notice anything.

[helbgd]

Thats is only the mdns response sent out by the shelly, its anouncing it's name in the network every few second's ... I assume u use a Fritzbox,

maybe you blocked the thing that devices are allowed to communicate between each other ? it's a setting in the Fritzbox security WLAN settings, if you are using any repeaters turn them off for testing

[Trackhe]

Thanks for the tip. Everything was set correctly. But I found an update for the FritzBox. Now it works Jea <3 The only thing that is worse now than before is that it is more delayed than before. Around 3-4 seconds.

[helbgd]

you might turn on enhancement for live tv in the fritzbox as well .. this enables the igmp proxy wich might improve things but okay .. that delay might come from as well from a bad wifi connection to the shelly

[Trackhe]

There was no delay before. and the connection 2.4 GHz → 65 Mbit / s is ok, I guess.

ping

64 bytes from 192.168.178.85: icmp_seq=0 ttl=255 time=5.303 ms
64 bytes from 192.168.178.85: icmp_seq=1 ttl=255 time=2.910 ms
64 bytes from 192.168.178.85: icmp_seq=2 ttl=255 time=5.877 ms
64 bytes from 192.168.178.85: icmp_seq=3 ttl=255 time=2.635 ms
64 bytes from 192.168.178.85: icmp_seq=4 ttl=255 time=2.286 ms
64 bytes from 192.168.178.85: icmp_seq=5 ttl=255 time=36.146 ms
64 bytes from 192.168.178.85: icmp_seq=6 ttl=255 time=36.361 ms
64 bytes from 192.168.178.85: icmp_seq=7 ttl=255 time=2.686 ms
64 bytes from 192.168.178.85: icmp_seq=8 ttl=255 time=36.010 ms
64 bytes from 192.168.178.85: icmp_seq=9 ttl=255 time=29.308 ms
64 bytes from 192.168.178.85: icmp_seq=10 ttl=255 time=41.148 ms
64 bytes from 192.168.178.85: icmp_seq=11 ttl=255 time=35.231 ms
64 bytes from 192.168.178.85: icmp_seq=12 ttl=255 time=20.836 ms
64 bytes from 192.168.178.85: icmp_seq=13 ttl=255 time=26.213 ms
64 bytes from 192.168.178.85: icmp_seq=14 ttl=255 time=21.528 ms
64 bytes from 192.168.178.85: icmp_seq=15 ttl=255 time=19.067 ms

i have no repeater or something but anyway thank you for helping me !

edit: live tv is not available for my DSL FB 7590

[helbgd]

anyway if you receive this multicast packet's now on the homebridge instance then you should be okay ... this status feedback delay seems to be caused by something in the 1.8 FW of the shelly's I did some research in google and found similar problems with iobroker hass.io or openHAB bindings ... it seems to be they as well addressed this to shelly already, not clear how seriously they take this :-)

[helbgd]

just downgraded my device with http://archive.shelly-faq.de/ to FW 1.7 and turned on tcpdump again, noticed that it reacts to every button change very fast and not like in the 1.8 FW so seems to be pretty clear a issue with FW 1.8

[Trackhe]

I can confirm it. With 1.7 its very fast and works perfekt.

[alexryd]

Seems like this issue and #171 are caused by the same problem. I hope Shelly will fix this.

[alexryd]

Has this improved with firmware 1.8.3?

[helbgd]

can confirm 1.8.3 has fixed the issue, I would say you can mark this as fixed :-)

[alexryd]

Great 👍