Best hardware platform

another option is a apu2c4. specs are 4 cores/1GHz, 4GByte RAM, 16GPIO, RS232, USB2.0… power consumption about 6 to 12W (depending on CPU load), that’s very nice.
Downside is, there is no graphical interface, so you have to install Linux via serial console (but this is quite easy) - after that, you can gain access to console via ssh.

1 Like

Just to add my personal opinion here: I would also stay with a straight ahead RPi openHABian setup IF no special hardware requirements are available.

(In my case I have a special Homematic piggyback PCB interfacing with the RPi so I’m actually bound to that device.)

I would also btw not take any special steps to reduce wear. Utilize a backup strategy. See also:

1 Like

The one issue I’ve had just recently with the chromebox is upgrading the
kernel. There appears to be a difference of opinion on where to store the
UEFI boot files between the firmware authors and the ubuntu folks. This
causes issues on kernel upgrades, and I’ve yet to sort out a step-by-step
to correct. I have had success using the ubuntu boot repair software to
fix it after updates, but it would be good to avoid that if possible. Any
boot experts out there?

Another chromebox approach I haven’t tried yet is using the google
seabios. It is supposed to be able to boot a kernel in bios mode. Maybe
that would avoid the uefi issues.

I’d be interested to hear of other experiences with using X86 boards. I
looked at the up-board, jaguar board, latte-panda, uudo x86, and minnow. I
am sure there are others. I picked the chromebox mainly on price, and that
I have one still running chrome os as a streaming media unit. Under chrome
os the box is maintenance free and never crashes. Still working out the
kinks with linux.

The fan is almost silent. You have to load the cpu and put your ear on it
to hear.

Using the legacy SeaBios firmware on chromebox works. I was able to update from lubuntu 16.04 all the way to 17.04 with no issues. Wifi, audio, etc. all seem to work fine in 17.04. I am interested to hear experiences from anyone else using x86 boards for openhab. Still trying to sort out startup issues with Mysensors though. I thought that the combo of x86 and usb arduino would have been the easiest example to work from, but it doesn’t seem as popular.

I actually went with a SSD on a raspberry solution and am really happy so far (maybe too early to judge though…)

Hey Michael,

I know this is an older thread, but wondering if you have any links to installation or configurations using these appliances for OpenHab.

I like the idea of using appliances for these setups, but want to do some more reading up on it before i start to invest the money.


I would guess it’s straight forward:

  • install debian/ubuntu/whatever you want (including windows)
  • install java8 (oracle is best choice)
  • install openHAB
  • configure openHAB…

As you don’t need a graphical interface, the (possible) lack of open source drivers for the graphic adapter will be of no importance.

These days most of the maintainers seem to be recommending Zulu as the preferred JRE. It is the version that ships with the Docker Image and it seems to have a prominent position on the install docs. I have seen mention it performs much better on ARM than Oracle JRE.

hey guys, I want to ask about SDcard vs EMMC questions: does those are the same type?I know emmc gets much faster, but what I want to ask, is does emmc has the same issues like sdcard’s after running a few months? what if I need a really stable environment like running years without any issue, what kind of storage I should choose between sdcard and emmc?

I don’t want to install the system inside a ssd due to the size of a ssd is too large, I want a tiny sbc which can running OH2 like… years…can I trust EMMC?

I think the jury is still out. Some claim EMMC will last longer than SD but they are fundamentally the same technology and EEMC will wear out eventually. You will have to look at the cycle rating for the EEMC you choose and come up with an estimate of how many writes you will be doing to calculate how long you would expect it to last.

There is no small form memory that I know of that doesn’t have the wear out problem.

Your best bet will be to way overprovision the storage (more storage means more bytes to write before the card starts to suffer wear since the writes are wear leveled). At the same time you will need to minimize writes which means moving logs and persistence off of the SD/EEMC card. That will buy you some time.

Practically speaking what you are asking for is impossible. If you really want a system that will last years or nearly indefinitely you need an SDD or HDD. The suggestions above will only buy you more time before the cards wear out.

1 Like

thanks man, really awesome detail explaination, looks like the ssd/hd drive is the only correct way to go if talking about years running
btw, I am currently running with 10+ items with influxdb and mapdb persist(cpuload1, storage left%, memory used%, humidity, temp, lux for every hour), and I also run docker glances to monitoring the system os health, it currently shows around 7k/s both write and read, does it looks normal in your perspective? (7k/s w/r, emmc) I did some googling but not sure why I always get 7k-14k/s(maybe it’s coming from ubuntu os log?)

and btw, I am using a x86 sbc with N2808+2G+32Gemmc, lubuntu desktop and running almost everything inside docker, so far I think this is the best hardware for OH2(low power=3w, low heat=33c tiny=100mm x 70mm)

I’ve no idea. Everyone’s system will be different and the amount of writes is driven by so many details specific to your setup that what is normal for me can and probably does not bear any resemblance to what is normal for you. I run everything on a desktop server in VMs so I’ve never bothered to measure.

I think the best will depend on each individual’s particular circumstances. For me the best is to run it on a powerful desktop server because I have so many other services I need to run (Claibre, Plex Media Server, Gogs, Alfresco, InfluxDB, Mosquitto, openHAB, a virtual desktop, OpenMediaVault, PFSense, ZoneMinder, etc). It is impossible to run all of that on a SBC, some won’t even run on SBC (e.g. Alfresco) by itself, and it is not cost effective to buy a bunch of SBCs to run it all. So for me that machine would be a poor choice.

Hi Richard,

As other have said, it is fairly straight forward from a typical system admin point of view. the basic flow would be:

  1. Create a Linux install USB key from Ubuntu
  2. Boot from USB install key and follow basic install (minimal install, no gui, etc.)
  3. Install JRE, following instruction from Oracle JAVA Linux install doc (basically xtract tar to dir, add sym link to /usr/local/bin, etc.)
  4. I do manual install of OH into /home/openhab2 (personal preference)

The hardware is functionally no different than a laptop/desktop, etc… It is just a small form factor PC that is very easy to wall mount with bracket, low power, etc. I have been more than pleasantly surprised with the performance/bios options, power utilization, etc… I use these for my pfSense firewall, Ubiquity/OH host, etc. (not that there aren’t more similar options as mentioned out there)

If you have any more specific questions, let me know!


Just in case anyone is interested: I have picked up a China box called Beelink M1 from Amazon and put a 120GB 2240 M.2 SSD inside the device. I wanted to replace my RPi3 with something slightly more powerful, with more RAM to do fun stuff and with more longevity concerning the storage after my micro-sds failed twice on me each after roughly one year. Unfortunately, the device is kind of picky what Linux it boots. I could only make Archlinux boot on it (tried Debian and Ubuntu in all kinds of flavors). But other than that, it works pretty well. The biggest downside is that it doesn’t auto-boot when it gets power. You always have to push the power-on button which really is a showstopper for server-based usage. I’m considering to replace it a Gemini Lake Intel NUC next year.

So just as a hint to consider when looking for a device: look for the auto-boot on power bios feature.

1 Like

Hi Jasper,

I’m using a board developed by us based on Raspberry PI CM3. On that I’ve applied all the design experience already done for other industrial grade boards, in particular for the SD card circuitry. We’ve done a lot of tests on switching off the power brutally without any damage of the SD card. This solves, at least, hardware problem on corruptions and still maintains the use of a so easy and spread system as Openhabian is.

1 Like

Wouldn’t another viable approach be to develop a redundant controller capability within OpenHAB. You run two identical configured OH Pi’s (or whatever) with one taking the ‘master’ role and one ‘dormant’. If and when one of the Pi’s fail the other takes over immediately and alerts the user of the failure. Some form of SD backup is immediately done of the remaining ‘good’ OH SD to replace the failing one and then they are synched again.

This allows for affordable hardware with no downtime at time of failure, just requiring some timely attention in case a double failure should happen (or possibly it could support several redundant controllers).

It’s not as easy as it seems:

  • what about external hardware?
  • persistence?
  • pi IO?

You would have to ensure constant contact to the internet (just to ensure the user gets the alert :wink: and of course you would have to use a UPS (one for each pi) but even then…

1 Like

Just to reiterate what Udo said. Of corse it is viable, but it will be WAY more work than just using a viable SD card backup and restore policy.

And one of the challenges is there is no “Hey! Your SD card is failing!” error one can use to know when to switch to the hot backup. Instead, SD card failures tend to show themselves by random inexplicable behavior like log files not rotating or changes to config files reverting to the pre-edited state. You SD card could have been failing for quite some time before you ever know it is a problem.

@NCO and others interested, I did convert over to Seabios on the chromebox. It solved the kernel update issue, and I’ve had the unit with 20+ days uptime. I have seen issues with crashes and hangs though, but I haven’t had time to investigate the few times it’s happened. Another recent conundrum is with wifi - I’ve seen my router drop and the chromebox doesn’t auto-reconnect. Searches show this isn’t uncommon with ubuntu. My guess is there are driver issues with the wifi chipset. Given those issues and the occasional router / modem hang I’m looking at this:
Going with wired ethernet isn’t an option due to lightning strikes in my area. I’ve already had to replace routers and other components that were directly connected to it. I am beginning to think unless a board is designed to work with linux (i.e. all chipset spec openly available) it will likely have issues.

Were you able to identify the cause of the crashes and hangs?