core: Metrics are stored in InfluxDB with the wrong data type

Home Assistant release with the issue: 0.100.2

Last working Home Assistant release (if known): None

Operating environment (Hass.io/Docker/Windows/etc.): Arch Linux, current with all patches

Integration: InfluxDB, ecobee

Description of problem: The InfluxDB component’s method of choosing data types for metric storage is flawed. It incorrectly stores values as strings instead of floats. An example of this can be found with the ecobee integration. Temperature and fan metrics are stored as strings (e.g. fan_str) and thus, they cannot be graphed in Grafana, nor can we do any downsampling or roll-ups.

This bug was reported as part of another issue a few years back: https://github.com/home-assistant/home-assistant/issues/5575

That other issue was never fixed and the bug that it reports (garbage measurements being stored) still exists.

To fix this, the InfluxDB integration could be smarter when determining data types (e.g. “Does it look like a float?”). Alternatively, a user could provide a map that ties metrics to a user-specified type.

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

influxdb:
  host: 127.0.0.1
  username: blah
  password: blah
  database: homeassistant

Traceback (if applicable):

Additional information:

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 15 (1 by maintainers)

Most upvoted comments

An option for influx to store the measurements always with the entity as name would be great. Because a large number of measurements under % or C is confusing.

goggel on Feb 11, 2020

So I did some digging into this issue and the one that @vvuk reported in https://github.com/home-assistant/home-assistant/issues/5575 …

The problem is that the InfluxDB integration uses the unit of measurement as the measurement name in some circumstances.. I believe that this is not the right behavior. A unit should never be the name of the measurement. I think that it’s better to use the entity_id.

As a work-around, you can override the name of the measurement in the influxdb configuration section like this:

influxdb:
  component_config:
    sensor.aeon_labs_zw095_home_energy_meter_gen5_previous_reading:
      override_measurement: sensor.aeon_labs_zw095_home_energy_meter_gen5
    sensor.aeon_labs_zw095_home_energy_meter_gen5_previous_reading_2:
      override_measurement: sensor.aeon_labs_zw095_home_energy_meter_gen5
    sensor.aeon_labs_zw095_home_energy_meter_gen5_previous_reading_3:
      override_measurement: sensor.aeon_labs_zw095_home_energy_meter_gen5

You can see that I am forcing a bunch of entities to all be inserted under the same measurement. The entity_ids are applied as a tag, making it easy to SELECT only data from a particular entity.

This is super tedious, however, because you have to do this for most of your devices and do a lot of DB exploration by hand. I will see about proposing a PR to correct this bad logic.

chrissnell-okta on Nov 13, 2019

Please keep open.

chrissnell-okta on May 13, 2020

An option for influx to store the measurements always with the entity as name would be great. Because a large number of measurements under % or C is confusing.

There is enough confusion and seems to be preferences around this, that an option should both be simple and easy. Is there any disagreement on just adding an option for this to influxdb config?

vvuk on Aug 18, 2020