Hi all, first post here. Will try to keep it short.
So I've built custom firmware with docker engine preinstalled and have gotten regular Home Assistant container running. I've seen discussion of a python venv build as well. I was thinking of building a custom image with apparmor, systemd and network manager. I also thought of the qemu route to run home assistant but there are no aarch64 qemu packages. I've repackaged the os-agent so far. Was wondering if anyone has tried to get supervisor running and whether I should start trying to port anything?
I understand I am speaking of crazy things. I would like to develop an IOT specific version of OpenWRT and am just throwing ideas out there. If anyone has any better ideas or input as to how something like this would be possible, Please let me know.
I have also considered porting home assistant supervised to work with OpenWRT and possibly use SELinux instead of apparmor.
I treat OpenWrt as an embedded OS rather than "router firmware". The build system is robust enough to do most things, if you can be persistent and figure out what you're looking to actually do (which makes asking for help much easier!). I learned the hard way - on ALL those points
I've never used any sort of home automation system, so I'm no help with that aspect. Is it open source? Can it be built from source? If so, start creating a package Makefile to build it out under OpenWrt.
Then you just hack through the pre-reqs and dependencies Supervisor needs, and then add those if they aren't already present. You wash, rinse, repeat until it's done or you've given up
Awesome thank you for the info! That's all I needed to know . It is indeed open source and I shall rinse and repeat, will update here when I have made progress and make a topic when inevitably need more specific assistance
Just be aware of the potential rabbit-holes.. I wanted Suricata 6 for OpenWrt.. That required libHTP and rust-lang (which had me digging thru LLVM of all things - OOF)
A year later, I'm still working to close out getting things to work. It just depends how stubborn you are willing to be hehe
Oof indeed. It's a good thing I'm stubborn! Getting my company off the ground and it's one of the many projects so I won't be the only one working on it, but it will take time.
The HA Supervisor is a container that doesn't just control deployment of other Docker containers (for add-ons), but also to manage the host OS. Thereby the number of hosts it can be used on directly is quite limited - basically just HAOS, and Debian.
But simply said, without the host being Debian (or HAOS itself), you can't have a "full" HA install.
I'd also advise against using the router as the IoT gateway, simply because HA can eat a lot of resources, especially if you host a large number of integrations. I've been pushing for HA to create a more optimised and streamlined approach to reduce the amount of resources used for even basic features.
If you want a proper IoT gateway, your best bet would be to integrate the lightweight options of the various things you need, e.g. the MQTT broker (for an event bus), the database (usually I'd recommend going for something like InfluxDB, but it might be too heavy for even a more recent router, especially if one wants proper speeds.
Another approach I could recommend is using an x86 SBC with dual or quad NIC (e.g. the Odroid H2+ with the Odroid Network card would work well), and either run HAOS directly on it (with OpenWrt running in a qemu or lxc container), or run both HAOS and OpenWrt on a minimal hypervisor.
Yes I've read up on supervisor which is why I was considering a port/compatibility layer. I'm building it specifically to run on slightly more powerful devices like the raspberry pi.
The qemu route seems to be the favorable option. However, it would be great if I could run it on openwrt itself to reduce overhead.
I have two options here:
a) Port the existing openwrt qemu packages to aarch64(no idea if this is feasable as I haven't looked into it much)
b) Build a qemu environment on some lightweight distro
The idea behind it is to only need 1 device to get a smart home running securely. A separate network for hassio with the necessary firewall rules. It would be self sufficient with built in hassio-openwrt integration.
I get your intention, however I'm still saying that most ARM64 hardware will be way underpowered to run the two roles parallel. Most of the hardware you see today with quad core Cortex-5x and Cortex-7x SoCs are built to handle high bandwidth data with advanced things like filtering and threat analysis, you can't just slap another, even more resource-hungry task on top of that, and expect it to work well. Hence my x86 recommendation.
I get what you're saying but the OpenWRT router part of the device wouldn't need anything fancy. The router would ONLY be connected to smart devices, most of which will be completely blocked from the internet.
I will look into x86 options thanks. It's for a product that I'm looking to keep cost down on. Could you possibly point me in the right direction? A cost effective board that could run both hassio and openwrt. Qemu or native with qemu.
Ah, I see what you mean now. I find that a bit weird then, because you still need a second box for IoT stuff at home. I thought you wanted to completely eliminate the need for a second box by going for a combined IoT+internet gateway solution.
In that case, however, I think OpenWrt is an overkill, as you don't really need to manage various configurations. In fact I'm 99% sure you could solve this by slapping a WiFi adapter onto an existing Home Assistant setup, and using the host OS to configure a WiFi subnetwork.
This seems a noble goal - an all-in-one box for security and HA. I'd be tempted to go there myself and build it that way. All HomeAssistant needs is a Python venv - probably not to hard to compose on an OpenWrt platform. But I digress...
I would not buy one.
Having all the eggs in one basket (specifically, the benefits of not doing so) is perhaps still a valid aphorism in this space, because too much is still in flux as far as the consumer space goes.
Perhaps if the HA market continues to standardise, people will be ready for an AI1 box. Today, such a thing only makes sense if it's like the Jitterbug phone where it's basically a device managed remotely by humans who know how.
For the hobbyist/geek market, I'm less inclined to expect people to want an AI1 product.
The main downside is that when one bit of it goes wrong, needs upgrading, etc, then the whole device may be subject to service interruption.
That said, I confess that I still operate (for the home LAN) a standalone WiFi AP separate from the border router, because I still want the ability to choose the best of each without having to settle for the balanced-combo that combination devices offer. Or having to replace both when I want to upgrade one.
. It is indeed open source and I shall rinse and repeat, will update here when I have made progress and make a topic when inevitably need more specific assistance