storage is not upgradable it is soldered eMMC I believe. You can get 16 or 32GB version.
For Frigate storage you can add USB HDD, mount it permanently and then in docker run config specify storage location so all your vidoes and pictures are stored on the USB drive. You can the enable Samba for that drive and have direct access via windows… you get my point.
Yes the no upgradability of t430 is limiting factor and the device will not be first choice for many including me. Having access to one gave me opportunity to use it as very powerful server . The low power consumption ( ~4W ) and decent computing power is great value for me + it works awesome with Frigate and COral
Thanks for the power consumption feedback
Yeah, that’s exactly what I had in mind just adding external storage or use rclone and schedule daily uploads to the cloud.
Btw, any other mini pc on your list that’s within the same price range?
To follow up on this - I’m running a little different setup than @Vendo232, I’ll be migrating my HA over and will just use the emmc as the ‘boot’ drive and use the HassOS native data migration to an external SSD as most do with Raspberry Pis. I did this with another thin client a couple of months back and it was easy and netted me plenty more space for cheap.
I’m using this as my HA server. Runs smooth even with Frigate running in the b-ground. 9 Cams (lo-res for detection) and 9 Hi-Res for clips recordings.
Cpu usage is aprox 30% …
question: when splitting the detect stream vs the clips stream - does that wr to resolution also apply to the snapshot part ? eg when i pick a substream for detection / low res - does it snapshot then on the full res?
@Minglarn you used 2 streams i see for clips in full res. Did this approach works for snapshots?
Snapshots is from the detect stream. ie low-res. But you can make an automation based on MQTT to grab a snapshot directly from the cam. I’m doing this for my plate recognition. Works pretty well…
I’ve also switched 2 of my streams to Hi-Res for testing purposes… Hi-res eats about 10% of CPU power, and frigate crashes more frequently when using hi-res streams.
@Minglarn ok clear - the issue i have is the picture are that dense that i dont get enough pixels to make a proper analysis with compreface… eg pictures to small / too few details - im trying to balance out the performance/cpu load vs the resolution and snapshot pic to retrieve/heightpixels… whats your recommendation? ip cams are 1080p but people could be a bit further away sometimes (eg theyre vivotek dome cams so not per se ment perhaps for this purpose?)
I just got in the new Raspberry Pi PoE+ hats today to use with my Pi4/USB NVMe adapter and a Google Coral TPU. The Pi4 boots with it (vs the old PoE hat that wouldn’t with both plugged in), and seems to be running fine. It’s been averaging 9-11w while Frigate is running. I suspect the switch may be under-reporting a bit or not catching spikes as the previous PoE hat should have been good to about 13w.
I have run HassOS in both a KVM and Virtualbox VMs (not at the same time) on an Ubuntu host. In both cases when you start the VM it picks up the Coral USB TPU as ID 1a6e:089a Global Unichip Corp. If you do a lsusb on the host it shows the device with this ID as well. When you start the VM and access your Hass instant from a browser, Frigate crashes saying it cannot find the TPU. I then stopped the VM and find that USB device ID on the host has changed to 18d1:9302 Google Inc. You delete the Global Unichip device from the VM and the Google one and it works.
This work around only works if you try and start Frigate first while the Global Unichip device is loaded. Others have observed that to get the USB TPU recognised as a Google device you must first try and use the Global Unichip one.
This would all be fine, BUT, it does not survive a reboot of the host. You have to go through the whole procedure again to get the TPU to work (which is not possible if you are not on the local network).
I tried changing the device ID in Virtualbox as suggested in the reference you give to kojikanao but this does not work.
I have spent hours on this without success. Does anyone have any suggestions? @blakeblackshear is it possible to update Frigate to recognise the Global Unichip ID for the TPU as well as the Google one?
I had a similar issue. I eventually settled on running Frigate in LXC. Either way, make sure you have gasket-dkms and libedgetpu1-std packages installed on the host and then the device should identify as Google for easy pass through.
Unfortunately I have both those packages installed and it does not solve it. The issue seems to be that until you try and actually use the Edge TPU, the OS (on the host) recognises it as the Global Chip device with Device ID 1a6e:089a. Once you have tried to use it, the OS (on the host) then recognises it as a Google device with ID 18d1:9302.
I had the same problem also (you can see my messages from one week ago). If you run something that uses the TPU on the host then it will trigger the udev rule and the device will permanently change to Google (at least it did in my case on Proxmox).
There is nothing in frigate’s source code related to this. All of that is in the underlying tensorflow lite API provided by Google. There is nothing I can do. Why not run this on the Ubuntu host?
Ok thanks @blakeblackshear. I ran in a VM because that (or Docker - but I wanted a ‘Supervised’ installation) seems to be the recommended installation on the HA website. I also want to use the Ubuntu host to double as a NAS.
Google responded to my query about this swapping from the Global Unichip ID to the Google ID saying that it is the ‘intended behaviour’ (goodness knows why).
The workaround I have applied is to use Virtualbox because this will boot up even though a specified USB device is not present in the host. So I put both the Global Unichip and Google Inc device IDs in the USB and it seems to get sorted out automatically which one to access. It also survives a reboot of the host which is what I was after.
KVM on the other hand would not allow this because the boot of the VM failed if it finds you have attached a USB device that is not present in the host (I have not found a way to override this).