The Great ReBuild of 2019 - Best Practice, ontology and to fix what isn't broken

[rlkoshak (Rich Koshak)]

1. Try to automate the backups if you can. Because of hardware limitations, you will be somewhat limited in what you can do with three environments because, for example, you only have the one Zwave controller. Be sure to take that into account. Don’t over proscribe your development process. Make sure that all the steps you are imposing on yourself actually add value. With a good backup and restore strategy you can recover from a lot of mistakes in no time at all. Ask yourself, are you really gaining anything by having three simultaneous deployments? I’m not saying you are not. I just want you and other users to think about what value the steps add value to you and you are not just doing it because it’s a “best practice.”

2. Yannick has started docs here. I can’t answer your specific questions. I’ve not played with HABot and the ontology yet. But it is admitted to be an initial release so there will be lots of stuff like this that hasn’t been figured out yet.

3. The Design Patterns are good for Rules development. The Tutorials and Solutions section is intended to be this as well. But to a large degree we try not to over define what is and is not a best practice. Every home automation system is different. Even trying to come up with a naming convention recommendation was a controversial and extended argument. Just this week there is a multi-hundred post thread about whether it makes sense to add a couple of sentences to the intro document recommending a hardware platform. We have lots of users with strong and orthogonal opinions on just about everything. So you won’t find much. When we can come up with a consensus, that pretty much always ends up in the Docs (for example, the Item naming convention consensus is in the Item configuration docs Items | openHAB).

4. I see no reason to use Docker on an RPi unless you have other compelling reasons to use Docker (e.g. the rest of your environment is already Dockerized). A straight openHABian will give you the most common deployment of OH. Depending on other problems you might experience, you might consider:

• hosting persistence DBs and Grafana (if you are using them) on a different machine
• moving the file system to an external SSD or HDD to mitigate SD card wear out
• minimizing writes to the SD card to mitigate SD card wear out

But in general, what you propose is a pretty standard install.

5. There is an announcement on this forum in the Announcements category and one or more articles posted to the openHAB Blog. I’m pretty sure you can set the Announcements category to “watching” (button at the bottom of the page I think) and you will get an email for all new posts.

@MrPetter

but should I read your input as Brick/Ecl.SH.Ont having been marginalized (again)…?

I don’t think so. It has only been part of OH for a couple of months now and it is primarily used to drive HABot which not many users are using yet. There isn’t enough of a user base yet to figure out where it’s going, if anywhere.

@yfaway

I would interested to hear how others maintain a separate development environment. Currently I also run on the PI, and develop on it as well. Due to the hardware integration nature, unless the rules are abstract enough, it is not easy to test on a separate hardware that doesn’t have coordinators such ZWave and Zigbee.

I personally do not maintain a separate dev deployment. But if I were to do so, it isn’t the Rules that need to be abstracted, it’s the Items and they already are abstract enough. All you will need to come up with is a way to exercise your Items and Things independent of the hardware since they won’t actually be connected to the devices. Thankfully this isn’t so hard through the REST API or by creating test Rules.

Then all your Rules and sitemaps and such can be developed and tested and when you move it to prod you just need to create the link to the Things (if they don’t already exist) to connect the behaviors to the devices.

Unfortunately development or testing that involves adding new hardware or figuring out a problem with a specific piece of hardware is not going to be possible in dev. You have to have the hardware to test the hardware and the only way to have the hardware is to buy two of them, take the hardware away from prod, or do that development and testing in prod.

@yfaway

I know you’re talking about architecture level, but at a lower level, I would consider whether continuing to use xtend rule is the wise choice now. There are a number of limitations with xtend rules including the inability to test them.

Explain. There are plenty of ways to test Xtend Rules. I’m not necessarily arguing against the recommendation (though unless one wants to move to JSR223 I do think the recommendation is premature) but saying one cannot test Xtend Rules is not a correct statement.

@yfaway

If rules are abstract enough, we can test the logic without needing the hardware.

It’s the Items that need to be abstract, and they are. The Rules don’t care that your LivingRoom_Lamp is connected to a Zwave outlet, an MQTT Sonoff, is a Proxy Item, or is an Unbound/Virtual Item. The Rule will do what you tell it to do on that Item regardless. You as the tester just need to look at your sitemap or watch events.log and openhab.log to see whether the Item changes states as expected when the Rules run. One can even write testing Rules to cause Items to change state that triggers Rules, wait a bit, then check that all the Items are in the expected states once the Rules are done.

@yfaway

We tend to tightly bind our rules to the specific items.

Only if one is not following the Design Patterns and other coding best practices documented here on the forum and elsewhere. Rule can and should be generic. If Rules ARE tightly bound to specific Items then that is a code smell and there might be a better approach.

@yfaway

A possible way to model a HA system is by the physical layout. A Room object can contains various device objects such a Light, MotionSensor, Temperature, and so on. This allows creating a central manager that control/query various aspect of one or more rooms, and allow a layer of abstraction on top of the flat items. When time allowed, I plan to re-factor my current Python light rules, and see if modelling like above works well enough. It bugs me today when the complex light rules aren’t testable.

I find it woks far better to organize your HA system based on function rather than location. When using function (e.g. lighting) you increase the likelihood that similar code will be co-located, increase the chances for shared code, and increase opportunities for code reuse.

@yfaway

It bugs me today when the complex light rules aren’t testable.

What have you tried? This sort of Rule should be very testable. But note that “there ain’t no such thing as a free lunch”. You have to write your tests just like with any programming platform.