I’ve been running OpenHAB on various Pis for many years now, but finally got sick of the horrendous startup times and general sluggishness, so went looking for new hardware. I wanted to share my results in case it helps anyone else in the same situation.
My requirements:
At least 4-5x faster than a pi 4.
8GB RAM.
Small form factor.
Low energy consumption.
Quiet.
Low heat output.
99% solid state (i.e. the only moving part should be a single fan) for maximum lifespan.
Under $200.
Comparing CPUs, I settled on the Celeron N5105 as the best balance for the above reqs.
An Intel NUC delivers everything above for right around $200 (with 8GB/256GB); but after shopping around some more, I found a few options that cut the price significantly by removing some features that I don’t need (e.g. mic input, DisplayPort output, extra USB ports).
So for $139 I picked up one of these little guys. Might be available on AliExpress for even less, but I wanted it now, not in 30 days, so didn’t look.
Installed Debian + Openhabian and have been using it as my OpenHAB house controller for a few days now, and it’s really great! Roughly 5-10x faster than the Pi model 4 it replaced. A reboot takes about 10 seconds to being able to SSH in, another 20-30 seconds for OpenHAB to fully spin up (89 Things, 279 Items).
A few caveats to be keep in mind:
Only 3 USB ports. If you need more, either go with the NUC or add a USB hub.
Comes with Windows 11. Easy enough to wipe it and replace with Linux.
When installing Linux, use a full installer image, rather than cloud-based; it requires some “non-free” drivers that you would otherwise have to download and manually include.
No mic input plug. If you’re running speech recog directly on your OpenHAB hardware, either go with the NUC or struggle with a USB mic.
Audio output comes from an add-on that appears to Linux as a USB card. Since Debian doesn’t see it as the “default” controller, it won’t share output from multiple executables. Only an issue if you want to run other audio software (e.g. SqueezeLite) on the device. This may just be a Debian ALSA problem, haven’t tried Ubuntu on it.
Overall I’m very happy with it, and would definitely consider picking up more for HTPCs.
Well. Allow me to publish some sort of contradiction here.
Upfront: While startup takes some minutes on RPi, OH is designed to run 24x7.
So if you do, startup times become a negligible detail.
And while I know that several people have been and some still do suffer from these symptoms, a properly setup system isn’t sluggish on a Pi.
So while I understand that throwing hardware after the problem becomes more and more tempting the longer you suffer from issues and the more you tried to fix them, ultimately it’s not a solution.
Usually the root cause for any sort of sluggishness is with the OS setup.
The first thing I’d always try if you feel yourself to be in this situation is to use a standardized, proven OS setup: use openHABian rather than to try configuring-debugging-optimizing yourself.
It’s in fact tricky and full of potential pitfalls to setup a Pi for proper hassle free openHAB usage.
That’s why I strongly advise to save your time, money, efforts and frustration and get a fresh standard openHABian install rather than new hardware.
There’s simply a lot of experience built into it that you or any other user have to has to find out again the hard way.
I agree that a Pi makes for a reliable, consistent “baseline” hardware for getting started on OpenHAB. But I also think it’s easy to run up against the limitations of a Pi as you expand your system and add new features (Want TTS? Good luck!).
It doesn’t matter how perfectly-optimized your install is, Pi hardware is designed to be lowest-cost and that comes with performance limitations. And I’m saying that as a big fan of the Pi hardware; I still use it for many situations, and would recommend it for new OpenHAB users.
But OpenHABian isn’t pi-specific, so it’s easy to take advantage of its hassle-free setup and config tools on other hardware.
Generally speaking, I see a lot of pressure from OpenHAB devs and experts to stick to Pi hardware; that certainly makes sense when trying to get new adopters as it makes setup and trouble-shooting a lot easier, but it also tends to stifle having a clear upgrade path to “level 2” hardware (somewhere between a Pi and a dedicated full-power PC).
Which is what prompted me to write the initial post in the first place.
Another “well” comment. Upfront, there’s no such “pressure”. The official recommendation still reads to use what you feel most comfortable with.
But the reason for the Pi recommendation is actually less about the hardware and getting starters up to speed. It’s in fact about the OS related efforts in configuring, debugging and - important - supporting OH users in the forum. Any OH user from newbie to expert keeps benefitting from ‘standardizing’ on an OS setup.
It’s about learning and sharing experiences we have made over the years in this community.
But even with openHABian on top, it’s the OS you will have to setup yourself if you’re not on RPi.
You need the skills to do so, you will have to spend lots of extra time and efforts to do so, and you need to have and apply the aggregated experience of what’s today implemented in openHABian on RPi.
I’m talking about performance relevant stuff like ZRAM config and software memory limit settings on various levels. Improper settings are in 90+% the root cause when sluggishness is your symptom.
Now settings like those you can only determine and build for specific hardware you optimize the OS for, and the only hardware that openHABian was optimized for is RPi.
Now of course there’s situations where a RPi doesn’t do, but to boil it to the point, they’re rare.
General sluggishness isn’t any such situation, and a hardware upgrade isn’t a proper fix here.
As replied and while of course annoying, that’s just sign of an improper setup. (Local) TTS or even STT would be such edge cases or local video processing and some few more.
Sure in those case you are better off going with more powerful hardware. But 95+% of users don’t need “level 2 hardware” for their needs. And anyone to take that route should be well aware that this means losing most of the aformentioned benefits as you will have to configure and maintain the OS yourself to match OH usage.
Recommending a hardware setup for computer based automation system, which rely on SD card as a boot and storage media by default is just wrong. Anything which has a onboard flash or option to plug a SSD drive into standard m.2 / msata / sata socket is better than raspberry.
While openhabian does a decent job of providing a working default, it can’t deffer SD card wearing indefinitely. Its nice for demonstration attempts, but there is far too many things in operating system setup, which are out of the control of openhabian to call it a reliable. Anyone who will install a influxdb or another database system which uses storage at regular basis (such as mysql), will cause your efforts to keep openhab stable fail. Simply, because database will do its thing writing data to SD card as often as it needs, not as often as you want.
And any storage other than rrd4j is going to live outside of zram or require its reconfiguration.
Its easier to buy a mini pc and install stock debian on SSD drive and openhab from APT package than keep tweaking ZRAM settings until its stable. RPi4 is doing very poor job of being a “fanless” system, it starts to throttle rather fast, unless you get a proper case with large enough heat sink. OP’s hardware selection might not be much better in this regard, however it is getting extra portion of heat out of SSD drive.
We can keep discussing what is the like hood of power cut with ZRAM contents not synced to the disk or simply rely on storage which works and operating system tools which can repair filesystem in case if it gets in inconsistent state (softly damaged).
I would point to lack of RS485 input which is quite common in industrial/building automation. You can survive without RS232 or CAN onboard, you can swap mini pcie with USB adapter and use USB modems, question is - how much dongles you want to hang next to your home automation server?
I been running in parallel number of installations hosting openHAB 3 compatible software. Some deployments utilized ARM, some other stayed on fanless PCs, some on industrial PCs. None of them used openhabian. None of them needed zram. Smallest setup we had worked just fine with 2 GB of memory and ~6 GB onboard flash (2x2 GB for OS partitions, 2 GB for user data). We used embedded build to host all this and automate update process, however at the bottom line all we did was a linux with reliable storage.
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.
