I wrote an addon to support the Active Cooling functionality. It makes things really easy.
2 Likes
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 
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.
2 Likes
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.
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 
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
2 Likes
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. 
1 Like
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.
Never mind. Got it. For anyone interested what I did was install xz itils
sudo apt-get install xz-utils
then use
xz --decompress file.xz
2 Likes
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
I went ahead and grabbed the Argon case, recommended argon charger, and the crucial mx500 drive. However my rpi4 isn’t recognizing the drive. Are there any steps I can take to get the drive to work?
lsusb shows the argon ssd adapter
dmesg shows the following
[ 351.720589] usb 2-2: new SuperSpeed Gen 1 USB device number 4 using xhci_hcd
[ 351.741747] usb 2-2: New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00
[ 351.741766] usb 2-2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[ 351.741779] usb 2-2: Product: Forty
[ 351.741791] usb 2-2: Manufacturer: Argon
[ 351.741803] usb 2-2: SerialNumber: 0000000000B6
[ 351.745206] usb-storage 2-2:1.0: USB Mass Storage device detected
[ 351.745898] usb-storage 2-2:1.0: Quirks match for vid 174c pid 55aa: 400000
[ 351.746125] scsi host0: usb-storage 2-2:1.0
[ 352.768634] scsi 0:0:0:0: Direct-Access Argon Forty 0 PQ: 0 ANSI: 6
[ 352.769105] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 352.794067] sd 0:0:0:0: [sda] Attached SCSI removable disk
but the device doesn’t show up in fdisk or anywhere else. Am I missing something?
Getting Argon One M.2 and will again putting my HA to RPI 4 + M.2 SSD. Now I can run Supervised version rather then the unsupported on Synology. Need to bookmark this thread… hahahahaah
1 Like
Can you give us the output of lsblk?
Edit: with and without the USB adapter connected 
With
pi@raspberrypi:~ $ sudo lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk0 179:0 0 119.1G 0 disk
├─mmcblk0p1 179:1 0 256M 0 part /boot
└─mmcblk0p2 179:2 0 118.9G 0 part /
Without
sudo lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk0 179:0 0 119.1G 0 disk
├─mmcblk0p1 179:1 0 256M 0 part /boot
└─mmcblk0p2 179:2 0 118.9G 0 part /
With
sudo lsusb
Bus 002 Device 005: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Without
sudo lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Ok wow, not even a block device…
Maybe a silly question, but have you disconnected the SSD from the adapter and then reinstalled it? It would also be good to take a look at the pins in the connector on the adapter, in the slot the SSD connects to. If you have a flashlight, shine that into the port to make it easier to see if there is any bent metal in there, even a single pin bent out of place could stop it all working…