What did you have to remove from your configuration?
Hey Stephen, noted that this release had added Fitbit integration without manually adding so removed all my Fitbit referencesâŠ
1 Like
It seems this update broke my DSMR integration (5B version in Belgium).
I still can see all of my electricity entities are fine, but my gas-consumption isnât working anymore.
Rollback to 2023.10.5 fixes this.
Ok, so I was wrong about this being Grid card problem, at least that I canât seem to reproduce that issue, however I am finding that the âfeaturesâ option does not work via the UI.
Yet I can add the âfeaturesâ with YAML.
Since that ha-slider migration the below code stopped working and I corrected it with the new parameters, everything works except for the âpointer-events: none;â
Old code:
card_mod:
style:
hui-generic-entity-row:
$: |
:host {
--paper-slider-active-color: var(--disabled-text-color);
--paper-slider-knob-color: var(--disabled-text-color);
--paper-slider-container-color: var(--disabled-text-color);
--paper-item-icon-color: var(--disabled-text-color);
color: var(--disabled-text-color);
pointer-events: none;
}
New code:
card_mod:
style:
hui-generic-entity-row:
$: |
:host {
--md-slider-active-track-color: var(--disabled-text-color);
--md-slider-inactive-track-color: var(--disabled-text-color);
--md-slider-handle-color: var(--disabled-text-color);
--paper-item-icon-color: var(--disabled-text-color);
color: var(--disabled-text-color);
pointer-events: none;
}
Can somebody enlighten me how should the âpointer-events: noneâ be handled? Thanks
HI Paul,
Been trying to figure out all changed variables there, but run into a bit of problem with that 
current theme variables are:
paper-slider-knob-color
paper-slider-knob-start-color
paper-slider-pin-color
paper-slider-active-color
paper-slider-container-color
paper-slider-secondary-color
paper-slider-disabled-active-color
paper-slider-disabled-secondary-color
paper-slider-bar-color
and I can not find the direct replacement for all of these in the doc you linked as that only lists:
--md-slider-active-track-color
--md-slider-active-track-shape
--md-slider-inactive-track-color
--md-slider-inactive-track-shape
--md-slider-handle-color
--md-slider-handle-shape
would appreciate it if you could find a moment to help and create a direct replacement instruction for those?
This is fixed in the 2023.11.2 update. Thank you!
I use this GitHub - j-a-n/lovelace-wallpanel: đŒïž Wall panel mode and photo screensaver for your Home Assistant Dashboards in my old IPad with guided access and it is great!
You have all tokens list in the code using the « all token » link in the page I provided (below the table). Just prefix them with âmd-slider-.
Also, these variables are not officially supported by HA and will never be because we donât want to be stuck with a library. So it can (will certainly) break in the future.
thanks I didnt spot that before
md-slider-active-track-color: green
md-slider-inactive-track-color: yellow
md-slider-focus-handle-color: black
md-slider-pressed-handle-color: white
md-slider-handle-color: pink
md-slider-hover-handle-color: orange
md-slider-handle-shadow-color: red
md-slider-label-container-color: grey
md-slider-label-text-color: purple
seem to be working. However, I can not find the correct variables for the slider container itself as they are nit mentioned in that linked page?
that doesnt sound really user-friendly⊠why make the move now thenâŠ
itâs not supported and will certainly break again.
As theming is supposed to be the way the endusers can/should customize their frontend (opposed to using all custom cards), why not make that theming more robust going forward?
Material etc controls imho are not a part of HA, they tend to be changed/upgraded/âŠ, HA should not provide a persistent âproxyâ theme CSS variables. This is completely up to users to maintain their styles. Sad but true.
We will not move away from Material. So theorically it should continue to work.
But if Material developers change the variables or deprecate the library (like they did for the previous slider), it will break 
Thatâs why we donât officially support it.
1 Like
This is my automation:
alias: Peter supermarkt
description: Peter supermarkt
trigger:
- platform: zone
entity_id: person.mobiel_peter
zone: zone.aldi
event: enter
- platform: zone
entity_id: person.mobiel_peter
zone: zone.jumbo
event: enter
condition: []
action:
- service: notify.mobile_app_sm_g781b
data:
message: >-
There {% if states('todo.boodschappen') | int < 2 %} is{%else%}
are{%endif%} {{ states('todo.boodschappen')}} {% if
states('todo.boodschappen') | int < 2 %} product{%else%}
producten{%endif%} left on the grocery list.
title: Peter is at the supermarket
data:
actions:
- action: URI
title: Open grocery list
uri: /lovelace/boodschappen
mode: single
2 Likes
I didnât ask for creating a proxy for any library thing at all, I asked to make theming more robustâŠ
Proxy for library? I wrote âproxy for CSS varsâ.
correct, I edited my post.
What I was saying is, please HA, provide the user with a stable/robust way of theming, that wonât break continuously.
Theming is a core HA provided technique to customize our frontends, so making that robust is high on the wishlistâŠ
1 Like
Assume there is some (material or whatever) control (slider or whatever).
The control consists of X elements; there are Y vars to style it - var_1 ⊠var_Y.
When I said âproxy for CSS varsâ - here is what I meant:
HA could have proxy vars (and maintain them):
persistent_var_1 = var_1
âŠ
persistent_var_Y = var_Y
And a user uses these proxy vars - and does not depend on the actual vars.
But one day number of var_1 ⊠var_Y may change - and also a purpose of these vars may change, and a structure of the control may change.
So - the realistic way is NOT to officially expose the controlâs vars to a user. It is up to the user to maintain his styling.
edit:
i need multiple restarts after (almost every) HA update to have it running all normal again. is this normal?
yes, you describe the way it is currently done. Not the ideal situation going forward though. Nor a very mature one.
My point is this is rather sub-optimal.
We should not try to describe the solution ourselves (frontend devâs are proâs and way more capable than we are to think of a robust way to improve this) but leave it to the proâs.
remember the state-color issue? It was fixed because dev team heard the communities needs and frustrations of eternal changes, implemented a new way for theme variables, and now itâs working perfectly.
If something internal is changed, it wont hurt the frontend of thousands of users, because it is handled in the frontend itself, and the user can be agnostic to those internal changes.
I would hope something like that could be implemented for the theming variables used in HA Frontend. (this release the sliders, what is it going to be in the next).
Expose generic elements to the user so these can be used in themes, but handle changes in whatever library/ccs/element/etc behind those away from the end-user.
2 Likes
What exactly does not work after an update but works after multiple restarts? Never had such issues and it doesnât sound logical as the update already implies a restart of HA
1 Like