Skip to content
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

Open
matej opened this issue Dec 10, 2022 · 28 comments · May be fixed by #108
Open

HomeKit representation of Shelly PM2 gets out of sync when using directional buttons #61

matej opened this issue Dec 10, 2022 · 28 comments · May be fixed by #108

Comments

@matej
Copy link

matej commented Dec 10, 2022

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

  • Setting the position through the Home app works fine.
  • Setting the position through the Shelly web interface using the position slider works fine.
  • Setting the position through the directional buttons on the Shelly web interfaces causes the HomeKit state to go out of sync.
  • Setting the position through physical buttons connected to the Shelly inputs causes the HomeKit state to go out of sync.

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:

  • No state is indicated in the Home app when movement starts.
  • When movement ends, the Window covering is set to be closing in the inverse direction of the movement.

Status messages

Here's a composition of the statuses the Shelly is reporting in both cases via MQTT.

Web UI slider (no issues):

{
   "src":"shellyplus2pm-123",
   "dst":"shellyplus2pm-123/events",
   "method":"NotifyStatus",
   "params":{
      "ts":1670674655.75,
      "cover:0":{
         "id":0,
         "move_started_at":1670674655.75,
         "move_timeout":3.42,
         "source":"WS_in",
         "state":"closing",
         "target_pos":2
      }
   }
}
{
   "src":"shellyplus2pm-123",
   "dst":"shellyplus2pm-123/events",
   "method":"NotifyStatus",
   "params":{
      "ts":1670674659.65,
      "cover:0":{
         "id":0,
         "apower":0,
         "current":0,
         "current_pos":2,
         "move_started_at":null,
         "move_timeout":null,
         "pf":0,
         "source":"timeout",
         "state":"stopped",
         "target_pos":null
      }
   }
}

Web UI directional buttons (with issues):

{
   "src":"shellyplus2pm-123",
   "dst":"shellyplus2pm-123/events",
   "method":"NotifyStatus",
   "params":{
      "ts":1670675416.45,
      "cover:0":{
         "id":0,
         "move_started_at":1670675416.45,
         "move_timeout":120.00,
         "source":"WS_in",
         "state":"opening"
      }
   }
}
{
   "src":"shellyplus2pm-a8032ab6fd48",
   "dst":"shellyplus2pm-a8032ab6fd48/events",
   "method":"NotifyStatus",
   "params":{
      "ts":1670675421.65,
      "cover:0":{
         "id":0,
         "apower":0,
         "current":0,
         "current_pos":12,
         "move_started_at":null,
         "move_timeout":null,
         "pf":0,
         "source":"WS_in",
         "state":"stopped"
      }
   }
}

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.

@Nicop51430
Copy link

Hi, for information I migrated to Home Assistant. now the problem is solved. everything is working properly.

@Nicop51430
Copy link

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.

@BassXT
Copy link

BassXT commented Jan 25, 2023

Same Problem here !

@larsjtx
Copy link

larsjtx commented Feb 15, 2023

I would love for this issue to be resolved as it's quite an annoying one in an otherwise perfect HomeKit-powered home. :)
Don't want to keep my family from using the physical direction buttons for the shutters because of this...

@MaTr75
Copy link

MaTr75 commented Mar 21, 2023

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.

@KaeseToBa
Copy link

Thank you for this great ticket description. Props to @matej.
I have exactly the same problem with my shelly plus 2PM. Im using 5 shelly Plus 2PM in 3 different rooms. One room of this have only one shelly. All of my Shellys running in the same issue

@userjp123
Copy link

All is ok, when NOT using the physical buttons.

Button press and reaction in HomeKit:
Physical Close-Switch:
WHILE moving: No Homekit change
AFTER stopping in a middle position: Opening… (circle rotating endless)

Physical Open-Switch:
WHILE moving: No Homekit change
AFTER stopping in a middle position: Closing… (circle rotating endless)

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.

@e1l52
Copy link

e1l52 commented May 19, 2023

Same problem here. Since my Shelly 2.5 are gradually dying I now have to replace all the roller shutters.
Is the project still active at all ? I see that the last version is now already 9 months old.

@christophgugger
Copy link

Me to, I have the same problem. Still no fix or news?

@christophgugger
Copy link

And the same issue is also when moving by http command, not only by physical buttons...

@KaeseToBa
Copy link

@matej Did you get it to work properly?

@matej
Copy link
Author

matej commented Jul 4, 2023

I personally used @Nicop51430's suggestion and now use Home Assistant for my Shelly PM2s. That works fine.

@KaeseToBa
Copy link

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

@jonasman
Copy link

I have the same issue, im thinking to change to home assistant just to fix this bug

@kess78
Copy link

kess78 commented Oct 28, 2023

Are there any news on that ?
I'm facing the exact same issue as described...

@hughfr4nc15
Copy link

Same issue.

@1onar
Copy link

1onar commented Dec 10, 2023

Same issue, using the physical buttons doesnt show properly.

@BirknerAlex BirknerAlex linked a pull request Jan 16, 2024 that will close this issue
@BirknerAlex
Copy link

BirknerAlex commented Jan 16, 2024

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.

@dmatik
Copy link

dmatik commented Jan 17, 2024

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,
Thanks o lot!
However, tried your code, did not work for me for some reason, now it is keeps in state "Closing..." with spinner, nevermind if I open or close the cover. And the status updated only if changing from Homekit.
I can see that the code is updated with your changes, and I have restarted the HB.

@BirknerAlex
Copy link

BirknerAlex commented Jan 17, 2024

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

[1/17/2024, 10:13:53 AM] [Shelly NG] [Rollo Wohnzimmer 1] 0 state changed to 1 { target: 96, current: 96 }
[1/17/2024, 10:13:56 AM] [Shelly NG] [Rollo Wohnzimmer 1] 0 state changed to 2 { target: 100, current: 100 }
[1/17/2024, 10:13:56 AM] [Shelly NG] [Rollo Wohnzimmer 1] 0 position changed to 100 { target: 100, state: 2 }

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.

  1. Go to http://<shelly ip>/#/settings/debug
  2. Enable "Enable Websocket debug"
  3. Go to http://<shelly ip>/#/diagnostics

Should now show the real events sent to the homebridge plugin.

@dmatik
Copy link

dmatik commented Jan 17, 2024

@BirknerAlex
Yep, saw your log outputs in the code.
However, for some reason even after starting HB in Debug, not getting the debug outputs for Shelly NG, I do get a lot of debug outputs for other plugins though.
Will try once more later today.

@BirknerAlex
Copy link

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. 🤔

@dmatik
Copy link

dmatik commented Jan 17, 2024

@BirknerAlex
I do run on docker and the file is updated.
However, I have all my covers defined with IP and ID in config.json and not discovered automatically. Might be the reason?

@userjp123
Copy link

Thank you for updating but same problem here:

  • cover.ts updated.
  • no cover.ts-logging
  • Homekit: Closing...

Logging in Homebridge-Status-Wnd: (only with Homekit-Position-change, nothing with buttons)

[18.1.2024, 17:13:03] [Shelly NG] [Shelly-WiGa] Device added
[18.1.2024, 17:13:03] [Shelly NG] [Shelly-WiGa] Device is connected
[18.1.2024, 17:13:03] [Shelly NG] [Shelly-WiGa] Accessory loaded from cache (ID: cover)
[18.1.2024, 17:14:01] [Shelly NG] [Shelly-WiGa] WebSocket: Cover.GoToPosition
[18.1.2024, 17:14:02] [Shelly NG] [Shelly-WiGa] WebSocket: Cover.GoToPosition

It really seems that the new cover.ts is not active.
I am new in Homebridge: Is a Hombridge-restart all I have to do ?

@to0b
Copy link

to0b commented Jan 24, 2024

@BirknerAlex

Thanks für your PR. You forget to mention to rebuild the plugin after changing the cover.ts file.

[24.1.2024, 09:11:31] [Shelly NG] [Rollade Essecke] Device added
[24.1.2024, 09:11:31] [Shelly NG] [Rollade Essecke] Device is connected
[24.1.2024, 09:11:31] [Shelly NG] [Rollade Essecke] Accessory loaded from cache (ID: cover)
[24.1.2024, 09:11:32] [Shelly NG] Saving 1 device(s) to cache
[24.1.2024, 09:11:40] [Shelly NG] [Rollade Essecke] WebSocket: Cover.GoToPosition
[24.1.2024, 09:11:41] [Shelly NG] [Rollade Essecke] 0 state changed to 0 { target: 90, current: 100 }
[24.1.2024, 09:11:41] [Shelly NG] [Rollade Essecke] 0 target position changed to 90 { state: 0, current: 100 }
[24.1.2024, 09:11:43] [Shelly NG] [Rollade Essecke] 0 state changed to 2 { target: 90, current: 90 }
[24.1.2024, 09:11:43] [Shelly NG] [Rollade Essecke] 0 position changed to 90 { target: 90, state: 2 }
[24.1.2024, 09:11:43] [Shelly NG] [Rollade Essecke] 0 target position changed to 90 { state: 2, current: 90 }
[24.1.2024, 09:11:50] [Shelly NG] [Rollade Essecke] 0 state changed to 1 { target: 90, current: 90 }
[24.1.2024, 09:11:50] [Shelly NG] [Rollade Essecke] 0 state changed to 2 { target: 90, current: 92 }
[24.1.2024, 09:11:50] [Shelly NG] [Rollade Essecke] 0 position changed to 92 { target: 90, state: 2 }

The status is still not correctly given back to the Home app if I manually control the Shelly with the buttons:

alt text
alt text

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.
alt text

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:
diagnostics-shelly-plus2pm-debug-log.txt

@B1ll4b0ngm3
Copy link

Is there any Solution for this issue ? I still got these problem with the 2pm.

@MaDDeePee
Copy link

i got that problem to. :(
My 2.5 are dying and i need to deal with 2pm - without working state notification.

@dmatik
Copy link

dmatik commented Sep 28, 2024

Well...
I switched to Matterbridge, works perfectly with all Shelly devices I have, included 2PM.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.