I’m in the same boat, where I’ve been experimenting with Home Assistant on a RPi4 running in the original Argon One case. It’s gone well so I want to migrate to the M.2 case, and off of the SD card. Although I do want to restore from a snapshot instead of starting over.
One quick question. Is it still necessary to install a dev version? The current version at the time of this writing is 5.9.
So I installed 5.8 a short while ago, which also installed a new (late Novermber) Raspberry Pi EEPROM update that broke USB boot partially, causing it to hang if you restart the system, but would boot fine from a fully powered off state (can’t remember what issue number it was on Github, sorry).
Oddly, Home Assistant seems to install whatever the “Stable” branch of EEPROM updates are available, instead of the “Critical” branch, which is the default branch (and the most recent “critical” version does support USB boot).
Fortunately the hang issue is resolved in a more recent EEPROM update on the stable branch a couple days ago. And 5.9 disabled the auto update for firmware, so firmware updates will only happen after it’s been confirmed they work. (I’ll find the PR to link, it’s open on my computer at home).
I updated to 5.9 yesterday and so far it seems good. It’s also running 2-3 degrees cooler since that, though I moved it at the same time from on my desk by a window to the top of a cupboard so it has a direct wired connection to my wireless router instead of going through a bridge, so not sure if the move, the HASSOS update or the firmware update changed that.
Once it’s been stable for a few more days I’ll update the guide to 5.9!
Looks like developers are actively working on the issue as it is effecting more than one type of device, i.e pi4. There is a beta os 6.xxx in test. I saw some replies that it didn’t work for some.
That looks really good! It’d be nice to clean up my automations list with something like this. I’ll take it for a spin (heh heh) when I have a little spare time this week
@FreelancerJ Thank you so much for this write up, I’m brand new to the Pi world and jumped straight in with the Argon case, SSD and Pi 4 running without SD card. I had run previously through a virtual machine on windows so this set up is a major improvement and your guide was brilliant. I used the Pi desktop browser to download 5.9 and desktop tool to extract the .img then followed the guide. Once running I restored from a snapshot and amazingly all up and running. One thing remains, fan control!
@adamoutler thanks for putting together Active Cooling functionality (the HA community has some great developers!) but need to setup I2C. With my hardware setup (HassOS from SSD, no SD card) could I use your HassOs I2C Configurator or do I need to follow this guide to complete? Apols if I’m missing something.
The configurator works for me. Let me know if it works for you. I’m going to make a topic soon https://github.com/adamoutler/HassOSConfigurator. It’s going to enable I2C on mmcblk0 (SDCard), SDA (Disk 1) and SDB (Disk 2), if available. Plug in your SDCard and an extra copy on a thumb drive if you have one and it will do all three.
Thanks for the heads up. I’ve run the I2C Configurator and after a full shutdown and restart (a reboot didn’t seem to be sufficient) it looks like that worked:
… adding dtparam=i2c_vc=on to sda1 config.txt adding dtparam=i2c_arm=on to sda1 config.txt no sdb1 config found no mmcblk0p1 config found This Configurator did it’s job. You can uninstall and reboot now. This configurator only works once.
As for the Active Cooling addon, that’s working, the fan is on . I’m using the default temperature settings where the low is 90F, however I can’t get below 95F-98F so the fan runs continuously. I’m not familiar with Pi4 temperatures so just wondering if you have deliberately set a low threshold. The HassOS is only running at just over 1%CPU so not exactly taxed.
Sure thing, I’ll point to the thread for any linking further. Makes sense for any support to be there, let’s you triage questions before getting flooded with issues on GitHub
Thanks! I’m about to refactor a bit of it for the current OS and neatening it up a bit
That temperature seems pretty normal. Mine hovers between 44 and 47 degrees C at the moment, which is just over 110 F I think. When I initially ran it without a case at all, it would bump up and down in the 60s.
The Raspberry Pi doesn’t start throttling due to temperature until it’s in the 70s C, which is like over 150F (if I’m doing that math right), so the passive cooling alone from the Argon case makes a big difference
Thanks for this. I am an experienced developer / sysadmin and use RPis a lot for home use. I am just getting to grips with hass.io and have chosen an RPi4 with this case and M.2 SSD as my HA system. However, I decided that I wanted to use a standard Installing Home Assistant OS route to keep the system as out of the box as possible. So my first step was to follow this guide; I used the 32-bit RPi4 image as my Pi is a 4Gb version and I wanted the I²C support. I also set up SSH to 22 and 22222 as per the documentation.
Going through journalctl boot log, I could see that the standard hassOS boot sequence mounts the hassos-overlay and hassos-data partitions by label rather than device or UUID. So I rebooted the Pi using a spare standard 8Gb Rasbian image (It’s advisable to do this anyway to make sure that the eeprom is up to date) with the hassOS SD mounted in a USB adapter on /dev/sdb. I then used gdisk to mirror the SD gpt partition structure onto the SSD – that is the same 32M, 24M, 256M, 24M, 256M, 8M, 96M, <the rest> allocation.
My initial rationale for this rather than using doing this was than I wanted to use the same gpt structure so that if and when the installation supports SSD out of the box, then I could migrate everything to SSD (and to be honest I hadn’t as yet discovered the datactl move command). I then formatted the sda7 and sda8 partitions as ext4 and used cp -a to copy the overlay and data contents onto these file systems. Lastly I used e2label to relabel the old and new partitions 7 + 8 to old-XXX and (hassos-overlay + hassos-data) before shutting down the system swapping the SD card back and restarting.
Everything came up seamlessly. As far as hass.io is concerned I am running a standard HassOS docker install, and all of the docker containers as expected. It’s just that boot is a lot faster, and everything is a lot snappier. You can only see the mount difference if you log on to 22222 and poke around. I have since upgraded to the latest 2021.1.4 release with a single button click.
IMO, this hybrid approach has a lot of benefits:
it doesn’t materially change the standard install;
it avoids all of the RPi USB boot hassle.
the SD card is really only read during boot and only written to during upgrade;
you get the benefits of reliability and I/O throughput of an M.2 SSD
Nice job! I was running similar to this before the Raspberry Pi had firmware supporting USB Boot. A nice touch is that if I had a problem booting, I could pop the SD Card out and another one in with a full OS, and inspect the SSD file systems to resolve the issue.
Unfortunately, unlike the original Argon40, the m.2 version of the case does not have a access slot to the SD slot, so you need to disconnect the SSD and remove the bottom case anyway
I moved to the all SSD option in this guide mostly cause I wanted to have the setup as close to the officially supported installation as possible, to minimise the number of custom things that I would have to rule out as a cause if anything stopped working, and lower the risk of an OS update going wrong.
I’d love to hear back from you as to how future HassOS updates go. I don’t know how far you’ve read into the structure of HassOS, but there are three major parts that update separately:
HassOS, whose versioning is like 5.9, 5.10 etc
Home Assistant Core, whose versioning prior to December was like 0.117.2, 0.118.1 etc, but is now date formatted like 2020.12.x, 2021.01.x (with x being incremented by 1 for each patch within the month)
Home Assistant Supervisor, which is also date formatted as YYYY.MM.x
As of the 2021 update of core, the Supervisor > System tab now shows all three in the one plaice, and let’s you update them all there too.
So the 2021.1.4 update you’ve gotten through so far is a docker based update, but the one I’d be interested in seeing how it goes is the HassOS 5.11 (or whatever it’s next version is) since that does the underlying operating system and if the split-media partitioning is gonna be a problem, that’s when it will bite. Needless to say, when you see an update for that, doublecheck you’ve got a recent Snapshot from the Supervisor tab, and download it to another computer, just in case
Thanks. I will keep you posted, especially on any HassOS 5.11 bumps. I’d read the reviews of the case, so I didn’t screw the bottom on until after I’d done the SD card shuffling.
One regret is that I am a fan of using LVM2 and use it for all of my Ubuntu and Rasbian servers and laptops. I couldn’t see a way of adding the module to the HassOS boot chain so that LVM2 volumes would be available for use.
To date I’ve just mainly used bare NodeRED and MQTT for my HA, but my son and son-in-law are HA evangelists, so have given into the pressure to switch . I am having lots of learning curve fun, but this is all of-topic.
Trying to set this up and am at the download homeassistant 5.10 but it seems they have changed the compression scheme to xz so no gz file to use. Now can’t seem to figure out how to extract the xz file.
Oh, that’s a good learn there.
I have another Pi 4 coming, which I intend for a different project, but I’ll use it to do a “from scratch” set up so I can update the guide with things like that, once it gets here