Hi there!
I got into Home Assistant recently and of course I wanted to have my HA deployed with balena. Surprisingly I found little information or previous user experiences, and the process of setting it up was more challenging than I anticipated. So I documented the issues I had and wanted to share them.
If you have suggestions, alternatives or any comments please let me know!
thank you very much for your medium post, we really appreciate the time you took to write it.
I will share it on our social media and I would also like to send you our swag pack as a thank you!
Sorry itās an old thread but I didnāt quite understand the Medium post that you sent. I feel that itās a bit hard to follow for someone whoās new and working with Balena Cloud. If you could have a step-by-step guide or any other docs then that would be helpful.
What part are you having trouble with? Maybe we can helpā¦
Maybe you also want to check out the projects here: https://github.com/balenalabs they will generally have a more detailed step-by-step guide on how to deploy them and you can then take the knowledge for this one
@tmigone Thanks for the detailed post on Medium ā I definitely found it helpful, and believe it speaks to some of the issues Iām currently facing with regard to running Home Assistant on Balena. My current challenge is that Iām a total N00b to Home Assistant, Balena, and containerized applications ā so thereās just a lot of surface area / learning curve ā and often, itās not immediately obvious which curve Iām on.
Case in point: Having completed virtually my entire migration from a SmartThings v1 hub (4 days until it implodes), Iām left with only some of my more complex automations - which may have used custom device handlers, or other automation (āmirroringā devices, such that all lamps in a fixture, for example, can be controlled as a single device). Clearly - that is a Home Assistant topic / question. Butā¦
What about the task (as described in the Medium post, and still just beyond my grasp on a couple of points) is the management of my Config file for Home Assistant ā and, the next great hurdle ā Lovelace dashboards. As Iām working within HA, clearly by config is being updated - and persisted, outside the container ā butā¦ where / how would I do UI development? I certainly want to be keeping the config under source control - and am at least comfortable with ābalena pushā ā butā¦ ?
One clear / obvious question for @tmigone : When you speak of development vs. production ā I assume this means you have two entirely different devices (but under a single application - or two distiinct ones?) within Balena. I love the idea of a dev environment, and have plenty of Pis to go around - but a dev device wouldnāt have all my Zigbee and ZWave devices plumbed to it, of course - making testing certain things challenging. I guess I could at least be doing UI work there, testing upgrades, new integrations and config changes.
Thanks again for the post, and thanks in advance to the community for any additional insights, #ProTips or hand-holding.
I have pinged Tomas, but Iād like to take a shot at your dev and prod device question. In balena terminology, we use development and production devices to indicate devices that are running the development and production version of the balenaOS. These are 2 separate images, that have some differences - for example support for local device development exists in the developer image. You can read more about this on our docs for the same
Thereās nothing stopping you from having the a production device (i.e. a device running production variant of balenaOS) along side a development device(i.e. a device running a development version of balenaOS) in the same app. In fact thatās exactly how I do my app development. I develop locally on my dev device, and then push to the balenaCloud when my app is ready to be distributed to my other devices.
If you donāt want to enable certain services on your development device, you can either maintain 2 separate docker compose files, or structure your app such that your services check for a local variable to start or stop. So if you have an env variable that prohibits your zigbee service from running, that can be something you use to distinguish between your prod and dev devices (env variables can be set either fleet wide or per device)
Thank you, @anujdeshpande ! Iāve been chipping away at some of the masterclasses and doing a bit of balena push via the CLI for some projects ā and Iām totally following what your describing, and appreciate the feedback.
I guess my question is less Balena-centric, and more about Home Assistant - so perhaps (at least part of) my question belongs over there (e.g. How to do development on devices that can only be connected to one ānetworkā. I know, I know - with stubs, or ādigital shadowsā of devices. But applying that, for example, to the Zigbee or ZWave āIntegrationsā and device registration, grouping, automations, scenes, triggersā¦ it seems the only place I can do development about āGrouping my 3 dining room lights together and controlling them as a single unitā will be in my prod, RUNNING device. Then, any successful changes would need to be āback-portedā to the repo ā YIKES! This doesnāt sound like the right workflowā¦
Thatās the part of Tomasā post, right at the fringes of my Docker and Balenu understanding, is the description of the mount vs, the bind mount, the timing of same and copying of files into the image.
Iām gonna give it another read - and go hands-on (on a development build :)) and see what I can figure out.
hey @snowake, Iām glad you found the post useful!
Let me clarify the āprodā vs ādevā conundrum. What both you and Anuj describe is correct. balenaOS offers two flavours (āProductionā and āDevelopmentā) with some differences, the main one being that the development version provides tools that aid you if you want to develop your code on your device (see this blog post for more context on that).
However, in my HomeAssistant blogpost I was not referring to balenaOS flavours when talking about prod and dev but rather:
āproductionā is my Raspberry Pi that actually runs HomeAssistant 24x7
ādevelopmentā is my development machine, my laptop computer where I do all my work.
This setup has an obvious drawback and itās the one you already found, if you are working with hardware that connects to your Home Assistant device you need to have it connect to both your dev and prod devices. At the time I wrote the blogpost I only had some Philips Hue lights and a couple of sonoff devices, both of which I had connected to my Raspberry Pi for prod but also to my computer for development. If you have a bigger setup this is not scalable at all and it might not even work. Iām not sure how the HomeAssistant devs do actual development maybe as you say itās worth bringing this issue to their forums/GitHub as they might have some tips.
Since then Iāve moved away from the workflow I talk about in the blogpost for this reason, moreover with recent (last 1.5 years) HA changes they are moving more and more into the direction of storing configuration in database-y files and not YAML files. So it become harder and harder to use this workflow I describe. What Iām currently running is a modified version of GitHub - balenalabs-incubator/balena-homeassistant: Raspberry Pi + Home Assistant + balenaSense which is just a HA instance (you can ignore/remove the balenaSense stuff). This approach has a couple notable drawbacks that I have to live with:
I have no ādevelopmentā environment anymore, so every time I upgrade stuff breaks.
I need to manually backup the āconfigā volume. This ties in to point #3 on my blogpost (Source control with GitHub: Backup HA configuration and rules to a git repository.). As I mentioned before HA nowadays relies more in database files than YAML so I had to give up on this. Now if for some reason I have to re-flash my Raspberry Pi I need to import my HA config backup.
Those are my 2c, other than that Iāll ask a colleague thatās much more experienced with Home Assistant to chime in if heās got anything else to add.
Thanks, @tmigone - for the detailed response! I feel like Iām at a decision point - and need to either go all-in on figuring out Home Assistant in the context and deployment model of Balena ā or just go with a more vanilla, HomeAssistantOS running on a RPi4 sort of deployment architecture - at least for my āProductionā use case (which is subject so significant WAF pressures). Case in point: The fact that:
Alexa- turn on dining room light
no longer behaves as expected desired ā and that is one frequently-invoked home automation routine. So - Iām struggling on a variety of fronts ā from ZWave integrations (and the proposal, from this thread, that in order to migrate to the newer ZWave-js integration - Iād need to install an ājs2MQTTā or some such container, along side my HomeAssistant, to facility the configuration (but, apparently, not the actual integration?
I guess one specific question I can appropriately ask here (it feels like the answer can be found in your Medium post - but Iām not finding it where expected).
Where would I find my config files? I do see the /config directory, as mounted in the homeassistant container ā but not finding the corresponding āpersistentā version of it in the Host OS? I suspect Iām missing some key concept
My goal, currently, is to delete an āorphanedā ZWave device which didnāt seem to add properly (with both of the required entities) - so I was unable to control it. Iāve tried removing (ZWave exclusion) ā and can get rid of the associated entities, but not the actual device.
I know, I know: Thatās a question for the HA forums. I asked it, here:
At any rate - for today, my goal is just to get the current Balena-deployed HA up and operational, and achieving full WAF. Going forward, I hope to detangle some of the various pros and cons and make an informed decision about my target state deployment - for both āproductionā and development environments (noting the hardware constraints discussed above). Perhaps an additional Zigbee / ZWave stick, and a few devices confined to just my officeā¦
Thanks again for your detailed write-up. Iām off to read it carefully a third time, while referencing the Dockerfile and docker-compose files - to see if I can enhance my understanding.
where / how would I do UI development? I certainly want to be keeping the config under source control - and am at least comfortable with ābalena pushā ā butā¦ ?
You can simply use a (private) GitHub repo for source control and continue using balena push. There is even a GitHub action to automatically push to balena. For UI development Iād recommend using what is called āmulti-stage docker filesā. This basically means, you write multiple docker containers (for different purposes) in one file.
So your UI containerās Dockerfile might look something like this
FROM node as build
COPY . .
RUN npm ci && npm run build
# final image, which will get actually deployed
FROM ngix
COPY --from=build . /var/usr/www # you'd better check if that path is correct
Where would I find my config files? I do see the /config directory, as mounted in the homeassistant container ā but not finding the corresponding āpersistentā version of it in the Host OS? I suspect Iām missing some key concept
Volumes in compose are an abstraction of storage that can be mounted. The default (like in your compose file) is using āDocker Volumesā which are like containers without running processes, just an empty filesystem.
You can list them with `balena volume ls. There are similar commands to extract the data as well.
Hope this helps as entrypoint to your further research