Review of our editors and where to go next

[balloob]

We have grown quite a couple of configuration UI's in Home Assistant by now:

Automation editor

Picker page:

• Landing page
• A list of all automations that are editable.
• There is a "Create Automation" FAB in the bottom right

Create/Edit page:

• Tapping on an automation brings you to the editor
• Editor uses config sections to represent trigger, condition, action
• Changes are saved by pressing the FAB

Opinion:

• The editor is getting a lot better with More entity improvement #675, which will allow easily picking entities and services.
• We Should add the service description to the action editor if available. Next step is to try to dynamically create a form for it. I've made a stab at this in More entity improvement #675 in the dev service tool, it will show a field for "entity_id" if the service supports it.
• Since we have only 5 actions, should we consider making it tabs or radio button instead of dropdown? Or maybe it's more important to stay consistent with the trigger/condition?
• The editors for 1 trigger/condition/action take up a lot of vertical space. On my macbook I only see 2 edit cards at once. Should we consider a column layout on desktop (like GitHub Projects)
• We scare people with the intro "make sure that you have configured Home Assistant correctly". By default it is configured correctly. We should move this warning to the bottom of the card and have a link with the caption "I don't see my automations". We can follow a similar style as the Shopping List tip at the bottom of the card:

Script editor

Picker page:

• Landing page
• A list of all scripts that are editable.
• There is a "Create Automation" FAB in the bottom right

Create/Edit page:

• Tapping on a script brings you to the editor
• Editor uses the action config section from the automation editor
• Changes are saved by pressing the FAB

Opinion:

• All comments for the action part of automation editor apply here too (it's the same code/UI)
• Idem on the scary intro. We should apply same solution as automation editor.

Customize editor

• Single page
• Entity is picked at the top from a dropdown
• Card is populated with currently set attributes which can be converted to be overwritten in customize
• Card offers a dropdown to add a new customize attribute. Offers user to pick from popular ones and offers a custom customize attribute option.

Opinion:

• We show programmatically set attributes first. Those are the attributes they should probably not change (as they are set based on the state of the device). We should explore a UX where we show the current active customize attributes for an entity and allow changing/adding those. Programmatically ones should only be available for advanced users. We can achieve this by creating a white list of "most common customized attributes" (name, icon, hidden)
• We should update entity picker to <ha-entity-picker> once Entity dropdown improvement #674 has been merged

What's next

We've been getting a bunch of components that expose the entities inside Home Assistant to external services. Examples are Google Assistant, Emulated Hue, Alexa.

These components have 2 different configurations:

1. Which entities have to be exposed
2. How are these entities exposed

Deciding which entities need to be exposed is done using whitelists and blacklists. Using a combination of include entities, include domains, exclude entities and exclude domains a user can create a set of entities that will be exposed to the sync service (using entity filter).

Configuration per entity is currently done leveraging customize. This should be changed as all configuration should go via configuration.yaml for that component. Leveraging customize means that you cannot sync with two google assistants and your configuration is unnecessarily ending up in the state machine and history.

The main reason developers tend to abuse customize is because it allows people to configure all their entities at once and you can leverage existing infrastructure: Customize can be configured per entity, per domain and using globs on entity ids (powered by EntityValues).

I want to create a UI that offers two things:

• Allow to manage what entities are exposed
• For exposed entities, manage the attributes for this service

However, this approaches it from a service/component angle. The benefit of using customize is that you can customize all settings for 1 entity at once. This makes me wonder, should we approach it from an entity angle instead. Kind of like the customize editor but with a card per service/component? Or would the per entity editor be something that we can tuck away in the more info redesign that @NovapaX is looking into in #627

I'm currently leaning to a per service UI similar to the automation editor.

• When you open it up, you'll see all current exposed entities.
• There will be a "manage entities" button on the top of the list that will bring you to an editor for which entities are exposed that will show which entities match your selection real time.
• Tapping on an entity allows you to configure the attributes for the service.

[andrey-git]

Regarding the "scary intro":
Customize editor is half-step forward by checking if the content of the edited file is a subset of the whole config. (And show warning if it is not).
This is not enough in the following scenarios:

• The edited file is empty, and thus is a valid subset regardless of whether it is properly connected.
• another file is broken, thus config reload fails and the properly-connected file looks like it is not a valid subset.
• File is not properly connected, but file content still looks like valid subset.

This can be fixed in the following ways:

• Allow a specific config_check: timestamp dummy key in schema. Pre-populate it in the empty config files and change on each file save.
• Make subset comparison before validating schema, i.e. write a dummy key to file, read root file and make sure key is there, delete dummy key.

[andrey-git]

Regarding order in customization editor:
It first shows overrides in customize.yaml , then overrides not in customize.yaml, then programmatic attributes, then "new override" picker (which adds a new list between itself and programmatic)
The "new override" list doesn't include any entry already in the visible list.

If we want to sort by "importance" then indeed "new override" should be before programmatic.
Maybe the dropdown can be replaced by a FAB that will should a list in a popup?

[MartinHjelmare]

Last time I tried to use the automation editor it screwed up all my action templates. I use templates both for triggers and actions. I'm not sure if this is fixed now. If it isn't it would be good if it at least didn't destroy the existing automations. I don't mind if the template feature is considered advanced and not available when adding new automations. I can make a proper bug report if you want.

[balloob]

Bug report would be welcome.

[abmantis]

Regarding components that expose entities, I really prefer setting attributes (such as alexa_hidden) directly on the entity configuration. One example that currently cannot be configured on the entity directly is the recorder exclude list, and I end up forgetting to add entities to it or remove old entities from the list.

I think that, ideally, we should be able to specify those directly on the entity definition. For components that create entities automatically, they would need to support having the entity_id definition in the configuration even if it is auto-discovered. That probably requires too much changes to too many components, but would put everything related to an entity in a single place.

Another ideia is having a entity_config: section for configuring those things, like the customize.

[balloob]

The nice thing about entity_config is that we avoid configuration leaking into the state machine.

But the issue with entity_config is that now configuration for a component lives in 2 places. For example, both under google_assistant: and homeassistant/entity_config:. Having it under google_assistant/entity_config would make more sense. Using the UI we could still offer an editor with everything in one place.

[zsarnett]

@balloob Can this be closed in light of the Google Sheets for the road map?

[balloob]

We should close this as everything is different now :)