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...

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...

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...

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...

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...

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...

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

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...