[34.5] influxdb issue

Configuration
1

Hi,

After an upgrade from HA 32 to 34.5, I have some influxdb problems.
" is type float64, already exists as type integer"
And then, no more measure was writed in my db…
Is anyone knows this problem?

Thanks

2

I was having the same issue. Looks like they changed some of the data formatting. I ended up just dropping my entire HA database in influx and starting over. Works fine now.

3

Same for me. Integer values changed to Floats (e.g. “5” became “5.0”). Don’t know if intentional or due to a bug.
I dropped all my past measurements and let them be recreated with the correct type.
No problem so far.

I don’t know much about influxdb; maybe there would have been a way to convert the existing data to a new type.

Sebastian

4

Thanks guys…
It’s really bad to suppress all my history…
If anyone has some better issue?

5

How can you dropped influxdb datas?

6

If you have a lot of valued history data, you might want to check if there’s a way to convert it.
I had only a few weeks of experimental stuff, so dropping it and starting with a clean DB didn’t hurt.

That said, to drop the measurement data, you can go to your influxdb admin interface: http://<your ip>:8083/.
In the upper left corner, select your home_assistant database.
Do a SHOW MEASUREMENTS to list the available measurements.
Do a DROP MEASUREMENT 'xyz' to drop the “xyz” measurements.

It should be sufficient to ony drop the measurements where the data type has changed, i.e. where you get the errors from hass.

If you want to drop everything, you could just do a DROP DATABASE home_assistant and recreate it with CREATE DATABASE home_assistant.
Restarting home-assistant afterwards seems like a good idea.

Sebastian

1 Like
7

Thanks,
It works better now.

8

I seem to have a related issue. I’ve set up h-a for some homegear thermostats, and pushing data to an influxdb (to later visualise with grafana).

Everything works fine for a couple of days, but suddenly and without apparent reason no more data is pushed to influx, and I start seeing

16-12-12 21:37:48 homeassistant.components.influxdb: Error saving event “[{‘time’: datetime.datetime(2016, 12, 12, 21, 37, 48, 7362, tzinfo=), ‘tags’: {‘domain’: ‘climate’, ‘entity_id’: ‘heizung_oben’}, ‘fields’: {‘max_temp’: 30.5, ‘value’: ‘auto’, ‘operation_mode’: ‘auto’, ‘Valve’: 6.0, ‘current_temperature’: 22.5, ‘ID’: ‘NEQ1230731’, ‘friendly_name’: ‘“Heizung Oben”’, ‘RSSI’: -59.0, ‘proxy’: ‘wireless’, ‘Battery’: 3.1, ‘min_temp’: 4.5, ‘temperature’: 21.0, ‘Mode’: ‘Auto’}, ‘measurement’: ‘°C’}]” to InfluxDB
Traceback (most recent call last):
File “/srv/homeassistant/homeassistant_venv/lib/python3.4/site-packages/homeassistant/components/influxdb.py”, line 141, in influx_event_listener
influx.write_points(json_body)
File “/home/homeassistant/.homeassistant/deps/influxdb/client.py”, line 402, in write_points
tags=tags)
File “/home/homeassistant/.homeassistant/deps/influxdb/client.py”, line 447, in _write_points
expected_response_code=204
File “/home/homeassistant/.homeassistant/deps/influxdb/client.py”, line 289, in write
headers=headers
File “/home/homeassistant/.homeassistant/deps/influxdb/client.py”, line 259, in request
raise InfluxDBClientError(response.content, response.status_code)
influxdb.exceptions.InfluxDBClientError: 400: {“error”:“field type conflict: input field "value" on measurement "°C" is type string, already exists as type float”}

Since this occurred twice now with no apparent reason, I’m a bit reluctant to just drop the DB again, and would rather hope to find a more permanent fix. Anyone have ideas what’s going on here? Thanks!

9

Look at the error message at the end: it’s talking about a field named “value” for a measurement “°C” having type string instead of float (i.e. a “word” instead of a “number”).
So looking at the error befor the trace, you’ll find this:

Error saving event "[{'time': datetime.datetime(2016, 12, 12, 21, 37, 48, 7362, tzinfo=), 'tags': {'domain': 'climate', 'entity_id': 'heizung_oben'}, 'fields': {'max_temp': 30.5, 'value': 'auto', 'operation_mode': 'auto', 'Valve': 6.0, 'current_temperature': 22.5, 'ID': 'NEQ1230731', 'friendly_name': '"Heizung Oben"', 'RSSI': -59.0, 'proxy': 'wireless', 'Battery': 3.1, 'min_temp': 4.5, 'temperature': 21.0, 'Mode': 'Auto'}, 'measurement': '°C'}]"

at about the middle, there’s the field list:

'fields': {'max_temp': 30.5, 'value': 'auto', 'operation_mode': 'auto',...

So there we find a field named “value” which has a value of “auto”.
Now, “auto” is a string and that’s what InfluxDB is complaining about.
If I had to take a wild guess, this “value” can be set to other value which are (floating point) numbers.
So this won’t work with InfluxDB when the data types change.

You’d either have to make sure that the value of “value” never changes between string and float or you have to exclude this field from being sent to InfluxDB.
If you’re only interested in the temperature values, you could create some template sensors that only expose the values you need and push those to InfluxDB.

Sebastian

10

template sensor sounds like an interesting idea, I’ll look into that. thanks!

11

Yeah, it’s pretty easy - I do it like this with the target temperature of my thermostats:

platform: template
sensors:
  target_temp_livingroom:
    value_template: '{{ states.climate.danfoss_z_thermostat_014g0013_heating_1_4_1.attributes.temperature }}
    friendly_name: 'Thermostat Temperatur Wohnzimmer'
    unit_of_measurement: '<C2><B0>C'
    entity_id: climate.danfoss_z_thermostat_014g0013_heating_1_4_1

Well - not quite. Since this causes a warning message about “attributes” being undefined (which you can safely ignore) at the start of HA, I’m actually using a template like this:

value_template: '{% if states.climate.danfoss_z_thermostat_014g0013_heating_1_4_1 %}{{ states.climate.danfoss_z_thermostat_014g0013_heating_1_4_1.attributes.temperature }}{% else %}0{% endif %}'

But I wouldn’t want to scare you off with the first example :wink:

Sebastian

12

So I understand the underlying problem now, I think, maybe you have some good ideas about that as well:

  • I have these thermostats, they have unit_of_measurement as ‘°C’ and a field called ‘value’, which is a string
  • I also have a yr sensor configured for weather information, which happens to also use unit_of_measurent °C, also has a field called ‘value’, but this one is a float…

Now apparently hass decided to always store this data in a ‘measurement’ in influx lingo (sort of a table) that is given by unit_of_measurement of the entity we’re looking at, and only uses entity_id as the measurement/table in influx if no unit_of_measurement is defined for the entity. okay, that sentence is confusing, but I hope you see what I’m trying to say.

Now I’m not very happy about storing this stuff in influx in a ‘°C’ measurement/table in the first place, and clearly it can lead to ugly collisions. I’d much rather have a ‘thermostat’ table for the thermostats, and maybe a ‘weather’ table for the weather information. Do you know if there’s some way to do that?
[I realise I could probably achieve that with the template sensors, just wondering if there’s any easy way to configure this for e.g. all attributes of an entity at once in either the entity or the influx section of the config]

13

I also would have liked naming the measurements after the entity names, for example.
However, as I understand it, it was chosen deliberately to use the unit_of_measurement instead (if available).
See this for some insight and a way to change it:

That said, I don’t see a reason to have the temperature values as strings - so maybe it’s a bug with the component you’re using for your thermostats.
Though, from your example above, the value of value was “auto” (for whatever reason), so it needs to be a string.
With a template sensor, you can cast the value to a specific type, like this:

{{ states.climate.mythermostat.attributes.value | float }}

“auto” as a float should be 0.0.

Sebastian