So my understanding is, there is no issue for you using the Argon One M.2 case with M.2 SSD with USB3 . But there is issue with NVME SSD with the case?
Not just the Argon case… any NVMe drive and adapter/case will not work… I hope the HA developers fix this bug soon.
Update SUCCESS!
And this is still weird. Turns out the the JMS583 Boards that enable NVMe drives to talk to the Pi (or other USB 3 devices) have a firmware built in. Also turns out that HASSio is rather picky about this firmware. Pi OS is less so (or at leas Pi OS has been patched to not have this issue)
Once I updated the firmware of both the powered and non-power JMS583 NVMe -> USB adapters I was able to successfully boot HASSio to a Wester Digital Blue 1T NVMe drive! I have not tried the faster EVO and PRO drives but the “Blue” drive was the one that I was planning to run HA on.
If you want to flash the firmware on your JMS583 based adapter… Use the 2.0.9 version here:
Down Load 2.0.9 firmware patch
Thanks for all of your help!
1 Like
But why you are using a NVMe drive for this task? I don‘t think it will have any advantage over a SATA SSD attached to a Pi 4.
Mostly because I got the drive for free… And it nets a more “compact” Pi system. Which fits perfectly in a 3D printed case… Yes it is over kill over the SATA Drive.
I’ve been using the new m.2 case with Hassos stable on a WD Blue SSD and have run into a few issues after what I thought was a trouble free first week. I’ve been running Frigate and six cameras which meant pushing the RPi4 quite a lot, I overclocked to 2000 and average CPU use was 70-80%. To use Frigate I needed a Google Coral TPU plugged into the other USB3. This worked fine till the other day when it locked up as soon as I ran Frigate. Lots of homeassistant kernel: sd 0:0:0:0: [sda] tag#19 uas_zap_pending 0 uas-tag 4 inflight: CMD in the logs. After a lot of trial and error I’ve finally got it back stable again but with the TPU in a USB2 slot, which has hit my inference speeds.
The reason I bought the M.2 case is I like the all in one form factor so I don’t really want to add a USB hub, so now looking around for another option like a hack for more power or less power hungry SSD. Reading the spec the 250gb WD blue is max peak 4350mW/1318mA @3.3v. I’ve only looked at the green and they dont list the max peak only the average which is 2200mw, same as the blue. Not sure I’m going to find a more efficient SSD.
Other questions I have is I read some about using dev Hassos on older posts, is USB boot now working on stable or should I switch to dev?
I enabled the dtparam=sd_poll_once=on but now my activity LED is off permanently, is that normal?
What sort of speeds are people seeing when running hdparm -tT /dev/sda? I’m getting:
# hdparm -tT /dev/sda
/dev/sda:
Timing buffer-cache reads: 1108 MB in 0.51 seconds = 2223656 kB/s
Timing buffered disk reads: 1114 MB in 3.00 seconds = 380023 kB/s
Something isn’t right there as the spec is quoted as max 550 MB/s!!
EDIT: Just to add, I’m still seeing this in the log when HD activity ramps up,
homeassistant kernel: usb 1-1.3: reset high-speed USB device number 3 using xhci_hcd
from what I read on an old github post this could be down to power issues so it seems as though even on it’s own in the USB3 bus SSD isn’t working perfectly.
I don’t think you will reach this speed with the Pi 4.
I am using here HassOS 5.12 64bit to boot with an M.2 WD Green without any problem.
Yes, I didn’t realise the buffer-cache is not the read speed. 380MB/s is sounding about right.
I’m guessing you don’t have anything else connected to the USB?
Whenever I start Frigate I can see this in the log regardless of which USB the TPU is connected to:
homeassistant kernel: usb 1-1.3: reset high-speed USB device number 3 using xhci_hcd
homeassistant kernel: usb 1-1.3: reset high-speed USB device number 3 using xhci_hcd
homeassistant kernel: usb 1-1.3: device firmware changed
homeassistant kernel: usb 1-1.3: USB disconnect, device number 3
homeassistant 9e0c0b43ef56[414]: 21-03-11 14:53:35 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.REMOVE usb hardware /dev/bus/usb/001/003
homeassistant hassos-supervisor[876]: 21-03-11 14:53:35 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.REMOVE usb hardware /dev/bus/usb/001/003
homeassistant kernel: usb 1-1.3: new high-speed USB device number 4 using xhci_hcd
homeassistant kernel: usb 1-1.3: New USB device found, idVendor=18d1, idProduct=9302, bcdDevice= 1.00
homeassistant kernel: usb 1-1.3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
homeassistant 9e0c0b43ef56[414]: 21-03-11 14:53:38 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.ADD usb hardware /dev/bus/usb/001/004
homeassistant hassos-supervisor[876]: 21-03-11 14:53:38 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.ADD usb hardware /dev/bus/usb/001/004
I’m not sure if that’s normal, it looks to me as if it’s losing connection, maybe due to power?
I just bought this case for a RPI4 that I will be using to replace my current RPI3 as my Home Assistant hub.
I am currently using a MariaDB on a Synology for storing all data from HASSIO, but my idea is to have a DB running locally on the RPI4 together with an M.2 SSD.
My first concern is the power requirements for such setup. Will the official RPI4 power source with 3.0A be enough?
And regarding the SSD, I guess that a 250GB or 500GB SSD will be more than enough for the purpose. Do you recommend any particular brand/model?
Yes, that is correct!
The ConBee II Stick for ZigBee is connected to a Pi Zero with an USB extension cable because the Home Assistant Pi 4 is on a not so good position.
The Argon One M.2 case having discount in my region now… still thinking should i migrate to SSD or not as ot seems it still has stability issue…hmmmm
This is the only thread where I read about stability problems with SSD. All other places and my Home Assistant too don’t have problems with stability.
Mostly problems with SSD are the USB 3-SATA controllers that are used, which not work correctly with the Pi 4 at USB 3. Other problems are the power adapters which deliver too low voltage.
Yeah. I was worried on the USB3 issue as this case is using the USB3 port with the SSD. Afraid it will interfere my CC2531, although my CC2531 has a USB extension with it.
This stick is USB 2, I think, so you can use an USB 2 port.
1 Like
Just placed the order for Argon One M2 case. Hopefully all good during setup.
I think there is an issue with power and booting the RPi from SSD. From what I’ve read the RPi can only supply a max of 1.5A over all the USB ports. The Max Average operating power of my SSD is 667mA so in theory it should be enough however with a Google Coral USB connected as well this is having problems. The max current for that is 900mA so if both operate at peak it’s over the 1.5A.
I’m back to booting off SD card now and just using the M.2 drive as storage, I’m still seeing some uas_eh_abort_handler in the log. I will have to look for a SSD that uses less than 667mA, if it exists.
But this seems to be more a problem of the controller which has UAS problems with the Pi 4.
Does it? I thought the ASMedia controller was OK? So Argon are selling a faulty product?
I’m testing with a reduced over clock and I will test with the Coral in USB2, should reduce the peak power to 500mA over an extended time. I’ve also found another SSD with a reduced peak power which I will get.
The ASMedia controller the Argon One uses is fine on the UAS side of things, I spent quite a while working that out before I bought it as I had been burned by incorrect UAS implementation in controllers before and didn’t want to be buggering around with that again 
I did have similar issues early on when I had both the Argon One’s SSD and a USB>NVMe ssd connected at the same time. Would run fine initially but when I pushed the load a little on the NVMe both the SSDs would drop out and then reconnect. I popped a USB cable with a amperage and voltage readout display between the Pi and each SSD and found the NVMe was just bumping too high an amperage when under load, so for the remainder of the time I needed both of them I threw a powered USB hub in the middle and it was fine.
Setting the OS on the SD card and using the SSD as the data partition is a good idea, it should definitely reduce the peaks of your SSD, though if anything writes something big like a video output then it might still drop…
Be interested to see what SSD you can find with lower peak power, I haven’t seen one below 600ma before. It’s been a while since I went looking with power in mind though.
I’ll see if I can find out what power draw the ASMedia chip has for you, in the meantime
1 Like
Hey @FreelancerJ thanks for your info! I’ve been researching a lot of USB SATA enclosures and I’ve been through a LOT of Amazon returns 
The consensus was positive with ASMedia devices and I was excited to see ARForty had developed the m.2 case as it was exactly what I was looking for.
You’re right about still having issues even booting off SD. I haven’t gone through the logs yet but it seems the device will disconnect after a while and not recover until a system reboot is performed. I’m guessing it’s not mounting again or gets into an error state.
I’ll be ordering a Kingston A400 tomorrow as according to the spec it tops out at 1.5w instead of 2.2w like the WD drives. That’s 450mA which should bring me under the 1.5A max. Fingers crossed! I also want to do some comparisons with Raspberry Pi OS to see if that performs any better. I’m pretty certain it’s a power issue though.