MULTILEVEL_SWITCH START/STOP Level Change support

[cdjackson]

New Aeon devices seem to use the start/stop level change commands and these need to be transferred into an increase/decrease state which is not currently available.

[nullku7]

Is this acceptable to have a work around until ESH sort out how to handle these.

Looking at example switch ZW129

Function 00 = press
Function 02 = held (this is fired ever ~200ms while held)
Function 01 = released (this is send after release)

Can function 2 for the same button just be treated as another button altogether.
From there it can be handled in a rule, such as, read dimmer level, dimmer level + x. If > y then y.

And function 1 also just another button, effectively a LONG_PRESSED.

Ideas and issues with doing it properly.
Hold to go brighter, send 100% over 4 seconds. (where 4 seconds is time for 0-100% regardless of starting level)
On release. Read level, set to level. This effectively stops the dimming function.

This means the system effectively only sends a ‘pressed’ and ‘released’ states
This is not as such a ‘state changing’ but just a ‘set to this level at x rate’. While that rate is changing it can have the ability to break, stopping/replacing the command.
For this implementation, the dimming level and time should be sent as a command. And the receiving device/controller should be able to handle it.
Risks are obvious, for example, a bus may become saturated. A dimmer may not handle requests at that rate. So on.

BUT, that is almost exactly how Clipsal CBUS implement their dimmers and controls, the wall plate only needs to send pressed and released, and the state is changed in the actual dimmer unit, keeping the bus silent.
To fire a dimmed value 5 times a second on cbus would be fine, but to do it to 2 simultaneously it would delay. I can simultaneously dim about 16 lights due to the way the bus communicates, despite being so slow.

Effectively a Dim to level over time needs to be implemented as a primitive, so that ones like aeotec can be used with the likes of cbus without risking breaking anything. And if a bus, such as KNX can handle the amount of messages should be able to be generated in OpenHAB/ESH at a reasonable rate (5hz)

I believe this would also satisfy ESH not wanting to add ‘moving/changing’ states for inputs.

[cdjackson]

I woukd suggest to discuss this on the ESH forum as I don't think this is planned. I already asked if a spinner type would be accessed as a PR but had no answer.

…

Sent from my iPhone

On 18 Oct 2017, at 14:01, nullku7 ***@***.***> wrote: Is this acceptable to have a work around until ESH sort out how to handle these. Looking at example switch ZW129 Function 00 = press Function 02 = held (this is fired ever ~200ms while held) Function 01 = released (this is send after release) Can function 2 for the same button just be treated as another button altogether. From there it can be handled in a rule, such as, read dimmer level, dimmer level + x. If > y then y. And function 1 also just another button, effectively a LONG_PRESSED. Ideas and issues with doing it properly. Hold to go brighter, send 100% over 4 seconds. (where 4 seconds is time for 0-100% regardless of starting level) On release. Read level, set to level. This effectively stops the dimming function. This means the system effectively only sends a ‘pressed’ and ‘released’ states This is not as such a ‘state changing’ but just a ‘set to this level at x rate’. While that rate is changing it can have the ability to break, stopping/replacing the command. For this implementation, the dimming level and time should be sent as a command. And the receiving device/controller should be able to handle it. Risks are obvious, for example, a bus may become saturated. A dimmer may not handle requests at that rate. So on. BUT, that is almost exactly how Clipsal CBUS implement their dimmers and controls, the wall plate only needs to send pressed and released, and the state is changed in the actual dimmer unit, keeping the bus silent. To fire a dimmed value 5 times a second on cbus would be fine, but to do it to 2 simultaneously it would delay. I can simultaneously dim about 16 lights due to the way the bus communicates, despite being so slow. Effectively a Dim to level over time needs to be implemented as a primitive, so that ones like aeotec can be used with the likes of cbus without risking breaking anything. And if a bus, such as KNX can handle the amount of messages should be able to be generated in OpenHAB/ESH at a reasonable rate (5hz) I believe this would also satisfy ESH not wanting to add ‘moving/changing’ states for inputs. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[dmartinpro]

Any update on this issue?

[bobboau]

I could certainly use this as well. It looks like the current driver returns 1.0 for a tap on button 1, 1.2 for holding down, and 1.1 for release. 1.3 for up swipe and 1.4 for down swipe would be an acceptable implementation IMO. I don't care how it works honestly as long as I can do something with the swipes at all.

[dmartinpro]

I clearly do agree. Why OH/ESH isn't able to deal with this behaviour after so many months?

[kaikreuzer]

If I understand it correctly, this is a wall button / remote control, hence this can simply be modelled as a trigger channel - should be pretty straight forward.

[dastrix80]

Hi All

Is the swipe functionality coming soon?

It would be fantastic to be able to dim lights or control volumes using the Aeotec Wallmote

Thanks