Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error when trying to write Generic Thermostat data to InfluxDB #3789

Closed
paul-creates opened this issue Oct 10, 2016 · 6 comments
Closed

Error when trying to write Generic Thermostat data to InfluxDB #3789

paul-creates opened this issue Oct 10, 2016 · 6 comments

Comments

@paul-creates
Copy link

Home Assistant release (hass --version):
Running in local development mode at SHA1: c9a8832
0.30.1

Python release (python3 --version):
Python 3.4.2

InfluxDB version

$ influx -version
InfluxDB shell 0.9.6.1

Component/platform:
InfluxDB and Generic Thermostat

Description of problem:
InfluxDB is unable to write events for the generic thermostat.

Problem-relevant configuration.yaml entries and steps to reproduce:

influxdb:

climate:
  - platform: generic_thermostat
    name: custom_thermostat
    heater: switch.aeotec_zw096_smart_switch_6_switch_2
    target_sensor: sensor.aeotec_zw100_multisensor_6_temperature_3
    target_temp: 60
    min_temp: 60
    max_temp: 80

Traceback (if applicable):

Oct 10 04:46:09 raspberrypi hass[5043]: ERROR:homeassistant.components.influxdb:Error saving event "[{'fields': {'temperature': 60.0, 'max_temp': 80.0, 'friendly_name': 'custom_thermostat', 'min_temp': 60.0, 'current_temperature': None, 'operation_list': None, 'value': 'idle', 'operation_mode': 'idle'}, 'tags': {'entity_id': 'custom_thermostat', 'domain': 'climate'}, 'measurement': '°F', 'time': datetime.datetime(2016, 10, 10, 4, 46, 9, 237136, tzinfo=<UTC>)}]" to InfluxDB
Oct 10 04:46:09 raspberrypi hass[5043]: Traceback (most recent call last):
Oct 10 04:46:09 raspberrypi hass[5043]: File "/home/pi/home-assistant/homeassistant/components/influxdb.py", line 123, in influx_event_listener
Oct 10 04:46:09 raspberrypi hass[5043]: influx.write_points(json_body)
Oct 10 04:46:09 raspberrypi hass[5043]: File "/usr/local/lib/python3.4/dist-packages/influxdb/client.py", line 402, in write_points
Oct 10 04:46:09 raspberrypi hass[5043]: tags=tags)
Oct 10 04:46:09 raspberrypi hass[5043]: File "/usr/local/lib/python3.4/dist-packages/influxdb/client.py", line 447, in _write_points
Oct 10 04:46:09 raspberrypi hass[5043]: expected_response_code=204
Oct 10 04:46:09 raspberrypi hass[5043]: File "/usr/local/lib/python3.4/dist-packages/influxdb/client.py", line 289, in write
Oct 10 04:46:09 raspberrypi hass[5043]: headers=headers
Oct 10 04:46:09 raspberrypi hass[5043]: File "/usr/local/lib/python3.4/dist-packages/influxdb/client.py", line 259, in request
Oct 10 04:46:09 raspberrypi hass[5043]: raise InfluxDBClientError(response.content, response.status_code)
Oct 10 04:46:09 raspberrypi hass[5043]: influxdb.exceptions.InfluxDBClientError: 400: {"error":"write failed: field type conflict: input field \"value\" on measurement \"°F\" is type string, already exists as type float"}

I believe this is happening because in Influx DB, it tries to convert the state to a number HERE, if it is unable to, it will directly assign the state. In this case, the state is 'idle'. This is then unable to be written to the measurement °F because it's a string, not a float.

@lwis
Copy link
Member

lwis commented Oct 10, 2016

This is a tricky one, what should the value for 'idle' be? Or should it just be discarded as an invalid measurement?

@paul-creates
Copy link
Author

Yeah, this is tricky. The thermostat is actually a collection of different values. It looks like it's trying to write all of them as one event to InfluxDB for the °F measurement. If that was the desired behavior, then in may make more sense in this case to report the "current temperature" or the "desired temperature" instead of the state. The state is also present in the "operation_mode" field, so there wouldn't be any loss of information.

I'm not sure how other climate devices report data, not sure if they would have similar issues, or if this is unique to the generic thermostat.

Another perspective is that for the generic thermostat, the current temperature and the state of the controlled switch are derivatives of other elements, and so they don't need to be reported by generic thermostat at all. I believe the primary relevant information from the generic thermostat is it's current state, and the user set desired temperature.

Yet another perspective is that the generic thermostat, and probably other thermostats too, are a collection of different sensors and control logic and should not all be aggregated into one event in InfluxDB. I can imagine one event for the thermometer component, one for the switch component, and one for the control logic (or maybe two for the control logic, one for desired temp, one for current state).

I don't know enough yet about the system design for home assistant as a whole to know what is the ideal solution, just throwing out some ideas =)

@fabaff
Copy link
Member

fabaff commented Oct 18, 2016

Similar to #2412

@MaKin211
Copy link

I've seen that but nothing seems to have happened since then. :(

@jasonmhite
Copy link

jasonmhite commented Dec 19, 2016

Same. There's always been type parsing conflicts with the InfluxDB component for me. It's not just with less common components like generic_thermostat, I also get it with the sun component:

Dec 19 15:29:30 raspi hass[27852]: influxdb.exceptions.InfluxDBClientError: 400: {"error":"field type conflict: input field \"azimuth\" on measurement \"sun.sun\" is type float64, already exists as type integer"}

This seems like a much more fundamental issue not consistently parsing fields to feed to Influx. The Influx component has never worked for me and I have been checking every now and then since it came out. I can't imagine the folks working on it overlooked something so obviously broken, so I think it's got to be an issue specific to certain setups. Any thoughts on what to look for to narrow it down?

@titilambert
Copy link
Contributor

titilambert commented Feb 24, 2017

This issue should be some by #5238
I think you can close it

@lwis lwis closed this as completed Feb 24, 2017
@home-assistant home-assistant locked and limited conversation to collaborators Jun 2, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants