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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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…
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…
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… 
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.
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.
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.
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.
By the way, I started this thread:
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.
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?
Don’t really understand what that means. How you represent things on a sitemap has no bearing on how you may give them membership of Group Items, if that’s what you mean.
Yes, using Groups as a sitemap widget to display a collection of Items is limited in this way. It’s not just that you can’t choose e.g. a Text widget, you also can’t choose order of display or colours or visibility or mappings or alternative icons or etc. etc.
People usually abandon this use as they develop more sophisticated sitemaps.
Perhaps it’s not obvious that you create a similar “subgroup” effect in a sitemap with other widgets, with arbitrary settings
Text item=myGroup label="click for more" {
Text item=myContact
Switch item=someItem mappings=[ON="on", OFF="standby"]
}
For what it’s worth, the Switch-Contact debate has been around a few times, but the zwave binding’s interpretation now has the baggage of history. Breaking changes are undesirable.
Thank you for your reply @rossko57. I’m sorry that I don’t explain myself well, I’m just don’t familiar enough with the terms to know exactly what things are called yet.
What I mean is that if I use a Group Item I can aggregate (OR(ON, OFF)) so that I can end up with one status that says “alarm” or “no alarm” per device. Listing all of them just takes way too much screen space. But, if I do this, I have no control over the layout or the transformation/mapping, and I’m stuck with the flawed logic as it is defined by the channel.
If I choose the other “subgroup” effect, where I do have layout control, I can’t aggregate as far as I understand. Sure, I guess I could make a proxy item the I displayed, but again this is a hack/workaround using rules to set basic values. This is what I mean:
Text item=MyProxyAggregatedState {
Text item=FireGroundFloorSmokeAlarm label="Røyk [MAP(alarm.map):%s]"
Text item=FireGroundFloorTempAlarm label="Temperatur [MAP(alarm.map):%s]"
..
}
I guess it just “rubs me the wrong way” that I have to do the value conversions on the “sitemap”/presentation level when it should be done on the “item”/logics level. Everything would work out nicely if you could make things correct on the “item” level, your wouldn’t have to make a lot of workarounds every time you wanted to present the value - be in in a sitemap or in some other “output channel”.
I understand that even logical flaws create precedence in that “everybody” has to implement workarounds that will suddenly break if the flaw is fixed. This is why it’s important to deal with such fundamental logic flaws as soon as they arise, and not let them linger around and manifest themselves. It just gets harder and harder to “get out of”.
That said, I have spent the last… 24 hours fighting with Oomph, class path conflicts, out of memory errors and the like, but it seems I can finally build openHAB, or at least most of it. I must admit that this far there’s lots I don’t grasp when in comes to the structure of the system, how it all ties together, and the modelling stuff, but the Java code itself is easy enough. From the little I have grasped this far, it doesn’t seem like this couldn’t be solved by creating more generic, logical “super item types” that behaves as they ought to, and then let Switch and Contact remain concrete “sub-types” that keep their “legacy behavior” and in this way avoids breaking anything. But, there are large parts that I don’t yet understand, so I guess I would have to do a lot of debugging to see if things would actually work the way I imagine.
Another thing I’ve noticed is that there already is a standardized way of “casting” between the data types within the Item types (acceptedDataTypes etc). It doesn’t seem hard at all to make ContactItem accept OnOffType and SwitchItem accept OnOffType. After all, they are both really just booleans. I don’t know if it’s that simple, but I think it’s worth looking into if this simple change would allow one to define a Switch as a Contact and vice versa.
The problem is that I’ve burned myself before on open-source projects, where I invest time to figure something out, but when I find the solution, the project isn’t really that interested because of reasons not obvious or known to me as an outsider. I hate wasting my time like that, so what I’m really trying to figure out is if there is anything here worth trying to improve, or if this is now simply “how we want to keep it”.
?? No idea what that means.
You can define a Group Item and give it members. You can define an aggregation function to give a Group a state from its members.
None of that is affected in any way by how you choose to display (or not) the group or any of its members.
Have you tried this? There was a reason I gave this example
Text item=myGroup label="click for more" {
You are not compelled to use widgets that happen to have names that match the name of the Item type (if any) involved.
If you have ideas about fundamental changes, OH3 is not yet set in stone and you will find many lively discussions about future paths e.g.
I’m on my phone and don’t have a lot of time but look at Profiles. I think you can use a Profile to transform ON/OFF to OPEN/CLOSED so you can use a Contact Item type for those Channelsb that are erroneously (IMHO) assigned to Switch Items. But like rossko said, there is 7+ years of legacy to deal with on this issue. It’s not as simple as just changing the zwave database.
But please pay attention to what rossko is saying about the Sitemap. If you want a Switch to be read only, use a Text element. You can put a Group Item on the Sitemap as Text or Switch so you don’t need to create a proxy item to see the aggregate values of all the members. This is what rossko’s example does. You can see the aggregate state of the Group and have full control over how it’s members are organized and displayed (if at all).
As for waiting your time, with OH more so than most projects, it is important that you really understand how it all works before venturing to try and make changes to the core. Based on the above I don’t think you are there yet.
Yes, it’s just that I don’t know what you guys call the different concepts. To me that is a “presentation layer” group, while a Group Item is a “logic layer” group. As far as I can see, they both have parts of what I need, but neither can do it all.
Since this is about fire alarms, “click for more” isn’t good enough for me. It must be visually obvious if there is an alarm, at the same time it’s futile to present 20 sensor states on the sitemap “root”. That’s why I need to “aggregate” multiple sensors into one, so that the “top level”/group will clearly warn if any of the “children”/“group members” have an alarm state.
This can be solved using Group Items, but they can’t at the same time convert the input into a presentation that is useful (because of the Switch/Contact issue).
I do understand that I can probably work around this using proxies, rules and other hacks, but as I’ve said above, I doesn’t “feel good” to build something that must use workarounds for the most basic functionality. My experience tells me that is a system that will quickly become unmanageable in the future when it has been untouched for months and the details are no longer in my memory, and thus I’m hesitant to do so.
I guess what I’m trying to understand is why the underlying logic can’t be fixed instead of everybody having to work around it.
Thanks for the link to the openHAB 3 discussions, but I’m pretty sure I need to acquire a LOT more knowledge about the structure of the project to contribute something useful to the discussion. I’ll definitely have a look, but I’d still like to get to the bottom of why this quite simple logical issue has remained unresolved for so long. I can only see two possible reasons (that doesn’t mean there can’t be others):
What I’m afraid of is that this is a symptom of the latter. If that is the case, I can’t defend for myself investing enough time to get the necessary knowledge to actually suggest changes/code, because solving a human/organizational problem is out of my reach anyway.