Homekit helpers - target position and opening/closing state

[andersonshatch]

Will address #76
@markob100 would appreciate your feedback on this after some testing.

[markob100]

Thanks for this! I will have a look at the weekend.

…

Sent from my iPad

On 30 Aug 2019, at 17:37, Josh Anderson ***@***.***> wrote: Will address #76 @markob100 would appreciate your feedback on this after some testing. You can view, comment on, or merge this pull request online at: #79 Commit Summary Keep a target position attribute Set opening/closing in addition to open/closed File Changes M src/SomaShade.js (15) Patch Links: https://github.com/andersonshatch/soma-ctrl/pull/79.patch https://github.com/andersonshatch/soma-ctrl/pull/79.diff — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[markob100]

I've had this running for a few days. Stable, but doesn't seem to add the enhancement.

targetPosition

Expected: targetPosition (as displayed on the JSON generated by the GET command) to change immediately on receipt of POST 'move to x' command to 'x'.
What happens: both targetPosition and Position stay at initial position until blind has settled at 'x'.
Example: Blind was at 100. I sent POST command to move to 47. Blind started moving. Both tP and P stayed at 100 (looking at it both in the repeatedly-refreshed browser window and in HK which pulls the data from the webpage JSON) until blind had stopped moving at 47, then both tP and P updated simultaneously to 57.

state
Expected: state (as displayed on the JSON generated by the GET command) to change to 'opening' or 'closing' (as appropriate) when blind is moving from Position to targetPosition. Then to read 'open' if Position is not 0, and to read 'closed' is Position is 0 (existing behaviour).
What happens: State doesn’t seem to change from ‘open’ - I don’t see ‘opening’ or ‘closing’ in the JSON when the blind is moving.

Am I missing something obvious? I've definitely got the right branch installed - I do see 'targetPosition' in the JSON, it just seems to match Position at all times.

Thanks for your work on this - much appreciated, and this is already much more functional than SomaConnect!

[andersonshatch]

I think there was essentially a race sometimes between whether you'd get the targetPosition of what you requested, or the one from the previous state. And state opening/closing I was not changing until the callback from the BTLE write succeeded, so it was definitely after the state is retrieved to be returned with the POST.

I've now moved these to happen earlier, which means they're set on the assumption that the state write succeeds (no error with BTLE comms); sometimes this will not be true, but you should at least see the states more frequently this way. LMK how it looks! :)

[markob100]

Thanks for this - interesting behaviour! If I POST a new TargetPosition, the GET endpoint correctly updates both TargetPosition and State immediately. However, it quickly reverts to mirroring the original Position in TargetPosition and mirroring the original State. In other words: it works as expected at first but then (whilst the blind is still moving) the behaviour reverts to that described previously.

…

Sent from my iPad

On 7 Sep 2019, at 19:57, Josh Anderson ***@***.***> wrote: I think there was essentially a race sometimes between whether you'd get the targetPosition of what you requested, or the one from the previous state. And state opening/closing I was not changing until the callback from the BTLE write succeeded, so it was definitely after the state is retrieved to be returned with the POST. I've now moved these to happen earlier, which means they're set on the assumption that the state write succeeds (no error with BTLE comms); sometimes this will not be true, but you should at least see the states more frequently this way. LMK how it looks! :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[andersonshatch]

Does it get disconnected and subsequently reconnect whilst moving to your target position? That would reset the states, and I’m not sure if it makes sense to restore them, especially if reconnecting is not instant.

…

On 8 Sep 2019, at 21:32, markob100 ***@***.***> wrote: Thanks for this - interesting behaviour! If I POST a new TargetPosition, the GET endpoint correctly updates both TargetPosition and State immediately. However, it quickly reverts to mirroring the original Position in TargetPosition and mirroring the original State. In other words: it works as expected at first but then (whilst the blind is still moving) the behaviour reverts to that described previously. Sent from my iPad > On 7 Sep 2019, at 19:57, Josh Anderson ***@***.***> wrote: > > I think there was essentially a race sometimes between whether you'd get the targetPosition of what you requested, or the one from the previous state. And state opening/closing I was not changing until the callback from the BTLE write succeeded, so it was definitely after the state is retrieved to be returned with the POST. > > I've now moved these to happen earlier, which means they're set on the assumption that the state write succeeds (no error with BTLE comms); sometimes this will not be true, but you should at least see the states more frequently this way. LMK how it looks! :) > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub, or mute the thread. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[markob100]

You’re right - it does. See log excerpt below. I don’t know why I wouldn’t want it to restore rather than reset states on reconnect, though? What’s the downside of ‘restoring’ on reconnect? soma:d12b7e625b6e connected! +0ms soma:d12b7e625b6e position 100 +1s soma:d12b7e625b6e group: Kitchen +32ms soma:d12b7e625b6e name: Kitchen2 +27ms soma:d12b7e625b6e battery at 57% +60ms soma:d12b7e625b6e disconnected +14s soma:d12b7e625b6e connected for 15.683 seconds +1ms soma:d12b7e625b6e flagging disconnect after timeout +15s soma:d12b7e625b6e connected! +646ms soma:d12b7e625b6e position 100 +2s soma:d12b7e625b6e battery at 57% +180ms soma:d12b7e625b6e requesting move to 64 +10s soma:d12b7e625b6e battery at 40% +167ms soma:d12b7e625b6e battery at 49% +240ms soma:d12b7e625b6e battery at 51% +149ms soma:d12b7e625b6e disconnected +3s soma:d12b7e625b6e connected for 15.645 seconds +1ms soma:d12b7e625b6e flagging disconnect after timeout +15s soma:d12b7e625b6e connected! +734ms soma:d12b7e625b6e position 100 +2s soma:d12b7e625b6e battery at 49% +150ms soma:d12b7e625b6e battery at 51% +120ms soma:d12b7e625b6e battery at 49% +195ms soma:d12b7e625b6e battery at 51% +510ms soma:d12b7e625b6e battery at 49% +120ms soma:d12b7e625b6e battery at 51% +600ms soma:d12b7e625b6e battery at 49% +180ms soma:d12b7e625b6e battery at 51% +900ms soma:d12b7e625b6e battery at 49% +120ms soma:d12b7e625b6e battery at 51% +480ms soma:d12b7e625b6e battery at 49% +301ms soma:d12b7e625b6e battery at 51% +404ms soma:d12b7e625b6e battery at 49% +195ms soma:d12b7e625b6e battery at 51% +900ms soma:d12b7e625b6e battery at 49% +120ms soma:d12b7e625b6e battery at 51% +780ms soma:d12b7e625b6e battery at 49% +120ms soma:d12b7e625b6e battery at 51% +375ms soma:d12b7e625b6e battery at 49% +210ms soma:d12b7e625b6e battery at 51% +2s soma:d12b7e625b6e battery at 49% +315ms soma:d12b7e625b6e battery at 51% +1s soma:d12b7e625b6e battery at 49% +180ms soma:d12b7e625b6e battery at 51% +135ms soma:d12b7e625b6e battery at 49% +165ms soma:d12b7e625b6e battery at 51% +900ms soma:d12b7e625b6e battery at 49% +120ms soma:d12b7e625b6e disconnected +2s soma:d12b7e625b6e connected for 15.705 seconds +0ms

…

Sent from my iPad

On 8 Sep 2019, at 21:58, Josh Anderson ***@***.***> wrote: Does it get disconnected and subsequently reconnect whilst moving to your target position? That would reset the states, and I’m not sure if it makes sense to restore them, especially if reconnecting is not instant. > On 8 Sep 2019, at 21:32, markob100 ***@***.***> wrote: > > Thanks for this - interesting behaviour! If I POST a new TargetPosition, the GET endpoint correctly updates both TargetPosition and State immediately. However, it quickly reverts to mirroring the original Position in TargetPosition and mirroring the original State. > > In other words: it works as expected at first but then (whilst the blind is still moving) the behaviour reverts to that described previously. > > Sent from my iPad > > > On 7 Sep 2019, at 19:57, Josh Anderson ***@***.***> wrote: > > > > I think there was essentially a race sometimes between whether you'd get the targetPosition of what you requested, or the one from the previous state. And state opening/closing I was not changing until the callback from the BTLE write succeeded, so it was definitely after the state is retrieved to be returned with the POST. > > > > I've now moved these to happen earlier, which means they're set on the assumption that the state write succeeds (no error with BTLE comms); sometimes this will not be true, but you should at least see the states more frequently this way. LMK how it looks! :) > > > > — > > You are receiving this because you were mentioned. > > Reply to this email directly, view it on GitHub, or mute the thread. > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub, or mute the thread. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[markob100]

@andersonshatch any thoughts on the above? Question is 'What’s the downside of ‘restoring’ on reconnect?'

[andersonshatch]

Haven't had a chance to verify this yet, but I think there will be an issue if the opening/closing state is restored on reconnect, but in fact, the device has already stopped moving.

This is down to the current position characteristic -- which I subscribe to and read on (re-)connect -- only getting updated when the device stops moving.
Whilst it is moving to the target position, we hear nothing from the device, so can only infer that it's stopped moving if there was no reconnect when we next get a current position value.

I think there could be a workaround for that, which is if we're in opening/closing state, check when we get a value for current position and switch to open/closed if it is equal to the target position (or within a few points of it, as sometimes they'll stop before reaching the target position)

Hopefully can verify this in the not too distant future.

[markob100]

I see, and thanks for sticking with this! That workaround makes sense but I wonder if it’ll run into another issue I have (let me know if you want me to open a separate ‘enhancement’ issue for this): the Soma units cut out after 5 minutes of activity. We have large roman blinds and it takes ~7 minutes to open and close them fully. So I have to send the ‘open’ command twice. Using SomaCtrl this is fine - blinds are at 100, I send ‘move to 0’, off they go, after 5 minutes they stop and are at 23. SomaCtrl updates and the position of 23 gets passed through to HK no problem. I just send ‘move to 0’ again and they move the last 23%. But if SomaCtrl ‘knows’ TargetPosition is 0 and it then compares CurrentPosition of 23 with TargetPosition of 0, would the workaround you’re proposing mean it assumes it’s in ‘closing’ state even when stopped at 23? (Also note that on reconnect TargetPosition seems to update to mirror CurrentPosition rather than the last POSTed TargetPosition.) Perhaps I should be focusing instead on why I get disconnects every 15 seconds. Any idea? Wondering about trying a Bluetooth USB dongle instead of the on-board rPi radio. Separately, though, I have been wondering about the 5-minute issue. Would it be possible to re-purpose the workaround you describe above for SomaCtrl to do something like this: - Store TargetPosition POSTed to device - Compare stored TargetPosition with CurrentPosition upon latter being updated (I.e. when device has stopped moving) UNLESS another command received in meantime (e.g. STOP, or a new TargetPosition in which case you go back to the start) - Re-POST TargetPosition if it doesn’t match CurrentPosition What do you think? Here, by the way, is the btmon log showing the BT disconnect and reconnect: ```

HCI Event: Disconnect Complete (0x05) plen 4 #133 [hci0] 40.140877

Status: Success (0x00) Handle: 64 Reason: Unacceptable Connection Parameters (0x3b) @ MGMT Event: Device Disconnected (0x000c) plen 8 {0x0003} [hci0] 40.140930 LE Address: D1:2B:7E:62:5B:6E (Static) Reason: Unspecified (0x00) @ MGMT Event: Device Disconnected (0x000c) plen 8 {0x0001} [hci0] 40.140930 LE Address: D1:2B:7E:62:5B:6E (Static) Reason: Unspecified (0x00) < HCI Command: LE Create Connection (0x08|0x000d) plen 25 #134 [hci0] 40.232883 Scan interval: 60.000 msec (0x0060) Scan window: 30.000 msec (0x0030) Filter policy: White list is not used (0x00) Peer address type: Random (0x01) Peer address: D1:2B:7E:62:5B:6E (Static) Own address type: Public (0x00) Min connection interval: 7.50 msec (0x0006) Max connection interval: 15.00 msec (0x000c) Connection latency: 0 (0x0000) Supervision timeout: 2000 msec (0x00c8) Min connection length: 2.500 msec (0x0004) Max connection length: 3.750 msec (0x0006)

HCI Event: Command Status (0x0f) plen 4 #135 [hci0] 40.235908

LE Create Connection (0x08|0x000d) ncmd 1 Status: Success (0x00) ```