“state” does not update

[markob100]

trafficstars

Describe the bug

The “state” string always shows “open”.

To Reproduce Go to http://YOUR-IP/SOMA-ID

Expected behavior For this field to show Closing Opening Stopped

(or some equivalent thereof) as appropriate.

Additional context I’m not sure if this is a bug with the code or a limitation with the data exposed by the Soma units. The reason I am interested is because I am trying to map these outputs into the PositionState characteristic of the WindowCovering service in HomeKit.

Thanks Mark

[andersonshatch]

This is intentional, at least for now. You should get open for any state except for completely closed. See here: https://github.com/andersonshatch/soma-ctrl/blob/17859209d7f12b596e187734c9f9101a13a9a564/src/SomaShade.js#L55

I think it's probably feasible to add closing, and opening, though I'm not sure on the meaning of stopped. Wouldn't that be open? Or open is only supposed to represent fully open?

[markob100]

I’m thinking about this in terms of the HomeKit PositionState Characteristic. See https://developer.apple.com/documentation/homekit/hmcharacteristictypepositionstate.

Since it doesn’t have ‘open’ and ‘closed’, but ‘opening’ and ‘closing’, ‘stopped’ doesn’t convey any information about position, just that the blind is ‘not moving’.

One other minor thought: HomeKit also has the Characteristic TargetPosition - where the blind thinks it’s moving to (https://developer.apple.com/documentation/homekit/hmcharacteristictypetargetposition). I am mapping the TargetPosition input set by HomeKit (by user) to the POST /<deviceID>/move?position= URL, and that works fine. Ideally, Soma-Ctrl would expose Target Position in the GET /deviceID JSON so that information could be passed to HomeKit if the blind were instructed to move to a specified position by another means (e.g. the Soma app). (I can already extract Position and map that to the CurrentPosition Characteristic (https://developer.apple.com/documentation/homekit/hmcharacteristictypecurrentposition), but that just shows where the blind is right now, not where the device is moving it to.)

Neither of the above really matters - works great, I’m just trying to put the last refinements on wiring it up to HomeKit! I’ll share the HomeBridge config when I’ve got it finished, others might find it useful.

Thanks Mark

Sent from my iPhone

On 23 Aug 2019, at 17:46, Josh Anderson [email protected] wrote:

This is intentional, at least for now. You should get open for any state except for completely closed. See here: https://github.com/andersonshatch/soma-ctrl/blob/17859209d7f12b596e187734c9f9101a13a9a564/src/SomaShade.js#L55

I think it's probably feasible to add closing, and opening, though I'm not sure on the meaning of stopped. Wouldn't that be open? Or open is only supposed to represent fully open?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[andersonshatch]

Thanks for the extra context. I suppose if opening and closing were added, you could assume stopped when you got either open or closed?

Would you be polling the state endpoint to watch for changes from opening/closing to open/closed in order to know when moving had finished?

Target position could also likely be exposed alongside opening or closing in the HTTP response, but this would only ever be the requested position that somactrl knows about; since it holds a connection to each device, you'd not be able to use the app or another means to control it.

[markob100]

1/ Agreed (I could infer stopped from either open or closed) 2/ Yes (I would poll state endpoint every 10s, say) 3/ TargetPosition: I see what you mean. Still, it would be useful to expose it as I’ve now realised that HomeKit wants to obtain a target position or the ‘percentage bar’ on the Home tile snaps back to current position otherwise. So if I move it down from 90 to 60, 60 gets fired to SomaCtrl no problem, and the blind moves there, but the bar in the Home tile immediately snaps back to 90 (until the blind has settled at 60, at which point it updates the bar with CurrentPosition). So user thinks the move from 90 to 60 hasn’t ‘stuck’. It’s a UX issue rather than functional issue.

Sent from my iPad

On 24 Aug 2019, at 14:38, Josh Anderson [email protected] wrote:

Thanks for the extra context. I suppose if opening and closing were added, you could assume stopped when you got either open or closed?

Would you be polling the state endpoint to watch for changes from opening/closing to open/closed in order to know when moving had finished?

Target position could also likely be exposed alongside opening or closing in the HTTP response, but this would only ever be the requested position that somactrl knows about; since it holds a connection to each device, you'd not be able to use the app or another means to control it.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[tedstriker]

From what I've seen, the reason for this lies in soma itself. It doesn't report the current position while moving blinds. The position is reported only after the target position has been reached. What's funny is, that it provides updates of the battery level all the time while changing blind position. The proper way to fix this would be a firmware update of the blinds motor.