Best hardware platform

Here’s my PR for openHABian.
I encourage anyone to have a look at it and help with testing by deploying this on boxes of yours and get me some feedback (on Github please). See last comment there for how to install.
And while I think it’s obvious the standard disclaimer applies: use at your own risk.

5 Likes

Rpi4 looks.promising for openhab.

2 Likes

It looks very (VERY) promising.

I sure would like to use the 4GB version asap… 2GB could do, but why should one be limiting them selves :slight_smile:

It is still missing an integrated reliable storage method :frowning:

With usb3 I personally don’t see that as a problem.

I’ll jump in here and hope to stay out of any arguments :wink:

I’m a potential refugee from the Zipabox, sizing up OpenHab and trying to get my head around what I’ll need to run it. I’ve gone through the whole thread and picked up conflicting messages about whether a Raspberry Pi would be sufficient for my needs. I don’t know if anyone here has experience of the Zipabox, but I’ll describe my current system in general terms.

Physical devices: 27 Z-wave, 9 awnings/blinds working via 433 MHz, 2 Enocean sensors, several devices that work over TCP/IP: 1 ventilation system that should be controlled by Modbus TCP/IP (never managed to get there with the Zipabox), two Nest thermostats and 1 Tado, Sonos devices.

Virtual devices: around 30 meters (essentially repositories for info on weather and other stuff). Tons of switches to trigger rules.

Rules: about 290. A large number of them execute every 10mins or so to recalculate numerous variables and so forth.

Obviously, I wouldn’t replicate this system entirely on OpenHab, but it gives you an idea of how large my current setup is.

(I was advised by Zipato not to install the latest firmware because I have “a ton of devices”. Sigh.)

So, do you think the latest Raspberry Pi 4 would give me reasonable performance? I would like to keep the power consumption to a minimum, since that’s one of my home automation priorities, but I don’t want to have problems with the system being underpowered either. I have an old laptop at home, but it’s far too bulky and power-hungry.

I’ve read through the debate about SD cards/external storage without arriving any clear conclusion about what I should do. Does the Raspberry Pi 4 help?

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!? :angry: 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 :smirk:
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. :smiley:

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.