For sure. A RPi3 is fine, too.
Upcoming openHABian will bring a patch to move most write stuff into RAM. That should compensate for the major weakness of all Pis. Won’t be assured to run on RPi4 for some time but on RPi3.
2 Likes
It’s hard to make a one to one comparison for Rules between systems. But I can say that in openHAB, you usually want to write Rules in a more event driven manner as opposed to polling. Polling is supported of course, but it is more efficient and flows better if you recalculate when the Item that represents one of the things you are calculating changes instead of on a fixed polling period.
This sounds like a pretty average sized setup. I’d expect you to have no problems running it on any of the supported RPis (2B or greater). The only gotcha is it is known that Rules parsing takes a long time on RPis (all of them, though tests on RPi 4 are still under way). And you can avoid that by using JSR223 Rules.
What!? 
That isn’t a ton of devices.
Easily, but the RPi 3 uses significantly less power so a 3B+ might better fit your goals. Except for Rules parsing, it should meet your needs and then some.
Sort of. The RPi 3B+ and RPi 4 support booting from external drives (OK, so RPi 4 will soon support this) so from that perspective it gets you off of the SD card entirely. But it will require more power. You have to weigh the cost of the extra power with the cost of your time in monitoring for SD card wear out and periodically replacing the SD card. And there are lots of ways to mitigate the SD card write problem as well.
1 Like
If you are concerned about SD Cards failing you can get a USB case inexpensively and use a laptop SSD.
I did that since I had the SSD just sitting in a drawer.
1 Like
Here is the case that works for me.
I do both. One reason for regularly recalculating everything is that the box is prone to restarting and when it restarts it loses all its variables (I could of course just run all the rules on startup to fix that). The other reason is that quite a lot of variables alter according to the time of day. You could have schedule-based triggers, but it be would quite cumbersome and the Zipabox schedulers are rather flaky.
I’d certainly want to reevaluate my setup in the light of OpenHab’s capabilities and features.
It’s apparently not average on the Zipabox 
What effect does the slow parsing of rules have?
Yeah. Swings and roundabouts.
openHAB has persistence and a restoreOnStartup strategy to deal with this problem. There is also a System started Rule trigger which can be used to initialize Items and variables when OH starts or parses .rules files.
Unfortunately so are openHAB’s. But there is the Astro binding which triggers Rules based on solar (or lunar or zodiacal) events and we have cron triggers. There is also support for CalDav calendars.
Definitely look at the Design Patterns, especially if you use Rules DSL for your Rules language. Rules DSL is pretty opinionated and if you try to code something in certain ways the Rules will be long and brittle. The DPs are tried and tested approaches to solving common classes of problems in a Rules DSL friendly way.
Two potential effects:
-
It can take an extended amount of time for OH to start up. Times of 30 minutes are not unheard of. You can address some of the problem by avoiding the use of primitives in your Rules but it’s going to take some time to start or parse changes to Rules.
-
You have to be very careful in how you edit your Rules files. Every file change event results in a brand new parse of all the .rules files. If you make more changes while it is actively parsing there will be a backup of parsing jobs created which can end up consuming 100% of your CPU for a good period of time. So you don’t want to edit files in place. Instead make edits in some other folder and then move them over in one copy. Making the copy with OH off might even be an improvement in the time it takes to settle down. I run in a VM so I don’t have a whole lot of direct experience with this.
Today I learned a new idiom. 
1 Like
I’m a software developer so somewhat familiar with the Design Pattern concept. I think my rules are pretty well designed within the limitations of the Zipabox platform, but the OpenHab approach may be very different. Apart from having triggers fire when a particular event occurs (say, the change from day to night), you want to ensure you always have an up-to-date state (is it day or night?) because the trigger might be missed. That’s why I update all the states regularly.
Eeek, 30 minutes is a lot. Presumably a more powerful hardware platform would help there? I’ll hunt around on the forum to see what people are reporting for different platforms.
That sounds reasonable.
You’re welcome!
I strongly suggest using JSR223 Rules then. These are less opinionated and will let you code in “real” languages (Jython, JavaScript, or Groovy). I find people who already know how to program really hate the Rules DSL. That doesn’t mean the Design Patterns are not useful because there are ways that openHAB processes and exposes events that make certain approaches work better than others.
If you look at the Time of Day DP you will see that in the OH approach:
- trigger the Rule at the start of any time period we care about
- also trigger the Rule at System started
- put the result of the time of day determination into an Item.
Thus we should never have a case where we won’t have an up-to-date state, at least for the time of day state. In the off chance that some other Rule gets triggered before the System started trigger causes the time of day Rule to run, that Rule can look to see if the time of day Item is NULL and wait until the time of day Item changes.
I run in Docker on a VM running on ESXi with 2 virtual CPUs and 8 GB of RAM (I have InfluxDB, Mosquitto, and Shinobi also running on this machine). A restart of OH takes two to five minutes. There is something about the RPis, maybe it’s the ARM processor, that causes it to take a long time to parse Rules DSL Rules. If you use JSR223 though, it’s not a problem and boots should be about what you would expect at around a few minutes.
Ahh, OK. So there are two ways to write rules and the parsing delay only applies to the higher-level DSL rules. Well, that’s two strikes against DSL, I think. You’re right - I’d probably prefer to use JSR223 if it means freedom to code as I wish. One of the annoying limitations of the Zipabox is that you can’t get down into the code; that said, if I can solve the problem, I don’t mind much how it’s done. But the parsing delay settles it methinks.
So, to summarise - although I won’t be buying anything just yet - does this setup look reasonable to cover my Enocean & Z-Wave devices, the Somfy blinds and a 433MHz temperature sensor?
- RPi 3B+
- Enocean 1000221 daughterboard for RPi
- ZWave Gen5 stick
- RFXCOM RFXTRX433E USB 433MHz Transmitter/receiver
- 8GB SD card
I read a comment by Markus that smaller SD cards (4-8GB) are perfectly adequate and make backups faster.
If you can get one, a new RPi 4, for the same price as the 3B+ may provide some added CPU unless you get the 3B+ discounted.
I wasn’t sure whether I needed the extra power if I’ll be using JSR223. The difference in power consumption when idle seems to be around 1w.
The question would be is the cost of the added power draw worth the future increased flexibility in hardware use.
That, of course, is your decision.
Don’t trade-in safety and reliability just for a couple of bucks.
RPi4 isn’t guaranteed to work fine for the time being. Chances are fair but there’s no experiences yet.
No openHABian image yet.
I’d get both and start with the openHABian image for the 3, then wait for openHABian for the 4 (or try yourself but without time pressure).
Once you get both to work you can use either and keep the other one as a spare part.
Yep. On the other hand side they have less buffer for wear levelling. But it’s way better to actively minimize writes to SD than trying to “buy” that safety.
But folks please stop discussing details here, open a new thread please if you feel the need to.
I have to agree with Markus here. Rpis are cheap considering what you spend on the other hardware (power plugs, dimmers and whatnot). Get both of them. Rpi4 will most likely work, considering how big the rpi community is, however will take some time before the software is adapted to the rpi4.
Regards S
I’ve started this topic a long time ago and really good to see all the discussions.
Man do I love the OpenHAB project!
Anyway, shortly after opening the topic I’ve made the decision to go for a Intel NUC. And until today I’ve never regretted this decision. I’ve been running the OS (Debian) and Openhab without ANY issue (except for my own screw ups in the config ofcourse)
But I had a now a mix between “older” OS, and OpenHAB v1 and v2…so started last week to build my system again from scratch on the NUC.
Now on the latest Debian 64-bit build and the latest OpenHAB v2 stable release.
Had some issues with drivers because of the 64 bit OS, but all is up and running. Now slowly building up the smart home again 
But I can really suggest to step to a NUC in case you are experiencing issues on the Pi and/or want to have a more reliable and “professional” base unit. The NUC is SUPER!
2 Likes
Shortly after running on PI, I’ve switched to pre-NUC small box size pc with 16gb ram and 250gb m2 hdd not sure about cpu 4cores some intel
running elementary os and kodi as main hts unit, OH running as docker image which I can’t recommend more, it’s simply perfect.
All crucial OH data are being stored outside docker container, easily to maintain, work with and backup.
RPi’s are great, using couple of them, but for OH I’d recommend something bigger as well as @JdeJong
3 Likes
I run OH2 in ODroid C2 units these days and I’m very happy with them.
I’ve helped a few people remotely who have Raspberry Pi units, they always seem slow to respond by comparison.
yeah odroids are great, personally using them to decode h.265 tv standard (EU)
1 Like