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?
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.
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
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.
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!
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
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.
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.
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.
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.
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.
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.
I seem to be missing the need of setting the contacts to UNDEF?
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.
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.
@rlkoshak Thank you for making what I consider a “serious” answer, which much have taken some time. I appreciate it.
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.
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.
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.
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.
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.
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.
@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?
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.
@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 
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.
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.
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.
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.
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.