Core: Influxdb measurement created with the unit name instead of entity_id

[martin3000]

When "unit_of_measurement" attribute is set for sensor then the influxdb measurement is created with the name taken from "unit_of_measurement" attribute instead of entity_id.
This causes that measurements like "€" are created in influxdb.
As a consequence all the sensors with a common unit are stored under the same measurement in influxdb. I.e. all sensors with the unit "€" are written to the same table.
This is a misunderstanding of the statistical term "measurement". The influxdb documentation states it more clearly:
"Measurement names are strings, and, for any SQL users out there, a measurement is conceptually similar to a table"
(https://docs.influxdata.com/influxdb/v1.7/concepts/key_concepts/#measurement)
A measurement in influxdb is a table with time series. There is no reason to mix potatoes and tomatoes into the same table only because their price is in "€".

The influxdb options default_measurement and override_measurement seem not to solve this.The default_measurement is only taken in account if there is no unit of measurement. And override_measurement puts all values into the same table.

One simple line in influxdb/__init__.py would fix it:
measurement = state.entity_id

[ghost]

Hey there @fabaff, mind taking a look at this issue as its been labeled with a integration (influxdb) you are listed as a codeowner for? Thanks!

_This is a automatic comment generated by codeowners-mention to help ensure issues and pull requests are seen by the right people._

[MartinHjelmare]

We are trying to follow the recommendation to avoid encoding data in measurement names:
https://docs.influxdata.com/influxdb/v1.7/concepts/schema_and_data_layout/#don-t-encode-data-in-measurement-names

[martin3000]

I try to avoid that the % humidity of my fridge is in the same graph as the % space free of my NAS.

[MartinHjelmare]

You can override the measurement name per entity_id, per domain, or use a glob pattern.

https://www.home-assistant.io/components/influxdb/#component_config

The current grouping isn't perfect. This has been discussed before. There's not a simple fix for this problem.

See https://github.com/home-assistant/home-assistant/issues/5575.

[martin3000]

The simple fix is to give the user the possibility to take entity_id as influxdb measurement like I implemented it here in my code version.

[stale[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[martin3000]

To fix this, you can change .local/lib/python3.7/site-packages/homeassistant/components/influxdb/__init__.py line 175:

    include_uom = True
    #measurement = component_config.get(state.entity_id).get(
    #    CONF_OVERRIDE_MEASUREMENT)
    measurement = state.entity_id

[dedors]

Is this really the only fix I can do? From my point of view, there is no use ever to have the unit of measurement instead of the entitiy name for the measurement name.
If I change some python file, I'll never know when it gets overwritten by a update.

[jjsapido]

I'm facing the very same problem.. especially frustrating since CONTINUOUS QUERY require an explicit definition of the field they are computed on.
It seems not really a solution to manually patch core files, which will be updated for sure before or after.
What about a yaml extra option config to just override any current naming approach and simply store values on timeseries named according to their entity id?

According to this idea also the current grouping of fields in a single entity could be avoided.
i.e. a climate.nest device currently grouping max_temp, min_temp, temperature, value (which is probably the current state on/off) could be standardized as a set of timeseries named
climate.nest.max_temp with a generic value field
according to <overall_entity>.<field>

That would make pretty much easier to access timeseries data programmatically and perform automated continuous queries
Thanks

[martin3000]

MartinHjelmare does not want changes here so people have to patch it for themselves.
The patch is very simple.

[jjsapido]

I read it but I don't really like to have core file patched, I mostly rely on docker containers and have not core libs in persistent storage volumes. What about implementing patched version as a custom_component? Did you try or have any insight about it?

Tbh I was just wondering if something simple like 1 entity value - 1 measurement can be implemented in some more structured way.
No cluster, no units, No tags, no series_dependent fields, no hassle, just a single general "value" field for every time serie, with a serie provided by every single hass entity field.

Also wondering if opening a new issue may help.
Thanks for your support :)

[martin3000]

I have no idea how custom components work.

[javier-fg]

Having same issue here :(

It will be very much appreciated if the author add the possibility to implement the patch of @martin3000 via add-on configuration parameters.

Using hassio and the docker images makes manual patching not an easy task.

[martin3000]

To fix this, you can change
.local/lib/python3.8/site-packages/homeassistant/components/influxdb/__init__.py line 210