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

Setup, Configuration and Use Items & Sitemaps
,
41

I wouldn´t know if a smokealarm cant… I would assume the smokealarm has a test button, and this will send its state when activated.

I understand and accept, there is a problem with contacts if openhab cant read its state when restarting.
But manipulating the contact (ie the openhab contact, not the physical contact) can cause more serious problems, like I mentioned with the open window or even more, if it´s a smokealarm as you mention.
How do you know the state of the smokealarm, to be able to decided when to manipulate the contact? Maybe this smokealarm is faulty. Its state is actually OPEN, (most failsafe devices would be using NO contacts, in case of power lost etc, the contact will OPEN), but you manipulate openhab to believe its CLOSED and working. What will happen in case of a fire in this situation?

When having a option to manipulate a contact in openhab, it´s highly important to understand, that it´s the proxy contact which is beeing manipulated, and not the physical contact itself. (I´m not aware of any devices, where its possible to manipulate the physical contact, without manipulating/activating the device itself). If the device can not report it state back by itself to openhab. The device would need to be triggered/activated somehow for openhab to get the state. If this isn´t possible, I would personally think twice before using such a device in fatal situations (Ie security, alarms etc). Or at least think even harder, before manipulating the contact from within openhab.

Ofcouse you can. You just have to make sure the device can send its state, either by manipulating the device itself, or let openhab read its state (when possible).
I believe most wired modules can send its states when openhab restarting, I have modbus devices as well as IHC devices which works like this). I also have devices which cant. When needed, I do trigger the devices manually to get them to update their state.

No, you trigger the devices to get them to update and send the state. If you cant, you have a situation you can not rely on. Manipulating the proxy item in openhab does NOT solve this situation for you. It may solve some other issues around rules, reporting other states etc in openhab. But the state of the device is the same, (unknown!). Dont you agree?

I dont disagree on the cause. But I highly disagree on the “solution” by manipulating the contact in openhab. Openhab has no control of the state of the device in a situation where it doesnt report its state automaticly and if you cant force it to send its state.

Thats whats highly important to know and to remember. (from my point of view).

When manually manipulating the state of a contact in openhab. Openhab still dont know the state of the physical contact! When doing so, you are “cheating” openhab to think it knows.
Why would anyone want to have a system, where you cant rely on its state?

I know, some would say, what damage does it do manipulating the state of a door/window contact after openhab restarting. It will come back in sync the first time the door/window is “activated” (OPEN/CLOSED). And I agree…
My opinion should be read in general manner - There may be situation where it´s suitable to just do the manually manipulation due to other aspects in openhab. But it´s important for me to stress, you shouldnt, unless you know exactly what you´re dealing with. In case of a door/window sensor etc… You would be better of triggering the contact (open/close the door/window, activte the test button on the smaorkealarm etc), and get the real state of the device returned to openhab. Thats the only way you can rely on the device is working as it´s suppose to.

42

As I said, then buy sensors that report every minute. (And expect to replace the batteries often) Or indeed physically go to all contact type devices in your house in case of a restart of OH.

A contact is not just being updated out of the blue, you can make the conscious decision yourself to either use persistence on Contact items or not, you can make the conscious decision yourself to make rules that update the state of Contact items or not.

If you just decide to leave the Contact items in their undefined state after a restart, that is exactly how they will be: item.state = UNDEF. And that as well can be something you can handle in your rules in whatever way you like.

1 Like
43

Or use USB powered sensors :wink:

44

Thats the price for beeing able to rely on a battery device, at minimum, if it doesnt report itself when openhab starts.
In my opinion, it do sounds more like a question of whats beeing most convenient in the situation. Either taking the walk around in the house triggering the devices manually when needed, or sit back and do the manipulation, while waiting for the device to (hopefully) updated by itself.
(I would assume when its a battery device, its rather easily accessable).

Question is - Whats the need for the manipulation then?
Is it because other things in openhab cant wait for the device to send the update itself. And openhab cant read its state. Maybe the device really isn´t suitable for the situation then?

UNDEF is exactly what you will be overruling when doing the manipulation of the contact. You (not the device) tells openhab the state of the contact. Your device could even be faulty, neither you or openhab would ever notice. Not unless you have a rule to trigger if the device hasnt reported anything else in X-“time” or have others devices depending on the updated state, at a specific time. By manipulating the contact, you´ll have made such a rule become useless.

I have to ask again, whats the need for the manipulation then?

45

I wouldn’t say it is a need, it is a preference. That’s also why I mentioned before that this can be a conscious decision.
UNDEF can be a nasty state that (for example) rules don’t always handle well: think of situations where item.state == ON is not the same as item.state <> OFF.

I’d say you shouldn’t rely on contact items for that in any case. I have windows that don’t open for months, and I’d still like to know if it opens (because then that’s a reason to worry). So I depend on the periodic reporting of the battery level (once per 24 hours or so), while the contact item doesn’t change at all.

46

Items are models. I can for example use a Contact Item to model light/dark. I cannot send it a command instructing the sun to come up.
How I choose to control that model is up to me - perhaps its clock based, perhaps Astro binding, perhaps a photocell. Or perhaps all three.

My point is that you are getting bogged down in the detail of some real device or another, but that does not - should not - dictate the behaviour of our internal generic models. The whole purpose of the model abstraction is to isolate it from all the variations of real world situations.

1 Like
47

That would require God mode :smiley:

EDIT: Actually you could send the command, but you would not get the result. :wink:

48

Ofocuse, this is what you have to do with that kind of device, (or your could just open and close the window when you need to get a new update of its state). If you were using a wired door/window contact, what then?
In both situations, you´ll have to rely on them some way or another. If you dont, there really isnt any idea in installing them at all, or?

Its always up to you what you do with your system. If you would like your contact to indicate the sun is shining in the middel of the night. Its fine with me.
But thats really not my point here.

49

A proxy Item, by definition, is not linked to any device. It lacks a Channel. If you can only change the state of a Contact Item that is linked to a Channel, and you can only change it through that Channel, you cannot have a Proxy Item of type Contact. There is no way to set it’s state.

Not all Items are linked to devices. Not all Items are linked to just one device.

For some use cases, that’s good enough. It’s not our place to dictate what risks of OH getting out of sync with their devices users of OH are permitted to accept at the expense of eliminating the possibility to support some real and currently supported and used use cases.

No I don’t. Because a Proxy Contact is not linked to a device. The only way to modify the state of a Proxy Item is through the UI, or a Rule. If you cannot change the state of a Contact in these ways, you eliminate the possibility of using a proxy Item of type Contact.

I’ll say it gain. A Contact Item is not always linked to a device.

And in cases where you do have devices linked to the Contact, you may not think that the solution is to modify the state of the Contact from OH. But others may have a compelling reason why they do. In my case, I have a number of devices and services that report to Contact Items using MQTT. When one of these devices goes offline I want to set those Contacts to UNDEF. I can’t rely on the MQTT binding for that because the MQTT broker isn’t going down, just one of my EPS8266s or RPis has gone offline. Your proposal eliminates the possibility of this use case.

Any change like this is going to have significant impacts to users. I’ve identified two important use cases your proposal would make impossible. There are more.

Agreed. But a Contact doesn’t always represent a physical device!

What about cases where you have some other device that helps you know the state like in my example above?

So now you are arguing that OH should support restoreOnStartup?

OH should support the user’s ability to model and code their home automation in the way that they want to. You want to have a strict rule that Contacts can only be modified through a Channel? Good, OH let’s you do that. Just don’t code any Rules or anything else that lets you modify Contacts. But why should your approach take precedence over my use cases? You want some guardrails put in place to help enforce your desired approach but it comes at my expense, and I don’t want to pay it. My use cases have as much right to support in OH as yours do.

Not everyone has the option to run power to everywhere they want to have sensors. OH should support both.

This is going to sound harsh and I don’t mean it to be but I can’t think of a better way to say it. Who are you to decide for others what is or is not reliable enough for other users? If you want to design your home automation in this way, that’s your prerogative. But that doesn’t give you the right to dictate that all OH users must follow your approach.

Or maybe your situation isn’t the only situation in which one would want to use a Contact.

Not every Contact is linked to a device. You want to eliminate that possibility.

I think you get an error in the logs when you try to send a command to a Contact and therefore the Contact would not change state as a result of the command.

No, we get your point. But you are missing our point. You want to make it so that our preferences for the use of a Contact to represent something not connected to a device be impossible. You want your preference to overrule ours. You are free to choose sensors that report the way you want them to when OH starts up and you are free to only have Contacts that are connected to devices and only become changed by the binding. OH supports your preference right now. But that’s not good enough. You want to cause OH to enforce your preference on everyone.

50

Then you have a device that you can poll regularly without any penalty.

The convenience that it could provide alone would already give enough reason to install it.
In some countries you can’t really rely on the electricity network, does that mean people in such countries shouldn’t get connected?

51

We need to be clear on, what kind of contact (item) we´re talking about.
This situation came from OH restarting without knowing the state of a contact, and therefore the need to manipulate this. This can either be a contact which is linked to the physical contact (follow the physical contact). As far as I understand, OH do not allow manipulation of this contact (ie it´s the same as read-only). Or it can be a duplicate/proxy item of the original item (the physical contact).
Manipulating the last one is the one I agree should always be possible cause OH wouldnt not anyway.
But it´s also this contact which makes no sense to me manipulating. (I admit, I do not understand your example with MQTT), as it will ruin the logic and therefore the need of this specific contact. If you need to manipulate it manually, I fail to see why you would need it automatically.

52

has this turned into some kind of philosophical discussion or a troll festival?

Kim… if you want to use OpenHAB (or any other software), you have to learn to use it within the boundaries of how it works… or write a new program or hack the current version. Since you are well know to have no coding abilities, I guess you are stuck learning to use OpenHAB how it currently works. Tough luck

Close thread
troll fail

1 Like
53

Its far from the same. A situation where you lost the electricity, you most often cant do anything about, Ie you´re not in controle… But a device for a smarthome system is mainly based on choices.

54

Come on, how old are you… Just because I dont share your opinion, I´m trolling?

Well, I better stop then… You cant have other opinions in here!

55

oh please do
of course you can have your own opinion Kim. And express it over and over ad nauseam.
For anybody who enjoys this, here is another thread where you argue your point… 16 posts… figured you would still be busy setting up the new contributor’s maintaining binding database clearinghouse
Is google asistant integration no longer maintained? - #10 by Kim_Andersen

56

There is only one type of Contact Item.

Incorrect. It only stops sendCommand. postUpdate is still allowed and postUpdate is how everything in OH changes the state of a Contact Item, from bindings to Rules.

But they are the same Contact Item. By design, OH treats all Contact Items the same regardless of what Channels it is linked to, or not. There isn’t two types of Contacts. Just the one. If there is any use case that requires allowing updating a Contact from, for example a Rule, than you must allow posting updates to Contact Items. If you somehow lock things down such that only a Channel Link can postUpdate to a Contact Item, you prevent all other uses of Contact Items.

To further elaborate on the MQTT example.

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.

You’re proposal would break this Rule.

I haven’t implemented this yet, but let’s say that I code up some OpenCV code that can tell me whether the garage door is open or closed or moving or what have you. Now I have two sensors that tell me whether the door is open or not, and maybe a little more information. Now I want to combine those two sensor readings into one Contact. So I’d use a Group:Contact:OR(OPEN,CLOSED). But that’s now impossible because the only way to change the state of a Contact is through a Channel Link. The Group:Contact doesn’t have a Channel Link so I can’t aggregate the two sensor readings into one.

Now let’s look at persistence. Let’s say I’m using Contact Items that are driven from outside of OH to detect presence. Maybe I have Tasker publish an update to these Items when my WiFi is near using the Tasker integration with the Android App. Sorry, with your restrictions I can’t use a Contact, which is the correct Item to use for sensors, because there is no Channel Link.

There is only one Contact Item. It isn’t always linked to a Channel. It doesn’t even always represent a device.

If you don’t want to update a Contact from Rules, than don’t do it. Don’t want it to be updated from restoreOnStartup, don’t add the Item to persistence. You have to go out of your way to make that happen anyway. But don’t break my Rules just because you think your approach is the only valid one.

Your approach is handled just fine in OH. Why do you want to break mine?

Interesting, and yet you want to take away my choices.

I’ll say it again. There is only one type of Contact Item. Period. If you add restrictions on it, it impacts all ways to use it.

57

You don’t get the point. You switch from “choice for reliability” as argument to “control”. This only leads away from the point you tried to make. This is in no way helping the discussion.
I’m not going to discuss solely for the sake of having a discussion.

58

This “took off” quickly. I think it’s a bit sad, since I see “both sides” to have valid points here. That said, this is partly beside the point I was trying to make.

When I chose the terms “read-only”, “write-only” and “read/write” I didn’t mean it literally. I meant in the perspective of a user interface. I could, and probably should, have chosen other words. “Input”, “Output” and “I/O” might have been better choices, or maybe some others that I don’t think of right now.

My point is simply that there should be a difference between a UI component that reads/gets data, one that writes/sets data and one that can both read and write/set data. As I interprete openHAB, a Contact translates into a UI component that reads data, while a Switch translates into a UI component that somewhat confusingly both reads/gest and writes/sets data (without visually differentiating between the two).

I think it’s very “unfortunate” that the system, by default, allows UI manipulation of for example z-wave smoke detectors. That doesn’t mean that I’ve ever argued that it shouldn’t be possible to manipulate using rules, databases or other sources.

With regards to the most recent discussion, I agree that it will have to be the responsibility of whoever designs the system to make sure that the system isn’t misleading the users. That said, I almost can’t imagine a situation where I’d actually want to set the value an Item that is linked to a sensor. Storing it in the database ultimately isn’t “good enough” since you can’t pick up changes while the system is down, so “undefined” is the only correct state to have after an update. Sadly, my smoke detectors are battery powered and has this exact problem, but as much as I’d wish I could get rid of the “undefined” status, I prefer that over a “lie”. But, I guess it depends on the sensor and how important you consider the status to be. In my case, we’ve had a fire in our house, our kitchen burned, I ended up with a one year recovery before my lungs were “reasonably normal” again, and we have spent years on trying to get rid of all the smoke and soot damage all around the house and all our things.

I’m saying this to try to explain that I consider it important to be able to rely on the data I read when it comes to fire detection, especially because we really don’t want to live (or die) through another fire. If I’m inside the house, I can hear the siren, but as was the case was when we had our fire, me and my wife were both outside working on clearing snow. If the state of a detector is actually unknown, I would rather know that so I could take whatever action I would deem necessary to figure out the state by other means.

I agree that one shouldn’t make limitations that makes sense in one scenario, that will “ruin” other scenarios. That’s why I would wish that one could define this (read/write/input/output/display/modify/get/set) on the Item level, and I naively thought that this was the intended difference between a Contact and a Switch. As such I see it as very useful to be able to “downgrade” a “read/write” to a “read-only” item, by for example defining a “switch-channel” as a “contact-item”.

It might be a too simplistic solution, but I think something is needed to get a bit more control of this, instead of relying on the presentation code to “protect against” corruption of the state.

59

Lets walk down this idea for the sake of discussion.

First, lets set some basics of OH architecture. OH is an event bus architecture. The way an Item gets updated or commanded is by putting an event on the event bus. The flow of an update is as follows:

<something> -Update Event-> Event Bus -> Item Registry -> Item

<something> can be the the REST API, a binding, a Rule, or persistence through restoreOnStartup (not the UIs because the UIs only issue Command Events). Once the event hits the event bus, they are all handled the same regardless of the source.

If the update causes a change the flow is:

<something> -Update Event-> Event Bus -> Item Registry -> Item -Change Event-> Event Bus -> Rules, Persistence, UIs

Here’s the process for a command:

<something> -Command Event-> Event Bus -> Binding -> device
                                                  -> autoupdate -Update Event-> Event Bus and so on

If you set autoupdate to false, there is no automatic Item update event and the Item will wait for the binding to generate the update so see the flows above. Again, the <something> can be the UI, Rules, REST API, or the UIs (not Persistence restoreOnStartup which only issues updates).

The only difference between a Contact and a Switch is if you try to issue a Command Event to a Contact it will be rejected and generate an error. That is the only difference. Because UIs only issue commands, even if you try to put a Contact on the UI as a Switch, it won’t accept the commands that are generated.

To be clear, there is nothing protecting against the changing of any Item.

Given this, what would it mean to set “read only” at the Item level? Since there is no distinction made based on the source of an Update Event, it would mean that nothing could change that Item’s state to include the Binding. Obviously that is not desired because we at least need to allow the binding to change the state of the Item.

OK, so let’s say that read-only means that only the binding can update the Item. Given the current architecture there really is no mechanism to enforce that. I suppose someone can add some additional metadata to the Event Bus events to indicate where the event comes from and allow events from some sources and not from others. It also means additions to the already over loaded (IMHO) Item configuration to configure this.

Now if we step back for a moment, would this actually solve a compelling need? The only way an Item gets an event is if you actively configure something to generate that event. You link the Item to a Channel which will update the Item. You manually write a Rule that postUpdates or sendCommands the Item. You put it on your sitemap using an element that allows commands to be sent to the Item. You add the Item to your .persist file to use restoreOnStartup. In short, the only way an Item get’s updated is if you make the conscious decision and take a deliberate action to cause that to happen. Otherwise the Item will remain unchanged forever.

Given you have to make a deliberate choice and take a deliberate action to “corrupt” the state of an Item, is it worth the significant added complexity to the implementation and architecture of OH to add some sort of enforcement? Or can you rely on yourself to not write code or make configurations that can cause the Item to become “corrupted”?

Take the following screen shot of one of my sitemap pages.

image
image1632×1171 75.5 KB

Everything you see with the exception of the Date Times are Switch Items (because the Network binding erroneously, IMHO, requires Switch Items instead of Contacts). So these are all read only Items in the sense that only the binding will update their states. Notice there is no way to change these through the UI. I used a Text element and thus the states of these Items cannot become “corrupted”. I have no Rules that postUpdate or sendCommand to any of these Items so my Rules cannot “corrupt” their state. I have no tools external to OH posting updates or commands through the REST API to these Items. I do not use restoreOnStartup on these Items. But not doing anything except controlling how they are presented on the UI (a UI that only I use BTW) the states of these Items are preserved uncorrupted.

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?

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.

1 Like
60

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

There may be some confusion because some widgets have the same name as Item types e.g Switch widget, Switch type Item. For obvious reasons.
Equally, there is for example no such thing as a Contact widget.

If you fail to select a widget, each Item type does have a default widget type associated - for example, a Text widget for a Contact type. That widget allows no user input, it is display only. Tah dah.

If you want to display a Switch type Item but allow no user interaction … you select a Text widget. Tah dah.

For a non-sitemap based UI like HABpanel, you still select exactly the widgets you want, and not the ones you don’t.

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.