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

[vespaman (Micael)]

I have a few door contacts, and while one of them works, the others don’t.

They are all defined as ‘Contact’ in the item file, but the one working reports OPEN/CLOSED on change while the non-working reports ON/OFF.

I have read that a contact does not accept anything but OPEN/CLOSED, so I added a map file to do this;
(door.map)
OFF=CLOSED
ON=OPEN
NULL=Unknown

… and then I changed the item into;

Contact GF_Corridor_Door_Garage     "Garagedörr [MAP(door.map):%s]"          (GF_Corridor)         {channel="zwave:device:controller:node37:alarm_general1"}

… but since this does not make a difference, I guess this is wrong?
This is on OH2, and the item is a z-wave Fibaro FGBS001.

If I have basic UI open with the item in question, it changes to ON/OFF but if I reload the page, it goes back to CLOSED, regardless if it is actually ON or OFF.

Edit: Found this; https://community.openhab.org/t/map-transform-for-zwave-items/8349?u=vespaman
Maybe this is what I’m experiencing?
Edit2: I guess it is. But I don’t understand what the conclusion was in those threads… Is there a work-around?

[rlkoshak (Rich Koshak)]

There are two places to use a map file, one is in the label, as used here, and the other is in the binding config. Unfortunately when using a mapping in the label all it changes is how the value appears on the sitemap and there is no support for a transform on a zwave Item (as far as I can tell, though I primarily know OH 1 and don’t know if there is an OH 2 addition to support it).

So for what ever reason that device is reporting ON/OFF instead of OPEN/CLOSED so you will probably either need to create a proxy Item and a rule to convert the Switch to a Contact, of just use a Switch to represent that Item.

[chris (Chris Jackson)]

You MUST use the correct type for the channel. In OH2, this is mandatory - it’s not like OH1 where you can simply change the item type and it will work itself out. In OH2, the binding has no knowledge of items or their configuration.

You don’t mention the device or channel - we can take a look at changing it if it’s incorrectly specified.

[vespaman (Micael)]

@chris

You MUST use the correct type for the channel. In OH2, this is mandatory

OK, thanks - this is what I missed. I have used the switch item as a workaround during the week.

@chris

You don’t mention the device or channel - we can take a look at changing it if it’s incorrectly specified.

The device that is wrong, at least in my set-up, is the Fibaro universal sensor, FGBS001, which has two inputs.
I don’t think it makes sense for them to be anything else but a contact.

[chris (Chris Jackson)]

@vespaman

the Fibaro universal sensor, FGBS001, which has two inputs.I don’t think it makes sense for them to be anything else but a contact.

Unfortunately this is the problem with the way OH2 works. While you might think it must be a contact, what if someone wants to use it for a switch, or something else that you haven’t thought of. For universal inputs like this, at the moment there’s no real solution.

I’m happy to change it, but what I can’t do is to keep swapping it each time someone wants a different type.

Ideally, OH2/ESH would allow the user to decide. There has been some discussion on this in different forums, but at the moment I don’t think it’s planned.

[vespaman (Micael)]

@chris

Unfortunately this is the problem with the way OH2 works. While you might think it must be a contact, what if someone wants to use it for a switch, or something else that you haven’t thought of. For universal inputs like this, at the moment there’s no real solution.

I’m happy to change it, but what I can’t do is to keep swapping it each time someone wants a different type.

I fully understand, which is why I forumulated my self like this.

But having thought about it more… when/why would it make sense not to have generic inputs as contacts? I mean, they are not effectively switching anything - there’s no output to be externally controlled on the FGBS001.

I see the problem with this hard-defined concept of OH2, since a change will break rules.

[chris (Chris Jackson)]

@vespaman

when/why would it make sense not to have generic inputs as contacts?

I guess if someone wanted to use a switch (ON/OFF). I do agree that it can be made to work either way, but I suspect someone will want to do something different than you (or me) and we end up in this confusing state.

[vespaman (Micael)]

@chris

I guess if someone wanted to use a switch (ON/OFF).

But wouldn’t that still be contacts? For me, a switch is something with outputs in OH.

Extending this reasoning, I think, while it is more a grey zone, the binary inputs of e.g. Qubino dimmers (the extra 2), should also be contacts. I guess I suggest that it is better to have all binary inputs, that are not controlling anything, default to contacts, and when/if OH2 in the future lets this to be defined, this behaviour can be changed.

Either way, I think it is more consistant to define the inputs of the FGBS001 as contacts - they are after all used in this way most (if not all) of the time. The exact reason for this product is to sit between a IR detector or other sensor of an alarm system - i.e. contacts. But if you disagree, this is fine with me, I have my workaround now, even if it looks ugly in the UI and rules.

[chris (Chris Jackson)]

@vespaman

For me, a switch is something with outputs in OH.

No - in ZWave, a switch can be an input or output. I have switches here that are not connected to anything physically - they just report the switch status to OH.

@vespaman

Qubino dimmers (the extra 2), should also be contacts.

So instead of using ON/OFF for switches, you want to use OPEN/CLOSED? That would be very confusing in my mind. I note below that you say that your workaround for the FGBS ‘looks ugly in the UI and rules’ - then if we changed everything to use contacts, it would look ugly for all of these switches - wouldn’t it? This is definitely incorrect in my mind - sorry.

I’m happy to change the FGBS - I’m sure there are plenty of ‘non-optimum’ channel definitions in the database. The database reader makes a ‘best guess’ of the channel type when it reads the XML files - it can’t know the best channel type, so people need to update them and also the endpoint names if desired… Please feel free to change this.

[vespaman (Micael)]

@chris

So instead of using ON/OFF for switches, you want to use OPEN/CLOSED?

No, in my mind (perhaps not the zwave definition, or indeed OH definition) the third input on the Qubino is just an binary input, not a switch.

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.
The contacts are also this - Open or Closed.

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

I will not make the change to FGBS001, since I think it is contra productive for users that may already have written rules around this, and like you say we can easily get into a contact/switch ‘war’ in the database.

[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 …

[vespaman (Micael)]

@chris

Basically, the fact that something is physically connected to a device shouldn’t (in my mind) alter what it is.

That would be my point!

Well, let’s put it this way; if you are able to control something on and off, you will have to have a relay (switch) or dimmer inside the actuator. So what you see in the UI is this relay or dimmer. Not the actual switch plate on the wall, (which might not even be bistable anyway, and if it was, it would/will go out of sync).

A switch plate on the wall, on the other hand, is an input to something, it is just open or closed. Now, what the text says can be changed with MAP(). But you cannot control this switch plate from the UI - it will not flip over mechanically if you switch it on/off in the UI. Hence the switch plate itself cannot be set ON.

e.g. you switch the lamp on, not the switchplate on the wall. Especially not from the UI.

I’m a electrical/hardware guy by profession, so I realize my view may not be how most people looks at this, and I am content if OH is easily understood be the big mass of people out there. As long as it is consistant.
Actually, in the light of things, maybe there should not even both contacts and switches in that case.

[chris (Chris Jackson)]

I guess we have different views, but then you need to remember that the hardware (ie the ZWave) is reporting a BINARY SWITCH for these devices and the binding doesn’t know, or care, if there is a load connected or not. So, if we took your view, it’s not easy to know in the binding how to handle the two cases…

@vespaman

it will not flip over mechanically if you switch it on/off in the UI. Hence the switch plate itself cannot be set ON.

Not really corerct. Clearly it can’t switch mechanically, but many devices these days have other ways of notifying the use - LEDs for example. So, the wall plate CAN be set to ON.

Anyway, everyone is allowed their view . I agree though - it should be a consistent view across the whole system - not just a ZWave view, but I don’t think this sort of thing is defined…

[vespaman (Micael)]

@chris

hardware (ie the ZWave) is reporting a BINARY SWITCH for these devices and the binding doesn’t know, or care, if there is a load connected or not.

But I must point out, to this, that you are missing my point; if it has possiblity to connect a load - it would be represented by a switch (or perhaps a dimmer). If it has not, something else.

By that note, I think we can leave this discussion.

I’ll concentrate on (perhaps) seasons’ last rhubarb pie with a large cup of coffee instead…

[chris (Chris Jackson)]

@vespaman

But I must point out, to this, that you are missing my point; if it has possiblity to connect a load - it would be represented by a switch (or perhaps a dimmer). If it has not, something else.

No - I’m not missing your point. What I’m saying is that for these switches, in ZWave at least, they use the BINARY SWITCH class to report their status as ON/OFF. What I’m saying is that within the binding, there isn’t any way to know if there is a load connected, or if it’s only a wall plate. It might depend on the exact switch, since they can do different things, but definitely for ones I have they report exactly the same.

[rlkoshak (Rich Koshak)]

I hate to chime in where I’m uninvited and frankly well over my head, but if you take a step back from looking at these things from the perspective of the binding or from the perspective of an electrician and instead from the perspective of a poor shlub like me I think the following rule of thumb makes sense.

If I can control it from OH it should be a Switch. In any possible configuration if at time I can send an “on” or “off” signal to the device (or whatever that OH Switch represents) and the signal is meaningful (e.g. it is not meaningful to send a signal to a PIR from OH), it is a Switch. Otherwise it is a Contact.

Anything else seems to muddy the definition and one starts to ask the question why there are two binary Item types in the first place then.

[chris (Chris Jackson)]

@rlkoshak

Anything else seems to muddy the definition and one starts to ask the question why there are two binary Item types in the first place then.

In my opinion, this is actually the point! Personally, I think item types should be more abstract than they are, and then let the user decide how it’s presented.

It’s not so simple to handle the distinction otherwise - as I said earlier, from the binding perspective, contact or switch, we have the same information being received (ie they both report a binary switch). Currently, in ZWave at least, we can differentiate the two in the database, however I was hoping to remove some of this dependancy in future.

[ellisbjohns (Ellis Johns)]

It’s been been over a year since this topic was begun and it’s still a problem for my setup but I solved it using @rlkoshak’s advice. I needed a way to see a count of how many doors were open in my house and provide my wife with an alert (my toddler escapes on occasion to visit a local construction site). I decided to use 2 aeon ZW120 contact sensors and a monoprice ZD2105 recessed door contact sensor. The aeon sensors report ON/OFF (since they are binary sensors) and the ZD2105 reports OPEN/CLOSED. All sensors monitor whether their respective door is open or closed. My solution was to create the logical/proxy items and associated rules below:

.items file
Contact BasementDoorSensorProxy “Basement Door Sensor” (Doors)
Contact DeckDoorSensorProxy “Deck Door Sensor” (Doors)

.rules entry
//Proxy rules for aeon contact sensors that behave as switches

rule "update Basement proxy door sensor1"
when
Item Door_Sensor_Basement received update OFF
then
sendCommand(BasementDoorSensorProxy, CLOSED)
end

rule "update Basement proxy door sensor2"
when
Item Door_Sensor_Basement received update ON
then
sendCommand(BasementDoorSensorProxy, OPEN)
end

rule "update Deck proxy door sensor1"
when
Item Door_Sensor_Deck received update OFF
then
sendCommand(DeckDoorSensorProxy, CLOSED)
end

rule "update Deck proxy door sensor2"
when
Item Door_Sensor_Deck received update ON
then
sendCommand(DeckDoorSensorProxy, OPEN)
end

//end proxy rules

the solution works but is a total hack. I’m hoping for a cleaner solution in the future. I hope this helps someone else.

[brianmichalk (Brian Keith Michalk)]

By the way, I started this thread:

Z-Wave Switches vs Contacts, and the database

Oh, I read that post several times because it kept coming back as results in my searches. It is exactly the problem I have, and the OP solution is exactly what I implemented. It’s a philosophical debate as to what it should be and can’t be determined at compile time – meaning by the ZWave (or other) database maintainer. I never used OH1, but apparently OH1 allowed one to remap one type of Item to another type of Item. So, as far as I know, the workarounds require virtual items and rules as p…

And you can clean up your rules without explicitly naming each item:
rule:

when 
    Member of gDoorSwitches changed
then
    logInfo("Logger","test: " + triggeringItem.name)
    val i = gDoorSensors.members.findFirst[ dt | dt.name == "v" + triggeringItem.name ]
    if( triggeringItem.state == ON ) {
        i.postUpdate(OPEN)
    } else {
        i.postUpdate(CLOSED)
    }
end

items:

Group:Contact:OR(OPEN, CLOSED) gDoorSensors "The doors are [%s]"
Group:Switch:OR(ON, OFF) gDoorSwitches "The door switches are [%s]"

Contact vDoorGarage "Garage door is [%s]" (gDoorSensors)
Contact vDoorBack "Back door is [%s]" (gDoorSensors)
Switch DoorGarage "Garage door switch is [%s]" (gDoorSwitches) { channel="zwave:device:d8092b29:node4:sensor_binary" }
Switch DoorBack "Back door switch is [%s]" (gDoorSwitches) { channel = "zwave:device:d8092b29:node5:sensor_binary"}

It’s still a hack, but it is cleaner.

[Nadahar (Nadar)]

From the state of this thread, I suppose there is still no solution to this? I have 4 Fibaro FGSD’s, which each have 5 “alarm channels” each (temperature, smoke, tamper, system and battery). These are defined as Switches in the database (mapped to “OK” or “Alarm”), which makes absolutely no sense to me since they are read-only (you can’t SET the smoke alarm). While they read the state when it changes, if you “touch” one of the switches in the GUI by accident, they will change - even though that has nothing to do with the actual status of the sensor. In addition, they have no way of indicating when the state is “unknown” except that neither of the “buttons” are selected - which isn’t intuitive to anyone but the one that set up the system.

If I transform them into something else in the sitemap, I can’t aggregate them. Also, I can’t show them as “subgroups” in the sitemap, because then I don’t get to control how they look/transform them.

I understand that I can create 20 proxy items and write rules for them all, but this isn’t very tempting as a principle. It lays the groundwork for a system that can easily break sometime in the future when something changes in the network and I don’t remember all the details. In addition, I’d have know and care about the order in which the different rules files would execute, as I would need to use the proxy items in yet other rules (that actually react to the alarms).

I have tried reading around this forum, and I haven’t yet seen a good solution. As I see it, the logic with regards to contacts/switches is lacking.

I’d say that would be needed was 3 abstract “binary” types: read-only (contact), write-only and read/write. I’m not sure where I’d put the current switch, as it seems to behave somewhere between the last two. From what I can see, it is read/write in functionality, but write-only in layout designs.

The read/write item should have a design corresponding to a switch with an indicator light

. The “switch” part would then represent the “write”, ie. what is controllable from the UI, while the “light” part would represent the “read”/state.

Given that this will probably never happen, and that the binding can’t always tell (like with z-wave), wouldn’t it at least make sense if it was possible to define an Item as read-only so that the UI won’t let you change it?

I don’t quite understand why more people haven’t raised the issue, as I don’t think the current (2.4) behavior is very intuitive. Are there any solutions to this on the horizon, or anything major that I’ve missed?