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

Setup, Configuration and Use Items & Sitemaps
,
13

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 :wink:. 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…

14

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. :slight_smile:

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

15

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.

16

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.

3 Likes
17

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.

1 Like
18

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.

2 Likes
19

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.

20

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

example
full800×600
. 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?

21

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.

1 Like
22

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”.

23

?? 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.

24

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.

25

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):

  • There is something major that I’m overlooking that makes the problem much more complicated than I realize.
  • The project has some kind of “internal communication issue” that prevents information and decisions reaching where they should. It can be anything from “large personalities” that will always dig in and defend a decision they have made earlier, regardless of if it makes sense or not, to multiple competing goals/visions to a fractioned decision/responsibility structure that effectively makes all but very “localized” changes very hard.

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.

26

@rlkoshak I think I understand what you mean now, using a Group Item to do the aggregation and then also make a corresponding “presentation group” that merely gets its value form the Group Item. The transformation/conversion will then be the same for the group as for the individual sensors. It might be that this is the “least worst” workaround.

Of course I’m not there, I didn’t intend to give the impression that I thought I was. I’ve just been looking at the code the last 24 hours or so, and as I said there’s a lot of the structure that I don’t understand, and in particular all the modelling stuff.

Not understanding the overall structure of the code base, doesn’t prevent me from focusing in on one small issue and try to understand that though, which is what I’ve done. I’m not anywhere near suggesting a concrete change, I’m just saying that from what I’ve seen this far, I don’t understand what the big hurdle is. What I’m trying to figure out is if I should try to invest the time necessary to acquire enough knowledge to be able to contribute something useful or not. Let’s say that I’m using this issue to try to understand more about the whole project.

That said, I’m not sure I think the problem in with the z-wave device database. I think it’s easy to see situations where you can’t always know if a Switch or a Contact is more appropriate based on protocol information alone, especially if there’s automation involved. That’s why I lean towards thinking that the problem is that openHAB is too rigid instead, at least when you can’t easily modify the “Thing” definition, as is the case with z-wave. I think it would make a lot of sense to be able to define this on the Item level, but there might be reasons that go completely over my head why this isn’t feasible. Until I know about them, it’s hard to factor them in though :wink:

27

Yes, yes they can. See rossko’s example.

Or option three, there is something you don’t yet know it understand which as far as I can tell it’s the case here.

I do exactly what you are trying to do using a Group that aggregates the states. I put the Group on my Sitemap with a text element and I see the aggregate state.

If I want to click on it and see the individual members, just like in rossko’s example, I add the curly brackets and last the items in the order and formatting I desire.

As far as I can tell, the Contact versus Switch issue is a red herring here. It has nothing to do with your actual problem.

The place where the Contract versus Switch issue would be a problem is if you have a mix of Contacts and Switches in the same Group. In that case look at Profiles to see if you can transform the Chanels so you can standardize on one or the other so the Group aggregation works. If profiles don’t work for this then yes, you will need a proxy item for some of the Items to normalize all your members of the Group to be the same type.

No. Create your aggregation Group. Put it on your Sitemap with the Text element. That’s it. You now have a read only element showing the state of your Group Item.

You don’t need to create anything else.

OH is really big. Trying to understand how it works by looking at the code without understanding how to use OH is doing it the hard way. Better to spend your time reading the docs and experimenting and reading the forum examples instead. You will find answers to questions like these much faster and much more easily.

But focusing on the code on this one little issue instead of the docs made you miss the obvious and simplist solution. Just use a Text element to show your aggregation Group on the Sitemap.

I think based on your demonstrated knowledge and experience with OH, your opinion on this matter is premature. You may be right but remember we have nearly a decades worth of development with dozens of really smart developers contributing to OH. And as rossko stated, this issue comes up periodically. This issue has been looked at from just about every angle you can think of.

28

It’s not a red herring to me, but I think I must explain better how I’m thinking for others to understand why. While I’m trying to solve this concrete situation (in the least hacky way I can find), I’m simultaneously trying to evaluate whether to keep using openHAB or to look for some other solution. My experience from running systems tells me that I’m focusing on too many different things to be able to remember lot of exceptions and workarounds the next time I need to make a change. In short, it needs to make sense when I come back to it, or I will probably have to spend considerable time to reacquire the necessary knowledge about limitations and workarounds before I can actually implement the change that I want to make.

The Contact/Switch issue is thus perceived as a “red flag” for me, because it requires a lot of adaptation, that at least for me, isn’t intuitive, to get it working. I agree that a mix of Contacts and Switches would be even worse, but I still see it as a problem that, unless I take precautions, it is possible to set the alarm state from the GUI. This means that I can’t trust the information that’s there (because I can’t tell if the source of the current state was the sensor or the UI), which effectively renders the information useless. Even if I remember to “protect” it from writing most places, forgetting it just one place (be it a sitemap or some other interface like HABpanel), can compromise the value. So, it’s not that it’s not possible to work around, it’s more that I don’t understand why the problem has been “delegated” to the presentation layer instead of being solved on the logic/data layer where I think it should be solved. This is important to me because it tells me if I’m likely to meet other similar problems later, when I’m much more invested in the solution and it’s much harder to back out.

My reason for picking openHAB in the first place was very simple: It’s open-source and it’s Java, which I write more or less on a daily basis anyway. Since these two factors made it such an obvious choice, I didn’t really look at all the details and figured that whatever hurdles I met, they could probably be solved. I guess I’m still trying to figure out if my reasoning hold water :wink:

You may be correct, but all in all that’s the way that my experience has told me is most likely to yield the most fruits. As I’m sure you know, software documentation is usually a field that suffers greatly, it tends to lag behind and often not deal with the more complicated aspects. I’ve tried figuring things out using documentation and forums without really getting anywhere until I start reading the code, that I’ve started to realize that it might be better to just “jump in at the deep end” from the start instead. I’m not saying that it has to be one or the other exclusively though, otherwise I wouldn’t be posting here.

My opinion is “always” premature in the sense that if I gain new knowledge that changes my calculus, I will revise my stance. I can only make a judgement based on the information I have acquired so far, so I’m not trying to make a claim that “this is the fact”. I’m just saying that: This is how it looks to me from what I’ve learned this far.

I’d be very interested in reading more of these discussions. Can anybody give me some hints as the where I can find them? They are probably the “shortest path” to gain the knowledge about the subject that I’m currently lacking.

29

Bear in mind this is equally applicable to e.g. a temperature sensor. That’s just another Number so far as openHAB is concerned; and by design you can choose to alter numbers from a UI as well.

It’s difficult to see why this is exercising you. If you want to view the state of an Item in the UI, you use a Text widget. If you want to change it, you use a Switch or Setpoint or whatever.
These are design decisions that you make; it’s not that onerous.

30

That’s true for Contacts as well. There is no Item type that is read only. You can change a Contract Item too.

If that’s a deal breaker for you then you might look elsewhere, though I believe HA and the commercial home automation system work no differently.

Because there is no way for OH to know a priori whether an Item should be read only. And what does read only mean anyway, only the binding can write to it? What if there is more than one Channel linked to the same Item, which one takes precedence? What if the binding goes offline? What if I have some other way to know what state the contact is in?

There are lots of open questions and your specific use case is one among hundreds. OH needs to support them all.

It’s been delegated to the presentation later because:

  • that’s the simplest solution
  • that’s the most flexible
  • it supports the most use cases
  • the OH Architecture doesn’t give primacy to bindings, meaning bindings, rules, and UIs all have the same right and priority to change an Item’s state
  • the work arounds that you are worried about in practice only rarely need to be deployed and when they do need to be deployed they can be done in a generic manner.

I’ll just point it that you are here largely suggesting making changes to the core of OH because you didn’t read the documentation to realize that there is a way to do what you are after in the first place (presenting the state of a Group Item read only.

Look through the closed issues and prs on the openhab-core repo going back to the beginning.

31

I thought that was the whole difference between the two. I understand that a Contact isn’t truly read-only in that it can be changed using rules or some “rogue widget”, but I thought it was write protected using “standard UI components”. If that’s not the case, I have definitely missed something essential. Wouldn’t that make them different in name/icon only?

If you got the impression that I didn’t read any documentation, I’ve given you the wrong impression. I have read the “basic” documentation I’ve found about the topic, but I haven’t read any manual “cover to cover”. I have also searched for information without getting a whole lot smarter.

Thanks, I’ll take a look and see if I see any lights :wink:

32

The difference is you cannot sendCommand to a Contact. You can postUpdate to any item type. So a Contact isn’t read only, it just can’t be commanded. See the docs for a full discussion on the difference between a command and an update.

It’s kind of write protected in the sense that the UIs only issue commands, never updates. So you can’t change a Contract from a UI. But a UI is one of many ways to changed the state of an Item.

By default, a Contact will use a Text element on the Sitemap as well. Text elements are read only. So from that perspective a Contract is read only. But the UI is only one aspect of OH, and for many of us, the least important aspect. So I think it’s important to not think about any Item type as read only. Even a Contact Item is very much changeable through any part of OH that can issue updates, which is pretty much everything except Sitemaps.