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

Setup, Configuration and Use Items & Sitemaps
,
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.

33

Just to add to what @rlkoshak has mentioned, there are lots of reasons why something within OH would want to update the state of a contact item. A typical example of a physical device for which you’d use a contact item in OH, would be a door sensor. Not rarely, those are battery operated devices, which are only sending information to OH when something actually happens at the door sensor.

Now what happens when you have to restart OH? The item within OH will get an UNDEF state. That could for example be set by a persistence service to the last known state. So then the contact item will need to be updated.
And what happens if something actually happened at the door while OH was rebooting? You can not ask the item to give an update (in quite some situations), so you could for example in a System started rule always reset all your contacts to closed, which is again done by updating the item. And that obviously is not going to physically change anything for the door or the door sensor.

34

I agree this is very confusing… There has been several debates about contacts vs switches. And like you, my understanding is pretty simple. You shoudlnt be able to change state of a contact (manually). You´ll have to change the state of the “thing” which is “controlling” this contact. Ie a relay contact… You´ll have to either power the relay or unpower the relay for the contact to switch state. A door/window sensor is simular… You´ll have to open/close door/window, for the contact to change state. If you change the state of the contact, without using it´s “thing”, you´ll geta n out of sync situation, which in my opinion, is not what anyone wants to.
So it makes no sense having a option to change a contact itself. It meaningless and by principal very wrong. Well at least thats my opinion. A contact should always be a read-only state.

As for the UI. In BasicUI you just define the times as a Text type. Just like Rich said. Then you´ll not be able to change it from the UI itself. I´m not sure if this is possible in HabPanel.

35

You will also get out of sync situations if you can’t update the state of the item to match the state of the device, also see my reply above.

36

This problem is cause by openhab not beeing able to get the status of the contact. And this is where this sort of problem should be solved. It will not be solved by having a manual manipulation of the contact itself.
What if you change the state of the contact (a window which shows OFF/OPEN) and then you manually set it to ON/CLOSED. Unfortunaly this window was indeed open. But now you´r alarm system wont notice this sensor correctly.

37

Agree, but this problem should be sorted in another way. Manipulating of contacts is not the way… Again thats my opinion.

38

Perhaps you cannot, because the device - let’s say it is a smoke alarm - only reports in once a day unless activated. We cannot force a redesign of external systems. We can allow openHAB to have features that allow us to deal gracefully with it.

39

Then you could never have a Contact proxy item. You could never have a Contact Item bound to a 1.x version binding, which would be odd since Contact Items have been around since will before they’re was an OH 2. And that would make Contact Items unique along all the Item types.

You have full control over how items are displayed and whether they can be modified in HABPanel too.

Many technologies do not provide a way for OH to interrogate the device to find what state it’s in. Do we just drop support for RF433, MQTT, etc?

One if the driving forces behind OH is inclusivity. This means that there are some things, like being able to update a Contact will be possible even though it may be not as intuitive for you or you happen to be lucky enough to only be using two way technologies. The alternative is a simpler OH that is incapable of supporting all use cases. If that’s what you are after, there are lots of commercial options that are much simpler to set up and use. They are also less capable.

40

No, this is caused by the way a lot of sensors work, and that’s not something OH has any control over.
So if you would “need” this in your implementation, you have to select devices that are always sending their state periodically.