ON/OFF vs OPEN/CLOSE & Contact item - Cannot get it to work

[chris (Chris Jackson)]

@vespaman

the third input on the Qubino is just an binary input, not a switch.

Ok - I’m not familiar with the Qubino devices, but Fibaro also has this sort of feature with their dimmers, and it works like a switch - not a dry contact.

@vespaman

I guess this is the difference in our way of viewing things… To me, the device a switch is controlling is ON or OFF. The actual (hardware switch) is either open or closed.

Yes, I guess we have different views on things . To me, if I have a switch on the wall, if the button is up, it’s ON, and down, it’s OFF. The fact that it is not physically connected to a load, and that this is done in the home automation system, doesn’t change this from a SWITCH to a CONTACT.

Basically, the fact that something is physically connected to a device shouldn’t (in my mind) alter what it is. I still want to see a switch in my UI so I can turn it ON/OFF - not an OPEN/CLOSED icon.

@vespaman

But we can agree on one thing - which this discussion makes clear - user configuration has to be the best option in the end.

Yes - you might want to find the previous discussions and raise this issue again… This is one at least and I think it links to a discussion in the ESH forum, and on Github.

MAP transform for zwave items?

How does the binding know what state to provide for a channel update when there are multiple item types? In OH1, the binding had visibility of the items so could provide a compatible state, but in OH2 we don’t see the item. If the user can have either a ContactItem, or a SwitchItem, then how does the system reconcile this? It’s obviously fine for commands sent to the binding, so multiple item types is fine in this direction, but when updating a state, shouldn’t there be only one item type? (or …