CustomUI - discussion thread

Can you try

"if (state === 'on' && entities['sensor.driveway_reachable'].state === 'True') return 'mdi:power-plug';
                        else return 'mdi:power-plug-off';"

I indeed only want to adjust brightness for an already-on light.
But your right on the changing of the height, that’s indeed a downside if the slider is hidden.

I tried that, but then the slider is not protected and you can still use it to turn-on the light with a certain level by pressing the slider once.

I am seeing this same behaviour. I would really like it if the slider were protected, too.

Thank you, @andrey for all your work - Custom UI is great!

currently, I use hs_color and inside bracket I use 3 value (0-360, 0-100, 50) (hue, sat, light). At the light value if you put 0 or 100 (no matter 2 values in front hue, sat will give you white or black. This works for me nicely.

new
customize:
    binary_sensor.door_back_sensor:
      templates:
        hs_color: "if (state === 'on') return [360, 100, 50]; else return [20, 30, 50];"

old
customize:
    binary_sensor.door_back_sensor:
      templates:
        rgb_color: "if (state === 'on') return [200, 100, 30]; else return [10, 20, 30];"
1 Like

As I indicated earlier, HA frontend uses a scaled light value. When you set l = 50, it is effectively setting it to 0 in the front end (or black).

What is icon_template? This is not something CustomUI looks at. Is it a backend Jinja2 template? It has a completely different syntax (it is not Javascript)

Is there a way to hide the Color Wheel and Color Temperature controls? Ever since I moved my Lutron Caseta dimmers over to the Wink Hub (v1) it thinks they are color changing bulbs for some reason. I would like to manually hide them if possible.

CustomUI doesn’t affect the more-info window.

You could dig into the exposed supported_features and override that

I have pushed a new release:

2018-04-29

  • Add support for action_name attribute that can be used to change the displayed action on scene and script cards.
  • Make confirmable controls protect slider on 2nd line
1 Like

I’m having some odd behavior with with state_card_custom_ui_secondary and the stopPropagation() method.

My (simplified) setup:

Configuration:

homeassistant:    
  customize_blob:
    "*.*":
      custom_ui_state_card: state-card-custom-ui
    input_boolean.guest_mode:
      icon: mdi:account
      state_card_custom_ui_secondary: state-card-custom_boolean
frontend:
  javascript_version: es5 
  extra_html_url:
    - /local/custom_ui/state-card-custom_boolean.html
    - /local/custom_ui/state-card-custom-ui.html
  extra_html_url_es5:
    - /local/custom_ui/state-card-custom_boolean.html
    - /local/custom_ui/state-card-custom-ui-es5.html

state-card-custom_boolean.html:

<dom-module id="state-card-custom_boolean">
  <template>
    ...
    <div class='horizontal justified layout'>
      <div class='horizontal start-justified layout'>
        <div class="badge">
          <state-badge class="badge" state-obj="[[stateObj]]"></state-badge>
        </div>
        <div class="info">
          <div class="name" in-dialog>[[friendlyName]]</div>
        </div>
      </div>
      <paper-button-group>
        <paper-button class="on" on-tap='handleOnTap' hidden$='[[!onButtonVisible]]'>On</paper-button>
        <paper-button class="off" on-tap='handleOffTap' hidden$='[[!offButtonVisible]]'>Off</paper-button>
      </paper-button-group>
    </div>
  </template>
</dom-module>
<script>
  Polymer({
    ...
    handleOnTap: function (ev) {
      var serviceData = {entity_id: this.stateObj.entity_id}
      this.hass.callService('input_boolean', 'turn_off', serviceData);
      this.stopPropagation(ev);
    },
    handleOffTap: function (ev) {
      var serviceData = {entity_id: this.stateObj.entity_id}
      this.hass.callService('input_boolean', 'turn_on', serviceData);
      this.stopPropagation(ev);
    },
    stopPropagation: function (ev) {
      ev.stopPropagation();
    },
  });
</script>

Which nicely creates a button instead of a switch:
image

On my PC (chrome), everything workds great. However, in Safari on my iOS devices (and the iOS app), tapping the button opens up the popup with the state history chart. It seems the stopPropatation event is not working on iOS?

  • I’m using the latest version of CustomUI released this morning (4/29)
  • I’ve tried javascript_version with latest, auto, and es5 all with the same result

RESOLVED:
It looks like it was a problem with javascript and/or polymer, adding and on-click event fixed everything:

      <paper-button-group on-click="stopPropagation">
        <paper-button class="on" on-tap='handleOnTap' hidden$='[[!onButtonVisible]]'>On</paper-button>
        <paper-button class="off" on-tap='handleOffTap' hidden$='[[!offButtonVisible]]'>Off</paper-button>
      </paper-button-group>

Clear browser cache.

After posting this it occurred to me that I should start a discussion about this specific combination of devices and see if maybe I just configured something incorrectly. The author of the Wink component told me that this shouldn’t happen and he will have to look into fixing it. So I don’t think it is anything that anyone should spend time on.

Thank for the wonderful tool. I love customizing the UI.

Did you try with your custom_boolean but without my customui code?

This works great, thank you!

sorry, I should have changed that into:

templates:
  icon:
    "if (state === 'on') and (entities['sensor.driveway_reachable'].state === 'True') return 'mdi:power-plug';
                        else return 'mdi:power-plug-off';"

or simply rephrase in asking how to write correct syntax for a multiple condition like above.

HI @andrey
since Hue seems to have more than one issue with the latest Hassio versions, and RGB values have been among them, could it be that this extra_data_template is causing trouble, and might need changing:

light.bedside_table:
  extra_data_template:
    'if (attributes.rgb_color) return "RGB: " + attributes.rgb_color ; return null;'

The values come and go on the sliders, and seems very unstable.
also, it is probably the last thing i can think of that is causing the following error in the logs, and results in Hassio not being loaded:

8-04-29 21:02:49 ERROR (MainThread) [homeassistant.components.light.hue] Unable to reach bridge 192.168.1.212
2018-04-29 21:02:50 ERROR (MainThread) [homeassistant.core] Timer got out of sync. Resetting
2018-04-29 21:02:50 WARNING (MainThread) [homeassistant.setup] Setup of hassio is taking over 10 seconds.
2018-04-29 21:02:53 ERROR (MainThread) [homeassistant.components.hassio.handler] Timeout on /supervisor/ping request
2018-04-29 21:02:53 ERROR (MainThread) [homeassistant.components.hassio] Not connected with Hass.io
2018-04-29 21:02:53 INFO (MainThread) [homeassistant.setup] Setup of domain hassio took 14.2 seconds.
2018-04-29 21:02:53 ERROR (MainThread) [homeassistant.setup] Setup failed for hassio: Component failed to initialize.

51

Wasn’t rgb_color removed in HA 0.66 ?

In any case everything CustomUI does is in the browser, so it can’t cause backend errors.

Thanks, that are great additions to CustomUI :grinning:

yes, as setting for the icon_color :wink:
lights still have this attribute:

I guess that would make the extra_data_template still valid?

testing to have the various color techniques show up, would this be a valid extra_data_template:?

light.kist:
  extra_data_template:
    'if (attributes.rgb_color) return "RGB: " + attributes.rgb_color ;
     if (attributes.hs_color) return "Hs: " + attributes.hs_color;
     if (attributes.xy_color) return "Xy: " + attributes.xy_color ; return null;'