Raspberry Pi 4, Home Assistant OS (5.5, dev version) on a SSD, and the Argon One M.2 Case (In Progress)

Thanks for letting me know, glad you’re up and running!

There is a note about potentially needing to sudo the DD command, but it was part of a larger paragraph, so I’ve now edited it so it is on it’s own line, immediately below the example command. I don’t like post examples of commands like dd with sudo pre-pended, since dd can be very destructive to data on a computer system if you just copy and paste it and hit enter before editing it to apply to your system, and I’d feel bad if someone wiped out their photos or something because of that. Leaving it to people to add sudo kinda helps avoid that, cause you have to stop and think “why didn’t that run?”.

I’ve also updated the i2c bit to confirm a second reboot is usually necessary to get it up and running. :slight_smile:

Does this case come with a power adapter?

It does not. I am using the official rpi4 adapter with ssd, working fine.

Ah OK, so it uses USB-C!
I thought that audio output was a power connector, didn’t find any info on the power adapter needed and whether it is included or not. :innocent:

I first followed your procedure to install this Argon40 case. Than I moved away from HassOS for convenience reasons (I need to access a browser via VNC on my system to monitor local equipments). So I used a portion of your procedure to install HA supervised on Docker + Raspbian OS 64 bits on this Argon40 case / Raspberry pi 4B/2Gb ( by the way Raspbian 64 bits is still in development !). Way less manipulations to get Argon40 up and running as Raspbian as I2c native (you still have to activate it in the configuration menu though). Thanks again. You saved me a lot of time !..

@FreelancerJ thank you for such detailed instruction :rocket: :muscle:
I must agree, that the worst part is/was enabling I2C on Pi3/Pi4.

I’ve created a Feature Request on the community, to easily allow enabling I2C and 1Wire via CLI: Allow enabling I2C and 1wire via Home Assistant CLI
Ideally, it should work similarly to raspi-config (https://learn.adafruit.com/adafruits-raspberry-pi-lesson-4-gpio-setup/configuring-i2c) or even better via GUI, similar to Raspberry Pi Configuration (https://learn.sparkfun.com/tutorials/raspberry-pi-spi-and-i2c-tutorial/all)
I’d like to ask everyone that had/has problems with I2C, please comment and upvote that feature request.

Great write up @FreelancerJ! Thanks so much.

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.

5.9 is the stable version of the 5.x dev versions basically. It supports SSD boot just fine :slight_smile: Of course still only the 64-bit version does


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!

1 Like

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.

I wrote an addon to support the Active Cooling functionality. It makes things really easy.


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 :blush:

Thanks for your hard work!

@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 :grinning:. 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.

Thanks for your help.

1 Like

Thanks. I’m glad it worked. You can find the new thread here. You can feel free to repost if you’d like.

Also, you can adjust the temperatures. I keep mine so the fan runs between 1-3% continuously.

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

I loved this tutorial. Everything is working as expected.

Only one concern, Most of the time I am seeing CPU temperature is varying between 105 to 112 F. Is it normal?

Thanks! I’m about to refactor a bit of it for the current OS and neatening it up a bit :slight_smile:

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

1 Like

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