Hi all,
In case someone is using downloader setup on configuration.yaml, and most probably are having a hard time trying to set the downloader integration in the UI, always getting back the “unknown error” message:
Just take note of the dir you are currently using in the yaml file, delete those lines pertaining to downloader, save, restart, and now you’ll be able to setup the same dir in the UI without any issues.
At least it worked for me.
Dear friends, with netatmo station weather I loss all main sensors after reboot or restart h.a.: Main temperature, Main CO2, Main preassure, Main noise and main humidity. The external sensor and the secondary sensors works fine. Only main sensor problem, ( 5 not available sensors ) .
The sensors have appeared again after waiting 5 minutes after starting up. Indeed, first all the secondary sensors and the external one appear and around 5 minutes later the 5 main sensors appear
Hyper excited for the release. Great work from the team, it’s amazing and I’d love 2024 to be “Year of the UX”, as it’s going sooo great so far.
I’ve started playing around with labels a bit and I’m really curious how others are approaching it. Especially I have detected a potential conflict with “label all the things” philosophy.
Since labels are great to use as targets, they make a ton of sense to be used on Entities.
However, if you use the same labels as a categorization tool on devices, helpers, automations and scripts, what will happen when using the label as target? It will prob make everything run, which is rarely desired.
Which brings me to the conclusion to either use separate types of labels for each type of element (which would bring us back to labels being named [Auto] Lights, [Script] Lights, etc) or alternatively (and I think better) just stick to labels for Entities, and use exclusively Categories for everything else.
What do you guys think?
It seems that only Homematic climate devices are missing.
Labels:
In some limited extent this functionality was (and still is) available before 2024.4:
selectattr('attributes.label','defined') | selectattr('attributes.label','eq','xmas')”.(also, these string labels occupied space in “attributes_id” DB table).
I was hoping that Labels would provide a shortcut to be able to easily bring up “all things of the same type” in a History graph.
For example, I’ve given all my Sensor batteries the same label, and if I go into the History view and just select that label, I get nothing displayed. So I suppose it’s acting just as a filter, rather than a source ? That’s a little bit unclear from the UI at least.
It looks like its fixed in 2024.4.1
Thank you for the info.
I just switched to the custom_homematic integration.
It makes a lot of things easier.
On the other hand, If one look at it “the other way around”
You “mark/group” i.e devices/automations etc. with “A Label” The label can be Area/Zone/ & now “Label”, which make “Label” kind of versatile , because you can use it for what ever purpose you find suitable, to Group Devices etc. "
Labels is an organizational structure that is completely up to you.
I can come up with dozen of “Labels” which in fact are Location/Grouping
Ceiling ( Individual rooms, or All ), Door locks/sensors(widely spread, thou grouped ), Left / Right. Etc.
It’s not an issue. All things users can name act like this. Devices (device_id), Areas (area_id), Entity (entity_id), and now Labels (label_id). I’m not sure why this is now a problem for you. Without an ID in the background, it can’t be linked to other items. Otherwise if you change the name, the link would break. Then you’d be here saying “I labeled everything, changed the name, and how I have to relabel everything!”.
Heck, there’s a long standing Feature Requests and Month of "What the heck?!" about renaming entity_id’s auto updating in automations. You want this to also be a problem with labels too?
There’s a bug in the current version with floors & labels in the history tab. Expected fix is for 2024.4.1.
I am using it, and it is working properly.
I have nothing against this way.
BTW, some people give human names for a furniture, carpets, not to mention cars. So, we can create a “person” entity for a lovely carpet with a virtual “device_tracker” which is always “home”, so warming…
But I think that “labels” are much more than just a “location” - so it should be reflected in the menu.
I don’t see why you don’t get this.
the id is used as unique_id now, and is not comparable to the entity_id of an entity for example. (which is not tied to the entity_id. change the entity_id, the unique_id remains the same. we can not do that with the Floor/Area/Label without running into trouble with our templates)
I dont want anything to be a problem, just trying to explain the experience we now get when we have second thoughts about a Floor/Area/Label name (and want to use those in our templates)
As it stands, the only real solution is to create a new Floor/Area/Label, move what you had before to the new, and delete the old.
Is there a reason why my Home Assistant VM since an update to the latest version (2024.4.0) suddenly started to ask my DNS for all PTR (local network) records?
What trouble?
of not being able to use the new/changed name in the templates, see 2024.4: Organize all the things! - #120 by Mariusthvdb
…
label_name(label_id)
exactly like area and device.
Show me a template and I’ll show you what you should do.