Open andersonshatch opened 5 years ago
Thanks for this! I will have a look at the weekend.
Sent from my iPad
On 30 Aug 2019, at 17:37, Josh Anderson notifications@github.com 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:
https://github.com/andersonshatch/soma-ctrl/pull/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.
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!
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! :)
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 notifications@github.com 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.
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 notifications@github.com 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 notifications@github.com 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’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 notifications@github.com 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 notifications@github.com 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 notifications@github.com 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.
@andersonshatch any thoughts on the above? Question is 'What’s the downside of ‘restoring’ on reconnect?'
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.
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:
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)
Will address #76 @markob100 would appreciate your feedback on this after some testing.