Best hardware platform

TRS-80 · June 24, 2020, 8:15pm

If you are primarily concerned about performance, it is hard to beat Intel NUC. They are even quite power efficient. A bit pricey though, for what they are (last time I checked).

However, of much greater concern are the firmware level backdoors (IME). Personally, I will not be buying any more Intel hardware whatsoever until they end this despicable practice (and I’m not holding my breath). In case you were wondering, AMD is not any better.

Which is why all these other ARM based Single Board Computers are so interesting to me. Many of them (other than RPi) have little to no binary blobs, much less crap like IME built into them. They are also quite inexpensive, and because they are essentially based on smartphone chips, very power efficent! For me, a winning combination.

If you don’t have the same concerns (and many people don’t, unfortunately in my view) then buy whatever you like.

You say that as if it is a good thing.

I changed from Windows to GNU/Linux a few years ago, it’s amazing to me how all the devices on our home network suddenly “just work” together, when everything is designed from the ground up with Freedom and open protocols in mind… Really makes you think…

Udo_Hartmann · June 24, 2020, 11:34pm

This is one simple line to fully update the whole system:

sudo apt update && sudo apt -y full-upgrade

Uuh, really? That comes with a high cost (and it’s not true either)

That is no linux issue and by using ZRAM you can prevent problems (you can even use a SSD)

As if windows installs are less complex…

I also have Visual Studio (Code) and

I don’t need a desktop on my headless server

nearly every update for windows needs a complete reboot, so that’s not true at all!

Well, you can’t prevent the updates (and I can setup GNU/Linux to automatically update and upgrade, but I want to have control)

which is also easy for Pi computers

Please, don’t recommend a setup only because you are familiar with it. To install openHAB on Windows, there is no setup routine, you have to install Java, unpack openHAB manually, setup the correct Java path manually… You have to ensure that no one can do funny things with openHAB…

The whole point is: If you are familiar with Windows, you can use openHAB with a windows machine. It will consume much more energy as an embedded system, but you will have a desktop (even if you don’t need it). My openHAB installation is restarted only if I do a configuration (and that would also be true it I would use a windows machine) But other than windows, I don’t need to reboot my computer because of updates, only when the kernel is updated)

NCO · June 25, 2020, 9:02am

I did not know that and did consequently not care about it
Possibly I should and I will.
At least to see, if it soncerns me.
Thanks for bringing this up.
So I will delete my NUC, RAM and SSD from Amazon Shopping card for now.

NCO · June 25, 2020, 9:07am

I kind of agree with both of your positions:
Windows seems to be user friendlier. So I get your point @zonegrise
But keep in mind that you (most likely) spend already years with windows (willingly or not).
So, if you (willing to) spend as much time for Linux as you did for Windows, @Udo_Hartmann is right with all his arguments.

Bottom line it’s a question of perspective.

igorp · June 25, 2020, 11:03am

For OH, any small computer that is supported by Armbian (community knows hardware and squeezes best performace out of the hw. User don’t need to do anything) that has 1GB memory is fine and quickly much better (also cheaper) than Rpi. Best is to get something with eMMC, without HDMI (since you don’t need it and only adds cost/consumption) and that is not exactly the latest and greatest. All bleeding edge hardware have SW issues so in case you want things that works, get previous generation … which is more then enough (overkill) what you need to run OH.

Installation? Very simple

Recommended budget for SBC HW is 25-50 USD, OH works also with cheapests, but its best to avoid. Also stay away from mUSB powered devices (or power them via GPIO)

In most cases there is no binary blobs (Rpi), no failed powering (Rpi), no overheating (Rpi4), eMMC (Rpi dreams about), …

TRS-80 · June 25, 2020, 1:50pm

Very good on you for realizing this point!

As most people, I spent my whole life with Windows (until a few years ago). GNU/Linux was a little different at first of course. But to me, actually seemed to make a lot more sense the way everything is laid out. The file system heirarchy, common commands (and directory names) are very short at command line, almost all configs in text files, pipes, “everything is a file” (including devices), the “Unix Philosophy” (lots of little programs, each doing one thing well, which you can combine together in your own way to do whatever you want). And on and on.

Here is a great old video (from AT&T Archives) about “Unix Philosophy”:

Now, all of the above are Nice Things™, but they are not even the most important differences between Windows and GNU/Linux. Any comparison between the two on a strictly features or usability standpoint is entirely missing what is by far the biggest difference!

Of course I am talking about your Freedom! On this point we are now talking about apples and oranges between the two! GNU/Linux was explicitly designed from the beginning with your freedom in mind! It is all about what is good for you and what you want to do with your system, instead of what { Microsoft, Google, Sony, NSA, RPi foundation, […] } want to do with it, and then only letting you do what they let you.

This is by far the biggest difference, and one that is not mentioned often enough IMO. And I did not really “get” what all the excitement about GNU/Linux was all about, until I got my head around this very important distinction.

I highly encourage you if you are at all interested in this (IMO, very important) topic to please follow the “Freedom” link above where you will find a very short video which I have found to be one of the best short introductions to the concept of Free/Libre Software, for those completely unfamiliar.

bastelulli · June 25, 2020, 7:26pm

sorry, actually this is not my discussion, but I can’t stay calm on reading this

OK: seems !
It might be, as long, as one is playing consequently on user level.
But on system level, windows to me is nearly a disaster!
On Linux it’s just a line in a conf-file; on windows it’s 1 hour clicking if it’s possible at all.
And the worst thing to me is called Android; this as off topic.
Who ever tried to write code on system level knows, where I’m speaking about.

To name Windows user friendly, what many believe, is more a marketing idea of MS then the truth.
/Ulli

rlkoshak · June 25, 2020, 7:50pm

Let’s all stop the operating systems religious wars on this thread. It’s been hashed out before. No one is going to change their mind. openHAB can run on almost any consumer operating system (even the BSDs) if that works for you.

I believe NCO’s and TRS-80’s point was that most of the time, people confuse familiarity with easier to use. If all you’ve used is Windows for a decade, Linux and Mac are going to be harder to use. If all you’ve used is Linux for a decade, Windows and Mac are going to be harder to use. If all you’ve used is Mac for a decade, Windows and Linux is going to be harder to use.

The easiest operating system to use is the operating system that you know. And OH will work with what what you know.

NCO · June 28, 2020, 7:34am

I agree - so back to HW.

What I like (theoretically) about the Intel NUC is also the housing and space for an SSD inside. Beside the flexibility to upgrade RAM if needed.

On the other side I am quite happy with my RPi3B+ and an SSD I use in a element14 desktop Pi housing.
Unfortunately this housing causes the RPi to stay OFF after a power failure (there is a start button in the housing.

So I would prefer a SBC with a wide range of accessories (housings for ssd and such) - which possibly will result in the RPi4 - unless there is another widely used SBC in the ARMBIAN list, which is more powerful than the RPi3B+

Spaceman_Spiff · June 29, 2020, 4:47am

I recently bought a used HP T620 Thin Client (4GB RAM, Quad Core) used on ebay for 55€. Together with a new M2 SSD (128GB) this cost me about 85€ which is about the same as a raspberry pi 4 kit.
With the ssd this can be a good alternative to the pi 4 with a marginally higher power consumption (~7Watt vs 3.5Watt).
The CPU should be much stronger, but I can’t seem to find the PI4 on any cpu compare sites.
It runs ubuntu server out of the box without any tweaks or problems.

igorp · June 29, 2020, 5:44am

CPU in that Thin Client is somewhere in the range of Celeron J1900 - to have some base to compare. Rpi4 is a bit slower (which is not actually a problem for OpenHab) while SSD connection and proper powering makes Thin client a class better … if you don’t plan to make use of GPIO which is presumably absent on those devices.

github.com

ThomasKaiser/sbc-bench/blob/master/Results.md

# Results

Below some results collected. Please keep in mind that these are **NOT** hardware performance numbers but depend on software/settings (see the differences kernel version makes for RockPro64 for example). The purpose of `sbc-bench` is to generate insights and not colorful graphs representing numbers without meaning. It's perfectly fine for the same hardware appearing multiple times with different numbers since those differ for a reason (software/settings).

Especially *openssl* numbers should be taken with a huge grain of salt since the benchmark numbers depend on kernel features and performance with other use cases (e.g. disk/filesystem encryption) [might look  differently](https://forum.armbian.com/topic/7763-benchmarking-cpus/?do=findComment&comment=59235).

So do **not** rely on collected numbers unless you carefully read through all the explanations and insights below and be prepared to conduct your own benchmarks if you really want to choose appropriate hardware for **your** use case.

## Some numbers

*The below table is also available sorted: [7-zip multi-threaded](Sorted-Results.md#7-zip-mips-multi-threaded), [7-zip single-threaded](Sorted-Results.md#7-zip-mips-single-threaded), [aes-256-cbc](Sorted-Results.md#openssl-speed--elapsed--evp-aes-256-cbc), [memcpy](Sorted-Results.md#memcpy), [memset](Sorted-Results.md#memset) and [clockspeed](Sorted-Results.md#clockspeed).*

*ROCK 5B, Orange Pi 5, RK3568-ROC-PC and Khadas VIM4 numbers are preliminary since software support situation for RK3588/RK3588s and A311D2 is still in a very early stage. Same applies to all RISC-V numbers and [Apple M1 Pro](https://github.com/ThomasKaiser/sbc-bench/issues/47#issue-1300572558). Please also note that with RK35xx devices so far [measured clockspeeds differ from what's defined in device-tree due to PVTM](https://github.com/ThomasKaiser/Knowledge/blob/master/articles/Quick_Preview_of_ROCK_5B.md#pvtm) and also that all these RK35xx based devices perform more or less identical [or only differ by PVTM (silicon lottery) and settings](https://github.com/ThomasKaiser/sbc-bench/issues/75#issuecomment-1672817171).*

| Device / details | Clockspeed | Kernel | Distro | 7-zip multi | 7-zip single | AES | memcpy | memset | kH/s |
| ----- | :--------: | :----: | :----: | ----: | ------: | ------: | -----: | -----: | ---: |
| [Akaso M8S (S812)](results/3R3N.txt) | 1200 MHz | 5.10 | Buster armhf | 3050 | 885 | 32120 | 1160 | 3330 | - |
| [Amazon a1.xlarge](results/2iFY.txt) | 2300 MHz | 4.15 | Bionic arm64 | 8610 | 2406 | 1297960 | 4280 | 14220 | - |
| [AMD Seattle (Opteron A1100)](results/4Kqn.txt) | 2000 MHz | 4.15 | Bionic arm64 | 14080 | 2006 | 720710 | 3020 | 9530 | - |
| [AMedia X96 Max+ (S905X3)](results/3QOj.txt) | 2100 MHz | 5.15 | Focal arm64 | 5270 | 1330 | 981830 | 2630 | 5150 | - |

This file has been truncated. show original

JdeJong · August 10, 2020, 8:08pm

Hi all,

Pretty cool that this threat is still active and people are still contributing.
Just to update my experience, I’m still running on the INTEL NUC, until this day I had no single crash or corruption.
I’ve reinstalled the machine completely, but that’s more because I’m always testing with additional software, programs etc…which sometimes end up in a mess
But, currently running Openhab 2.5.8 on Debian 10.5 without any issues.

The intel NUC has been a perfect buy. Fast, reliable and silent…

/Jasper

Kim_Andersen · August 10, 2020, 8:32pm

Which Intel NUC… There are several you know

Fox27 · August 26, 2020, 3:27pm

Hi all,

Now i’m running OH on a Raspberry Pi 4. But the weak point is always the SD-card. Sinds I have a Synology NAS i’m looking into the options to run OH op this NAS.

Which methode is nowaday (2020) preferred on the Synology NAS? SPK, Docker or virtual machine?.

mstormi · August 26, 2020, 6:20pm

That’s a software question hence somewhat off-topic.
In the first place, a DEDICATED hardware is recommended to minimize dependencies.
That would exclude any of your methods, on any NAS.

Udo_Hartmann · August 26, 2020, 10:49pm

In question of SD-card wearout: Please be aware of ZRAM to minimize write access. It’s possible to use a SSD to start openHAB from, or just boot from (read only) SD-Card, then use SSD for any data.

broliyoung · August 27, 2020, 8:40am

Hi all, someone using odroid n2+? Now is ufficially supported by armbian. It seams to have a lot of kill feature. Only I don’t like the big.little architecture because of some possible little problem during the switch from little to big and vice versa

Suy · August 27, 2020, 8:57am

I’m also interested in odroid n2+ (or even a NUC)…
What do you mean by that big.little architecture problem? Did you read something about it?

Suy · August 27, 2020, 9:05am

I’m also thinking about using a NUC … RPI is primary meant for education purposes, and it get’s hot (RPI4) ,sd card’s are not that reliable and an ssd only usable via USB… Doesn’t sound reliable to me.

MDAR · August 27, 2020, 9:08am

@Suy

I didn’t know they’d elected for that strange combination of CPU cores again, just like in the XU4.

I had terrible issues with Java falling over every time it got moved from big cores to little cores (and vice versa)

The only solution I found was to pin the Java process (or specifically the openHAB2 processes) to the big cores, using the affinity command within the service file.

A search of the forum for “XU4 CPUAffinity” should get you plenty of information

Specifically this post on a thread

FYI

I use the ODroid C2 or C4 as they only have Big cores.

They are both very stable machines that run openHAB2 really well, the C4 is lightning fast with openHAB2.

Especially if you use the DietPi OS (basically a shaved down Debian OS)

Ubuntu 20 headless runs well, but it takes longer to boot the core OS, before it starts loading openHAB2.

Either way, it’s all up and running within 5 minutes.

(Sub 2 minutes with DietPi, on either platform)