cociweb
(Cociweb)
December 24, 2024, 11:33am
1
Since the new profile settings are introduced years ago the theme mode change service had been broken.
the user profile overrides as light/dark and there is an incorrectly named: ‘auto’ which is a static value by the user session: it’s mode is inherited from the browser(or OS).
please add an additional option in the profile beside the light /dark/browser(OS) select (which is currently the auto) and a real auto which is controlled by automation/service globally (as a plus on user basis.)
We have a stucked conversation on Github since we are not able to decide is it a bug of the core or a bug of the ui which is introduced earlier or it should be a feature request (which is worked earlier…)
opened 08:29PM - 03 Jun 24 UTC
### Checklist
- [X] I have updated to the latest available Home Assistant ver… sion.
- [X] I have cleared the cache of my browser.
- [X] I have tried a different browser to see if it is related to my browser.
- [X] I have tried reproducing the issue in [safe mode](https://www.home-assistant.io/blog/2023/11/01/release-202311/#restarting-into-safe-mode) to rule out problems with unsupported custom resources.
### Describe the issue you are experiencing
```
service: frontend.set_theme
data:
name: default
mode: dark
```
should change current (=default) theme mode to dark, but it doesn't work - nothing happens (it doesn't work neither with mode: light)
Unfortunatelly, in the users's (GUI) profile only auto/light/dark modes are available. The light/dark options are a manual option to forcefully override the ha's default mode of default theme settings. In our case the 'auto' is based on the user's browser/OS settings and does not lies on the control of HA-core. (eg service call for automations)
### Describe the behavior you expected
I would recommend to (re-)introduce/revert a 4th option, (eg the old "backend selected") where the theme mode is based on the ha-core (service call / automations) and not on the users/browser(/OS) preferences. Please note that the above mentioned service call was worked before the redesigned profile layout (years ago).
[off] I don't really know which version, but it was years ago.... I don't think it does matter now...
### Steps to reproduce the issue
1. set the theme to default in the configuration.yaml.
2. set the theme option to any in the user's profile
3. set the opposite mode by a frontend.set_theme service call of the default theme as it is used currently.
...
### What version of Home Assistant Core has the issue?
2020.01.0?
### What was the last working version of Home Assistant Core?
_No response_
### In which browser are you experiencing the issue with?
_No response_
### Which operating system are you using to run this browser?
_No response_
### State of relevant entities
_No response_
### Problem-relevant frontend configuration
_No response_
### Javascript errors shown in your browser console/inspector
_No response_
### Additional information
This ticket is a frontend related successor of https://github.com/home-assistant/core/issues/106040
Also, there are many topics by the community, eg:
- https://community.home-assistant.io/t/scripts-to-load-themes-have-stopped-working/520625/3
- https://community.home-assistant.io/t/frontend-set-theme-with-mode-not-working/518800
- https://community.home-assistant.io/t/change-dark-light-mode-of-default-theme-based-on-automation/516181
- https://community.home-assistant.io/t/set-default-light-dark-lovelace-theme/412486
If this is considered as a 'Let's go' implementation, I would also suggest to rename the misleading 'auto' option something like 'browser/os select' option, since the behavior is not clear enough from it's name.