A review of openHAB philosophy may be in order around Items.
An Item is an abstract approximation, a model, of some simple device.
Dimmer is a good example. It has a state, just one state, a numeric 0 to 100 percentage.
You can send that Item commands such as ON or INCREASE from UI or rules. Note, those are not related to the state directly.
In the idealized world, those commands get passed via a binding to some real real device. It’s the binding’s business how to manage that,probably using parameters you’ve set in the channel and Things you’ve defined for it. Maybe it sends “dim up”, maybe it sends “127”.
In this generalized model, the device responds with a new status at some time later - “power level G” or “55%” or whatever. The binding’s job is to unravel and translate into a suitable state update for the abstract dimmer Item that we started with - a simple 0-100 number.
In real life it’s never that simple, but understanding the ‘why’ of the core operation is really helpful. For example, clearly a command to an Item is different to updating its state, and causes different follow on effects.
Questions are helpful too, though it would probably be best to post them on a new thread.
OK, so first of all, a more appropriate way to implement this is using a Group:Dimmer. Put both Dimmers into that Group and then send your INCREASE/DECREASE commands to the Group Item. The command will be passed down to the members.
Groups do not only aggregate information from individual member Items, they can also accept commands. Sending a command to a Group causes the command to be sent to all Group members. An example of this is shown by the second group above; sending a single ON or OFF command to that group turns all lights in the group on or off.
As for why your virtual Item didn’t do anything may be a gap in the docs but I’m not sure where that gap can be filled.
When I Item is first loaded by OH, it has a special state NULL: Items | openHAB
NULL is it’s own state type and any Item can have a NULL state.
What I suspect is happening here is that the behavior that occurs when a State is NULL and you issue an INCREASE/DECREASE command is defined by the binding. Some bindings may choose to ignore the command because there is no base number to increase/decrease from, the Item is NULL. Others may treat the command as an ON command. Others might have still different behaviors. If this is the case, the documentation for that will be in the README for the binding, or if it’s not there that is where it belongs.
If that isn’t the case, this indeed should be added to the docs. Though, as evidenced with your first example, there are a lot of docs full of tiny little details that you have to remember and get right. In my experience, adding more to the docs mostly just means that those of us with experience can link the the docs to show you what you missed.
There is no documentation for it because you can’t. I don’t want to be flippant, but it’s unreasonable to expect to document everything that isn’t possible.The only thing you can access in Rules are:
If it’s not there it’s probably not supported. And as should have been made clear in the Concepts section of the docs (if not suggestions are welcome), everything you use in the UIs and your automations (i.e. Rules) mostly deal with Items. So there shouldn’t be an expectation that you could access attributes of a Channel from a Rule.
Thanks that was a valuable hint. I will change my setup and use a Group:Dimmer.
Regarding the Min/Max attributes: How can the PaperUI then work with these? It accepts only values within the boundaries.
PaperUI doesn’t work with these. PaperUI just shows the Thing as you defined in your .things file. If you define the Things using PaperUI, than it lets you actually set these attributes but that is all.
It’s the binding, in this case the MQTT binding, that implements the logic that handles the min/max attributes. How it does so should be in the binding’s docs.
