+1 agreed.
Processor cache for this device is smaller than a RPi so it will be slower when performing SQL lookups. FYI. I.E. RPi is better for HAs database. Just did some research on this no too long ago.
Great write up. Thanks for taking the time to do this.
Got a bunch of random issues with SD cards also with rpi3+, finally bought usb3 to m.2 enclosure and cheap 32gb m.2 ssd. It was about 25 euros total from eBay.
It was major improvement in the beginning, but gradually declined because of the database. Now I changed database location into ram with instructions in this thread and everything seems to be really smooth.
Trying to run HASSOS is not that easy with usb drive but for some reason I prefer the standard raspian image and python virtual environment more because the environment feels more natural.
HA is great. HA on an RPi is not. Anyone still recommending hass.io probably just got lucky and never tried anything else.
I bought a Synology 2-bay NAS with a SSD drive - JUST for this, and it’s stable as a rock!
I too are tired of the endless stream of lame excused from people that just know better how to run it on an RPi. And it’s ALWAYS the SD card that’s the problem - “Buy a better one”. BUT NO ONE NEVER SAID WHICH ONE IS ACTUALLY GOOD ENOUGH! I know for sure my genuine SanDisk Ultra was not up to the task…
And seriously, why do people bother? Do you just hate, and need to torture yourself by running it on a device thats clearly not suitible for it?
This is use specific.
I’ve run RasPi 2yrs last count without fail or reboot. These were headless video players and some HA remote devices.
If you have heavy r/w on SD it likely will fail. You must use correct equipment for your use. Anything used in wrong manner/environment will fail but blanket “don’t use” does not apply here.
I had the same issues with HA/SD Card. Moved my installation on an SSD and upgraded from ResinOS to Raspian Lite and Hass.io, no problems ever since… and much faster in general.
Well… I had situations where even HA wasn’t starting anymore and had to reinstall the whole thing. I believe this happened like 5 times. Especially custom components can be very unreliable for the RPi and were the main issue for me.
I encountered no issues with the database, however, I also upgraded after fiddeling around with the RPi for like 2 months. Now running on a budget NUCi3 with Ubuntu server 18.04 and Hass.IO in docker. I can never imagine going back to a RPi and I therefore fully agree that the RPi shouldn’t be the recommended setup for Hass.io. A RPi can never outperform a NAS/NUC in terms of performance, stability and customization.
As we still dont have v1.0 the RPi might still be ok, but with the future versions/releases and its integrations/components, I believe the RPi will be less and less suitable for Hass.io IMO.
1 Like
I’m just curious about all the corrupt SD cards laying around.
Is there a way to test them as failed?
I had experienced the same as the topic creator. Had one SD for 6 months. Strange crashes. Replaced SD. Tested the old SD with some tool (on win, don’t remember the name), it could read and write correctly all the time.
The new SD seemed to work for some time. But… some weeks ago I had to do some restarts again.
So, how do you guys test your bad SDs?
If you do not need the database, RPi is still a good option. I have mine read-only file system…
Copy a file to it, eject it and reinsert the SD Card, if the SD card is shot the file you copied will be missing.
I use a utility for linux for f3 that checks the card:
http://manpages.ubuntu.com/manpages/trusty/man1/f3read.1.html
In my experience, running HA on an almost 15 year old single core Pentium M laptop, 1GB of RAM and an SSD is worlds better in performance and reliable that the SBCs. Tried multiple SBCs in the OrangePi line and inevitably would have issues after a few weeks in “production”. System becoming unresponsive, SD cards failing (even industrial rated SD cards) and generally poor performance. A lot of this is the database. In my humble opinion, it is very poorly designed. Storing JSON strings defeats the purpose of a relational database and absolutely murders query performance since most of it has to happen in code, not in SQL. Moving to MySQL on the SBCs seemed to help a little. But then memory became a problem.
After the processor in an OrangePi Zero (I realise the 512MB of RAM is a bit light to run HA) quite literally melted, I loaded HA on an old laptop running Ubuntu Server. Zero problems since. Bonus is the laptop has a built in battery backup.
Don’t waste time on SBCs for HA unless for testing/learning.
For me it’s Vmware for easy backup/restore and the machine lives on an SSD for a great IO boost. Moved the DB over to MariaDB and got some serious speed increase for start time of HA and ability to view logbook & history instead of the endless wait I had with SQLite (DB is about 1GB in size). I do run Ubuntu and have small regrets here & there because HassIO and the plugin capability is always annoyingly pretty to look at. I have to manually weave in integrations & related components. It’s certainly not as plug and play but gives me lots of control and is truly rock solid for a good 2 years. The MariaDB switch is recent though… and so worth it.
Some people here have used SD Formatter as recommended when reusing an SD Card and then found the card was good.
Why install Ubuntu on a Pi when Raspian and Raspian Lite are available?
You can run Hassio on Ubuntu. In fact their Linux installation instructions assume Ubuntu.
before u give up
Put on a real PC
I put HA on one of these
and it has not miss a beat ( its headless and change bios reboot when power off )
have 16 Tasmota Switches (4 more on way)
did this also
then did this one of today
just order 3 more
and im a kiwi ( new zealand)
I’m running hass on an Pi 3B with a 64GB SD card. It would start out okay but after a few days, I would see in ‘htop’ that the hass process was spending a lot of time waiting for disk I/O. It slowed the Pi down with other tasks as well.
I decided to create a compressed ramdisk using ‘zram’ and have hass record the history on the ramdisk. Configured the ramdisk to be 128MB and have the recorder retain 14 days worth of information (default is 10, I believe). So far so good. I have been running it for about a week now and the db file size is about 80MB. The sqlite file compresses pretty well, so I should be okay with the ramdisk size (assuming a > 50% compression ratio).
I use Hassio with database on mariadb (but still on sd card) and i have no problem at all. it is working for moths witout errors or reboots. for sd card i use sandisk A1 16GB. i set purge days to 60 without a problem now i try with 90 day to see if it is working
Just looked this up and there’s a heavy docker dependency for both HA and the “supervisor”… I kinda like the fact that HA runs directly in Ubuntu. It helps me monitor the Ubuntu server things that I want and has access to the shell for any command that I’d want to automate. Is there a way to install HassIO w/o that docker dependency, directly in Ubuntu?
For folks still doubting it, there is nothing like the ease of restoring a VM of any flavor VMware, VitrualBox, HyperV, XenServer, ProxMox, QEMU, etc. — and being up super quickly whenever the underlying hardware you’re using decides to break. Keep in mind that you can run many more things like ElasticSearch and it’s Kibana dashboard (ELK stack). If you do that on an RPi it’s just ridiculously slow. Same with start time of HA with my 160 or so devices. It’s multiple minutes on RPi vs. 30-40 seconds for a restart of HA on a hypervisor (better on SSD of course rather than mechanical).
I realize power is not free and an RPi obviously has that low consumption advantage. However, RPi SD corruption over long running time and the speed lag with more IoT devices should quickly outgrow beginner HA tinkerer. I can only see an RPi as a sandbox or a backup device. So while power is not free, neither is my time. When waiting for the hundreds of HA restarts that I have to wait for, the quicker those go the better for me.