First time poster and after a few months of indecision I decided to post for advice. I do not want to start a war about whether or not it is better to install SUPERVISED or just the stock HA OS at all. What I decide to do is unique to what I want to do, as I am sure it is with other peeps considering everyone’s posts I have labored to read since I decided to take the Home Assistant route.
I have a RPI CM4 with the standard IO Board. My CM4 module is 8gb ram with 32gb EMMC, WiFi and Bluetooth. Right now I am imaging my working install from the EMMC so I can get this back if my attempt here is not what I want. I also have a SONOFF ZIGBEE USB Dongle. I am using a 12vdc 10 amp MeanWell power supply. This PSU has served me very well with my NAS, my LattePanda 3 Delta 864, and numerous other RPI 4 and 5 projects current and in the past.
I also have a Home Assistant Yellow with the same flavor of CM4 on order in case I want to continue to run it with its dedicated HA OS and free my working existing CM4 to continue a bench presence to test new stuff without threatening the reliability of my production home automation system.
I understand the restrictions of using the HA OS and my only concern and caveat is if those restrictions will prevent me from automating specific hardware. For example, I have a Samsung Titan OS TV that is nearly impossible to control using code. I also have numerous (to say the least) IoT projects I want to include into my system. I am concerned that the HA OS is so restrictive that I cannot add any of my code to make what is possible, possible. Everyone knows that has prototyped IoT devices that you consistently run into driver and library issues, anything that ventures outside the edges of the mainstream.
So I am at a cross-roads. Go with the supported version, or venture down the many rabbit holes using supervised container installs. This is the reason I pulled the trigger on getting a yellow with a CM4.
Any advice would be greatly appreciated. I certainly do not want a system that breaks with an update and then have to code and research for days to fix it, but I also do not want to live with the fact that device ABC will not work unless you can code XYZ, but cannot do that with a locked-down restricted OS.
Yeah, I want it all. Don’t we all. LOL. Thanks for your valuable time!!!
I hear a bunch of what if with no real backing. Until you hit a wall - - - there is no wall.
You cannot say supervised is easier to manage in any reality so you’re just creating work until you may(?) need it.
Run haos if you find something you can’t automate use. Your other box to figure it out. If supervised BECOMES the answer then revisit at that time. Backup restore works between supervised and HAOS. Use it to your advantage.
Thanks for the incite. And yeah, what you suggested is the current plan. My only concern that begs to question with this set up… how can or will my bench container install interfere with my live version running on the yellow? I have not seen a lot of posts about how to turn off one system to allow another.
If you are extremely well versed in running a Debian 12 headless server and understand all the dos and don’ts then it can be done, but there are many pits to fall into and because it is a supervised installation, then it is hard for the devs and especially the community to provide more than hints at what to look at.
Many have started with a supervised installation and thought they could just wing it by doing Google searches, only to realize that some choices rule others out.
Especially the requirement of Network Manager have hit many users, because that means no fiddling with config files for network setup, even though they are available.
Once you fiddled with the config files Network Manager will import these changes and then it requires extreme knowledge to get it wrangled out of the system again. Just reverting the changes in the config files is not enough.
Often the easier way is to start over and reinstall everything.
If you are experienced in coding and doing development, then look into a developer setup instead.
My guess is that the normal HAOS will suit you just fine though.
It is pretty versatile and with the userbase chances are your devices have already been incorporated into HA before.
Based on what you’ve said, If you’re pretty knowledgeable with linux use supervise version, if not use HASOS. I’ve used the supervised version for years for exactly the reasons you’ve mentioned. I’ve only had minor issues as the developers pull functionality into the HA code base. The network management items is probably the only thing that has really been an issue. In my situation I utilize cellular as a backup and to this point in time HA OS still has no way of implementing such a solution. All things are possible with HA supervised.
Thanks for that suggestion. I did not know it was available.
When you say “chances are your devices have been incorporated…” I am banking on that. But what if I create, say, and environmental sensor pod using a RPI Pico W using a barometric/humidity/temp sensor, a light sensor, and who knows (grabbing at devices) a RGB LED group and I want to report all that to HA nd control the LEDS based on events? I realize there are addons to allow certain things, but are there generic (maybe boilerplate) devices I can configure that I apply to that? My application is only partially end-user, but I have to say a majority of it is definitely developer.
I sincerely hope I was not too vague. One of the features that pushed me here from Alexa is conditional routines. Like, I only want my front porch light to turn on when someone is detected by my Ring door bell, or my Blink external cameras, AND when it is not already day light outside. I want to manually control my customized Hunter irrigation controller when a specific zone sensor group’s moisture sensor says it is dry enough to turn them on, or let me know a zone was delayed because of that conditional event, maybe take the exterior temperature and humidity into account when it decides to try again… which could be in 6 hours or 3 days. Etc., etc. I’m not satisfied with turning lights on from sunset to sunrise. I would rather use an astronomical calculation from a database or script, along with light sensor readings to determine when is best for my lights to go on or off.
Most of what you’ve stated in your third paragraph seems like some you can do with an HA automation. You’d might have to use HA templating capabilities, but you can set up some pretty complex automation. You can also take advantage of ESPhome and as a means to integrate various hardware and interact with HA.
This is then not directly connected to the HA server, but instead over some kind of connection channel, like WiFi, Zigbee, Z-wave or whatever, which is how most devices are connected.
You would probably choose an interface already available in HA and then use that to transfer your measured values.
It could be websockets or a RESTful interface, just to mention two types, but there are many more.
I would say transfering your data from a device to HA will be the least of your problems in developing a sensor. It is what makes Home Assistant special in the smart home world.
Many would probably go with an ESP device for such sensors and ESPHome is available if you do not want to start from scratch.
Wow, thanks everyone! These are the replies I was hoping for. And I did not know about ESPhome either, that’s fantastic!! I do work with ESP32 and use to with ESP8266. I have been having a lot of fun with the ESP32S3 and the RPI Pico W, and now I see the Pico2 W just released. Sounds like I am in business now, thank you for all the great suggestions! Looks like I have a lot of reading and experimenting to do.
Ran into an issue with the console text size last night which I will research now for a fix. Maybe it is the size monitor I used. It saved me actually or I probably would have been up all night experimenting with HA.
Thanks again everyone! I wish I could tag all of you for solving my questions for me. Or can I?