Hello sir, purely from interest to learn something, how did you come up with these? I did not see them mentioned anywhere.
Also these credentials?
and this parameter?
I know I am very inquisitive so feel free to just ignore or stop me, I will understand, you have done enough by putting up the guide already.
Also just wondering. Any way to read current fan speed?
Best regards
D
Shouldn’t these two triggers contain both above AND below value? Based on this logic would I assume incorrectly that temp raising above 60 degrees will cause three of the automations to run?
I also wonder what is your usual temp. Mine keeps hanging around 48.7 without fan on. The case actually is quite hot. Do you get the same feeling?
Thanks.
D
I definitely restarted HA - but I don’t remember if I rebooted the Pi or not. So maybe a second boot does clear it up.
Mine sits around 39/40c @ approx 3% CPU usage. It is 8gb Pi4. Quite happy with the case.
So I’ve been listening to my enclosure closely, and agree, the sound level is pretty much the same all the way through once it is on. The pitch changes whenever I change the fan speed however. It’s slight, but it’s definitely there (the automations show up in my “Configuration” page now, so I’ve just been clicking the execute button on each one while listening).
It’s most noticeable when going from 10% to 100%, so if you want to check, try that. I had to put my ear basically next to the case to really hear it through (I live above a bus station so you may have a easier or harder time than me based on your ambient noise).
I’m emailing Argon40 to see if there is a register that can be polled over the i2c bus to retrieve current fan speed, since they only document the register to write to to change the fan speed and power mode.
These I first found on an issue filed on the Argon One Case component. When I first set up i2c following the Home Assistant guide, I got a different i2c error and went looking for other solutions, and adding them fixed it. I looked them both up searching DuckDuckGo (yeah I’m one of those guys 
), and found a few forum threads where some kernel developers were talking about them from when they added support for them to the linux kernel, which is how I found out that they were the Chip and Chip Implementation IDs.
I actually think I may not need them, and just be able to use exactly what is in the official Home Assisant I2C guide, because I glazed over the mention of doing a second reboot before trying the extra lines.
Because at the moment I am adding and removing things on my install to see what happens and what works, I think I’ll do a clean install once I’ve gotten to the point where I’ve gotten everything working, so that there isn’t any leftovers from things that didn’t work, and then simplify the guide then. So I’ll be able to confirm for you if those extra lines were needed (though I doubt there is any downside to having them, they are just more specific versions of the “i2c-dev” and the original "dtparam"s.
‘pi’ is just the default username in Raspberry Pi OS, which I never bothered change on my own original install, and ‘hassio’ was the hostname of my Raspberry Pi on the original install. They aren’t really relevant to this guide, I just left them in the examples because when you run those commands in the terminal on your own computer, the terminal prompt will look similar. Wherever you see pi@hassio in the guide, it will be your own username and hostname appearing on your computer 
Mine is seasonal 
All winter it typically hung around 35-40C, while the ambient temp in my apartment was typically 15-20C, last summer it spent most of it’s time between 40 and 45 C with an ambient temp of around 22-26C.
It’s currently at the back of my desk and about 30cm from a window, so once I move it to it’s final permanent location (which is in the top of a cupboard where it can be hardwired to my router instead of connected through a bridge), I expect it will be higher.
These temps are still fine really though, cause that is the temperature inside the CPU, which is always gonna be highish when running power through it. My Mac Mini’s idle CPU temp is in the 60’s, but the casing is definitely nowhere near that. The sensor at the tip of it’s heatsink would be around 35 at idle.
(This reminds me, I should replace it’s thermal paste soon, it’s been a couple years).
I do, it’s definitely warm to the touch. The think to remember is that the case provides passive cooling and to do so is expelling heat from the Pi through its surface, as opposed to most computer cases which expel the computer’s heat entirely through a vent, with a fan pushing air through a fin stack to take the heat from the fins to the air, and the air then out of the case.
I would be really worried if the case was cool to the touch, since that would indicate the heat isn’t transferring from the CPU to the case through the thermal pads we installed.
I have a few i2c temperature sensors I’ve been planning to set up around the apartment, so I might attach one to the outside of the case to get an idea of what its surface temperature is, through with cpu temps steady in the 40s it will probably be in the high 20s/low 30s.
Well, yes and no.
The trigger once the temperature first gets into their temperature range, but don’t get “primed” to trigger again until after the temperature has been below the number they are waiting for. So the behaviour you get the way we have set it is:
If we add the “below: 55.0” and “below: 60.0” entries, then when the temperature drops, it will trigger each lower automation and lower the fan speed gradually with the temperature instead of keeping the fan speed at the highest it reached until it’s back below 50C.
Both ways of running the fan work fine, but having the “below” values mean the Pi will probably take longer to cool down after a big job.
I think it would be worth it if the fan got noisier the faster it ran, but since the noise is pretty much the same the whole time, I see no downside to keeping the fan on the faster setting until we are below 50C, since it means the fan will turn off quicker overall.
Good catch!
Again so informative, thank you
So, I ran into the character limit on the original post, so I’m continuing to add to it in a reply, and I’ll just have them hyperlinked to each other.
To round this out, the last step will be to set up a wifi network from the Raspberry Pi, which does not connect to the internet, to isolate some of our… less trusted IoT devices from the world, and keep them safe, while still conveniently keeping control of them through Home Assistant.
Straight up, this part only works if your Raspberry Pi is connected to the rest of your network via ethernet, or if you are using a USB wifi adapter as a second network interface.
When I was running Home Assistant on top of Raspberry Pi OS, I used hostapd to broadcast a network, dchpd to map IP addresses to devices, so they wouldn’t change over time.
A while ago, I found David Ramos had written a custom Hassio add-on that would run hostapd within Home Assistant. Nothing to fancy, just choose your network name, password and IP range and away you go. You could combine it with the built in DHCP add-on to assign IP addresses and have it working like a champ.
For me, there were only two things missing: MAC address filtering, and choosing a specific network interface (once I got to writing this guide, anyway, I’m using the built in interface, but other’s doing similar may need to choose a USB one).
It also required making some changes with the SSH add-on, with protection mode enabled. The NetworkManager software used by Home Assistant to manage the network interfaces, as well as communication between the docker containers that make up Home Assistant, has a default setting for wifi interfaces that, while good for privacy when connecting TO wifi networks, breaks the ability to create a network for others to join.
In short, every 3-5 minutes, NetworkManager changes the advertised MAC address of your wifi interface. It keeps itself properly identified to the router running the network so it doesn’t get booted by MAC address filtering itself, but all other devices on the network see it as a new device. It’s a pretty standard thing to do now (iPhones and Android also do this by default), but when setting up to broadcast a new network, NetworkManager doesn’t realise what we’re doing and keeps changing the MAC address. All the devices on the network then disconnect because they use the MAC address (as a BSSID) to make sure they’re talking to the right network.
I had to solve this originally too, by running:
nmcli dev set wlan0 managed no
The problem with this is, occasionally updates to Home Assistant reset this. I got around that by including the above command in the systemd unit that started hostapd, so on ever boot the setting would be explicitly set, but we can’t do that in Home Assistant OS, and the Add-on requires us to run it manually, so you would have to remember this every time your IoT wifi stopped working.
I was looking through how it was set up and the issues section, so I could fork it and make it work around these issues, when I found, in grand open-source fashion, someone else had also run into this, and had already addressed it all in their own fork. They also expanded it to include a DHCP host all in one Add-on. (And like good Open Source citizens, they submitted a PR for their fixes around hostapd that were relevant to the original Add-on, although they are yet to be merged).
Meet the Hass.io Access Point Add-on, by mattlongman.
Here we get a wifi network from either the built in wifi chip or an external one, a DHCP server (dnsmasq), MAC address filtering and we can even choose whether to hide the SSID (name) of our wifi network so it does or does not show up in the viewable list of wifi networks.
And it runs the above command for NetworkManager every time it starts, to make sure the settings are right! Nailed it!
So first, we need to install the Add-on. It isn’t in the community repository, so we will need to manually add it. Fortunately, it’s pretty straightforward.
Go to the Supervisor in your Home Assistant, and then go to the “Add-on Store” tab. Head up to the 3 vertical dots in the top right corner, and choose “Repositories”.
By default you’ll see Franck’s Community Add-ons repository, and a text field below that to allow us to add a new repository. Paste in the link to the GitHub Repo:
https://github.com/mattlongman/hassio-access-point
and then click “Add”. It will get slotted onto the list of repositories, and you’ll see it appear in the background as well. Click “Close” and then select the “Hass.io Access Point” entry in the Store, and install it.
Now there is a bit of set up to get it going. We need to know what we’re calling the network, and come up with a good password, as a lot of the devices we will be adding to it are likely to be a pain to change their wifi settings, especially as they get older and their respective configuration app get out of date.
We’ll need to choose an IP range as well. It shouldn’t be the same range as the main network, as that will be a tad confusing to Home Assistant (if there is a 192.168.1.5 on both networks, how will it know which you want to talk to?).
Finally, if you want to have MAC address filtering on, you’ll need to collect the MAC addresses of the devices you intend to connect to the network.
I should note, by the way, MAC address filtering isn’t a super strong security setting on it’s own, which is why a strong password would still be a must. It just is an added layer to help deter mischievous locals who are bored and poke around to see what they can mess with (I’m looking at you, unit 66. I know it’s you!). It basically just means they have to work out your password AND a valid MAC address, so setting something brute forcing its way through passwords will take significantly longer as it has to try each password with an array of MAC addresses as well. Still, it won’t help if your wifi password is “abc123” or something of that ilk.
Now I know most people will diverge a bit here to choose their own settings for their own situations, so I’ll outline what I have and why, and it’s hopefully enough information that you can make your own choices that work.
First of all, there is a bunch of info we’ll be entering here that actually may end up being entered in multiple other parts of our configuration as well. So I kinda cheat on this, and make gratuitous use of YAML Secrets.
While it is meant to be used to keep your passwords out of your config files, so you can safely share them when asking for help or showing off your setup, it also works as a great “Source of Truth” for other info as well. I keep IP addresses, usernames, MAC addresses, just about anything that I might need to enter in multiple places through my config, and don’t want to have to remember where those places are. Update one spot, reboot, and everything is still working nicely, no forgotten corner of my config.
So let’s jump into our secrets.yaml file in a text editor. It’s in the same folder as your configuration.yaml. First add some comment lines, to break up what the secrets are logically. We’ll also set our wifi network’s name (SSID), password, and the broadcast address for the network (trust me, useful):
# Use this file to store secrets like usernames and passwords.
# Learn more at https://www.home-assistant.io/docs/configuration/secrets/
# Integration Passwords/Keys
...
#IOT Wifi Config
IOT-Wifi-SSID: "A Network Name"
IOT-Wifi-Key: "A c0mp1ex p@55word"
IOT-Wifi-Broadcast-Addr: "something.something.something.255"
# MAC Addresses
See where I’m going with this?
I use ESPHome, and so whenever I need to put in the wifi credentials for a new node, I can just reference the secrets, so if they change I don’t have to go and edit EVERY SINGLE NODE 
You’ll also see a entry in Home Assistant’s log file every time an Add-on accesses a secret, for your piece of mind, so you can check that nothing fishy is going on.
Head back to the Supervisor, and go to the Hass.io Access Point, then the Configuration Tab, and we’ll add in those secrets to get started:
ssid: '!secret IOT-Wifi-SSID'
wpa_passphrase: '!secret IOT-Wifi-Key'
channel: '6'
address: 192.168.66.1
netmask: 255.255.255.0
broadcast: '!secret IOT-Wifi-Broadcast-Addr'
interface: wlan0
hide_ssid: '0'
dhcp: '0'
dhcp_start_addr: 192.168.66.10
dhcp_end_addr: 192.168.66.20
allow_mac_addresses: []
deny_mac_addresses: []
debug: 0
hostapd_config_override: []
Click save. The Add-on’s configuration screen doesn’t autosave so if you navigate away, even just to the log or info tabs, you lose your changes.
Lets unpack this a little.
The SSID and passphrase are our Network name and password. You’ll notice that to call the secret, it’s a little different than in the rest of our config. When you are calling a secret in configuration.yaml (or any .yaml file in your /config folder and it’s subfolders), you do so with:
option: !secret nameOfSecret
But when you are requesting one in the configuration of an Add-on, we need to surround them in single-quotes:
option: '!secret nameOfSecret'
Subtle difference, but you’ll be told your yaml is invalid if you don’t throw them in quotes.
Back to wifi: “channel” is the wifi channel your network is on. If you live in a freestanding house, you are unlikely to need to change this from the default, but there are plenty of apps out there that will like you scan the wifi environment and list what channels the networks around you are using. If there are a lot, try find an unused channel to jump in. At least, use a channel different to your primary home wifi network, to minimise the interference.
The address is the IP address your wifi chip will have, so pretty much always ending in “.1”, although you can choose any number you like really. The start of the number can be any private IP range for example, “192.168.”, “10.”, or, to be wild, anything from “172.16.” to “172.31.”
There is a nice table in that wikipedia article, and it also tells you what the next option, “netmask”, should be for each IP range (subnet mask, in the 4th column). You want to make sure that your “IOT-Wifi-Broadcast-Addr” secret is correct for the range you choose. It should be the last possible address for that range.
I stuck with the 192.168 range, as the Pi isn’t powerful enough to host more than 30-50 devices, depending on the load each adds, so I don’t need a really large range.
The “broadcast” address if used to send messages to every device on a network at once. For example, Wake On LAN messages get sent there, specifying a MAC address, and whatever device has the matching MAC address wakes up.
Interface is the ID of the wifi chip we will be using. The one built in to the Raspberry Pi should always be wlan0. An easy way to find them from here is to use the “Glances” Supervisor Add-on. It lists all network interfaces on the left side, so if you are using a USB wifi card, look at Glances before plugging in, and then plug the card in and restart the Add-on (or possibly the whole Raspberry Pi, if nothing seems to change) to see what network interface is added.
(All the interfaces starting with an underscore are used by Docker, and they may come and go, so just ignore them)
hide_ssid does what it says on the tin. If you enter 0, the name of the network will show up in “Join Wifi Network” lists, if you enter 1, it won’t. Wifi scanning apps will still show it, but without a name.
Its worth noting, some “smart” devices don’t have the option to join a network with a hidden SSID, so you may need to leave this as 0.
dhcp enables or disables the built in DHCP server, which assigns and keeps track of the IP addresses being handed out to devices connecting to the network. Why would we leave it disabled? Well, at this time, the DHCP server in this Add-on only does dynamic assignment: you can’t choose what IP address a particular device gets. And if one is disconnected for a while, it may get a different address when it next connects.
Depending on the devices you connect to this network, that might not be a problem, in which case you can set this to 1 and away you go!
However, a fair number of integrations either ask for the device’s IP address in YAML, or see a changed address as a different copy of that device. My TV’s integration for example, gets a login token and stores it paired with the IP address of the TV for whenever it needs to connect and send a command. If my TV’s address changes, Home Assistant can no longer connect. Additionally, my sound system’s IP needs to be entered in the YAML file to tell Home Assistant where to connect to.
On the other hand, my Air Conditioner’s integration is identified by it’s MAC address, and ESPHome devices use unique IDs, so their IP addresses changing wouldn’t matter.
So if you devices can’t afford to change IP addresses to work with Home Assistant, you’ll need to use the DHCP Server add-on from the Community Repository in addition to the Access Point add-on. Fortunately, they work well together, and we’ll get into that later.
When deciding what approach you are going to take, its worth keeping in mind that you can’t run both DHCP options at the same time, so you might just choose to use the other add-on, and just not specify any addresses to start with, so it’s easier to change if you need to for a new device later down the track.
If you aren’t using the separate DHCP add-on, set “dhcp” to “1”, and then you can set “dhcp_start_addr” and “dhcp_end_addr”. Make sure it is the same IP range, and then enter any number from .2 upwards for the start address and any below .255 for the end address. Your Raspberry Pi will only give out addresses in-between the two numbers you specify (inclusive).
Next, we have “allow_mac_addresses” and “deny_mac_addresses”. Both just ask for a list of MAC addresses, pretty simple. You can only use one or the other, however, if you specify “allow” addresses, hostapd will ignore the deny addresses (since the allow list will be more restrictive than the deny list, and there is no point having an address in both).
debug sets what level of detail to get in the logs. You can see the GitHub page for the add-on for more info on that, but its basically to help track down bugs, or if something is wrong with your config. in normal use, you should leave this as 0 so you don’t waste disk space on large log files.
Lastly, hostapd_config_override allows you to pass through a list of hostapd settings you want to specify that aren’t explicitly exposed here. Look up hostapd's Man file for more info if you think you need to add something here, like specific encryption settings, but generally you can leave this alone.
The add-on also sets more options than are exposed to Home Assistant for configuration, so if you are looking at this, check the “hostapd.conf” file in the add-on’s source on GitHub. I think the defaults are sane, but you may have different needs.
So do we really need MAC address filtering? For me, yes, cause I live in an apartment building and have cheeky and bored neighbours, and during lockdown, they seem to have been getting more tech-literate 
So this section is optional, but useful anyway.
Now, a MAC address is just 6 pairs of characters, that can be 0 to 9 or “A” to “F”, so not very descriptive. And when you save the configuration for a Add-on, it gets rid of any comments (lines starting with #) you leave, so entering in a list of addresses could be tricky if you replace any devices in the future, what with having to work out which one to remove and all.
So again, secrets to the rescue. Lets chuck the MAC addresses into the secrets file with short but descriptive names!
# MAC Addresses
Daikin-MAC: "AA:BB:CC:DD:EE:FF"
SoundSys-MAC: "CC:DD:EE:FF:00:11"
TV-MAC: "EE:FF:00:11:22:33"
Phone-MAC: "00:11:22:33:44:55"
Huh, wait, why did I add my phone?
Some IoT devices can only have their settings changed from mobile apps or via a web browser pointed at their IP address. So allowing my phone to connect means I can jump in and do that if needed (like if Unit 66 works out the wifi password again, and I need to change it). My phone’s settings allows me to turn of Auto-join on a per network level, so that makes it nice and easy.
Back to the Add-on configuration.
allow_mac_addresses:
- '!secret Daikin-MAC'
- '!secret SoundSys-MAC'
- '!secret TV-MAC'
- '!secret Phone-MAC'
That’s muuuuuch more readable! If we replace the TV or phone, we can just update the secrets file, restart the Access Point Add-on and bam, everything keeps running smoothly!
(hit Save. I totally didn’t repeatedly forget this and lose config after config, not at all)
At this point, if you are using the built in DHCP, you can start the add-on, and it will begin broadcasting the network. The “Log” tab will display the basics of the network such as when devices connect (and if MAC address filtering blocked them), as well as what IP gets provided for each connected device (identified by MAC address in the logs). Now just start joining your devices to the wifi network and configuring them in Home Assistant as normal.
If you are setting up the second add-on, you CAN start the access point add-on now, but you might have interesting behaviour if you start connecting devices. Lets get our DHCP config set up.
Head back to Supervisor’s Add-on Store, and select “DHCP server” in the “Official add-ons” section, and then hit install.
Let’s jump straight into the config:
default_lease: 86400
max_lease: 172800
domain: iot.local
dns:
- 192.168.66.1
networks:
- subnet: 192.168.66.0
netmask: 255.255.255.0
range_start: 192.168.66.2
range_end: 192.168.66.250
broadcast: 192.168.66.255
gateway: 192.168.66.1
interface: wlan0
hosts: []
Yet another breakdown:
The two “_lease” options are how long in seconds a IP address is held for a device before the network makes it available to different devices again if that device isn’t still connected to renew the lease at the end of that time frame.
“domain” is not really used, but its a required entry, so I just called it “iot.local”. Any devices that set their own hostname on this network would potentially be accessible using .iot.local instead can an IP address from Home Assistant, but I’ve not really tried this out.
“dns” is, like domain, not really used in this set up, but its a required field. I set it to the Pi’s address so devices on the network that do try to get to the internet will get a very quick “nope” from the Pi, rather than endlessly searching for nameservers.
“networks” is very similar to our Access Point settings, so I’ll just cover the own ones, since these will all otherwise be the same. You can, however define multiple networks, so if you want to assign IP addresses for your main network as well, you can make a second list entry for that. Remember to point your router to the Pi’s main network IP address for DHCP.
“subnet” is new, its just the network portion of the IP address followed by 0. 192.168 addresses will just have the last number as zero, whereas 10. addresses will have the last 3 numbers as 0.0.0
The wikipedia article above will help here if you are stuck.
“gateway” is the IP address of the device that gets you from your network out to the internet, usually your modem or router. But in this case we don’t want them to have internet access. Really, this being set to the Pi’s IP address is just a way to get the devices trying to phone home over the internet a quick “nope”, like with the DNS option above. While it is technically possible to bridge this network to your main network through the Pi, the Access Point Add-on doesn’t do it.
“interface” will be eth0 by default, which we do NOT want for these settings, as it will make the Pi start trying to give IP addresses to your main network, which could cause a little havoc if you don’t mean to do so. Make sure this is set to the same interface as in the Hass.io Access Point Add-on.
“hosts” is where we can specify IP addresses for specific devices, so only those devices get these specific addresses. You don’t have to specify addresses for every device connected to the network, just the ones you want to always get a specific address. Fill this section out as follows, if needed:
hosts:
- name: Daikin
mac: '!secret Daikin-MAC'
ip: 192.168.66.10
- name: TV
mac: '!secret TV-MAC'
ip: '!secret TV-IP'
- name: SoundSys
mac: '!secret SoundSys-MAC'
ip: 192.168.66.12
Those secrets are coming in handy. If we need to change them later, there is one place for the info in both Add-ons!
Note that the “name” entry can’t have spaces. Even if you add quotes, they will be removed when saving (btw, let’s Save!) and you’ll be presented with an error. Underscores and dashes work fine.
You’ll notice you can make the IP Address a secret too, which is useful if you need that IP address elsewhere in your main configuration files or other Add-ons.
(I didn’t do this for my sound system as it needs the IP address with a port number on it, and I have no idea how, or if it’s possible, to concatenate secrets. If it can be done and you know how, I’d love to know!)
And now, with all that, we can start the Hass.io Access Point Add-on, and then follow up with the DHCP server Add-on. (starting them the other way round may give you an error in the DHCP one, since the wifi interface may not be accessible).
Once you add your devices, they’ll start showing up in Home Assistant and voila, nice and neat control without having them on the internet, or using up connections on your main router (which might be a real problem if you are using a ISP provided one).
You may want to enable “Watchdog” on both Add-ons so that if they quit for any reason, they’ll get restarted automatically, so you aren’t cut off from your devices until you get the chance to log in and restart them yourself.
coming soon: Backups!
Thank you for this post… It helps me a lot to install the Argon Case ! I had just two problems with the “dd” command I had to use sudo to go over security problems… and after installing I2c I had to reboot twice to make it work… But everything is perfectly documented … Thanks !
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.
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. 
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 
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 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!