Relay: Partial Pulse Time based on fauxESP brightness value (Alexa, blinds 50%)

[0xPIT]

I'd like to 'alexify' my window blinds. My requirement would be to do "Alexa, Blinds 50%" and they close ~half.

I replaced the ESPs in the Etersky WF-CS01 curtain switches with Espruna flashed ones. I presume from a "dry test" that everything works, including relay interlock. However, by virtue of the relay implementation, only fully open or fully closed blinds can be easily supported.

Now I'm thinking: Would it make sense to map fauxESP's brightness value to the relay's pulse time somehow? We might add RELAY<n>_PULSE_TIME_PARTIAL. This would enable something like using RELAY1_PULSE_TIME * brightness% as the actual pulse time. But, this would mean keeping state of the remaining pulse time.

Are there any thoughts on how to do a neat, simple implementation?

[mcspr]

Could it be separate from relays? I assume the idea is to add a 3rd mode to the existing alexa code, in addition to simple relays and lights. Although, relay itself may remain ON / OFF switch. What it is turning ON or OFF may handle the timing by itself using whatever data available.

For Alexa... could something like this HA skill work instead? Either via custom component, or MQTT discovery message announcing cover device.

[0xPIT]

Thinking of it, the key question seems to be do we need to keep state or not and who keeps state?

With the example of blinds, opening (moving it up) takes 36s, closing (moving down) takes only 32s. -> 50% would mean something different if I press up or down then. So button makes more sense than relay, but who will initiate the open or close? If it's a button, and that button keeps state, a later MQTT or other request would not know how far the curtain has moved... Probably all curtains/blinds have end-stop switches, though.

HA Skill: Of course workarounds like that can function, but I'd prefer to keep my infra as simple as possbible, i.e. to "just" Alexa and not introduce additional parties.

[mcspr]

By default, button 'provider' is GPIO, so it needs some kind of physical input. We have a set of states that button produces - it is either a switch, or a button that clicks (or double clicks, or triple clicks). In case the configured action does something with the relay (on, off, toggle), we get the associated index and set the appropriate status.

Relay itself only holds a boolean status and triggers some action when it changes. Default 'provider' sets GPIO level, but it might be a virtual one that does something else (so... see providers. either the hard-coded ones within the relay code, or something external like lights)

Either way, I would explore the idea of making something that controls the cover by itself and then wire the rest. Then, whatever fits better wins :)

re. Timers. This short ones may simply call os_... APIs and use SDK handle by itself. It should be something generic, true, but it was not really needed anywhere else. Plus, time parsing should also be moved, so it is a lot of things at once.