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

[Kim_Andersen]

@rlkoshak

I have an RPi in my garage that, among other things, reports the open/closed state of my garage doors to Contact Items. Let’s say the RPi becomes unplugged. I have Items and Rules in OH that will detect that the RPi is offline. I now know that I have no idea what state the garage doors are in. I can’t rely on the Thing’s ONLINE/OFFLINE status because the MQTT broker is still running so as far as the binding is concerned, the Thing is still ONLINE. But I know the RPi is OFFLINE. So I have a Rule that updates all the sensors attached to that device, including the Contacts, to UNDEF.

I seem to be missing the need of setting the contacts to UNDEF?

[RolfV (Rolf Vermeer)]

Because @rlkoshak rightfully says:
“I now know that I have no idea what state the garage doors are in”

So that would indeed be the perfect case where you would want a contact’s state to be UNDEF.
And subsequently you could do all kinds of things with that state, like stopping a rule that would turn on sprinklers (as you don’t want to risk watering the inside of your garage), or anything like that. I’m just making something up right now, but you could imagine a whole range of uses.

[rossko57]

Perhaps another way to look at it is that Kim wants a new Item type, maybe we could call it ChannelFollower, that links to one (and only one, no more no less) channel and so can only do what a binding tells it.
I imagine you might still be allowed to edit label, or transform state, etc.

I think that idea would be a “hard sell”, as any existing Item type can do this by the simple method of choosing not to provide any tool (rules, UI, other bindings) to amend it.

[Nadahar (Nadar)]

@rlkoshak Thank you for making what I consider a “serious” answer, which much have taken some time. I appreciate it.

@rlkoshak

Finally, a parting comment. No home automation system is capable of providing safety critical functions. If you are looking to try and implement something safety critical on OH without some sort of more reliable backup, you should stop now and abandon your plans. OH, HA, and none of the rest are suitable replacements for fire alarms, burglar alarms, and most especially not suitable in a medical or industrial context. OH can complement systems built for these but OH should never replace or be used instead of.

I’ll start by addressing your “disclaimer”. I understand that there’s no guarantees, and that goes beyond OH as well (computer/OS, the uncertainty of the wireless transfer (z-wave) itself, the network and not the least whatever method you use to be notified). The smoke detectors I use have built-in sirens and work as “regular fire alarms” without involving z-wave/OH at all. This is just an added layer that lets me do additional warning to locations where the siren isn’t audible, so it is indeed just an extension/a compliment. That said, I want it to be as reliable as I can within these limits.

It’s useful for me to read your description of the event bus mechanism because it will hopefully make me able to be more precise when I describe my suggestion. To reiterate, I’ve never meant to suggest that the events themselves should have any kind of “write protection” enforcement. When I’ve said “write protected from the UI perspective”, I simply mean that unless you make a conscious effort to enable changing a “read-only” item’s state, it will not be manipulable from any UI.

My idea that this should be some kind of property of an item, which can be read by involved parties. UI’s and other “control interfaces” would then respect this property. If we think of a switch and a sitemap, this would mean that when using Default or Switch, it would either render this a Text or as a “non-clickable” Switch (whatever was deemed to be most appropriate). In the same way, a Slider for such an item wouldn’t be possible to move and would only display the state it received from update events.

A Contact item would always have this property set since it can never receive commands, but for example Switch items or Dimmer items would not have this set by default.

Ideally I would prefer if this property could be “set automatically” by the binding in those cases where the binding knows that the channel doesn’t accept commands. But, I would also like for this to be possible to define in .items files, so that it is possible to “downgrade” an item from how the binding (or channel) defines it. While I don’t quite see when this would be useful, for the sake of keeping things generic, I guess it should be possible to “upgrade” an item in .items files as well.

As I understand it, this property could then be used by all “control interfaces” whether we’re talking about a sitemap, HABPanel, a voice interface or any other interface. I’m not talking about enforcement, merely information. HABPanel for example, have a checkbox on the Knob widget that “write protects” the widget. This would be a typical use case, where the item property automatically “write protected” widgets when appropriate. When using a Knob to display the temperature from a temperature sensor for example, it’s equally “unhelpful” that the UI allows you to SET the temperature as it is that you can SET the status of a fire alarm.

I understand perfectly well that you already can implement all these “write protections” in the individual UI’s (with some exceptions like Group items), but I see this as a “fragile” way to build a system. For me, the correct “level” to define this is on the item, and once set there, it would automatically be handled correctly in all “control interfaces”.

So, in a sense, Contact/Switch is a red herring after all, because my interpretation of the logic was that a contact was merely a Switch with an “implicit read-only property” (not enforcement). But, I think it’s easier if we all disregard this, the above explanation is hopefully easier to understand/clearer.

@rlkoshak

…(because the Network binding erroneously, IMHO, requires Switch Items instead of Contacts).

As I see it, my suggestion would make the whole Switch/Contact issue much less of an annoyance for everybody, especially when the binding knew that the channels were “read-only” aka didn’t support commands.

@rlkoshak

Do you really need extra guard rails for this? Do you need to protect yourself from yourself? Or can you just refrain from taking the positive actions required to cause these Item’s states to become “corrupted” in the first place?

It’s not that I can’t manage without it. I just see this as an issue that a lot of people will have to face in one way or another, and that could be handled much more intuitively and consistently. It would also allow sitemaps and other “UI configurations” to be much cleaner with less use of proxies, rules and other workarounds.

@rossko57

It really doesn’t work like that.
Each widget in a UI sitemap is selected by you . There are no constraints on that. If you want to present a Rollershutter Item as a Switch, you can. (though it probably will not perform sensibly.)

I understand that, and I think I have already explained what I mean in this post. If you agree or not is another matter, I’m simply trying to explain what I think would be an improvement.

@rossko57

New users frequently get hung up about PaperUI displays, “how can I do xx?” etc.
PaperUI is an administrators interface, it’s a toolbox; naturally it shows the available tools, and is never intended for ordinary daily use. Not least because you don’t even get options about what to show. never mind how.

I strongly suggest having a play with all this.

I don’t understand what you try to say with this, I don’t think I’ve raised any concerns that is related…? If it was a metaphor, I clearly failed to understand it.

[rossko57]

My PaperUI reference ; new OH users will complain about Switch Items where they cannot hide the clickable user action. (or other manipulations, e.g text colour)
There’s no provision in PaperUI to do that because it is an admin interface, not for end users.
Sometimes it comes as a revelation that there are separate “proper” UIs which can be tailored.

You should give some thought to how you’d like your “read only” designation to work in that situation.

There is no need to ever implement rules or proxies to make a display-only item in any of the user facing UIs.

[Nadahar (Nadar)]

@rossko57 Ah, I didn’t even think about UI configured items - but I don’t see why the same “read-only” property couldn’t be configured from the UI. Likewise, when displaying items in PaperUI, it should be easy to show designated items as “unclickable” when showing their state - or am I missing something?

[rossko57]

I don’t know if you’re missing anything, I only observe that users often get in a twist thinking that PaperUi is what they (and their family) should use everyday.

[Nadahar (Nadar)]

@rossko57 Ok, I guess I was there at one stage when I first looked at openHAB as well, but I’m way past that point

[rlkoshak (Rich Koshak)]

@Nadahar

My idea that this should be some kind of property of an item, which can be read by involved parties.

What is the practical advantage between setting a property on the Item to dictate what UIs can allow versus choosing a read only element to present your Item on the UI in the first place. You’ve already said this is a property that only impacts the UI. It’s a UI concern. Why force users to define a UI restriction outside of the UI?

Contact, String, and Number Items (IIRC) are already presented on the sitemap as Text which is read only. If you want to present some other Item on the sitemap to be read only, choose Text as the element.

I still fail to see how adding a property to the Item and all the complexities required to cause the UIs to read that property actually solves the problem any better than what exists. In fact, IMHO it solves the problem in a less clear manner because you are mixing UI and Model in the MVC architecture, you are imposing a great deal of additional complexity on the UIs with some fundamental changes to the assumptions for how the UIs work, and it’s strictly speaking unenforceable. At best OH can say “will you please follow this setting, pretty please?” because the UIs all work through the REST API. If you can do it through the REST API you can do it from a UI.

@Nadahar

If we think of a switch and a sitemap, this would mean that when using Default or Switch , it would either render this a Text or as a “non-clickable” Switch (whatever was deemed to be most appropriate). In the same way, a Slider for such an item wouldn’t be possible to move and would only display the state it received from update events.

What problem does this really solve? Why add all of this complexity and enforce some sort of contract on the UIs when you can just choose a read only element on the UI in the first place? It still just seems like a much more complicated (from an implementation perspective) way to achieve what is already achievable much more simply in the current approach.

@Nadahar

For me, the correct “level” to define this is on the item, and once set there, it would automatically be handled correctly in all “control interfaces”.

I strongly disagree. It is strictly a UI concern and therefore belongs in the View part of the Model View Controller design.

And I fail to see how it is any more fragile than setting it in the UI as you build it. You know what the Item is. You know what it represents (if you don’t you need to go back and figure out your own model again). You know whether it makes sense for it to be read only or not on the UI. So you have both the knowledge and the power to choose the correct way to display that element as read only or not as you build your UI.

And the bindings have that power too. They can choose to use a Contact Item for binary sensors. Problem solved and OH already supports this. The fact that many bindings choose incorrectly (e.g Network) is a different argument.

Once could argue that there should be a “read only” Number Item equivalent, something akin to Contact which doesn’t accept commands. Similarly one could argue that there should be a String Item equivalent that does accept commands to provide symmetry. I could be convinced of that. I don’t think I can be convinced that there should be a setting on Items that independently controls whether an Item can receive a command from a UI. That’s a UI concern and there are already ways to manage this.

@Nadahar

As I see it, my suggestion would make the whole Switch/Contact issue much less of an annoyance for everybody, especially when the binding knew that the channels were “read-only” aka didn’t support commands.

Except it makes the model much more complex. We’ve gone from two options: Switch/Contact to four. And it introduces two ways to implement the same thing. And there is a way to deal with this that could be implemented that doesn’t require this breaking of the current model. The Profiles could be updated to allow for the translation between Item Types so, for example, one could map the ON/OFF from the Channel to OPEN/CLOSED required by the Contact Item. Or one could leverage Groups and a very simple Rule:

rule "Convert Switch to Contact"
when
    Member of SwitchToContact changed
then
    postUpdate(triggeringItem.name+"_Contact", if(triggeringItem.state == ON) "OPEN" else "CLOSED")
end

In Python

from core.rules import rule
from core.triggers import when

@rule("Convert Switch to Contact")
@when("Member of SwitchToContact changed")
def sw_to-cont(event):
    events.postUpdate("{}_Contact".format(events.itemName),
        "OPEN" if event.itemState == ON else "CLOSED")

Or, I can just use a Text element on my sitemap to display them, as I do now. The issue is annoying because it is not consistent across all OH bindings. It’s annoying when two bindings choose differently and you are trying to use the two together (e.g. in a Group that aggregates all the states). Your proposal would not address that. Your proposal only addresses how they get displayed on the sitemap by default.

@Nadahar

It’s not that I can’t manage without it. I just see this as an issue that a lot of people will have to face in one way or another, and that could be handled much more intuitively and consistently. It would also allow sitemaps and other “UI configurations” to be much cleaner with less use of proxies, rules and other workarounds.

But there are no Rules required. There are no work arounds required. If you don’t want an Item to be changed from the UI, don’t choose a UI element that allows changing the Item. The Rules and work arounds are only required if you need to combine Switches and Contacts into the same Group (for example) and your proposal doesn’t address that problem.

Ultimately, you seem to be pushing towards being lazy about creating your sitemap so you don’t have to define every element. And I agree that defining a sitemap can be easier. But I just don’t see that the benefit of being able to use Default instead of Text when you define your sitemap provides any real benefit. There is a tiny bit of benefit in being able to use the Group sitemap element, but there are so many other limitations to using Group (can’t use stuff like visibility, color, control order, etc.) that I don’t see how this proposal would be worth it.

This is just my own opinion. You are free to open an issue on the UIs and the core repos to implement something like this. But I do not think it will be well received. The amount of work required to make it work is huge, it really doesn’t add anything that can’t be done now, and it mixes a View concern with the Model which isn’t supposed to happen.