Hardware recommendation

[splatch (Łukasz Dywicki)]

@mstormi

@splatch

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.

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.

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.

@mstormi

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.

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.

@mstormi

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.

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.

@mstormi

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.

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.

@mstormi

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.

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?

@mstormi

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.

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.

@mstormi

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.

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.

@mstormi

@splatch

Putting hardware aside, many of openhabian scripts will work with most of linux distributions out there.

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.

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.

@mstormi

@splatch

it [RPi] 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.

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.

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.

@mstormi

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 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.