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

matej · 2022-12-10T13:01:43Z

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.

The text was updated successfully, but these errors were encountered:

Nicop51430 · 2023-01-18T18:56:30Z

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

Nicop51430 · 2023-01-21T10:39:40Z

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 · 2023-01-25T17:22:18Z

Same Problem here !

larsjtx · 2023-02-15T15:23:17Z

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 · 2023-03-21T05:55:11Z

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 · 2023-05-11T09:42:24Z

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 · 2023-05-19T10:11:14Z

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 · 2023-05-19T18:57:41Z

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 · 2023-06-03T18:23:39Z

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

christophgugger · 2023-06-03T18:26:13Z

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

KaeseToBa · 2023-07-02T08:15:27Z

@matej Did you get it to work properly?

matej · 2023-07-04T09:07:33Z

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

KaeseToBa · 2023-07-04T10:36:40Z

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 · 2023-07-13T14:58:01Z

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

kess78 · 2023-10-28T08:10:07Z

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

hughfr4nc15 · 2023-12-01T10:29:07Z

Same issue.

1onar · 2023-12-10T08:06:59Z

Same issue, using the physical buttons doesnt show properly.

BirknerAlex · 2024-01-16T22:22:36Z

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 · 2024-01-17T07:26:33Z

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 · 2024-01-17T09:17:50Z

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.

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

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

dmatik · 2024-01-17T10:34:07Z

@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 · 2024-01-17T11:02:26Z

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 · 2024-01-17T11:14:10Z

@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 · 2024-01-18T16:25:15Z

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 · 2024-01-24T08:42:03Z

@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:

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

B1ll4b0ngm3 · 2024-04-27T07:23:37Z

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

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

Fixing state update correctly on homebridge #108

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

matej commented Dec 10, 2022 •

edited

Loading

Nicop51430 commented Jan 18, 2023

Nicop51430 commented Jan 21, 2023

BassXT commented Jan 25, 2023

larsjtx commented Feb 15, 2023

MaTr75 commented Mar 21, 2023

KaeseToBa commented May 11, 2023

userjp123 commented May 19, 2023

e1l52 commented May 19, 2023

christophgugger commented Jun 3, 2023

christophgugger commented Jun 3, 2023

KaeseToBa commented Jul 2, 2023

matej commented Jul 4, 2023 •

edited

Loading

KaeseToBa commented Jul 4, 2023

jonasman commented Jul 13, 2023

kess78 commented Oct 28, 2023

hughfr4nc15 commented Dec 1, 2023

1onar commented Dec 10, 2023

BirknerAlex commented Jan 16, 2024 •

edited

Loading

dmatik commented Jan 17, 2024

BirknerAlex commented Jan 17, 2024 •

edited

Loading

dmatik commented Jan 17, 2024 •

edited

Loading

BirknerAlex commented Jan 17, 2024

dmatik commented Jan 17, 2024

userjp123 commented Jan 18, 2024

to0b commented Jan 24, 2024 •

edited

Loading

B1ll4b0ngm3 commented Apr 27, 2024

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

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

Comments

matej commented Dec 10, 2022 • edited Loading

Visual behavior

Status messages

Nicop51430 commented Jan 18, 2023

Nicop51430 commented Jan 21, 2023

BassXT commented Jan 25, 2023

larsjtx commented Feb 15, 2023

MaTr75 commented Mar 21, 2023

KaeseToBa commented May 11, 2023

userjp123 commented May 19, 2023

e1l52 commented May 19, 2023

christophgugger commented Jun 3, 2023

christophgugger commented Jun 3, 2023

KaeseToBa commented Jul 2, 2023

matej commented Jul 4, 2023 • edited Loading

KaeseToBa commented Jul 4, 2023

jonasman commented Jul 13, 2023

kess78 commented Oct 28, 2023

hughfr4nc15 commented Dec 1, 2023

1onar commented Dec 10, 2023

BirknerAlex commented Jan 16, 2024 • edited Loading

dmatik commented Jan 17, 2024

BirknerAlex commented Jan 17, 2024 • edited Loading

dmatik commented Jan 17, 2024 • edited Loading

BirknerAlex commented Jan 17, 2024

dmatik commented Jan 17, 2024

userjp123 commented Jan 18, 2024

to0b commented Jan 24, 2024 • edited Loading

B1ll4b0ngm3 commented Apr 27, 2024

matej commented Dec 10, 2022 •

edited

Loading

matej commented Jul 4, 2023 •

edited

Loading

BirknerAlex commented Jan 16, 2024 •

edited

Loading

BirknerAlex commented Jan 17, 2024 •

edited

Loading

dmatik commented Jan 17, 2024 •

edited

Loading

to0b commented Jan 24, 2024 •

edited

Loading