Best hardware platform


(Pat Rooney) #102

Yes, I suspect most people have had good experiences with the Pi, but the two failures I had meant I no longer trusted it. The SD cards I used were good quality also (Kingston & Verbatim Class 10), so perhaps I was unlucky. But for me the extra expense of the NUC was well worth it for peace of mind.


(Ben Helps) #103

Still a fan of repurposing an old laptop personally. Free built in UPS :wink:

In all seriousness I’ve shied away from sd card devices for exactly the reason of silent failures.
An old laptop I had running off a 4gb stick managed 2 years before corruption, but I tweaked it to make it so ( no swap, map /var/log to a ramdisk, cut out unneeded services/logging, etc )


(Rich Koshak) #104

Everyone’s experience is different.

Backup and restore is a must. You can’t just set it and forget it with a system like OH that you are constantly updating, changing configs, and which is saving data. There will be failures no matter the platform or hardware it is running on.

There are a ton of RPi+HDD cases.

I think this is another case where experiences differ.


These are my running RPis. The uptime is reported in Days:Hours:Minutes:Seconds. So yes, Hydra has been running without problem for over 96 days without a reboot.

Cerberos is a RPi3, Hydra is a RPi Zero W, and Manticore is an RPi 1B. Note that the actual uptime is much longer. Those numbers are how long the service I have running on those Pis that report sensor readings have been running. I find them to be very solid platforms. I don’t think any of my VMs have as long of an uptime.

I’m not saying that your experience is wrong, but I don’t think it is the norm. Maybe you were unlucky and got a bad RPi.

I think the number of people who do so provides a decent counter-argument. I’m not trying to convince anyone that RPi is the way to go. In fact, if you have a choice I would recommend using a more powerful machine. But I do think it is well suited for the job for those who chose it.

http://ideaheap.com/2015/03/log4j2-rsyslog-logging/
https://fabianlee.org/2016/10/17/syslog-sending-java-log4j2-to-rsyslog-on-ubuntu/


(Pat Rooney) #105

I certainly can’t argue with those numbers @rlkoshak, very impressive! My issue with the cases was that by the time you add the cost of the case to the Pi you are close to the cost of a NUC, without having the SSD attaching via a USB cable, which just looked like a bit of a bodge to my eyes. The WD Pi Drive looked the best but was expensive.
I now have one of my Pi’s running Kodi (OpenElec) and it’s rock solid in this role.
On reflection, perhaps it was the fact that I had an Aeotec Z-Wave dongle, a NooElec 433MHz receiver and the SSD drive hanging off the Pi that caused the problem by drawing too much current?
Anyway, I now have a solution that works, so I’ll stick with it.


(Rich Koshak) #106

Very likely. The RPi is very sensitive to inadequate power supplies and to USB devices that draw too much power.


(zolakk) #107

I’ve been running on a Pi3 for over a year and I’ve never had to replace the SD card or reboot it aside from config changes and to move it so I could include my zwave locks. What I ended up doing is just redirecting /var/log to an NFS share on my PC to save on wearing on the SD card


(Kjetil Volden) #108

Nice to know it’s possible. But it would be cool with something a bit more built in and ready to go. :slight_smile:


(Rich Koshak) #109

The number of people running OH who would want to use syslog is a very tiny percent. And since those same people will already have the skills to set up rsyslog will also have the skills to add a new log4j2 appender to the logging config I don’t see how it would be worth the extra effort to make something “built in and ready to go.”

Of course, PRs are welcome if you disagree.


(Frank Rein) #110

Hi @NCO,
4 months ago you said that you moved to a rpi with ssd. What are your experiences with this setup up to now?


(E. Gerland) #111

Sorry for the delay.
I am absolutely happy with it.
No issues anymore regarding hanging system and such.
I am using this one now:
https://www.element14.com/community/docs/DOC-83477/l/desktop-computer-kit-with-expansion-board-that-can-turn-a-raspberry-pi-into-a-real-desktop-pc

Just yesterday I bought another ssd to make a safe image of the runtime system.
Now I am absolutely convinced that this is the right way (at least for me).


(Skinah) #112

I use a raspberry pi 2 currently and I am trialing this method to deal with SD corruption as it only occurs when you write to the card. I also use a UPS which is key to stopping power outages causing issues. Stop the writes and you stop the corruption, it really is that simple. The green LED on the pi shows you when the sd card is writing.

Is anyone using the XU4 from odriod?


(Frank Rein) #113

Thanks very much @NCO


(Rich Koshak) #114

Note that reducing the writes only delays the wear out. Since it is impossible to eliminate ALL writes to the SD card this approach will primarily just delay the inevitable.

That being said, reducing the writes enough and given an SD card big enough you could extend the life of the SD card to decades so it can certainly be worth while.

My biggest problem with SD cards though is there is no forewarning when it is worn out. The system will simply start behaving strangely and you will not have a real good way to know how long the SD card has been failing so you know how far back in your backups you need to go.


(CLAUDE BEN SHAUL) #115

I’m using a Ockel Sirius B miniature PC running Windows 10. I was one of the backers of the Indiegogo campaign and decided to use it as a dedicated openhab server. It’s really tiny, barely larger than my phone.

I never consider loading Linux on it, despite coming from UNIX and having also spent time with IBM AIX. I’m more comfortable using Windows at home


(Skinah) #116

That is not even close to why I reduce and aim to stop writes, I do not care about the flash wearing out as that is such a small aspect of the issue. Flash storage in general works by storing things in BLOCKS and the issue is because when doing a write to a log file, that same storage block can/will contain parts of other files in it. If the power fails in the middle of a write, you will get data corruption and it is not corruption just in the log file, it corrupts other files that you rely on for a stable setup. This is true of all flash types and (sorry I have to laugh when people tell me a usb stick is better) unless the hardware has a way built in to handle it like a SSD does which is why they are larger and cost more. Essentially they have a mini UPS built in that detects a power issue and will dump to the storage and complete any writes before the power completely fails. The only reason using a USB stick helps is because if you move the log files to a USB stick, you then move the writes onto the USB stick where no important files are contained. The storage blocks only contain log files and hence it is less of an issue. If you understand the root of the problem, you can then design around it and you can google and read more on this topic.

Flash wearing out is no where near what people make it out to be, usually it is a fake counterfeit card or is caused by people thinking that pulling the power out is OK because the PI has a usb power input. It is never ok to pull the power when a write is occurring or a file is open. A UPS is important and small cheap ones for a PI exsit as someone linked to a nice case in a post above that has one added.

I worked for years on a development team for an embedded Linux device which used flash storage and I was part of the design meetings of a large team discussing this. I then littlerally pulled the power out hundreds of times each day when doing testing on the device so it does work. It is also known and discussed about in other rasbian projects yet here in Openhab land very few people attempt to stop the mis-information. Stopping all writes completely can be done by mounting as read only, which makes things harder when wanting to do updates and trying to provide support to people with little Linux experience. Doing what I outlined in my post has worked well for me when I reduce the log file generation to keep the logs below 17mb where they rotate. The other downside is it requires a UPS as in the case of brown outs where the power cuts in and out it wrecks havoc to a SD card as my current method does not stop the writes on boot up and shutdown, hence a intermittent power will quickly corrupt things still.

I use two PIs setup ready to go to swap out and use images of the cards as a backup. With so many PI’s around the house and the ability to write the image to a new flash card it is simple to get other people to swap a device out when I am not around.


(Skinah) #117

Anyone tried one of these?
2gb ddr3, gigabit Ethernet, sata and loads more grunt than the pi range.

http://www.hardkernel.com/main/products/prdt_info.php?g_code=G151505170472


(Markus Storm) #118

I have one C2 running fine as a Kodi server but not as OH server. Just saw a new thread on this forum about someone doing that, though.
Downside is C2s are not pin compatible w/ Pi hats and you cannot use openHABian images, so it’s always somewhat off-mainstream.


(Rich Koshak) #119

Which is what the UPS is for.

Agreed, USB is no better.

And yet we all seem to experience the problem at some point or other. And often it is ready to tell the difference. For example, a files that revert to the same older version on restart of the OS every time is not caused by the corruption of a single block.

And stopping all upgrades and updates, dealing with the writes to fake hwclock, etc. Agreed, you can run as read only but you have to disable a lot of other important features like OS and OH upgrades. If not, then you have only reduced the amount if writes, not eliminated them. But if you reduce enough of them then it’s no big deal as you have extended the life of the SD card beyond what anyone should need.

And you have a fool proof way to help people I’d such a counterfit?

From a practical perspective on the forum, it is exceptionally difficult if not impossible to help or guide a user through the process of diagnosing the difference between corruption because of power loss. So we have two choices. We can risk waisting time and have them rebuild on the old SD card it were can have them go but a new one and stress the need for backup and restore procedures and a move to a network mount or SSD or HDD.

Sorry, I’m not convinced. Guess I’ll just have to keep spreading my missinformation.


(Skinah) #120

My appolgies that was not directed at you, I got ranting about what people in general write and should not have done so after hitting reply on your post.


(Colin MacKenzie) #121

It seems like there is a need for hardware targeted specifically for OpenHAB. I have a Wink Hub 2 which has Zigbee, Zwave, BT and Wifi radios and yet it is largely useless when it comes to bindings for my stuff and no way to improve it. If I made a Wink Hub2-like Linux board with all the radios would people be interested? My current thinking:

  • Uses multiple Ember EFR32 chips which can be configured for Zigbee, Zwave or BTLE
  • Uses Octavo OSD335x which is basically a BeagleBone Black in SoC form.
  • Would still have usb, GPIOs, I2C, etc…all the stuff a BeagleBoneBlack has.
  • Would have built-in flash plus sd-card…but configured in a way that the OS doesnt get corrupted. I’ve had this happen on some of my RPi/BBB projects as well.
  • This thing would be small and cute. Probably about the size of a hockey puck would do it.
  • It would not be RPi cheap unfortunately…scale/demand can’t compare to RPi demand and thus economics. The Octavo chip itself is $40, PCB, case, plus 3 Ember radios and a Wifi one I might be able to target $150.

You can’t even get RPi processor chips so RPi-based is a bust unless I just make a Hat. Would people prefer just a Hat with the radios? That would likely be cheaper, but doesnt solve the corruption issue.

I am new to HA in general but this is trully the Inter-mess of Things. The industry is still too fragmented but OpenHAB is the first thing I’ve seen that seems to bridge the divides. I just got some NXP based chips working with custom firmware based on their SDK and going to try out the Ember ones next as their chips can become any mesh-net standard - zigbee, zwave, btle, etc.