Devices disappearing from HomeKit

evski commented 5 years ago

First off when this works it's an awesome plugin! Problem I have as follows:

I start home bridge and devices are detected
I set staleTimeOut to 999 to try solve my issue
Devices appear in home app and work fine
I rename the devices and change their type to lights (as I'm using them for light switches which means I can use Siri to turn on and off lights)
Everything works great!
I go to bed and next morning devices are gone from home app
I check on the shelly app to see if devices still connected and I can see and control them no problem
I restart homebridge and repeat above steps

Any ideas greatly appreciated!

alexryd commented 5 years ago

staleTimeout is specified in milliseconds so a value of 999 means just under a second. What happens if you set it to something like 86400000 (24 hours)?

evski commented 5 years ago

Doh! My bad will try that and report back.

On 10 Apr 2019, at 08:42, Alexander Rydén notifications@github.com wrote:

staleTimeout is specified in milliseconds so a value of 999 means just under a second. What happens if you set it to something like 86400000 (24 hours)?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/alexryd/homebridge-shelly/issues/17#issuecomment-481575120, or mute the thread https://github.com/notifications/unsubscribe-auth/ANIQNhzvvCYdULT0nNMSPWBkMoQAPdR3ks5vfZXwgaJpZM4ck8k4.

evski commented 5 years ago

So far they are still present in home app and both turned on ok when tested, but will not turn off or update with status of switch. Guessing there’s clue here. Not sure if related to firmware update or the fact they are set to edge mode. I had this behaviour before and restarting homebridge resolved but then it just happens again.

alexryd commented 5 years ago

What device are you running homebridge on? I have seen this problem a few times myself on my Raspberry Pi. Seems like homebridge sometimes stops receiving status updates over UDP. I’m not sure if it’s a problem with this plugin, the Raspberry or the local network...

evski commented 5 years ago

Yes I’m running on raspberry pi. Anything I can do to help debug it please shout. I’ve chisel into my walls to put shelly device behind the light switches and this is the final step :) Fingers crossed.

On 11 Apr 2019, at 08:56, Alexander Rydén notifications@github.com wrote:

What device are you running homebridge on? I have seen this problem a few times myself on my Raspberry Pi. Seems like homebridge sometimes stops receiving status updates over UDP. I’m not sure if it’s a problem with this plugin, the Raspberry or the local network...

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/alexryd/homebridge-shelly/issues/17#issuecomment-482009178, or mute the thread https://github.com/notifications/unsubscribe-auth/ANIQNmcUSXPzDH_HSRUMylDu-ho8aXA6ks5vfuq0gaJpZM4ck8k4.

alexryd commented 5 years ago

Is your Raspberry connected over wifi or ethernet?

If you install node-shellies (npm install -g shellies) you could then try running shellies listen when homebridge stops receiving updates to see if the status update messages are actually reaching the RPi. You should see [Property changed] when you turn a switch on or off.

evski commented 5 years ago

Pi is connected other Ethernet to router. Tried shellies listen no messages when switching. Any ideas what to try next? Thanks again for the help!

Sent from my iphone using thumbs, please excuse my brevity!

On 12 Apr 2019, at 06:55, Alexander Rydén notifications@github.com wrote:

Is your Raspberry connected over wifi or ethernet?

If you install node-shellies (npm install -g shellies) you could then try running shellies listen when homebridge stops receiving updates to see if the status update messages are actually reaching the RPi. You should see [Property changed] when you turn a switch on or off.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

alexryd commented 5 years ago

Sounds like your RPi stops receiving status updates altogether then, not just homebridge. What do you need to do to make everything work again, restart homebridge or restart the whole device?

It’s a long shot, but you could try adding "networkInterface": "<device IP address>" to the configuration of this plugin and see if that helps.

evski commented 5 years ago

The Pi was plugged into my router I tried putting it into the network switch for the house and then power cycling everything. Since then it’s remained stable. I’m guessing if I have a power cut I’d need to go through setup again in home app (relabelling, setting scenes etc). Have you considered an option to manually set or fix devices once found? Thanks again for your work on this.

Sent from my iphone using thumbs, please excuse my brevity!

On 15 Apr 2019, at 15:13, Alexander Rydén notifications@github.com wrote:

Sounds like your RPi stops receiving status updates altogether then, not just homebridge. What do you need to do to make everything work again, restart homebridge or restart the whole device?

It’s a long shot, but you could try adding "networkInterface": "" to the configuration of this plugin and see if that helps.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

alexryd commented 5 years ago

How do you mean devices should be set or fixed? You only need to set up your devices again if this plugin doesn’t receive updates from them after the time specified with staleTimeout has passed.

pmarszal23 commented 5 years ago

I had the same issue with not refreshing status of shelly switches. I had raspberry pi connected through network switch to my router. When I connected pi directly to the router all problems were solved.

evski commented 5 years ago

Yes I did same and it solved the problem for a few weeks but then one of the devices dropped out again. What would be perfect is an option to specify the device IP in config.json, which disables auto detection. That way if drops out you don’t need to go through relabelling and assigning the device each time.

On 15 May 2019, at 19:44, pmarszal23 notifications@github.com wrote:

I had the same issue with not refreshing status of shelly switches. I had raspberry pi connected through network switch to my router. When I connected pi directly to the router all problems were solved.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/alexryd/homebridge-shelly/issues/17?email_source=notifications&email_token=ADJBANTWXAKT3NW2QTJSOXTPVRKY7A5CNFSM4HETZE4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVPSXNA#issuecomment-492776372, or mute the thread https://github.com/notifications/unsubscribe-auth/ADJBANRVESXLIIMB46QUFOLPVRKY7ANCNFSM4HETZE4A.

rzepetto commented 5 years ago

Hi, I am having simillar problem. In my case, I am installing homebridge on raspberry pi 3B+, installing necessary plugins, updating config.json and running homebridge. Everything works. After a while ( up to 15 minutes ) I am able to turn on shellies, but I am not able to turn them off. There is proper status in homeapp as it shows that devices have been turned off, but lights are still on. ( I can turn them off with shelly app/shelly cloud or manually, so it's not connection fault. I have been testing this with 3 different setup.

Raspberry PI 3B+ rasbian .
Raspberry PI 3B+ rasbian + docker homebridge.
Homebridge on macbook.

Forgot to mention, when I restart homebridge, everything works back again for a while... and then I can't turn off light from the home app. My Raspberry Pi is connected via wire to main router, macbook was connected on the same wifi 2.4Ghz as shellies are. For testing purpoes, my config.json looks exactly the same as in the example, just only one platform, no accesorries in the config file.

Karo-X commented 5 years ago

Hey folks, I'm having the same issues. For the transparency: Modem/Router: Fritz!box Firmware 7.1 HomeBridge: Raspberry Pi 3 Model B+ (connected via ethernet) AccessPoints: 1x AeroHive AP122, 1x AeroHive Atom HomeKit: Apple TV 4K, HomePod Shelly's: 4x "Shelly 2.5" Configuration for homebridge-shelly v0.9.2: { "platform": "Shelly", "name": "Shelly" }, Logfile when shelly-modules stop working (sometimes after 9h): [Shelly] Device SHSW-25 XXXXXX is stale. Unregistering its accessories.

Logfile after restart Homebridge: [Shelly] 0 device loaded from cache 2nd restart: [Shelly] New device discovered: SHSW-25 XXXXXX at 192.168.178.xx

Troubleshooting: I'm very not sure if the issue ist caused by the shelly-plugin, but if this mistake occurs with several people, it does not seem to be an isolated case. Is there a chance to set the staletimeout to "0" / unlimited? or what is the best practice to set the config?

Restarting the Homebridge is a workaround, but not the solution.

galzil commented 5 years ago

This didn't occur while I had homebridge installed on a VM (Ubuntu on a win 10 PC), but started now as I moved my homebridge to hoobs on a dedicated RPI 3+ last week. Very annoying, started thinking about setting a reboot on a schedule

Karo-X commented 5 years ago

@galzil: true. I had installed it on a test MacBook, too. So I think it’s a raspberry thing.

Ipnotik commented 5 years ago

Same here. After some months of flawlessly operations (PERFECT every time) now my shellies seems to get out of sync and after a while (next day) they disappear. Furthermore they don't update their status and every time I restart the homebridge I have to copy the file "cachedAccessories" (that comes from a backup of homebridge folder when the shellies were perfect) or they don't reappear. I'm using homebridge within Docker app installed on my Synology. @alexryd please help!

Here is the cachedAccessories file content:

discostur commented 4 years ago

has there been any solution to this? @Ipnotik

Karo-X commented 4 years ago

I don't think @alexryd can fix it because it has nothing to do with his plugin. For me it is a combination of the modem and my WiFi router. As soon as I run the Raspberry via WLAN, the shellys work without problems and also report with the current status. As soon as I hang the Raspberry on the DSL modem (btw a Fritz!Box), the problems begin. Apparently certain packets between the modem and my external WLAN antenna (AeroHive) are rejected. As I read it is probably due to the modem. I will try another one in the near future or if nothing else really works, connect the Rapsberry via WiFi. It's not great if you can use LAN cables, but what should I do?

MaWe1108 commented 4 years ago

I have the same problem. Devices can be switched on but not off. I tried connecting my pi4 over WLAN and ethernet to my router (Fritz!Box) but after some time the problem comes back. When I can't turn them off I can turn them on every time (switched off with wall switch) and via the web interface. So maybe it is a bug in the plugin? When I restart homebridge it works for a few hours. Any ideas what else I could try?

MaWe1108 commented 4 years ago

Now the switches couldn't be turned off even after multiple restarts of homebridge, my pi and the router. I read somewhere that the accessoires are cached and that if you remove the platform or accessory entry in your config.json and restart homebridge while the plugin is still installed the cache for this plugin/accessory is cleared. I did that and after adding the entry again and restart homebridge again it worked! Also I recognized that on the web interface of the plugin my shellys where listed as offline. But as I wrote earlier I still was able to turn them on/off over the web interface. After I did the steps above the shellys where listed as online. There must be some kind of problem with the cache.

Karo-X commented 4 years ago

I am no longer so sure what it could be. The fact is: The current detail-status of the switch (regardless of whether it is a light switch or shutter control) is not transmitted. For the roller shutters, it says to me that it is during the opening even though it is actually 50% closed. When I touch the button in the HomeApp, 50% is displayed there. Interestingly, this value from the Home-App is the same as at the HomeBridge web interface. Apparently hombridge is not transmitting all parameters correctly? The Current Position | 100% Target Position | 50% I don't know if you can / should delete a cache here.

EDIT: now I found this: https://github.com/RobXYZ/homebridge-brunt/pull/4/commits/7b4e1f68d1c7ea8d1e60aa7fedde2466756e1b6f

@alexryd maybe you have time to look if you can insert this code to your Plugin?

MaWe1108 commented 4 years ago

After it worked for a few weeks it stopped again. I opened the webinterface of the plugin where the 2 shellys where listed offline. On the right there was a button remove or disconnect. I thought maybe removing and adding would help so I removed both. But now the shellys are not found anymore in the web interface and the plugin when its loaded also finds 0 devices. When I try to open the shellys webinterface it works. What action is triggered by clicking on remove? How can I reset it? I removed the plugin and installed it again, but that didn't help. What can I do now?

MaWe1108 commented 4 years ago

I ran shellies listen:

[Device discovered] 2020-06-28T21:23:42.214Z Type: SHSW-1 ID: 8CAAB5061293 Host: 192.168.111.201 Property: relay0 Value: false Property: input0 Value: 0 [Request failed] 2020-06-28T21:23:42.255Z Failed to load settings for device with ID 8CAAB5061293 Error: 401 Unauthorized [Device discovered] 2020-06-28T21:23:45.631Z Type: SHSW-1 ID: 8CAAB505E4A5 Host: 192.168.111.200 Property: relay0 Value: false Property: input0 Value: 2 [Request failed] 2020-06-28T21:23:55.645Z Failed to load settings for device with ID 8CAAB505E4A5

They were found (I use password for them so I think it's ok the settings request fails). Why does the webinterface of the plugin didn't find them?

MaWe1108 commented 4 years ago

Now I am a bit closer to the problem. In /var/homebridge/accessories is the file cachedAccessories. When all works this file has nearly the same content as when it stops working. There are two differences:

Firmware Revision for Shelly 1 is 1.6.2 when it works -> 0.13.0 when it stops working
Shelly 2 has 5 Characteristics when it works but 6 when it stops working. The added part is: }, { "displayName": "Hardware Revision", "UUID": "00000053-0000-1000-8000-0026BB765291", "props": { "format": "string", "unit": null, "minValue": null, "maxValue": null, "minStep": null, "perms": ["pr"] }, "value": "prod-191217", "eventOnlyCharacteristic": false }],

If I delete cachedAccessories and restart homebridge it works again.

Any idea what causes this?

alexryd commented 4 years ago

@MaWe1108 I don’t think cachedAccessories has anything to do with your problems. It’s probably an issue with multicast in your network. Did you run shellies listen from the same device that you are running homebridge on?

MaWe1108 commented 4 years ago

But why should the switch on command always work but switch off not. The router does not know what message is inside the package. So if it is a multicast problem both messages should fail. I also switched to lan and an old router with the same problem. When I delete the cache and restart homebridge all works again.

alexryd commented 4 years ago

See this page for a description of why this seems like a multicast issue and what you can do to troubleshoot it.

jello1974 commented 3 years ago

Had the same problem. I solve it by unchecking media_player.....Hope it helps

alexryd / homebridge-shelly

Devices disappearing from HomeKit #17