-
-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HomeKit representation of Shelly PM2 gets out of sync when using directional buttons #61
Comments
Hi, for information I migrated to Home Assistant. now the problem is solved. everything is working properly. |
after 3 days of use, I confirm that everything is working properly. whether I use the switches or HomeKit or Home assistant the positions of the roller shutters are updated correctly. |
Same Problem here ! |
I would love for this issue to be resolved as it's quite an annoying one in an otherwise perfect HomeKit-powered home. :) |
Same problem here... The old shelly 2.5 work perfectly with the "old" Shelly-Plugin, but the Plus2PM have these issues with shelly-ng-plugin. As my old 2.5 are dying one after the other I replace them gradually with the Plus2PM. One additional perception: The problem seems to be worse, when there are more than one Plus2PM in one room. In my living room I have 4 Shutters, 2 with the old Shelly 2.5 und 2 with the new Plus2PM. I observed, that usually one of the new devices works good in HomeKit and the other one doesn't. Which one works good? Obviously exactly that device that I used first after restarting homebridge. Maybe this helps in examining the problem. |
Thank you for this great ticket description. Props to @matej. |
All is ok, when NOT using the physical buttons. Button press and reaction in HomeKit: Physical Open-Switch: Status in Homebridge device-view and Shelly-WebInterface is always ok ! (while moving and ending with percent-value) Problem seems to be in the states (transfered from plugin to HomeKit), when the shutter is moving and is stopping in a middle position. |
Same problem here. Since my Shelly 2.5 are gradually dying I now have to replace all the roller shutters. |
Me to, I have the same problem. Still no fix or news? |
And the same issue is also when moving by http command, not only by physical buttons... |
@matej Did you get it to work properly? |
I personally used @Nicop51430's suggestion and now use Home Assistant for my Shelly PM2s. That works fine. |
I tested yesterday with homeassistant and can also confirm that it runs without any problems. Now i migrate my smart home from iobroker to homeassistant and can shutdown my homebridge |
I have the same issue, im thinking to change to home assistant just to fix this bug |
Are there any news on that ? |
Same issue. |
Same issue, using the physical buttons doesnt show properly. |
I have opened a merge request, you can test this while waiting for the review on your local homebridge instance, execute wget https://raw.githubusercontent.com/BirknerAlex/homebridge-shelly-ng/fix-states/src/abilities/cover.ts -O /homebridge/node_modules/homebridge-shelly-ng/src/abilities/cover.ts inside the container or add it as container start script. This fixes the issue on my PM2. |
Hi, |
I added in yesterdays MR also more logging, if you turn on debug logging on home bridge it should log the needed events. Something like
Would be awesome if you can test it then again and provide all event logs. You can also check against the shelly log if there were some events missing.
Should now show the real events sent to the homebridge plugin. |
@BirknerAlex |
Do you use the docker image? If not, the real cover.ts can be under a different path? Maybe the file isn't really replaced on your instance, that would explain why the issue still exists and you have no log messages. I have tested everything again on my side and I can use the hardware switches and getting updated correctly in the home app. 🤔 |
@BirknerAlex |
Thank you for updating but same problem here:
Logging in Homebridge-Status-Wnd: (only with Homekit-Position-change, nothing with buttons)
It really seems that the new cover.ts is not active. |
Thanks für your PR. You forget to mention to rebuild the plugin after changing the cover.ts file.
The status is still not correctly given back to the Home app if I manually control the Shelly with the buttons: Seems that the target position characteristic is not updated properly when using the buttons. If I check the controller app the values of target and current position are different. The values from the HomeAssistant Accessory are both 92%. Also if I only control over HomeKit the values are updated correctly. If it helps here are the shelly debug logs: |
Is there any Solution for this issue ? I still got these problem with the 2pm. |
i got that problem to. :( |
Well... |
This issue might be related to #24, #37, #45, #52, however since all those have subtle differences in their descriptions, I decided to start yet another ticket with my observations. I hope this helps track down the root of those problems.
Visual behavior
Here's the main issue I'm observing when using a PM2 as Window Covering:
Homebridge-Shelly-Shades.mov
Observations
So in short, everything is fine when using a target percentage. When using a method that just sets the direction things brake. The state recovers when one of the working methods is used again.
The broken behavior is:
Status messages
Here's a composition of the statuses the Shelly is reporting in both cases via MQTT.
Web UI slider (no issues):
Web UI directional buttons (with issues):
The key difference I'm seeing here is that we don't really have
target_pos
in the reporting flow. Which makes sense. It's just not known ahead of time. Now, I don't know what exactly the plugin does here, but I do remember seeing a bunch of issues in the past with other kinds of HomeKit accessory types, if the target values didn't get updated during a change. I'm speculating here a bit, but if the target state is never set in the second scenario, then setting it together with the current state when the stop update is received might help.I hope this helps. I'm happy to help with more testing to sort this one out.
The text was updated successfully, but these errors were encountered: