That now is a bold statement and imho wrong as such, at least without differentiating and going into the details of system purpose and intended usage.
There’s home automation vs. industrial applications, and most people are fine to run OH with the default rrd4j so a standard openhabian-on-Pi is already covering a major part of our user base.
And you’re completely ignoring the main point of this recommendation:
It’s directed at all OH users and in particular to people that want it cheap and simple, that cannot or don’t want to assemble hardware, setup OS and tune and maintain a system themselves.
Which is actually the majority of OH users and to them it is decent advice.
It’ s more than that.
Again, this is a bold statement without defining “reliability” and KPIs you would expect on this.
And where’s the diifference to your mini PC, what can they control that openhabian can not ?
If the main risk is potential loss of data on power cuts then this isn’t tragic per se.
Historic data is not mission critical in most home automation setups. To many OH users even loss of data is acceptable, and of course you can and should backup/restore data.
I feel this is a little like defending the classic long-practiced operation of Linux servers thoughout several upgrade cycles over a cloud scaler’s approach to just reinstall boxes from scratch in case of problems.
Note that reliability isn’t the most important factor.
If any single factor is, it is service availability what users are after.
And as a matter of fact overall availability is much more determined by quick MTTR rather than long MTBF.
Again, I contradict.
No it is not easier, it’s right the opposite. Even for people like ourselves that know how to, doing so takes way more time and efforts than to flash the openhabian image to a RPi SD card and just wait an hour. The statement is also wrong because you do not have to tweak ZRAM. It comes preconfigured/optimized.
There has been no sign of this being a problem of relevant extent in the field in the time I’ve been a moderator of this community. Home automation isn’t as challenging as is crypto mining or some such.
I don’t recommend RPi because it’s particularly good hardware but because it’s reasonably reliable, easy to install, to replace, cheap and the best package overall.
Well again, in the first place, openHAB is home automation, not an industrial appliance which is obviously your focus.
You won’t encounter CAN in homes, and if you need RS485 at all (more and more device can do IP instead) a $2 dongle will do. I run a SOHO type of installation with three of those, why not. There’s also RS485-to-WiFi adapter solutions at 30€ or less.
Sorry, but I don’t think there is any “but” other than demo setup which would pass “system purpose” where SD card is allowed. All others are wrong, because you risk of loosing collected data and operating system configuration. Obviously you want backups, but last thing I would wish to test with my home automation system is recovery from backup every 8 months. Its long enough to forget exact steps, and often enough to remember you did it same year, and forcing you to update OH installation despite of your system working before. SD card will require service sooner or later. Any OS update is putting a pressure on SD card which you want to avoid, so trying to keep your linux safe and free of major vulnerabilities shrinks lifetime of your solution.
Its decent recommendation for demo setups. Looking at the pricing of RPi4 right now I think you can find safer hardware configuration than it. If price is main factor, then RPi, especially 4, is not cheapest device out there.
Its not a bold statement, its true statement, its a question when your RPi 4 storage will get corrupted. Its not question about mine mini PC, but OPs and any other mini PC compared to RPi. I pointed out very clearly in my earlier post that openhabian can not control all storage locations. It can’t control mysql, it can’t control postgresql, nor any other database which can run next to it. Even if you can make influx fit into ram, its gets quite risky as this thing can get storage hungry.
Limitations which are coming from rrd storage are big enough that people are switching to something else, and something else might be anything supported by armbian, since you are based on generic purpose operating system with variety of packages available.
Why then openhab comes with persistence enabled by default? Since most of users, according to your statement, can accept loss of data - it could rely just on most recent state stored in memory.
If my time to recover is same with longer time between failures, why should I invest in a solution which forces me to exercises time to recover more often? Both metrics are relevant. Putting MTTR over MTBF is your personal preference, but I really doubt if its preference of entire community and people who have their home automation pushed to the extremes.
Installing debian on regular SSD/mini pc will be probably less than SD card flash and first RPi boot, simply because SSDs have better I/O performance. You need no zram, if your stuff runs out of SSD, because why you would interfere with optimized writes made by databases itself?
Running zram is not hassle free and amount of posts referring to it is growing. Its clear mark that people are getting into troubles with it. Not everyone, not always, but some.
Basic fact that you do not observe/measure CPU throttling, doesn’t mean that issue does not exist. People are just unaware of it, cause it might have a temporary nature.
RPi4 without heatsink will throttle almost immediately after getting 100% CPU load for seconds. Smaller heat sinks will let it deffer throttling for more or less couple of minutes, until thermal capacity of sink is reached. Even large RPi cases which permit to install a heat sink will limit air flow and cause it to throttle. Its not a crypto mining which causes that, its a regular CPU load which stays high for minute or more. You will experience a 100% load during system boot as well as during openhab startup, more commonly when you run a persistence query involving getting data in and out data from zram or navigating through graph pages which query for a lot of data.
I agree its doing well under hobby usage, however it is not cheap and hard to replace since (almost) two years. Its hard to source even in small quantities. I’ve been tracking availability of it, and if you need a board alone, without all the crap you get in overpriced “kits”, you’re left alone. Raspberry CM4 in certain configurations is gone for years already.
You encounter CAN in homes when you think of battery management systems (there is no better bus system for such), you will find it in many heat pumps (i.e. stiebel), heating controllers and multiple wired proprietary/non standard home automation systems. Everywhere where you need to prioritize traffic - CAN bus will be a right choice. A RS485 is pretty common for heat pumps and inverters, thus you can’t run away of it. Each of these interfaces makes your RPi case to not fit. Its again a question of how many dongles you want to place in USB ports or how many TCP adapters you are willing to buy. Each of these increases overall costs and fragility of deployed solution.
Giving above issues with reliability of storage, I/O performance, thermal issues, very limited availability and missing out of the box common automation interfaces RPi proves to be fine for demo kits (if you can still buy it ;-)).
Putting hardware aside, many of openhabian scripts will work with most of linux distributions out there.
It’s decent recommendation for any setup but maybe the most business critical ones.
But we’re not talking cloud server based business nor telecoms nor industrial control applications that are part of some manufacturing line or some such. We’re still in the home and small commercial building automation arena.
Sure Raspis have been extraordinarily pricey in a while due to various reasons, but some weeks ago Raspi Foundation has announced an immense increase in production capacity in Q3. That’ll also affect pricing soon. I’d expect prices to drop back to normal levels by end of year latest.
That’s a plain wrong statement. With openHABian you can do anything you can do on Linux such as e.g. to attach an SSD and move the database over there.
Another wrong statement. I’m not claiming zram has been hassle free in the past or is guaranteed to be now. But the number of posts on this is definitely not growing. And if you go into the details of those posts like I do on most, it’s usually elder issues caused by some user modification or last-but-one-gen zram configuration in combination with some relevant OS component change, most have been identified since and problems are fixed in current openHABian.
Any major OH change or new Debian release has interdependencies that often show up at later times. That’s just the ordinary business you cannot avoid but it’s not specific to zram or RPi so not ok to attribute it to them, you will also encounter similar issues on any other low resource constrained system that you need to optimize the OS setup for to get it to work well.
Instead, I’m seeing more posts now of people with homegrown solutions that have stability or performance issues even on high-powered hardware - because their OS isn’t tuned to match the hardware.
And sorry to be outright but I think as the maintainer of openHABian and moderator I have a better overview on this than you do.
Well.
Upfront, I don’t claim it’s the preference of the entire community - I’ve just spoken of the majority, and that was not in the context of MTTR vs. MTBF.
Now “People who have their home automation pushed to the extremes” will always do “their own thing” anyway and install their own HW and OS the way they want to and keep spending their time on tuning and maintaining it, but they’re clearly a small minority that no shrink-wrapped product-like approach (as are openHABian or RPis) can ever target properly. And that’s perfectly okay the way it is, of course.
Now on MTTR vs MTBF, it’s not a preference thing to claim that improving on MTTR is way more efficient w.r.t. to the goal of increasing availability than to focus on MTBF.
That’s best practice knowledge from the IT and telecoms industry in fact. I have a lengthy track of working there as a system architect.
Moreover, please note first that openHABian-on-RPi is a holistic approach that is conceptually different from the what most people including yourself are used to. It is inspired in parts by the cloud scaler’s approach to (auto-) deploy containers and VMs on centralized big iron yet adapted to low resource, local, standalone hardware.
It’s actually combining the best of both worlds.
Note ZRAM is there to help MTBF, and please don’t cherry pick arguments and stay fair here, look at the full story that actually goes that the hardware recommendation is to include a small UPS with your server (onboard or dedicated, doesn’t matter) so power outages are mitigated.
On MTTR now, openHABian-on-Pi provides SD card mirroring. It’s a “poor man’s” form of mirroring without hot standby like you have in data centers, but it allows for ultra-fast MTTR and the upside is it also does so very much outside controlled environments like data centers or industrial deployments, right in the wild where it is deployed most, under various conditions in people’s homes.
If your SD card breaks, you just swap cards, reboot and you’re back up running. Same if your RPi breaks. You pick the spare off your shelf and move the SD card over.
Your electrician, neighbour, heck even your mom can do it without that you yourself need to be on site.
I’d like to see that work with your mini PC based approach where every piece of hardware and even more so the corresponding OS configuration is specific to every single installation.
Sure you might be lucky at times but usually when hardware breaks or software does (on updates) you’re in trouble (and not on site).
Your MEAN time to recover will be orders of magnitude longer than in my concept and your resulting avilability will be lower.
Unfortunately the implementation I referred to above requires special dedication and tuning to hardware specifics such as e.g. setting device UUIDs for boot devices which is why it only works on RPi.
You cannot benefit from this on mini PCs even if you deploy openHABian.
So that’s a good reason to choose RPi over anything else.
As probably will be the mini PC you choose today?
Yes there has been and currently still is a Pi shortage, but that’s as true for almost any chip electronics. And as said above we’re close to getting over it.
Again, it’s a different conceptual approach that you must not pick cherries out of just for the sake of argumenting against.
Key here is to use a standardized hardware and setup every time. It’s original or at least fully backwards compatible hardware that is available in years and is just replaced on issues (without a need for an expert to jump in to restore or adjust OS config in that very moment).
It’s the proven approach from the electrics and automotive industry.
I tend to agree with you. I have some setups on raspberry pi running for years for basic setup. All this thread is going nowhere if you need a basic home automation without million complex rules databases and special software running along then stay with raspberry pi hell there are a million things using raspberry pi i am going to give a small example of a comercial offering from dobiss a Belgium home automation complete offering that uses the embedded raspberry pi. The moment you need complex stuff influxdb with writes every millisecond and complex rules ai stuff vtt tts image processing etc then it’s up to the user to configure the system and maintain even comercial offerings like Gira Jung beos etc are dumbed down to only limited features to keep up with the hardware. So it’s per requirements if you only need an app and some basic automation stay with raspberries also consider that Nabu casa choose it also.
Wow, strong opinions. All I want to add is I feel both sides.
I’m running a pretty standard setup, and yes. The reason for that it’s so much easier to find help and examples on the forum. It helped me bigtime to get started with openHAB. And kept the fun in home automation.
But what I also like is the freedom. Depending on your own use case you can change things. Either on software (influxdb/grafana seems to be common) or hardware. I’m happy with the performance of the PI4 but changed to a hard drive and added a fan. And I can image in some cases you need more power. And that’s also possible. That’s the other side of openHAB I love, the flexibility to grow with your needs.
I hesitate to get involved in this discussion but this vastly overstates the risk for the typical openHAB use case openHABian is intended for.
It’s just one data point, but I’ve had a modest openHAB instance running with openHABian on SD card on an RPi 3 for six years now without problem.
Everyone’s experience is going to be different, but I think it’s important to avoid hyperbole in discussions such as this because it skews the discussion. A typical openHABian install for the typical home automation use case will see many many years of life out of that SD card. It won’t be as long as an SDD for sure, but is it long enough?
So far I’m not seeing a lot of corrupted SD card posts on the forum and the few I have seen have to do with people thinking they can just yank the power, not long term wear.
I’m not going to come down on either side of the argument but I find this particular data point to be exaggerated (perhaps on purpose for effect) and I worry that future readers may come across this thread and think that it is indeed typical for an SD card to only last eight months.
How above is wrong? Does openhabian do anything to prevent mysql or postgresql from eating SD card alive? If you recommend moving storage out of SD card to i.e. SSD or USB then the reference setup is just gone and gets closer to traditional PC. I had a look at zram scripts you have, only one database supported there is influxdb. It simply leaves a whole set of other databases available via OS packages and openHAB integrations uncovered.
I get that you can’t support all use cases in software with limited hardware, however claiming that your reference setup covers majority of use cases and then adding support for external disks etc. contradicts a concept of reference setup based on SD card. Support you have in openhabian for SSD/USB drives exists there for a reason. This brings me back to my initial statement - that any system with onboard flash or traditional SSD drive will serve you better than raspberry with SD card.
That’s problem you can avoid by building a proper operating system image. Making it by scripts, as it is done now, without explicit control of what comes in will always be a gambling. I understand and value state of art built over past years, which is ok for demo or storage-less use cases. I keep going back that problem zram attempts to solve is SD card wearing at the cost of extra CPU load. You don’t need to make such sacrifices if you accept a fact, that there are better storage options than SD cards.
Performance of RPi 3 class device (with 2 or 4 core) with stable storage is sufficient to run most of home automation/small automation systems for sure.
May I ask what entitles you for speaking of majority of this community? A moderator badge, ego or a poll you performed where people marked “I like to recover my system from backup more than do not recover it at all”? I tend to reflect my own opinions without claiming they are valid for entire, major or even minor part of this community. I recommend you to do same unless you are able to measure and prove your statements with numbers. If you don’t then its just your own opinion, equal to mine.
A basic fact that openhabian is being used by this community doesn’t mean they favor MTTR over MTBF. They simply might not have any other choice.
The 2019’s community survey, showed up that RPi was responsible about 55% of setups. Such number made it large, but not the only one hardware platform. Desktop and embedded PCs accounted for 27% of setups, getting a second place.
How openhabian on rpi is holistic, if you need to fire it again, after first boot to move storage to other disk? Rest of that sentence is your own reasoning, definitely not mine background or intention.
I try, and I hope that I partially do, prove that insisting on getting RPi and its SD card a reliable is a nice exercise, however it should not be recommended for everyone, definitely not for ones who value stable and hassle free operations. You keep mentioning various options in order to improve reliability of reference setup, which proves that this reference setup is not reliable by default. After all, how much extra hardware do I need to get to make holistic approach (you claim) to be possible on RPi, to happen?
Great t hat you have a SD card mirrorning, but RPi have just one SD card slot by default, does it mean we need some other piece of storage? How well the mirroring will work with small or almost fully packed SD cards? Each write you do on SD card impacts its lifetime.
Again, I don’t know why you keep mentioning data centers.
If you look at PCs they are standardized better than ARM based solutions. The UEFI which is very common these days unifies access and enumeration of hardware. Its much easier for Linux to detect hardware your system have under UEFI than under RPi. I used single OS image on all PCs I had in my hands, thus what you claim to be an issue - is not. Its much more difficult to bake a working linux device tree for ARM than to break UEFI based system. You can move disk from one computer to other and nowadays linux will still boot from it. Unless you expect nvidia graphic or audio cards to work, many PCs out there will work.
Like-hood of broken operating system update is by all means larger with SD cards and its wearing than with SSD/eMMC storage. The way in which openhabian controls operating system gives you no guarantees at all, so PC based approach is no better or worse than that.
A proper, and safe way, to handle operating system updates involve two system partitions I mentioned earlier. You boot from A but update B and try to boot from B, if boot fails, you get back to A, if it succeeds you mark B as default and wait until next update to override contents of A partition.
The openhabian-tools, which trigger some package updates shall work with bare debian/ubuntu. I see no reason why anyone would want to mess with RPi boot config under UEFI.
There are certain components (i.e. CAN related) which were difficult to get back in 2021, there were specific ARM cpus from recent generations which were hard to get (i.MX8). I said in my earlier answers to you, that any system which have option to use traditional disk or embedded flash is better than RPi. I do not insist on any specific hardware here, but hardware with a stable storage.
I agree that standardization is important, however there is no single standard for home automation, thus there is no single hardware which can mark a standard. Since openHAB is software solution making its own standard way to connect various hardware/software, making any hard assumptions on which hardware solution is reference one, is short minded, especially if it involves unreliable storage.
Since I haven’t seen electronics and automotive industry deploying RPi or systems booted from SD cards its safe to ignore later part of above paragraph.
It’s a misunderstanding of yours about what “control” means.
There’s no menu option to install mysql or other database, that’s true, but that does not mean at all that openHABian image is unable to control all storage “locations” (I assume you mean disk devices or mount points?) available on a Pi.
Neither does it mean you cannot run a mysql on an USB-attached SSD on an otherwise standard openHABian RPi booting from SD.
All of this is possible, it just has to be configured manually. Any user with the proper knowledge and motivation can do. If you want your favorite pet database auto-installed, script it, put up a PR and I’ll be happy to merge it into openHABian.
Lack of this or any other feature to be chooseable from a menu just means that there has not been substantial interest and willingness to contribute in getting this done.
Not at all, it’s right to the point. What you call a reference setup covers by far most users’ needs.
Chooseable from the menu.
But anyone who wants to run some other database or off an SSD can do as well.
On Pi, on openHABian.
And no it’s not a question of the hardware. That’ll do. It’s a question of contributing back to the community. Someone has to do the work for others’ benefit, i.e. script and test auto-installation and configuration for it.
Which at least the first part of is another wrong statement. Onboard flash, USB stick, eMMC, they all are no better than SD cards w.r.t wearout/reliability. Read on here: Corrupt FileSystems every 2-3 month? - Setup, Configuration and Use / Beginners - openHAB Community.
Ever had to replace your Tesla’s MCU ? Yep, they also crash like Pis due to worn out onboard flash.
I bet any Tesla driver would have been a lot happier if that had been an SD instead of soldered chips, replacement would have been 10€ rather than the 3000+ they had to pay.
You totally misunderstood my sentence right in the first place. I said I had spoken of the majority (“of” like “about”), not for it. And for the rest of your last post as well, your wording remains pretty provocative (e.g. repeatedly insisting that openHABian/Pi is “good enough for a demo” means it is not for production purposes, I’m getting that and I think so does everyone else, “definitely not for ones who value stable and hassle free operations” and telling me how a “proper” OS image would need to be made, calling it “gambling” showing you haven’t even understood how openHABian image generation works and some more). And it is getting even more aggressive at times.
I’m not raising my moderator’s hand yet but I think with your latest post we’ve come close to that. Personally I don’t like this tone and where it is leading so I will no more discuss those remaining parts and stop replying before it gets even more personal than I feel you already made it.
A rpi is fine as long as you can fit it all in RAM. Including databases and what not.
With only periodic write-out (logs and databases) to the SD card you will be fine for years.
And it can be very robust in case of power losses.
A NUC/miniPC is faster.
Mybe you want it to do audio or video. Or even image Recognition.
It is not hard to configure openHAB on raw Debian. But it can be a steep learning curve, no doubt about that
from Bookworm ( became the new stable last week) you can get those non-free firmware blobs for network/WiFi included in the installer.
Which brings me back to my question, why would your recommend attaching an SSD to RPi instead of just using a computer with the same SSD? Amount of tinkering with regular linux install on a hard drive is much lower than with raspberry, not to mention about all issues you get with a USB drives.
As I am happy user living without openhabian, I tend to have limited capabilities to contribute there. Sorry. Pet databases you refer to, are part of base operating system you use.
They are better cause they are closer to motherboard thus latency in accessing them is lower, amount of hops you have to pass is smaller, thus its stability is better than within SD card. More over many of eMMC powered devices will also provide you a storage interface to offload I/O intensive operations out there. Or a SD card interface which you recommend.
Sorry, I can’t comment on Tesla’s issues without diving into details of how they used storage. I would also rather make no bets on people’s happiness and focus on technical merit.
Which still comes to the point that your statement is based on your own gut feeling as there is no single source of truth of how many openhab and openhabian installations are out there. There are few indirect statistics available - an ancient survey I linked above is one of them. What makes you think you speak of majority?
I share my own thoughts just like others and you do. I am sorry that you feel touched with these, but being a responsible community member I feel myself in duty to warn people of possible risks of running their entire thing on RPi. I am not a person known for discouraging people from doing things, which as you know, happens a lot on this forum.
For the rest of your post, be my guest. To remaining readers of this topic - sorry for making it that long.
Thanks for the feedback George. I too have outgrown the RasPi 4B+ 4GB (114 Things, 524 Items, 86 Rules). When I switched over to all JS ECMA 2021 rules for OH4, I experienced a huge slow down. It was taking 5-15 seconds to run a single rule. I did increase my heap size to minimize garbage collection, but it was still sluggish. I moved over to Windows 10 temporarily and its super responsive. I’m ordering an intel NUC today. Thanks again for the feedback.
I also have one of this (really a MSI Cubi), but I use it with Windows 10, and all works very good, including in the same device Mosquitto, Zigbee2MQTT, Influx and Grafana (and also Weather-Display that is the most demanding software in the device). I would mean that is not necessary to use Linux.
It used to be the case that the only way to get a cheap (both in terms of purchase price and electricity costs) dedicated machine for running openHAB was an rpi. And you absolutely want a dedicated machine, so it made perfect sense to recommend using an rpi.
Then the rpi price sky-rocketed and at the same time a plethora of cheap (again both in terms of purchase price and running costs) x86 based machines became available.
From a hardware point of view, at this point in time there really is zero reason to recommend running openhab on an rpi.
I don’t personally use openhabian so I cannot comment on what that brings to the table, but if you are planning on running it on a regular linux distro, just get an x86 box instead.
As dcumented, you can run openHABIAN on an x86 box is you are unsing a Debian Distro.
I am about to move my openHAB 4.0 installation to a Intel(R) Celeron(R) J4125 CPU @ 2.00GHz (QuadCore) with 6GB memory and 126GB SSD.
Just upgraded the box to Debian 12 and used openHABian for setting up all the stuff needed (openHAB, MQTT, homegear, frontail, etc.) This was running absolutely smooth.
Sure, my point was that I have no experience whatsoever with openhabian so I cannot comment on it. And a hardware recommendation on its own is rather pointless without also covering what to run on it, hence why I qualified it with the “regular linux distro” part.
By the way @hmerk, if yours is fanless you probably want to add an external fan. I’m using mine in the tropics and running it without a fan is simply not possible.
That’s a pretty bold statement. It’s not just a hardware point of view. The whole package needs to be taken into consideration including operating system, third party software, power.
The audience and purpose for openHABian is to provide something as close to a turn-key-system as possible to those users who do not yet have the skills to do it all themselves (or skilled users who don’t want to). To achieve that, some sort of standard hardware configuration has to be settled upon and given the nature of home automation, something that supports USB, GPIO, with on board networking and bluetooth is a pretty good set of requirements.
At the time that openHABian was written, RPis were really the only viable option. And despite supply chain issues which appear to be correcting themselves, it remains a good choice to be the targeted platform for openHABian.
But if for whatever reason an RPi doesn’t fit your requirements, you have options to run openHABian. However, those options will be a little more work for you and will make it harder to support you here on the forum. It appears to be easy to underestimate how much time and effort it saves us who help users with problems here on the forum when we can make sweeping assumptions about hardware, OS, and configuration.
These concerns may not matter to you at all and that’s just fine. But to conclude that these concerns don’t matter at all to anyone (which is the logical conclusion to the statement “zero reason to recommend”) is something I strenuously reject.
Mine has a fan and is located in my cellar, sitting on top of a 19“ wall cabin.
This is my home distribution point where I also have a big UPS and my HP DL380 server, running several VM‘s….
Mine (which isn’t running openHAB but opnsense) is running fanless on a shelf lightly covered with a plastic box to reduce dust in my unheated/uncooled garage for four years now. But I’m in the mountains at 7100 ft (2165 m) altitude.
I try to make a concerted effort to not assume that my experience and environment generalizes to the whole world though.
