Feature Request: Enable customization of timeline colors for sensors

[LeapFrogSupport]

History Explorer is an outstanding contribution to Home Assistant. It is far superior to the History panel kludge that was released in the 2022.7 core update.

Here's an feature that I think would be very useful ---

I have a template sensor derived from a binary_sensor for our garage door:

 - platform: template
    sensors:
      garage_door_status:
        friendly_name: 'Garage Door Status'
        unique_id: "Garage Door Status"
        value_template: >-
          {% if is_state('binary_sensor.garage_door_tilt_sensor_access_control_window_door_is_open', "on") %}Open{% else %}Closed{% endif %}

It would be advantageous to enable the ability to change the default timeline bar colors for the template sensor for an entity. In my case, when the garage_door_status sensor state is Closed, the timeline color is red, and when it is Open the color is purple. This feature would enable the user to customize these colors. I suggest something similar to the domain color features for switch.on / off and light.on / off that would be applied at the entity level.

stateColors:
  switch.off: silver
  switch.on: red    
  ........
# FR: Would like to be able to do
#  sensor.garage_door_status.open: red
#  sensor.garage_door_status.closed: green

Screenshot of my current History Explorer panel is attached.

[alexarch21]

So basically being able to customize the state colors on a per-entity level ? Sounds like a reasonable suggestion and easy enough to implement.

As possible workarounds right now, you can either override these two states for the entire sensor domain or add a device_class statement to your template sensor, effectively putting it into a device class (like door) that you can then customize the state colors for.

[LeapFrogSupport]

@alexarch21 "So basically being able to customize the state colors on a per-entity level ?"

Yes, exactly. That would be perfect.

I used your suggested workaround by modifying the templated garage_door_status sensor to a binary_sensor, adding the device_class (door) and setting the state colors in the card. That works a treat, so thanks for the suggestion. It still would be nice to have the ability to override the state color(s) at the entity level so I hope you have time to add that to an upcoming release.

Edit:
It may be me, but I tried to use a similar workaround for a binary_sensor.leak sensor (device_class: moisture) but it didn't work. As a workaround I changed the state color for all binary_sensor(s) and then overrode those selections for the garage_door_sensor. Is it possible that state color doesn't work for device_class: moisture?

Edit 2:
In exploring (!) the features of the card I discovered that in my case the timeline color is determined by the label specified by the sensor's template. For example, if I have a leak detector whose template specifies "Clear" as the off state the background color will be aqua (I think that the color I see). If I change the template so that the off state is reported as "Closed" the background color will be red. If "Dry", the color is brown. I assume this is intended behavior but it took me a while to figure it out. Maybe I didn't read the documentation carefully enough, and if so I apologize.

So, a related nice improvement in History Explorer would be to allow the user to specify the default colors for timeline based on the entity's templated state (e.g., on/off, open/closed, dry/wet, lock/unlock, etc.).

[alexarch21]

So, a related nice improvement in History Explorer would be to allow the user to specify the default colors for timeline based on the entity's templated state (e.g., on/off, open/closed, dry/wet, lock/unlock, etc.).

This is exactly what the card does. What you're seeing in the timeline events is the actual sensor state. If it says 'Dry', then that means the sensor state is 'Dry', exactly as-is. There's no translation or reinterpretation going on. It's the raw sensor state value that you assigned to the template sensor. The card will select a default color for every individual state as it encounters them, unless you override it. For your sensors, you will need to override the state names you see, because that's the sensor value (like for example sensor.Dry).

Things are different for binary_sensors, they will always be either on or off (or unknown).

[LeapFrogSupport]

Thanks for the clarification, your explanation helped me get'er done!

Although I read the documentation several times and looked through all the examples, I completely missed that you could override the state simply by using 'sensor.state: yellow' or whatever. I was already overriding colors for light.on, switch.off etc. but didn't grok that this capability extended to the more specific case of sensor.Dry: green. Silly me. My apology for that.

In case someone else stumbles into this, here's my working overrides:

stateColors:
switch.off: antiquewhite
switch.on: red
light.off: antiquewhite
light.on: red
sensor.off: lightblue
sensor.on: red
sensor.Clear: skyblue
sensor.Motion: red
sensor.Closed: lightblue
sensor.Open: red
sensor.Dry: tan
sensor.LEAK: red
door.off: lightblue
door.on: red

Thanks again.

[alexarch21]

Maybe the documentation could be clearer on that too. There's always room for improvement.

[LeapFrogSupport]

If you would like, I'll take a shot at adding a few sentences for you to use here: https://github.com/alexarch21/history-explorer-card#customizing-state-colors

Edit: Attached.
Customizing state colors.docx

[alexarch21]

Thanks, I'll include your contribution on the next documentation update. I might reword it a little, since this doesn't exclusively apply to template sensors, but to basically any sensor that uses states other than on or off (MQTT, hvac, weather, etc).

[LeapFrogSupport]

Agree, it indeed would be helpful to clarify the broader use case in the documentation update.

I don't know if you'd like a separate feature request and if so I can create one , but here's another suggestion for improvement of the timeline graphs:

• Provide the ability to set the timeline graph margins (similar to the "axisAddMargin" feature).
• Provide the ability to change the timeline font and the label and graph height.

Neither of these is a particular priority but if either one is easy to implement it would be yet another feature that may be useful to others. As always, comments / feedback is welcome.

[alexarch21]

Provide the ability to set the timeline graph margins (similar to the "axisAddMargin" feature

Can you elaborate what you mean by this ? The axisAddMargin features for line graphs change the margin of the visible data space on the Y axis. There is no Y axis on timelines, in fact the visualized data space is all horizontal (the vertical axis doesn't contain any information). So there's no margin on the Y axis so to speak, because there is no Y axis.

Provide the ability to change the timeline font and the label and graph height.

That would be opening a huge can of worms to be honest. Because once you introduce customization to that level, you'd have to add it everywhere in the card, or people will start complaining that the menu point of this dropmenu there should have the font configurable too... I'll rather keep that can closed for now :)

[LeapFrogSupport]

Good day!

The specific intent of this feature request was to enable the user to set the vertical spacing between timeline graphs. Sometimes a picture is worth 1K words, so see the attached. Personally I would like to be able to set the spacing to near zero, perhaps with the only visible area between the timelines a few pixels that might be tall enough for the gridline.

I understand your rationale regarding the timeline font/label/graph height, thanks for considering it anyway.

!

[alexarch21]

Ok, so it's the spacing between the timelines. I assume you already set the popup height to slim ?

The problem here is, as you noted, the tooltip popup. Since it's rendered into a canvas, the popup is going to be cut off if there's not enough vertical space. That's not much of an issue if you have 3 or more timelines in a graph, but it's an issue with one or two. If I force the space smaller with 3 bars, it could look like this:

Which would be approximately fine, even though the popup is already clipped a little. This would become much worse with only 1 or two lines. So the renderer will have to override the user provided spacing for less than 3 items. Otherwise things will break.

The real solution is to make the popup an html overlay. But that's a lot of work for relatively little return. Most people don't mind the extra spacing. I mean I could make it a 'use at your own risk' option, but then I'll get bug reports about the popup being only half visible when people put the spacing at 0 :)

[LeapFrogSupport]

"Use at your own risk" works for me.

Alternatively, maybe one option would be to combine the reduced timeline spacing option with a mandatory change to a horizontal layout for the tooltip. Would that solve the 'cutoff' problem?

[alexarch21]

V1.0.24 now supports the customization for states of single entities. I also used your example to make the readme a little more explicit about the raw state values.

About the timeline size, that's another issue. The real way forward here is a html overlay.

[LeapFrogSupport]

The customization by entity works perfectly! Thank you so much.