only issue left here is the grey not_home color, we can not adjust. the badge-person-not-home-color doesnt apply obviously, so please remember the request for the addition of state-person-not-home-color var:
Question on the new local calendar:
Can the entries be created using yaml?
It is not mentioned in the docs. I wonât be using it via the dashboard but it would be a useful helper/input_helper. But only if it can be defined via yaml as yaml is much faster than the UI currently is.
Basically instead of an input_text use input_calendar with name, date and frequency.
the colors might be valid for the badges on the tile card
though it is confusing to see the Library heater show the color of the bigger icon to be heating while in fact it is not. Maybe thats an integration thing, it does after all state âVerwarmenâ as Programmed, but that is not the actual stateâŚ
HA core thermostat card does not use the state color vars? That would be an issue probably.
I completely agree with you. At first, âlocal calendarâ made me think of a standalone home assistant calendar, where you could add,edit,delete events. And, even more, use that calendar outside of HA.
Now, I created a local calendar. and then⌠nothing. Finally, I found it in when accessing the âcalendarâ menuitem at the left side of the page. I was added as one of the âcalendarsâ in the âcalender viewâ.
Create, edit? Nothing. Just delete the calendar event.
So, itâs actually a helper. But, even most helpers can be edited.
For now, I use google calendar. This way, I can add events as i like. Start automations based on events of that google calendar. Itâs more capable than âlocal calendarâ. At the moment, âlocal calendarâ adds nothing to HA. Hopefully, itâs just a start, and many more options become available. But, like it is now, I see no reason to use it.
as a result for me was that zha - zigbee could not be loaded. then I reinstalled 2022.11.5 and I got this
WARNING: Error parsing requirements for async-upnp-client: [Errno 2] No such file or directory: '/srv/homeassistant/lib/python3.9/site-packages/async_upnp_client-0.32.2.dist-info/METADATA'
Installing collected packages: aiohttp, httpx, home-assistant-bluetooth, homeassistant
Attempting uninstall: aiohttp
Found existing installation: aiohttp 3.8.3
Uninstalling aiohttp-3.8.3:
Successfully uninstalled aiohttp-3.8.3
Attempting uninstall: httpx
Found existing installation: httpx 0.23.1
Uninstalling httpx-0.23.1:
Successfully uninstalled httpx-0.23.1
Attempting uninstall: home-assistant-bluetooth
Found existing installation: home-assistant-bluetooth 1.8.1
Uninstalling home-assistant-bluetooth-1.8.1:
Successfully uninstalled home-assistant-bluetooth-1.8.1
Attempting uninstall: homeassistant
Found existing installation: homeassistant 2022.12.1
Uninstalling homeassistant-2022.12.1:
Successfully uninstalled homeassistant-2022.12.1
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
music-assistant 1.8.7 requires pillow<=9.2.0,>=8.0, but you have pillow 9.3.0 which is incompatible.
aiogithubapi 22.3.1 requires backoff<2.0.0,>=1.10.0, but you have backoff 2.2.1 which is incompatible.
Successfully installed aiohttp-3.8.1 home-assistant-bluetooth-1.6.0 homeassistant-2022.11.5 httpx-0.23.0
2022-12-09 10:21:41.426 WARNING (MainThread) [homeassistant.components.zha.core.channels.base] [0xA314:1:0x0008]: async_initialize: all attempts have failed: [TimeoutError(), TimeoutError(), TimeoutError(), TimeoutError()]
2022-12-09 10:21:41.508 WARNING (MainThread) [homeassistant.components.zha.core.channels.base] [0xA314:1:0x0300]: async_initialize: all attempts have failed: [TimeoutError(), TimeoutError(), TimeoutError(), TimeoutError()]
2022-12-09 10:21:41.917 WARNING (MainThread) [homeassistant.components.zha.core.channels.base] [0xA314:1:0x0006]: async_initialize: all attempts have failed: [TimeoutError(), TimeoutError(), TimeoutError(), TimeoutError()]
2022-12-09 10:21:42.072 WARNING (MainThread) [homeassistant.components.zha.core.channels.base] [0xDB97:1:0x0006]: async_initialize: all attempts have failed: [DeliveryError('Request failed after 5 attempts: <Status.MAC_NO_ACK: 233>'), DeliveryError('Request failed after 5 attempts: <Status.MAC_NO_ACK: 233>'), DeliveryError('Request failed after 5 attempts: <Status.MAC_NO_ACK: 233>'), DeliveryError('Request failed after 5 attempts: <Status.MAC_NO_ACK: 233>')]
so after going back to 2022.11.5 still no zigbee anymore. and back to 2022.11.4 resolved itâŚ
thatâs what I mentioned already ⌠it seems that the HA dev team will go for a User-interface that we all know from other smarthome appsâŚ
Just look how similar it looks compared for example to the Amazon Alexa app - or even the Hue app.
While I beleive, that âmushroomâ look - or at least the UI design they want to reach - can be a good one for a smartphone app where you have little space - and your focus will probably be on tap actions to turn a light on, etc. - the new design will loose a lot of its power of displaying information around your smart home.
I would say - 90% of my Dashboards have the purpose of displaying information - rather than switching things on and offâŚ
And IF HomeAssistant will continue with this design path - I will probably search for another solution ⌠OR itâs time for a Fork of HomeAssistant.
@Core-Devs & @Frontent-Devs:
Donât get me wrong⌠I can see some benefit for the new UI designs. But please: Consider this as an additional option that Users can use.
Provide them the tools to create a Mushroom like Dashboard if they WANT to do so⌠but please do not limit those that donât want to use this kind of dashboardâŚ
There is already a helper called âScheduleâ so that is of course not an option Plus a schedule and a calendar are logically not the same thing, so that name would anyway be wrong for the local calendarâŚsince it is a calendar, not just a weekly schedule.
I use the custom:scheduler-card for scheduling my lights, thermostats (including TRVs) etc. This provides a very easy to use and understand interface. Iâm quite a âtechieâ but my wife certainly isnât. She can easily see and change things if she wants.
(I used to use node red and big timer for my schedules but realised that meant realistically only I could make changes. So I looked for something more generally easy to use.
Having adjusted most of the new colors to my own themes (only left are the person.not_home in graphs which seems to be hard coded? and the strange colors on the stock Thermostate card), I realize we now have to set state_color: true on all cards, to use those new colorsâŚ
Seems a bit odd to have all this work done, and then not show that by default. Wouldnât it therefor be logical to change that to default too? have those state colors show by default, and, if a users wouldnât want tp do so for any reason, let the state_color: false be the exception to set in the card config?
Its al the more confusing to see an entity not be colorized in the frontend card, but get the correct color on the more-info panel in that same card.
maybe, a further feature request:
The ability to set the âshow state colorâ per entity, rather than per card?
This would allow to set only the state color to those entities, where a Color might be usefull (battery, person, thermostat, etc) - and other entities in the same card would not use ANY coloring?
How to make graphs to gradient from 3 shades of blue to white like it was always
instead of current 3 shades of blues to black right now? Both on light and dark default themes or custom themes itâs black.