The InfluxDB integration can surface attribute information as tags, but there’s no way to my knowledge to do the same thing for labels/devices/areas associated with the entity. WTH?
It kind of is already and they’re easily accessible through templates
Areas, labels, states, all there.
But you’d need to hardcode the labels themselves, yes? Like, if I add 10 new labels, I’d need to go through and write templates to pass each label through if I wanted to have them accessible in InfluxDB.
What I’m talking about is being able to do something like this:
influxdb:
api_version: 2
ssl: false
host: HOST_NAME
port: PORT_ID
token: SECRET_TOKEN
organization: ORGANIZATION_ID
bucket: BUCKET_NAME
tags:
source: HA
tags_attributes:
- friendly_name
- labels
- area
- device_name
I’m using InfluxDB as the example here, but there are other usecases (e.g. filtering inside of developer tools).
Right now, AFAIK you can’t do this - at least not easily! Because it seems very difficult to get this information from the entity itself, which is very much a WTH moment for me.
You’re going to have to write something in somewhere because that’s a third party config and our of scope for what HA provides… Labels exist, areas exist, all the things exist it’s up to influx in this case to handle it. HAs job is done.
And as mentioned, there are other use cases that aren’t covered (e.g. being able to filter within Developer Tools → States). That is also very much a core HA thing.
“HA’s job” is not done to solve this WTH. I don’t see why there’s belligerency over “can we add these common attributes as attributes”.
At the VERY least it indicates that there is lacking documentation on the matter.
Because there is a dev architecture decision (will have to hunt the post maybe one of the mods can help) that basically says HA over time is getting away from attributes. They’re hard for end users. So that’s the first hurdle. (notice integrations create a LOT more entities for a device lately?)
Second sure it’s a core integration but the point still stands. All that data is already there. For influx all they need to do is - use it. Whether it’s core or custom it still is up to the dev that owns Influx as ha already provided the plumbing for what you ask.
For use in the UI. Use templates for sensors, templates. For any integration they can pull from the state engine directly.
What it seems you’re asking is just a shortcut to make it easier for influx to ingest the tags and for that that’s more - WTH why does the influx integration not ingest labels and areas natively
Ah, that’s my core misunderstanding.
As a techy person, seeing that is disappointing (attributes and metadata are useful!), but I understand since it fits HASS’s post-pandemic pattern of making things more difficult for tinkerers in order to appease folks without tech backgrounds (see also: moving everything out of YAML, often times without a 1:1 replacement for advanced functions).
But despite my griping, I do get it (and agree there’s been a lot of good that came out of it). I suppose it’s worth renaming the topic.
I’m not for all the attributes going away btw I think metadata is amazing. The more the merrier. But I can also see where all the creators did trend to stuffing everything in an attribute so now there are a lot of entities overloaded with attributes that could be entities themselve - and easier for users to manipulate…
My point is yeah the data is great but let the integration handle it and if the integration handles it poorly, flame on!