In my binding I currently have one shutter channel for a rollershutter thing.
It can accept commands: %, UP(=0%), DOWN(=100%) and STOP.
It also gets updated to the new % when it stops after a command or after the rollershutter is activated from a physical button.
However some users have expressed the requirement to trigger some rules when the rollershutter starts moving , for example, “up”.
What is the correct design for that?
First option is to implement a second (readonly) channel shutterState (item type: Rollershutter) to be updated based on movements (UP, DOWN, STOP), leaving the current channel shutter as it is (commands + % state updates).
I do not like too much this option as it needs a new channel and is also wrongly using UP(=0%) / DOWN(=100%) as states when in fact it should indicate “going up” or “going down”.
Second option is to still keep just one channel shutter (item type: Rollershutter) and update its state:
from current % --to–> MOVE after a UP / DOWN / % command is received or physical button activates it
from MOVE --to–> STOP and then right after --to–> new % after it is stopped.
the bad of this option is that it does not distinguish UP/DOWN but reports just MOVE, and also that it quickly changes from MOVE to STOP to new % whenever the rollershutter stops.
How about adding a Contact channel (a read-only binary), where the OPEN/CLOSE states reflect the run/stop state of the shutter.
I wouldn’t implement it at all unless you can get reliable “run” status from the shutter. There’s little point in having your binding guessing, people can make their own rules triggered by command and state to do that.
thanks @rossko57
then why not like in first option a new channel with only MOVE/STOP valid states ?
Still it would not distinguish “going up” from “going down”, but just “move”.
Hoever I searched a bit and could not find any other binding with a double channel, one for % commands and one for tracking movement state.
Yes, the shutter hardware reports a reliable going-up/going-down/stop state.
There isn’t a corresponding openHAB Item type with such states. Using a String Item is a bit clonky if you only need a binary go/nogo signal, and would prevent easy management of multiples using Groups with OR AND functions. But …
That changes the story! - you’d prefer to signal all three possible states I guess?
In that case I’d recommend a Number channel, again for easy manipulation in Groups or Rules. Maybe 0 1 2 sensible?
If people want strings in their language, they can apply transforms.
The Modbus binding is an example that automatically makes available several channels from one data Thing - Number, Dimmer, Switch, error timestamp, etc.
There’s a bit added on the end of the channel reference that routes to the umm, sub-channel. Examples channel="modbus:this:that:datathing:number" channel="modbus:this:that:datathing:lastReadSuccess"
So you might end up with something like channel="mybinding:this:that:rollershutter" channel="mybinding:this:that:motion"
