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

[matej]

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:

https://user-images.githubusercontent.com/91322/206855612-f611d7db-343a-40da-a943-5d150064740c.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]

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

[Nicop51430]

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]

Same Problem here !

[larsjtx]

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]

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]

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]

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]

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]

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

[christophgugger]

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

[KaeseToBa]

@matej Did you get it to work properly?

[matej]

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

[KaeseToBa]

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]

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

[kess78]

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

[hughfr4nc15]

Same issue.

[1onar]

Same issue, using the physical buttons doesnt show properly.

[BirknerAlex]

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]

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]

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]

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

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]

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

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]

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

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

[MaDDeePee]

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

[dmatik]

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