Core: [RFC] How to implement theming

[andrey-git]

Some components, like the input_slider has customization built in.

However it is inconvenient to specify the attributes for each device.

I propose something like the following for dimmer lights customization:

customize:
  light.ceiling_lights:
    toggle_ui: true
    brightness_theme:
      min: 30
      max: 70
      pin: true
      offOnMin: false

The polymer UI can then use those attributes.

What do you think?

[balloob]

I do not want to make the UI any more customizable than it already is. Customizations need to be maintained. Giving your UI endless possibilities means it is impossible to change / grow as it has a lot of testing efforts. Look at any major product out there, you can't just go around change everything. The official Home Assistant UI will always do everything 1 way and make the right choice for _most_ users.

Besides that, our backend is also not made with a specific UI in mind. We just put out that the light has a brightness and any frontend can figure it out.

[andrey-git]

@balloob
The other UIs of cause don't have to respect any settings. I also agree that the default should fit most users.

You could argue simplicity against adding new fewly used platforms - they have maintenance cost. But I think customizability is whats product an edge:

A common user doesn't have to know about it at all, but the power user can do things via Yaml.

[balloob]

If a system like this would be added, it would be a custom config just for the frontend. It doesn't have to put extra info in the state attributes.

For maintenance and complexity purposes it's out of scope of the official UI.

[andrey-git]

The whole customize: component is just for the frontend:
hidden, friendly_name, icon, sensor_class

How about moving that out from state attributes into something like "ui attributes"?

Also unlike the backend which supports custom components - there is no such support in the UI.

[happyleavesaoc]

@andrey-git There are custom panels: https://home-assistant.io/developers/frontend_creating_custom_panels/

[andrey-git]

@happyleavesaoc thanks. This is cool for new 'pages', however it doesn't allow new "widgets" on a regular page.

[andrey-git]

Only partially related to customization, but seems users would like an update to the dimmer UI: https://community.home-assistant.io/t/ui-more-suited-for-dimmers/8660

[Fonta]

While I agree with balloob with not allowing too much customization options, it's would be bad to have a few.
A thing like a switch button type would be nice.
As an example:
Changing the lightnings to the toggle:

[andrey-git]

@f0nt4 I think that one already exists by setting assumed_state

[Fonta]

@andrey-git thanks! Have been looking for it, but couldn't find it.
Thought it didn't exist.

[andrey-git]

Here is another customization request (aliases to binary_senssor states): https://community.home-assistant.io/t/customize-text-of-binary-sensor-on-off-state/4653/16

[randellhodges]

I think there needs to be the ability to extend/customize the UI. I became interested in HA when I saw all the components and how easy it was to extend HA to implement new components. I even implemented a couple private ones for myself.

I then wanted to extend/customize the cards. Like giving items a different name inside a group and other things. Once I started digging into the UI, I lost interest.

I can see not wanting to pull some stuff into the core of the application, but, I personally feel an extensible UI is needed. Dynamic icons for battery percentage, day/night themes (or custom ones), things like the above is really needed.

I'm not saying the core team should implement them, but provide a framework and hook points for the community to add them. Maybe they do, and I don't see them.

[pvizeli]

I think @balloob explain the reason why the main UI is like it is.

But HA support websocket and rest api and it is very easy to make a own, customable UI like https://home-assistant.io/ecosystem/hadashboard/. Every body can do that without forking some things.

I think the best way is to have a new UI in ecosystem they could be easy customable, and maybe, it going to new UI in some times ;)

[partytimeexcellent]

I have to say I agree. The UI is generally more pleasing than many other home automation projects but I do think it's too limited as far as customizing goes.

[christianwaite]

I found I didn't want to toggle a light on to the last value before I could then set its brightness, so created a component to match sliders to lights.

It's a testament to the devs that someone of my limited abilities could create this easily, but I wouldn't have had too if the options were there...

[Fonta]

@christianwaite In the latest dev version it's possible to click a light and immediately access the dim slider.
What I would ligt to see though is an option to define if an light is indeed dimmable or if it's only on/off.
Because now every light is dimmable in HA. I could move them to switches of course but a light is a light imho.
Could you share your yaml config for how you matched the sliders?

[Instagraeme]

I think @pvizeli hit the nail on the head. The frontend we see is simply the one that ships with HA. It doesn't mean it's the best frontend (it's not); nor does it need to be. It should simply expose what is possible with HA.

[andrey-git]

@balloob I completed the implementation. Please take a look before you make your final verdict:

The diff below contains a new customizable ha-themed-slider. That slider is used in the new state-card-light. You can see screenshots of that as UI2 here: https://community.home-assistant.io/t/ui-more-suited-for-dimmers/8660/11

The change in hass-util.html allows to choose between the new state-card-light UI (default) and the old toggle UI.

https://github.com/home-assistant/home-assistant-polymer/compare/master...andrey-git:dimmer

[andrey-git]

As a general answer to everybody:

I totally agree that a drastically different UI, like HAdashboard belong in a different repository. However I think that my proposal is an incremental improvement of the "main" UI.

For a project to be successful it should also have a great UI.
The default should be as simple as possible and targeted at the majority of users. But allowing to customize the UI would make it great for everyone. Forking doesn't really scales.

[christianwaite]

I wouldn't want to deal too much with a large ui configuration, but I think being able to specify a light should be a slider instead of a toggle is within the realms of the standard ui.

I'd forego the toggle altogether in your example, just set the yellow light icon to grey when the slider is bellow the min value.

[andrey-git]

@christianwaite note that the whole configuration is completely optional. The UI still works out-of-the-box.

I didn't understand your UI proposal :(

[balloob]

Let me just quote myself, as I feel like it got lost in the discussion:

I do not want to make the UI any more customizable than it already is. Customizations need to be maintained. Giving your UI endless possibilities means it is impossible to change / grow as it has a lot of testing efforts.

I also responded to the thread in the forums. I would be down to replace the toggle with a slider if we know the light supports brightness - but not both as that's too crowded on mobile.

[christianwaite]

I agree, the toggle makes it too cluttered and is unnecessary.
I've just linked sliders too the lights, they turn the light off if below a certain value. I don't have two way at the minute though, so if the light changes independently of the slider (automation or physical switch) then the slider doesn't update.

My Config:

slider_update:
  off_limit: 24
  pairs:
    input_slider.livingroom_main: light.livingroom_main_level_10_0
    input_slider.diningroom_main: light.diningroom_main_level_11_0
    input_slider.livingroom_tripod: light.tripod
    input_slider.livingroom_floor: light.globe
    input_slider.diningroom_tangerine: light.tangerine
    input_slider.diningroom_futon: light.futon

My Custom_component:

"""Slider Update Component."""
import logging
from homeassistant.components import light
from homeassistant.helpers.event import async_track_state_change

DOMAIN = 'slider_update'
DEPENDENCIES = ['light']
LOGGER = logging.getLogger(__name__)

def setup(hass, config):
    LOGGER.info("The 'slider_update' component is ready!")

    OFF_LIMIT = config[DOMAIN]['off_limit']
    CONF_PAIRS = config[DOMAIN]['pairs']
    LIGHTS = CONF_PAIRS.values()
    SLIDERS = CONF_PAIRS.keys()

    def sliderChanged(entity_id, old_state, new_state):
        TARGET = CONF_PAIRS.get(entity_id)
        NEWSTATE = int(float(new_state.state))
        if(NEWSTATE >= OFF_LIMIT): light.turn_on(hass, TARGET, brightness=NEWSTATE)
        else: light.turn_off(hass, TARGET)

    async_track_state_change(hass, SLIDERS, sliderChanged)

    return True

[andrey-git]

I responded more fully on the forum (https://community.home-assistant.io/t/ui-more-suited-for-dimmers/8660) but with just a slider it is impossible to turn the light on to the previous value.