A couple of recent releases of Home Assistant have had breaking changes that have affected me, and they’re a result of some growing pains.
To understand the growing pains, you need to understand where Home Assistant came from and where it’s heading. Like many open source projects, it started out from one developer’s desire to solve a problem. Founder Paulus Schoutsen wanted to control, integrate and automate his smart devices. He wasn’t happy with existing solutions, so he wrote his own. One he put it out on the internet it rapidly grew, attracting other developers and an entire community.
I first started using Home Assistant just over three years ago, and at the time I wrote that it had a steep learning curve. Almost all of the configuration was done through YAML text files and, while YAML isn’t particularly complex, it wasn’t as user friendly as alternatives such as SmartThings that present configuration through an app. I also noted that breaking changes were fairly frequent, as the internal architecture would occasionally change in a way that required configuration changes.
As the application core became more stable and the user base increased, the development focus started to switch. The developers wanted Home Assistant to be useful to a wider community – not just techies who don’t mind delving into configuration files and fighting with text editors to ensure that spaces and tabs don’t get mixed up and cause their YAML to break…
It’s an admirable goal. The benefits of Home Assistant are clear – a focus on privacy and local control without reliance on the cloud. By making Home Assistant easier to use, more people can take advantage of those benefits.
Gradually, developers started moving configuration into the user interface. It is now possible to set up many of the integrations with external services and devices directly from the UI instead of through YAML files. Most simple automations can also be set up through the UI, as can the layout of the UI itself.
For users running the full version of Home Assistant, either on a Raspberry Pi or in a virtual machine, it’s possible to update the system through the UI and there is even an add-on “store” for additional features. If you run Home Assistant under Docker or through a Python virtual environment you still have to manage those things yourself, but only the more technically minded users would choose to do that anyway.
So why is this causing growing pains?
For a start, not all integrations can be configured in the front end. Some still require YAML configuration. That should be temporary as every new release brings more of the integrations into the front end, but in the meantime it would be a possible source of confusion for new users. I can see users limiting themselves to those integrations that can be configured through the front end, but since most of the major integrations are now available it’s unlikely to affect many users.
The bigger problem comes when configuration for an integration is moved from YAML to the UI.
The problem is that the UI configuration is not simply a user friendly interface for the underlying YAML. It replaces the text configuration in the YAML. The actual data for the configuration is stored in a JSON file in the .storage directory, but it’s not intended to be user editable.
There isn’t a standard way of doing the conversion from YAML to the UI method. Some integrations will check to see if there is already an existing YAML configuration, and if there is they will convert that and set up the new UI configuration based on the existing YAML. That’s a one time move – from that point on, the YAML configuration is redundant and any changes to the configuration should be done through the UI. The YAML configuration isn’t removed, but the release notes for such changes recommend that you remove it manually to avoid confusion.
If all of the integrations worked that way when switching to the UI method, there wouldn’t be a problem.
Unfortunately there is no requirement that they do. For two consecutive releases I had integrations that migrated to the UI configuration without importing my existing YAML setup. That meant that I had to reconfigure them from scratch in the UI.
The first was the Met Office weather integration. My original YAML configuration just used “met_office” for as a prefix for all of the resulting sensors. As I described in my Stormy Weather post a few months ago, I was using “sensor.met_office_wind_gust” as a trigger for an automation. When I reconfigured the integration in the UI, my sensors were all prefixed by the location name of the Met Office sensor reporting the data – i.e. the wind gust sensor had become “sensor.location_name_wind_gust”. That meant a change to the automation and several changes to the UI where I was displaying the entities.
I realised afterwards that I could rename entities from the UI, but I’d already made the changes at that point. Editing entity names has been possible in the UI for some time, but I’d just never noticed.
I can see the benefit of the change – it’s more flexible and allows for multiple locations to be polled. It just meant a bit of extra work when I did the upgrade.
The second instance is more interesting, as it’s an integration that is now partly configured through YAML and partly through the UI. The rfxtrx integation that I use for my doorbell, a weather sensor, and some switches, used to be configured in YAML with a platform section to set up the transceiver device:
rfxtrx: device: /dev/rfxtrx
Followed by specific devices for sensors or switches:
sensor: platform: rfxtrx devices: 0716000100da0170: name: doorbell data_type: - Sound fire_event: true switch: - platform: rfxtrx devices: 07100a0041010000: name: rfxswitch1
The new configuration puts everything under the platform definition:
rfxtrx: device: /dev/rfxtrx devices: # Doorbell 0716020000180e70: fire_event: True # Switch 1 - A1 07100a0041010000: device_class: plug
The YAML code is still required to identify the device IDs but not to set up the entities. The devices will appear in the UI:
From here, the entity names can be configured:
I set them to match my existing automations. I had to experiment a little to match up the new default names – such as “GDR2 A” – with my previous names, but it was a one time task and I only had a few to deal with.
I also found that I had to change my doorbell automation. Previously it triggered on an event:
- alias: 'Doorbell pushed' trigger: - platform: event event_type: signal_received event_data: entity_id: sensor.doorbell_sound
Now it just triggers on state – and I have, of course, moved the configuration of the automation into the UI:
I assume that the change to bring all of the YAML configuration under the platform definition is to bring the integration into line with the current standard way of operating, and is probably a halfway step towards full integration into the UI. Hopefully, when that happens it won’t require any further changes.
These were fairly minor issues to deal with, and do just represent growing pains as Home Assistant matures into a user friendly platform. I do wish that Home Assistant had kept the option of user editable configuration files though. Given that the UI configuration is being stored in JSON anyway, it doesn’t feel like it would be much harder to continue to use YAML. The UI configuration could reflect the content of the YAML files and changes made in the UI could be saved back to YAML. I lean strongly towards the argument that the UI should just be a different way of doing the same thing – i.e. that the same results should be achievable through editing files.
That’s not going to happen, though, and there’s a very long thread about it on the Home Assistant Community. Suffice to say it’s been contentious.
I’m less worried about the switch to UI configuration than the fact that it leads to breaking changes. I’d prefer a rule that all integration changes that move configuration from YAML into the UI should import the existing YAML configuration. In my opinion, breaking changes should only be those forced on Home Assistant from outside – for example, if a vendor switches off an API that an integration uses, that’s clearly a change outside of Home Assistant’s control.
In the long term, once all of the integrations are migrated, the problem will go away. It is merely a growing pain. The move towards making Home Assistant more friendly to non-technical users is great, and will help many more people to benefit from its strengths.
A few minor stumbles that mainly affect those of us who are already comfortable enough with the technical side to deal with them is not a big deal, and ultimately a small price to pay for the continued success and wider adoption of Home Assistant.in Home Automation