A lot of integrations have been removed from default_config and added to the core bootstrap. So they are always loaded, even if you don’t include default_config
Examples are the input_* integrations, they are no longer in default_config but they are always loaded for everyone.
1 Like
Soon 
Current way:
{% set ns = namespace(floors=[]) %}
{% for floor in floors() %}
{% set ns2 = namespace(areas=[]) %}
{% for area in floor_areas(floor) %}
{% set ns2.areas = ns2.areas + [area_entities(area)] %}
{% endfor %}
{% set ns.floors = ns.floors + [(floor, ns2.areas | sum(start=[]))] %}
{% endfor %}
{{ dict.from_keys(ns.floors) }}
I don’t believe there is a PR for this yet.
Also Soon
There are ways to do it, but the templates aren’t easy at the moment. These both are things that were found in beta but did not make the release cut.
EDIT: This made the cut.
{{ labels("light.christmas_tree") }} # ['christmas_decorations']
4 Likes
Same here. I don’t see the functionality taking effect.
Right now it’s only for the more-info dialog. There is a PR open for a Tile card feature.
1 Like
Same here, all homematic (wand-)thermostats are missing
Logger: homeassistant.components.climate
Quelle: helpers/entity_platform.py:787
Integration: Klima ([Dokumentation](https://www.home-assistant.io/integrations/climate), [Probleme](https://github.com/home-assistant/core/issues?q=is%3Aissue+is%3Aopen+label%3A%22integration%3A+climate%22))
Erstmals aufgetreten: 18:29:37 (13 Vorkommnisse)
Zuletzt protokolliert: 18:29:37
Error adding entity None for domain climate with platform homematic
Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 787, in _async_add_entity capabilities=entity.capability_attributes, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 328, in __getattribute__ return super().__getattribute__(__name) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 501, in capability_attributes data[ATTR_PRESET_MODES] = self.preset_modes ^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 328, in __getattribute__ return super().__getattribute__(__name) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/homematic/climate.py", line 116, in preset_modes return [HM_PRESET_MAP[mode] for mode in self._hmdevice.ACTIONNODE] ~~~~~~~~~~~~~^^^^^^ KeyError: 'AUTO_MODE'
Switched back core to 2024.3.3 and homematic works fine.
Actually you don’t see it, which is a shame.
Let me say it would be a nice and much appreciated improvement to be able to check/read the set value. I’ll post that improvement request soon.
In order to set it you have to go to the integrations screen, and click ADD ENTRY:
Write down the path there, relative to your config dir.
That’s it.
If you try to add another dir, it will complain:
The problem is, as mentioned at the top, after setting it there is nothing in this screen showing what you have set, and that’s a big bummer!
1 Like
Has this scrollbar always been there?
Either it’s new or the width of the menu has been narrower because I can’t remember it being cut off like that.
Looks correct to me, what’s the problem? N → O → P
Make an issue then. Not really the place to bring that up.
correct.
However, if you check the documentation of many integrations that have been moved, there is still this:
To be able to add Helpers via the user interface you should have
default_config:in yourconfiguration.yaml, it should already be there by default unless you removed it. If you removeddefault_config:from your configuration, you must addinput_button:to yourconfiguration.yamlfirst, then you can use the UI.
or
If you removed
default_config:from your configuration, you must addinput_boolean:to yourconfiguration.yamlfirst, then you can use the UI.
at least suggesting those integrations have to do with default_config
or see
This integration is by default enabled, unless you’ve disabled or removed the default_config: line from your configuration. If that is the case, the following example shows you how to enable this integration manually:
# Example configuration.yaml entry system_health:
there are several more that still have that link to default_config in the documentation, while in fact that is no longer the case and they are in bootstrap default_integrations
I am having exactly the same issue and trying a roll-back now
in Sweden yes, but second last in Denmark 
, which brings us to HA, where these letters don’t exist in code or core, and even your UI
Labels have problem with text overflow:
As a wild guess, I’d say it’s caused by the Breaking Change in MQTT lights’ brightness attribute.
1 Like
Petro, didnt you at some point say you’d be leaving old school groups once the labels arrived?
Wondering about that, and if we now have the same functionality, only better
even dynamically created groups, do we still need those with the new organize tools…
eg,
- service: group.set
data:
object_id: media_players_available
name: Media players available
icon: mdi:playlist-play
entities: >
{{state_attr('media_player.broadcast','entity_id')
|select('has_value')|join(',')}}
could probably simply be replaced by adding a label broadcast_player, and then use
{{label_entities('broadcast_player')}}?
I did a few preliminary tests on unavailable players, and dont think I saw an error on setting a volume on that, or even playing to that group those label_entities()
Great update, much need! I’m a bit confused though, why were Categories only written into Automations/Scenes/Helpers and not Devices and Entities pages?
I want to be able to Categorize my Devices and my Entities. The update blog post talked about people using emoji and bracket hacks to organize their table entries, that goes for Devices and Entities too. After the update, the only manually editable grouping method I have is Areas.
This seems like a killer feature to have, why leave it out? Is this something possibly coming in a future update?
2 Likes
It’s always been there, and it’s dependent on both the number of items in your sidebar and the viewport. Mess around with the window size in your browser and you’ll see the scrollbar expand or disappear (if all the items fit).
The width of the menu isn’t narrower either, but some of that width has now been taken up by the scrollbar, hence the cutting-off effect. The other option would have been to take up the dashboard space to accommodate the scrollbar, but that would potentially affect your card layout.
Here’s a picture of mine from an earlier release (2024.3), but I can definitely confirm it’s been that way for ages.
1 Like
I did but I haven’t done the work yet. Just some of the plumbing.
The plan is to
- Add devices to areas
- Add areas to floors
- Add an
alexa_targetlabel - Add a
zwave_multicastlabel - Recreate all entities using these old school groupings but with labels, areas, and floors.
I’ve done 1 and 2, just haven’t done 3 and 4.
I need to think how I’ll add step 4 because there are some multicast settings that need to be sorted out.
The majority of my old school groups for handling what turns on/off via an alexa utterance. I need to separate the entities for zwave multicast to properly call the multicast service in parallel with other multicast services. This is specifically to turn all lights and switches on at the exact same time. It’s a bit complex, but it’s nice to watch when you use it.
Outside that, I have some old school groups that essentially represent areas and floors that I can just flat out delete now. I just have to find all references to those entities and shift to using them in target.
Lastly, I do have some dynamic groups. Frenck mentioned adding service to dynamically add/remove labels from entities with a service. It won’t be added to core, but only to spook. I’m on the fence about shifting to that, so I will most likely use old school groups until there’s a comparable new dynamic group feature.
3 Likes