2.12.1 has a bug with setting Home app Rolling Shutter slider to fully closed / open does the opposite on multiple devices.

[tzickel]

I installed in a rolling shutter Shelly Plus 2PM and put the latest firmware 2.12.1 (20240623-075044/2.12.1-g417cbdf).

If I put the sliders in the Home app to the state "Closed" (It doesn't say 0% open), it will jump to "Opened" state (again, doesn't say 100% open). And if I slide it all the way to the other side to the "Opened" state, it jumps all the way to "Closed" state...

If I tell Siri though to close / open the blind, it works fine...

I found an old Shelly 2.5 with firmware 2.10.1 connected it to another rolling shutter, and it works just a fine with the slider...

Update: updated the old shelly 2.5 to latest firmware, has same bug. This is on iOS 17.5.1 BTW (With no home hub if relevent).

[tzickel]

Here is the logs when moving from 3% open to closed, and instead if jumps to opened:

9288601099 shelly_main.cpp:483     Up 9288.59, HAP 0/1/16 ns 1, RAM: 210028/199268; st 50; 4.1: c:1 mp:133.81 ip:5.00 mt_ms:20190 cp:3.84 tp:3.84 md:0 lmd:1
9292897440 shelly_hap_window_c:375 WC 1: HAPSetTgtPos 1.00 cur 3.84 tgt 3.84 lmd 1
9292902880 shelly_hap_window_c:350 WC 1: Tgt pos 3.84 -> 1.00 (HAP)
9292908576 shelly_hap_window_c:330 WC 1: State: idle -> move (0 -> 20)
9292976979 shelly_output.cpp:64    Output 1: off -> on (move)
9292983029 shelly_hap_window_c:330 WC 1: State: move -> rampup (20 -> 22)
9293077634 shelly_hap_window_c:552 P = 108.74 -> 133.81
9293083702 shelly_hap_window_c:330 WC 1: State: rampup -> moving (22 -> 23)
9293578867 shelly_hap_window_c:350 WC 1: Tgt pos 1.00 -> 1.43 (fixup)
9293584021 shelly_output.cpp:64    Output 1: on -> off (moving)
9293589791 shelly_hap_window_c:330 WC 1: State: moving -> stop (23 -> 24)
9293798651 mgos_sys_config.c:323   Saved to conf9.json
9293805873 shelly_hap_window_c:330 WC 1: State: stop -> stopping (24 -> 25)
9293818826 shelly_hap_window_c:330 WC 1: State: stopping -> idle (25 -> 0)
9293829817 shelly_hap_window_c:375 WC 1: HAPSetTgtPos 0.00 cur 1.43 tgt 1.43 lmd 2
9293835654 shelly_hap_window_c:350 WC 1: Tgt pos 1.43 -> 100.00 (HAPalt)
9293841229 shelly_hap_window_c:330 WC 1: State: idle -> move (0 -> 20)
9293877098 shelly_output.cpp:64    Output 2: off -> on (move)
9293882980 shelly_hap_window_c:330 WC 1: State: move -> rampup (20 -> 22)
9293977556 shelly_hap_window_c:552 P = 107.67 -> 133.81
9293983719 shelly_hap_window_c:330 WC 1: State: rampup -> moving (22 -> 23)
9294279178 shelly_hap_window_c:340 WC 1: Cur pos 2.36 -> 2.85, P = 134.18
9295079219 shelly_hap_window_c:340 WC 1: Cur pos 6.32 -> 6.82, P = 134.28
9295879451 shelly_hap_window_c:340 WC 1: Cur pos 10.28 -> 10.78, P = 134.21
9296601488 shelly_main.cpp:483     Up 9296.59, HAP 0/1/16 ns 1, RAM: 209964/199268; st 51; 4.1: c:1 mp:133.81 ip:5.00 mt_ms:20190 cp:14.24 tp:100.00 md:1 lmd:1

[tzickel]

Here are the logs from the Shelly 2.5 (not the Plus above) that work fine moving from 3% to closed (running 2.10.1 though):

1132653806 shelly_main.cpp:513     Up 1132.64, HAP 0/1/12 ns 1, RAM: 27056/42160; st 49; 4.1: c:1 mp:112.93 mt_ms:15989 cp:3.58 tp:3.58 md:0 lemd:0 lhmd:0
1136719968 shelly_hap_window_c:370 WC 1: HAPSetTgtPos 2.00 cur 3.58 tgt 3.58 lhmd 0
1136725873 shelly_hap_window_c:347 WC 1: Tgt pos 3.58 -> 2.00 (HAP)
1136732028 shelly_hap_window_c:327 WC 1: State: idle -> move (0 -> 20)
1136804051 shelly_output.cpp:63    Output 1: off -> on (move)
1136810767 shelly_hap_window_c:327 WC 1: State: move -> rampup (20 -> 22)
1136905273 shelly_hap_window_c:549 P = 93.75 -> 112.93
1136911801 shelly_hap_window_c:327 WC 1: State: rampup -> moving (22 -> 23)
1137104725 shelly_hap_window_c:347 WC 1: Tgt pos 2.00 -> 2.42 (fixup)
1137110662 shelly_output.cpp:63    Output 1: on -> off (moving)
1137116526 shelly_hap_window_c:327 WC 1: State: moving -> stop (23 -> 24)
1137224703 mgos_sys_config.c:232   Loading conf2.json
1137363773 mgos_sys_config.c:174   Saved to conf9.json
1137371779 shelly_hap_window_c:327 WC 1: State: stop -> stopping (24 -> 25)
1137386854 shelly_hap_window_c:327 WC 1: State: stopping -> idle (25 -> 0)
1137760074 shelly_hap_window_c:370 WC 1: HAPSetTgtPos 0.00 cur 2.42 tgt 2.42 lhmd 0
1137765909 shelly_hap_window_c:347 WC 1: Tgt pos 2.42 -> 0.00 (HAP)
1137772011 shelly_hap_window_c:327 WC 1: State: idle -> move (0 -> 20)
1137802388 shelly_output.cpp:63    Output 1: off -> on (move)
1137809167 shelly_hap_window_c:327 WC 1: State: move -> rampup (20 -> 22)
1137903467 shelly_hap_window_c:549 P = 93.53 -> 112.93
1137909726 shelly_hap_window_c:327 WC 1: State: rampup -> moving (22 -> 23)
1138105358 shelly_hap_window_c:336 WC 1: Cur pos 1.88 -> 1.25, P = 111.99
1138203701 shelly_hap_window_c:599 Moving to 0, p 112.26
1139002966 shelly_hap_window_c:599 Moving to 0, p 0.00
1139803144 shelly_hap_window_c:599 Moving to 0, p 0.00
1140603054 shelly_hap_window_c:599 Moving to 0, p 0.00
1140653603 shelly_main.cpp:513     Up 1140.64, HAP 0/1/12 ns 1, RAM: 27056/42160; st 49; 4.1: c:1 mp:112.93 mt_ms:15989 cp:0.00 tp:0.00 md:2 lemd:0 lhmd:2

[tzickel]

Ok, I updated my poor old shelly 2.5 to newest firmware now, and it has the same bug too :(

[markirb]

https://github.com/mongoose-os-apps/shelly-homekit/compare/2.10.1..master#diff-83af29c79c513510ea62e6345632c7e86a0db353bb445dc58c70803d73b24e67

this is the diff from 2.10.1. not much actually... but this should make a difference. looks like your 3 to 0 is interpreted as a tap (HAPalt) and not a target position?

[tzickel]

this is the diff from 2.10.1. not much actually... but this should make a difference. looks like your 3 to 0 is interpreted as a tap (HAPalt) and not a target position?

I have no idea what it means. All I'm doing is sliding the slider in iOS 17.5.1 to the edge (i.e. where the home app says Open or Close).

[github-actions]

This issue is stale because it has been open 3 weeks with no activity. Comment or this will be closed in 1 week.

[github-actions]

This issue has now been closed, as no update was provided after it was marked stale. Feel free to provide updates to reopen this issue.

[tzickel]

Ahh, the let's auto close stuff instead of fixing them way, good luck.

[timoschilling]

If we look on the protocol, we can't see a bug, that's why the issue is closed, otherwise we would add a confirmed-bug label and the issue would stay open.

Please make a video where we can see the log, you window and the iOS UI during the change.

You can test the following thing: tell siri to open it to 25%, 50%, 75%, close and open, does that work as expected?

We often have this kind of issue and it's strange behavior of iOS. I have some original certificated Velux roller shutter and even they have the problem in some iOS versions. The shutters didn't get software updates so it must be get broken and fixed by iOS.

[naanlizard]

Happening for me as well, on 5 brand new Shelly Plus 2PM flashed with the latest firmware as of this post

Telling siri to open or close works, but dragging specifically on the slider in the homekit UI shows the bug

[gmuth]

If this would be an iOS bug using (close) via the mongoose-homekit-webapp should work. however this does not work either. Even if iOS would send confusing commands this should not lead to a wrong position state.
The issue does not always happen - so recording is difficult.

[markirb]

I agree that this seems to be a Bug in this change quoted above:

https://github.com/mongoose-os-apps/shelly-homekit/compare/2.10.1..master#diff-83af29c79c513510ea62e6345632c7e86a0db353bb445dc58c70803d73b24e67

This needs a very deep look

[markirb]

I specifically think it is this commit: 9279566

So I need you help. I build a version without this, can you try if this is the cause?

shelly-homekit-ShellyPlus2PM.zip
shelly-homekit-Shelly25.zip

[gmuth]

Markus, thanks a lot!
Yesterday I removed the device from homekit and reverted back to 2.11.2 for further monitoring (and looking into logs each time opening or closing the shutter. I'll install this version (20241003-075605/2.12.2-2-g0d240e1-wc_fix), add the device to homekit and see what happens. In the past the issue came up once or twice a week when using automated opening and closing. So relevant feedback need some time.

[gmuth]

The issue still exists:

I triggered "open shutter" using HomeKit with iOS 17.7:

311813350965 shelly_debug.cpp:231    No log file, sending new entries
311817312869 shelly_main.cpp:477     Up 311817.30, HAP 0/1/12 ns 1, RAM: 27012/18440; st 33; 4.1: c:1 mp:106.62 ip:5.00 mt_ms:23812 cp:0.00 tp:0.00 md:0 lemd:2 lhmd:2
311825313116 shelly_main.cpp:477     Up 311825.30, HAP 0/1/12 ns 1, RAM: 27012/18440; st 33; 4.1: c:1 mp:106.62 ip:5.00 mt_ms:23812 cp:0.00 tp:0.00 md:0 lemd:2 lhmd:2
311833313050 shelly_main.cpp:477     Up 311833.30, HAP 0/1/12 ns 1, RAM: 27012/18440; st 33; 4.1: c:1 mp:106.62 ip:5.00 mt_ms:23812 cp:0.00 tp:0.00 md:0 lemd:2 lhmd:2
311841313153 shelly_main.cpp:477     Up 311841.30, HAP 0/1/12 ns 1, RAM: 27012/18440; st 33; 4.1: c:1 mp:106.62 ip:5.00 mt_ms:23812 cp:0.00 tp:0.00 md:0 lemd:2 lhmd:2
311849313042 shelly_main.cpp:477     Up 311849.30, HAP 0/1/12 ns 1, RAM: 27012/18440; st 33; 4.1: c:1 mp:106.62 ip:5.00 mt_ms:23812 cp:0.00 tp:0.00 md:0 lemd:2 lhmd:2
311849574219 shelly_hap_window_c:373 WC 1: HAPSetTgtPos 100.00 cur 0.00 tgt 0.00 lhmd 0
311849580259 shelly_hap_window_c:350 WC 1: Tgt pos 0.00 -> 100.00 (HAP)
311849586455 shelly_hap_window_c:330 WC 1: State: idle -> move (0 -> 20)

• no more output was received anymore - the log stream has died
  it looks like the open-event was received: it started to handle the event
  output was switched on (log entry is missing though) roller did open completely!
  my guess: shelly firmware crashed and automatically rebooted (uptime has changed)

• now the state is inconsistent: real shutter is open, but state says 0=closed.

• now closing is impossible:

200901207 shelly_main.cpp:477     Up 200.89, HAP 0/1/12 ns 1, RAM: 26996/21280; st 37; 4.1: c:1 mp:106.62 ip:5.00 mt_ms:23812 cp:0.00 tp:0.00 md:0 lemd:0 lhmd:0
208901179 shelly_main.cpp:477     Up 208.89, HAP 0/1/12 ns 1, RAM: 26996/21280; st 37; 4.1: c:1 mp:106.62 ip:5.00 mt_ms:23812 cp:0.00 tp:0.00 md:0 lemd:0 lhmd:0
216901012 shelly_main.cpp:477     Up 216.89, HAP 0/1/12 ns 1, RAM: 26996/21280; st 37; 4.1: c:1 mp:106.62 ip:5.00 mt_ms:23812 cp:0.00 tp:0.00 md:0 lemd:0 lhmd:0
218824721 shelly_hap_window_c:373 WC 1: HAPSetTgtPos 54.00 cur 0.00 tgt 0.00 lhmd 0
218830659 shelly_hap_window_c:350 WC 1: Tgt pos 0.00 -> 54.00 (HAP)
218836818 shelly_hap_window_c:330 WC 1: State: idle -> move (0 -> 20)
218855296 shelly_hap_window_c:330 WC 1: State: move -> rampup (20 -> 22)
218944785 shelly_hap_window_c:554 P = 0.00 -> 106.62
219044599 shelly_hap_window_c:554 P = 0.00 -> 106.62
219145083 shelly_hap_window_c:554 P = 0.00 -> 106.62
219244648 shelly_hap_window_c:554 P = 0.00 -> 106.62
219344705 shelly_hap_window_c:554 P = 0.00 -> 106.62
219444764 shelly_hap_window_c:554 P = 0.00 -> 106.62
219544702 shelly_hap_window_c:554 P = 0.00 -> 106.62
219644718 shelly_hap_window_c:554 P = 0.00 -> 106.62
219744801 shelly_hap_window_c:554 P = 0.00 -> 106.62
219845005 shelly_hap_window_c:554 P = 0.00 -> 106.62
219944877 shelly_hap_window_c:554 P = 0.00 -> 106.62
220044645 shelly_hap_window_c:554 P = 0.00 -> 106.62
220144619 shelly_hap_window_c:554 P = 0.00 -> 106.62
220244729 shelly_hap_window_c:554 P = 0.00 -> 106.62
220345669 shelly_hap_window_c:554 P = 0.00 -> 106.62
220444566 shelly_hap_window_c:554 P = 0.00 -> 106.62
220544776 shelly_hap_window_c:554 P = 0.00 -> 106.62
220644603 shelly_hap_window_c:554 P = 0.00 -> 106.62
220744269 shelly_hap_window_c:554 P = 0.00 -> 106.62
220844551 shelly_hap_window_c:554 P = 0.00 -> 106.62
220944664 shelly_hap_window_c:554 P = 0.00 -> 106.62
221044677 shelly_hap_window_c:554 P = 0.00 -> 106.62
221145021 shelly_hap_window_c:554 P = 0.00 -> 106.62
221244949 shelly_hap_window_c:554 P = 0.00 -> 106.62
221347129 shelly_hap_window_c:554 P = 0.00 -> 106.62
221445053 shelly_hap_window_c:554 P = 0.00 -> 106.62
221544565 shelly_hap_window_c:554 P = 0.00 -> 106.62
221644914 shelly_hap_window_c:554 P = 0.00 -> 106.62
221745466 shelly_hap_window_c:554 P = 0.00 -> 106.62
221845003 shelly_hap_window_c:554 P = 0.00 -> 106.62
221944781 shelly_hap_window_c:554 P = 0.00 -> 106.62
222044731 shelly_hap_window_c:554 P = 0.00 -> 106.62
222145234 shelly_hap_window_c:554 P = 0.00 -> 106.62
222244920 shelly_hap_window_c:554 P = 0.00 -> 106.62
222344685 shelly_hap_window_c:554 P = 0.00 -> 106.62
222444812 shelly_hap_window_c:554 P = 0.00 -> 106.62
222544775 shelly_hap_window_c:554 P = 0.00 -> 106.62
222644776 shelly_hap_window_c:554 P = 0.00 -> 106.62
222745257 shelly_hap_window_c:554 P = 0.00 -> 106.62
222844852 shelly_hap_window_c:554 P = 0.00 -> 106.62
222944910 shelly_hap_window_c:554 P = 0.00 -> 106.62
223044597 shelly_hap_window_c:554 P = 0.00 -> 106.62
223144586 shelly_hap_window_c:554 P = 0.00 -> 106.62
223244994 shelly_hap_window_c:554 P = 0.00 -> 106.62
223345161 shelly_hap_window_c:554 P = 0.00 -> 106.62
223444839 shelly_hap_window_c:554 P = 0.00 -> 106.62
223544954 shelly_hap_window_c:554 P = 0.00 -> 106.62
223644645 shelly_hap_window_c:554 P = 0.00 -> 106.62
223744998 shelly_hap_window_c:554 P = 0.00 -> 106.62
223844704 shelly_hap_window_c:554 P = 0.00 -> 106.62
223944749 shelly_hap_window_c:554 P = 0.00 -> 106.62
223949494 shelly_hap_window_c:561 Failed to start moving
223955508 shelly_hap_window_c:330 WC 1: State: rampup -> stop (22 -> 24)
224044059 shelly_output.cpp:66    Output 1: on -> off (stop)
224199003 mgos_sys_config.c:323   Saved to conf9.json
224206753 shelly_hap_window_c:330 WC 1: State: stop -> stopping (24 -> 25)
224227816 shelly_hap_window_c:330 WC 1: State: stopping -> idle (25 -> 0)
224244723 shelly_hap_window_c:330 WC 1: State: idle -> error (0 -> 100)
224345801 shelly_hap_window_c:350 WC 1: Tgt pos 54.00 -> 0.00 (error)
224352357 shelly_hap_window_c:330 WC 1: State: error -> idle (100 -> 0)
224901309 shelly_main.cpp:477     Up 224.89, HAP 0/1/12 ns 1, RAM: 26948/21280; st 37; 4.1: c:1 mp:106.62 ip:5.00 mt_ms:23812 cp:0.00 tp:0.00 md:0 lemd:0 lhmd:0
232900699 shelly_main.cpp:477     Up 232.89, HAP 0/1/12 ns 1, RAM: 26996/21280; st 37; 4.1: c:1 mp:106.62 ip:5.00 mt_ms:23812 cp:0.00 tp:0.00 md:0 lemd:0 lhmd:0

• it looks like the inconsistent state is known to the shelly
  the message „Failed to start moving“ indicates that something is wrong.
  it says State: idle -> error (0 -> 100)
  it says Stats: error -> idle (100 -> 0)

• a workaorund could be implemented
  when start moving fails the internal state should be stopped
  issuing "stop" in state "stopped" does not make sense (assuming state=stopped after reboot)
  it could assume something is wrong
  once it realizes the current-position is invalid it could reset cp=5 (or 50 to support both directions)
  this should enable closing again

• detect inconsistent state
  when output is switched on and no power is consumed it can assume the shutter-end-switch has kicked in to avoid damaging the shutter-motor
  this hypothesis can be testet: switch output on opposite direction (tp=tp +/- 5) and check power consumption again

• another solution for power users would be to provide an API to set the cp or cur_pos manually:

  curl http://shelly25/set?cp=100
  echo '{"id":1,"method":"Shelly.SetState","params":{"id":1,"type":4,"state":{"cur_pos":3}}}'\
  |websocat ws://shelly25/rpc

[gmuth]

Issues look related:
#844
#844 (comment)
#920

Could this be 'the' inductive spike hardware issue and potential solution?

[nextgenoperations]

I am also seeing the same issue on a Shelly shellyswitch25. For me it started when I upgraded to 2.11.2, was fine on 2.10.1

If I simply click the square icon on the home app for my shutter to open or close fully or use Siri it all works fine. but I enter the 'slider' page and try and use the slider to open / close the shutter partially, it all goes wrong and shutter never full opens or closes... if I try to fully open, it almost opens, but then starts to close again... odd.

I don't see this as a hardware issue as it was ok until the upgrade to 2.11.2 and the fully open or fully close commands always work fine....and the shelly seems to always present the status on it's webpage (position 100 or 0) it really does seem related to any calculations that are happening when using the slider and 'stepping' through the positions.

[markirb]

What I really take from this is that devices should not reboot when getting triggered. Do you have WiFi Power savings on maximum (IIRC it is 1 for plus devices but 2 for non-plus)?

[gmuth]

Sorry, I did not note the WiFi Power savings setting - I did not change it - so I guess 2.

As for the ticket I suggest two follow up tickets and a label for this common issue like "hardware issue".
The problem looks like the reason is partly a hardware and partly a software issue.
Because the original firmware doesn't seem to have that problem it looks like the shelly-homekit firmware configures or uses the hardware in a different way. There was a change in the past concerning power management to reduce power consumption and cpu-temperature. It think the new configuration has a higher probability to trigger a hardware-failure/CPU-crash. I downgraded to 2.10.1 and get higher temperatures (e.g. 44 degree) but hope to get less reboots.

@markirb, instead of classifying this as bug, I would like to close this one and open two enhancement tickets to look for workarounds to solve this issues: one to set CP manually, another one to detect "i-crashed-while-openning" and "have-to-adjust-cp".

[nextgenoperations]

Just to add I don't see my Shelly 2.5 rebooting when I try to open the shutter with the slider, but happy to re-test if required.

What I see is on 2.10.1 everything was working fine and then on 2.11.2 it broke.

[gmuth]

I've been monitoring the roller shutter device and its behavior using version 2.10.1 for two weeks now and did not have a single issue. So I can also confirm that the behavior identified in combination with the individual setup (shutter motor) and the 2.12 versions has higher probability to crash/reboot during switching - leaving the shelly with a messed up position state.

Software Workaround
Downgrade to Firmware 2.10.1

Hardware Workaround
Install RC Snubbers to "effectively mitigate voltage spikes that can occur during switching of inductive loads"

[markirb]

Unfortunately +2PM is not available in 2.10.1

However I see that all GEN1 devices/ESP8266 seem to have a problem / maybe even a memory leak apparent in RPC calls in versions >2.10.1, which might explain crashes.

Still does not fully explain the +2PM behavior that seems to be the same? or is it another way?