I’m building a home atomation with Openhab2. First (simple) rules are in place and working.
There are many topics that one needs to think about when building homeautomation yourself. One of these topics is backup and recover, another is limiting points of faillure.
One topic I was thinking of is:
Suppose a “critical” sensor or switch (or in genereal a critical Thing) physicly breaks down in a way that replacing it is the only option.
What woud be best practise for writing rules etc in order to make the process, of physical replacement of a thing, go as smooth as possible?
As a standard I force myself to think of ways so that my wife (who hates these kind of geek stuff) can do it. I’m writing my own manual but the procedure in itself needs to be as simple as possible.
I’m planning to buy as much of sensors/things of the same manufacturer/type. In case of critical points (like floodcontrol in my cellar) I’m planning to buy spare parts.
But still, suppose that for some reason my wife needs to buy a new one and can’t find the same type of “thing”.
Again, with a detailed manuel, she will hopefully succeed in setting up the new “thing”. But what can I do today so that her work tomorrow is as simple as possible? How should I setup my rules?
For the moment I create a group for each item and write my rules based on changes of that group.
In PaperUI adding a new item to a group is simpIe, changing names of the new items is more error prone.
Evenmore since the broken item won’t change its state anymore it can stay in the group for years. I’don’t wont to ask my wife to edit rule-files.
Clearly there are some disadvantages to this practice, a large list of groups is one of them. Most probably more expereinced Openhab coders have come up with a better plan already?
So please don’t hold back!!
A related question: is there maybe already or are there plans to have some sort of “replacing thing” procedure in openhab2. I can imaging my wife connecting to openhab and instead of just “Adding a thing” in paperUI she chooses “Replacing a Thing”. A window pops up with the things currently available (at the top the one that has not been reporting back for a long time and thus chances are that this one is broken). My wife clicks on that item and from thereon the adding procedure starts automatically and runs all the way through to the end. All in a way so that rules and stuff work afterwards.
Or is this Sience Fiction? Or, is this already available but did I overlook the obvious?
Replacing a sensor always means work to do such as to setup the basic parameters (which often are stored in the sensor so they’re gone, too, and need to be re-configured with the new unit).
I wouldn’t leave that to anyone else but you who knows the most about your system. Usually plus some mechanical work.
A good idea is to setup your rules to have a verification routine for each sensor value and the rules to ignore that sensor item if that routine returns ‘invalid’. That way a critical sensor to break should not result in a catastrophe (you should be able to resort to running in a ‘safeguard’ mode to work without that sensor value.
For truely ‘critical’ sensors you should put up 2 or even 3 of them so at least one of them continues to work. That way you shouldn’t need to touch items or rules when a sensor is down, and it’s reasonable as any sensor can break at any time and you cannot be sure how long it takes you to notice and take first measures against. You can then replace the sensor when you’re back home.
The sensor is represented by a Thing and each sensor reading is represented by a Channel. You create an Item that links to that Channel. Your Rules and sitemap and persistence work with the Item. So if you need to replace the device, you simply create or discover the new device Thing and update the link to your Item to point to the new Thing’s Channel.
Rules and UIs and persistence do not change at all. I don’t think it can get any easier than this.
This is also why I strongly promote using meaningful names for your Items that are independent from the device. Frontroom_Temperature is a much better name than Zwave_Node12_Temperature. With the former not only does the name make sense to you, but if you replace the sensor with a device that uses some other technology you don’t have to change the name of your Item to remain consistent.
However, the process and procedures for the creation or discovery of the new Thing will differ from one binding to another and there isn’t much you can do about that except to document it.
Use meaningful names for your Items. You don’t need to touch the Rules.
You might be able to handle more situations by using Member of triggers and the triggeringItem implicit variable. See Design Pattern: Associated Items for examples.
many thanks for you quick answers/support. This is exactly what I needed. I “felt” already that the route of going via groups per channel was not how it should be done.
For some strange reason I never really thought of creating an item in xyz.items so that the channel can be linked to that item. (Overlooking the obvious is my middelname)
I have just checked that procedure and found that the items, that were defined on beforehand in xyz.items, are presented in a drop down in paperUI.
Correct!! Thx!!
Glad that you mentioned it! I have this on my list to!
Didn’t figure that out yet. If you have a good link in mind, don’t hesitate!
I do admit that, since I’m just beginning this journey of OPENHAB with main focus on Zwave-stuff, I’m not yet convinced of the “durability” of the sensors. Therefore, at this stage, I only use them to watch and report and, in the case of critical points, to start a backup-system. In onther words:
In my cellar there is an “semi-pro” system installed to prevent a flood. But also semi-pro systems sometimes fail (I know, believe me). The Openhab with Zwave binding and sensors will “watch” and report what is happening. They will(hopefully) activate a backup system(less pro) in case of problems.
So I guess having a spare part ready to implement is hopefully enough at this point.
I understand what your saying. However when my father passed away a few years back I learned that tomorow live can be different for you and/or your family. The idea that my wife is left with stuff that is frustrating her more than it is doing her good is, at least for me, just no option!
Conclusions, Thx to both of you! I really feel I come closer again to my “perfect” setup.
