The RPi Compute Module used in the Telegea Smart Hub is designed for industrial use and mounts an eMMC flash storage which replaces the SD card. The flash chip is a Samsung KLM4G1FEPD. Here is some information from its datasheet.
We don’t have specific data for running OpenHAB on this device for an extended time but we’ve been using many of these devices for other projects for more than a year and never had any issue with the flash memory.
Raspbian with OpenHAB is running fine on the Telegea Smart Hub (see details here). We haven’t tried openHABian yet but if this is of interest we can certainly do this.
You’re absolutely right that ALL systems will fail and I was pretty happy with the raspi in the past.
The recent weeks have been a little annoying.
Assuming that I have a working image of my runtime system and would move it to a brand new SD-card. Does this mean the image would work for all the upcoming failures (exchangeing the cards each time) or is it possible that the image will migrate issues (corruptions) to the new card.
(Maybe a stupid question!?)
My new option would be a NUC (Intel NUC Kit NUC5CPYH) with 4 GB RAM and a 32 to SSD.
I assume that this will be much more stable will cost just about 180€.
I did not check out Amanda in openhabiann, but will do before migrating to the NUC.
If you copy a working image (non-corrupted ! You eventually just didn’t spot that yet, so better install from scratch) image to a spare card and lock that one up in your vault, yes, then you should be able to recover your home if your active card dies of corruption (but don’t run off that copy… that would corrupt it !).
Now you didn’t fully read my posts, did you ?
there’s risks and drawbacks if you change architecture
cost (think of spare HW, too)
you still need backup.
If you have backup, you don’t need to change HW
You could as well attach just that SSD to your Pi. Or attach a simple USB stick instead and move all logging there as described in the thread I referenced.
But the point remains: You need to get your backup right. Amanda can create SD card copies for you, too.
Sorry to give you the impression that I did not red your post (I did
I just wanted to emphasize that a change to a NUC and RAM with SSD would eliminate the corruption caused by the SD-card.
Actually I tried to overcome this by an USB Stick already (moved root to USB using openhabian), but the issue stays the same (I will start from scratch to verify though).
I do backupsevery now and then, but it does not help, if I am not at home, when the systems crashs.
So I just would minimize the risks by considering HW not using SD-cards at all.
May or not be as easy using paper ui, but for backups I tend to just do tar zcf backup.tar.gz /etc/openhab/ and then scp it somewhere with a cron script. If fact just all of /etc/ (for mosquito, zone minder, etc)
If a hdd is borked I just reinstall Linux again.
Best life I’ve ever gotten out of a memory disk was 4yrs uptime off a laptop running of a 4 gb USB stick, though from memory I had /var/log mapped to /dev/shm on boot and no swap
To move root to USB does not make a difference.
I’m referring to this post. No, I don’t think you read it …
SD and USB might have been bad right away, but that would have been a big coincidence.
Most likely your data was already corrupted when you moved it to USB.
Yes, start from scratch. And check the Pi HW before that.
To use different HW minimizes , but does not mitigate the risk the way a backup concept does.
No, I still don’t think you read it
You could create a SD clone and instruct all of your family members how to install it in a Pi just in case.
That’s what I did …
Now I have read your post (again
What I don’t get though:
If I make a backup of the sd-card every day and the system crashes due to a corrupt sd-card, how do I know which one is not corrupt?
I did several sd-card images of my system, so before starting from scratch, can I somehow check which image is still not corrupted?
Should I perform a format process or is this done by windiskimager anyway?
Nope and nope. At least I don’t know of any safe method.
Fair questions, but I don’t have any answer other than to do ‘trial and error’.
Keep enough generations to be able to go back far in time if required.
From time to time, switch cards to boot from that SD you’ve just written your image to. Keep those that have proven to work.
In case of need, it is better to run off an older but verified image. To avoid confusion: this applies to RAW (SD card level) device backups. Plus, you should have daily filesystem-level backups so if in need , put in an old image that you know to work, and copy over the files that have changed since (or simply copy all config files).
Amanda can do both for you, raw AND file level backups in one dumpcycle.
Before I move over, I would like to check some more (cheaper) options.
(Thanks @mstormi, @rlkoshak for convincing me).
Start from Scratch with brand new SD-card and virgin openhabian 1.3 including moving root to a USB Stick to reduce wear of the SD-card (logs and persistence).
Try the same (Move logs and persistence) to my NAS (Wouldn’t it be a good feature to do so from within openhabian (look for a mounted share and move them)?
I run a 4 NIC port version of this for pfSense firewall and these for instances of dedicated “PRODUCTION” uses where typically use RPis for test/dev. (ex. share one system for OH2 and Ubiquiti network controller software)
Couple of quick notes:
Uses x86 so easy to setup with ubuntu, etc.
mSATA drive module so the SD-CARD issues aren’t really an issue.
2+ GB and JavaVM for OH2; very responsive.
Fanless / no moving parts
with 2+GB mem, plenty of resources for multi-purpose (like mentioned above)
the BIOS options are fairly impressive. When getting the 1st one, I was expecting the basics for BIOS options, but was pleasantly surprised with the many features.
looks interesting indeed.
Looks like a quad core Celeron J1900 - should be enough for a dedicated OH server :slight_smile
I will put it onto my list of potential approaches.
After some discussions in this thread and the others about sd-card corruption I consider as a first try to move mySQL and logs to my NAS and see if the sd-card issue improves as expected.
Thanks for the hint to the firewall barbone
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.
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.
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.
