Add experimental UI

[balloob]

This is my take on home-assistant/architecture#14 and #1127 which has the goal to allow users to define a UI in a standalone file.

I'm really just exploring how this could work, what data structures can work and how we can simplify it a lot.

My approach:

• Add a websocket command to load <config>/experimental-ui.yaml. This file is not cached so you can edit the file and refresh to see latest version. (branch for Home Assistant)
• Add a new panel that is accessible via url only: /experimental-ui
• Add a new family of components <hui-*>. These components will be used to render the new configuration format.

It's currently written in Polymer but I think that the element creation can be done without it.

Feature set:

• Render first view in expeirmental-ui.yaml
• Able to render cards of type entities
• Able to allow setting CSS variables on the view

Known breaking changes with current UI:

• It's not possible to change the rendering type of an entity on the fly. This is because custom UI should not be defined inside state object attributes. We should define it inside our UI config. This means that the entities key of an entities card should be able to contain dictionaries specifying entity_id and possible type.

Example <config>/experimental-ui.yaml:

views:
- cards:
  - type: entities
    title: Example
    entities:
      - input_boolean.switch_ac_kitchen
      - input_boolean.switch_ac_livingroom
      - input_boolean.switch_tv
  theme: dark-mode

And use configuration.yaml:

input_boolean:
  switch_ac_kitchen:
    name: AC kitchen
  switch_ac_livingroom:
    name: AC living room
  switch_tv:
    name: TV

Feel free to discuss in this PR the config format. What we should support and what not.

CC @andrey-git @c727

[andrey-git]

Regarding the code itself: Is this a concept - i.e. discuss feature only, or something that is intended to move to "production" later, so also comment on performance, portability, etc?

Regarding concrete css properties vs pre-defined themes (like in current implementation):

While concrete css might be easier for users editing configs, for the future UI editor it is much more pain if I need to put the same 5 props on many entries.

Maybe support both?

[c727]

There are 3 kinds of customization that I think we should support:

• overwrite keys from stateObj: friendly_name, icon
• custom ui/ card: full-, state-, dialog-card
• static theming: e.g. make important toggles red

We said that "all" domains can have full- and state-cards. For example a full-card for air conditioners or alarm panels can be useful. How do we want to handle this?
a) we add additional full-cards for all domains <- user has to configure up to 3 custom cards here
b) we move all card types (full|state|dialog) in one file and pass a parameter which view it has to render

I think we need 3 types of cards in views:

Type	connected stateObjects	Current example	New custom example
single entity	1	media player	alarm panel, air conditioner
multiple entities	1+	entities-card	list of sensors like plant card
custom	-	-	iframe, floorplan custom card

We should store all configureable keys for a card in a config-key (entities-card: title -> config.title) to keep them separated, especially if we add also add custom_ui-keys here.

[balloob]

• I'll remove the CSS piece and make it theme based.
• we should add additional cards. We don't want to have 1 element that can be 3 complete different things, that is going to be a shit ton of if-else statements.
• I mainly want to hash out the feature set first. However, I also am experimenting with how to generate and update the DOM as efficient as possible and explore what code can be reused.
• I also want us to not be limited to material design / polymer. If people want to make something like HA Dashboard, it should be possible too.

[c727]

stateObj can be null

[balloob]

• It should also be possible to just have your custom component do the rendering of all the entities. Like a custom panel.

  <hui-view>
    <your-component />
  </hui-view>

• Are we thinking too much in our old UI if we are calling it 'cards'? Instead of a card, it can also be a button or just a graph ?

[c727]

Imo if a user wants to customize a whole view he should use a custom panel instead. I think some restrictions for /states, like column-width, are fine

[balloob]

Created a new repo for defining a schema and feature set. Let's create a new issue and PR against schema.md for each feature that we want to add. https://github.com/home-assistant/ui-schema/blob/master/schema.md

[andrey-git]

Other things (not sure if belongs to the schema repo):

• Do we want to support some sort of dynamic config? I. E. Ability to say "all lights that are 'on'?
• We need some way to represent "new unmentioned entities" so that when an entity is discovered it will be visible somewhere.

[balloob]

@andrey-git for discovery of new entities, I was thinking of taking the approach of the Android home screen. On Android, when you install an application, it is placed on your last home screen. After that it's up to the user to re-org.

We can do a similar approach. When we see a new entity (based on that it's not in the entity registry yet), we will add it to one of the frontend views.

We can also dynamically create a view of entities that are not specifically mentioned in any frontend config - problem there is that we don't know how cards are configured and thus can't really know which entities are shown.

[balloob]

For dynamic config, that can be achieved using composition:

# Example card config
type: entity-filter
filter:
  domain: light
  state: on
card: entities-graph . # defaults to 'entities'
card_config:
  card-specific: config

[balloob]

@andrey-git opened issues for the topics you raised home-assistant/ui-schema#2

[balloob]

Added a filter card as an example.

views:
- cards:
  - type: entities
    title: Entity Example
    entities:
      - input_boolean.switch_ac_kitchen
      - input_boolean.switch_ac_livingroom
      - input_boolean.switch_tv
  - type: entity-filter
    filter:
      state: 'on'
      domain: input_boolean
    card_config:
      title: Filter Example
  theme: yellow

[c727]

domain should be an array

[SteveMacLowell]

Re: Discovery of new entities - following on to the Android example (I've always had Samsungs, so my idea of Android might be a bit shit!), what about a hidden 'All' view that is accessible from a menu of some sort? As the name implies, all entities would be added to this view and can be dealt with further from there.

[balloob]

@SteveMacLowell that is a good idea, please share it in home-assistant/ui-schema#2

[SteveMacLowell]

Done!

[balloob]

This idea has not gotten the traction that I hoped it would get among developers. So I am going to go ahead and make it available to users. That way people can play with an early prototype and start giving better feedback.