Dear @Geraldine and @lorenzo,
we just found a minor issue with the data submission from one of your nodes, where the problem is probably at least partly on the backend side.
Have a look for yourself
You can also see it when subscribing to your error channels (following Fehlersignalisierung bei Datenakquise (Backend) and MQTT error signalling - Kotori DAQ) like:
mosquitto_sub -h swarm.hiveeyes.org -p 1883 -t 'hiveeyes/+/lema-bkr/+/error.json' -v
One of the error messages is:
hiveeyes/57eaf23a-968f-4740-b747-137e3ab00580/lema-bkr/node-5/error.json {
"timestamp": "2018-05-31T13:46:15+00:00",
"message": "400: {\"error\":\"partial write: field type conflict: input field \\\"Humidite\\\" on measurement \\\"lema_bkr_node_5_sensors\\\" is type float, already exists as type string dropped=1\"}\n",
"type": "<class 'influxdb.exceptions.InfluxDBClientError'>",
"description": "Error processing MQTT message \"{\"Humidite\": \"56.20\"}\" from topic \"hiveeyes/57eaf23a-968f-4740-b747-137e3ab00580/lema-bkr/node-5/data.json\"."
}
Don’t panic
This problem is not uncommon, you are not alone with this specific issue - see also:
- Firmware "node-wifi-mqtt" überträgt Sensorwerte als Strings
- Problem with MQTT/JSON transmission using the "node-wifi-mqtt" firmware - #4 by gtuveri
Background
Although InfluxDB does not use an explicit database schema definition, fields keep their data type once having been created implicitly, so the data format of the first data point counts.
In the words of the InfluxDB documentation about Schemaless Design, this means:
InfluxDB is a schemaless database. You can add new measurements, tags, and fields at any time. Note that if you attempt to write data with a different type than previously used (for example, writing a string to a field that previously accepted integers), InfluxDB will reject those data.
In our case, this is currently a String data type for the measurements in question:
> show field keys from lema_bkr_node_5_sensors
fieldKey fieldType
-------- ---------
Humidite string
Subsequent attempts to store measurments in the correct data format (float) to the same database/measurement collection obviously will fail. As our backend system Kotori still does not have adequate feedback or recovery mechanisms in place, this issue requires a manual resolution.
Solution
We have different options to solve this problem.
Abandon the field or collection
You can just use a different field name for storing into the same collection or you can just abandon the collection altogether and use a different channel address for submitting subsequent measurement data. This is a countermeasure everyone can apply when running into this or similar issues.
Fix the database
As the database is not yet accessible from the outside, we would have to go there and fix the data schema of the measurement collection. We will check if this is possible.
With kind regards,
Andreas.