I used to run hassbian from ssd on my rpi3b . im now using a rpi3b+ witch forces me to use sd card to run hassio. After 3 dead sd cards Im now spending to much time restoring images and that I am not enjoying…
I like the rpi very much as a server and uses the gpio for in and outputs so an nuc is not right for me.
Do anyone her know if it will be possible to run it from isb in the future?
How are you killing SD cards? I just started with my 3b+ this week. The recommended (by RPI Devs) path, if your machine is Windows or mac is to format your SD card with the SD Formatter tool.
That has been working for me with NOOBS. I plan on installing Raspian or Raspian Lite & then Hassio.
My testing of HassOs in a VM indicates HassOs flakiness.
To install Hassio I will use the Linux install instructions, skipping the non-existent Universe repo & adding the machine architecture argument to the Hassio install command.
The way most people end up killing cards; exceeding the I/O cycles of the SD card.
If you have a lot of sensors which rapidly change, and are storing these in the logger, and maybe in InfluxDB, you’ll likely find that the SD cards wear out faster than you might expect.
It depends a bit on luck, picking a good “high-quality” SD card, and managing your system to limit excessive writes, but I’ve seen SD cards last anywhere from a few weeks to a few years.
I agree that HassOS really should be made USB bootable. Being forced to use a device as unreliable as an SD card for booting and the database is undesirable from the point of view of reliability. Automation and security both need to be reliable. USB memory sticks, SSD’s and hard disks are a much better option than an SD Card.
The ability to install Addons with one click is attractive, which is why, after a lot of frustration with HassOS, all caused by filesystem (SDcard) problems, I will switch to Raspbian with Hass.io installed on top, on a USB connected SSD.
thank you for taking the time to help me out here.
I tried that and if I remember correctly I had the following issues with this approach:
Docker CE is not available for Raspian Buster. See this post:
I think I then run into this issue described here:
And then I browsed this page to fix another issue:
I finally had hass.io up and running but finally failed installing the deCONZ add-on. It always said “This add-on is not available”. I think I was not able to make my Conbee II stick available to the docker container I guess.
Happy to give it another try. Perhaps I made some simple mistakes along the way.
I just need to know how to make the USB stick available and/or install the deCONZ add-on. Then I would be fine.
Use Rasbian Stretch until Buster has been updated. Just this week I did a fresh install using the above method on an RPi3 running Stretch. Running perfectly. Buster is not needed (unless you are using a Pi4)
Basically you download any image and use e.g. the balenaEtcher (for Mac) tool for put it on your hard drive. balenaEtcher normally works for USB sticks or SSD cards only but with some settings you can use it for SSDs too. Just be careful here to not accidentally wipe your main disk.
I think you are all going to have to bear in mind that any device has a number of write cycles (read cycles don’t seem to affect stuff much)
So most fails are (in order) : -
SD cards (followed pretty closely by)
USB Sticks (then a respectable gap to)
SSD’s (followed by a truly significant gap (orders of magnitude))
Hard disk
We are awaiting new solid state Hard disks based on varistors (I think that’s the term) the technology is available but they say being scaled down and tested (come on guys, that was 4 or 5 years ago). This ‘should’ extend cycles beyond hard disks (and maybe we can drop the ‘disk’ bit by then too) and no moving parts (like some of the current weaker options).
Whilst we wait : -
Reduce your write cycles
Most ‘drives’ (also refers to the motor spinning the disk) include wear evening, so it tries to ensure the ‘disk’ is worn out all at once (as it fails). This is why HA recommends a much larger card than you need, to spread the wear out.
So what do you use all those logs and history for ?
Turn off everything, then enable only for what you ‘need’ (not ‘want’, there’s a difference).
Buy a good quality ‘drive’ and treat it with respect, and it will be with you longer.
The devs hear your requests but they are constrained by meeting a reasonable price point for the ‘average’ user.
In the interim @kanga_who ('s excellent and continually updated guides) are able to help many people push the current envelope.
There are also guides on turning off history/logging and also for enabling specifics (it does help with debugging, but I’ve turned it all off)
My $0.02 anyway