Feld plötzlich verdoppelt in influx - mit falschem Datentyp

Entwicklung / Development Fehleranalyse / Troubleshooting
1

guten morgen!
neuerdings hab ich hier wieder ein problem. merke es jetzt erst. der datenfluss ist aber schon vor einigen tagen versiegt:

gr

das script, das da arbeitet, ist hier zu besichtigen (obwohl ich da in dem zeitraum nix angefasst habe).

eine fehlermeldung dazu aus wtee:

hiveeyes/27041c2a-8afd-4a1e-b3ae-44233fa1f06b/mois/yun/message-json {"Timestamp": "2023-07-13T18:16:58", "CountPerMinute": "74", "GammaRadiation": "0.100 "}hiveeyes/27041c2a-8afd-4a1e-b3ae-44233fa1f06b/mois/yun//error.json { "type": "<class 'influxdb.exceptions.InfluxDBClientError'>", "message": "400: {\"error\":\"partial write: field type conflict: input field \\\"CountPerMinute\\\" on measurement \\\"mois_yun_sensors\\\" is type float, already exists as type string dropped=1\"}", "description": "Error processing MQTT message \"b'{\"Timestamp\": \"2023-07-13T18:16:58\", \"CountPerMinute\": \"74\", \"GammaRadiation\": \"0.100 \"}'\" from topic \"hiveeyes/27041c2a-8afd-4a1e-b3ae-44233fa1f06b/mois/yun/message-json\".", "timestamp": "2023-07-13T16:18:33+00:00"}

ein daten-typ-problem also.

in der datenbank gibts das feld schrägerweise zweimal:

> SHOW FIELD KEYS FROM mois_yun_sensors
name: mois_yun_sensors
fieldKey             fieldType
--------             ---------
CountPerMinute       float
CountPerMinute       string
GammaRadiation       float
Timestamp            string
brightness           float
humidity hive1       float
...

offensichtlich weg kann CountPerMinute vom typ string:

> SELECT "CountPerMinute"::string FROM mois_yun_sensors LIMIT 10000
name: mois_yun_sensors
time                CountPerMinute
----                --------------
1688947793034058021 null
1688947926576962138 null
1688986152165107793 null
1689074337213801733 null
1689075128204053461 null
1689159402702461407 null
1689326610519521504 null
1689326742515015247 null
>

die einzelnen einträge hab ich inzwischen manuell gelöscht. das feld - und der fehler - ist aber immer noch da.
und hier komme ich nicht weiter. ich krieg die syntax nicht zusammen, um das richtige der beiden mit dem selben namen zu löschen.
hm, ich lerne gerade: felder löschen geht gar nicht.

muss ich tatsächlich alle felder die ich behalten will mit sowas wie
SELECT "CountPerMinute" AS "CountPerMinute" INTO "mois_yun_sensors_tmp" FROM "mois_yun_sensors"
umziehen, dann mois_yun_sensors mit dem string-feld droppen und dann wieder alle, die ich behalten will, zurück kopieren (und zum aufräumen mois_yun_sensors_tmp droppen)?
ich freu mich über datenbankmanipulationshilfe an dieser stelle.

und wie ist das überhaupt soweit gekommen? bzw: kann ich verhindern, dass das wieder passiert?

2

Hi Markus. Das ist ja blöd. Vielleicht war ich beteiligt.

Zwei Dinge könnten eine Rolle spielen:
a) Dein Programm schickt die Daten mal so mal so.
b) Kotori interpretiert die Daten mal so mal so.

Kotori habe ich neulich mal neugestartet. Das Datum könnte hinkommen. Vielleicht liegt es daran, dass dabei irgendetwas umfiel.

Auf jeden Fall sicherstellen, dass Dein Programm den Wert immer stabil als float schickt. Dass Kotori ihn von float nach string konvertiert, wäre ungewöhnlich. Dass Kotori den Wert aber übersieht, (oder es gibt einen Bug!?), von string nach float zu konvertieren, wäre wahrscheinlicher.

Um absolut sicherzugehen, sollte ein float auch kein int sein. float(value) sollte es hinreichend sicherstellen. Beispiel:

>>> float(42)
42.0

>>> float("42")
42.0
1 Like
3

Ahja. Daran könnte es liegen. Du kämst am schnellsten aus der Affäre, wenn Du das Feld anders benennst, und eben, wie oben geschrieben, vorher sicherstellst, dass es nicht als String gesendet wird.

Korrekt.

Ja, genau. [1]

  1. https://github.com/daq-tools/kotori/pull/148 wird vielleicht Abhilfe bringen, aber das ist momentan noch Zukunftsmusik. ↩︎

4

sehr schön, die werte kommen wieder rein.
variable neu benennen

InfluxDB shell version: 1.7.10
> SELECT "CountPerMinute"::float AS "CountsPerMinute" INTO "mois_yun_sensors" FROM "mois_yun_sensors"

und float() ins übergabeskript log_geiger.py einbauen did the trick:

# Define measurement
measurement = {
    'Timestamp':        Timestamp,
    'CountsPerMinute':  float(CountsPerMinute),
    'GammaRadiation':   GammaRadiation,
}

(und auch an allen anderen stellen im skript CountPerMinute in CountsPerMinute geändert.)

jetzt liegen halt noch diese nutzlosen datenreihen CountPerMinute in float und string rum. die schaden nichts, oder? löschen werd ich sie, wenn influx das irgendwann mal kann, gut?
danke mal wieder!

1 Like
5

es ist wieder passiert. diesmal dem wetterbot, zeiträue: 15.11., 3.00uhr bis 16.11. 12.42 und 17.11. 2.40 bis 19.11., 11.44.

Update zwei Tage später: Diesmal ist die Ursache sonnenklar. Die Batterie an der Wetterstation hat sich lang gemacht. Dunkle Jahreszeit und so: Da hat das Solarpanel eben nicht mehr gereicht. Im Grunde wars deutlich zu sehen an den Sonnenwerte. Am späten vormittag ist die Anlage zweimal nochmal wieder hochgekommen. Dann war Schluss. Update Ende.

hiveeyes/27041c2a-8afd-4a1e-b3ae-44233fa1f06b/mois/yun//error.json { "type": "<class 'influxdb.exceptions.InfluxDBClientError'>", "message": "400: {\"error\":\"partial write: field type conflict: input field \\\"wb_AirPressure\\\" on measurement \\\"mois_yun_sensors\\\" is type string, already exists as type float dropped=1\"}", "description": "Error processing MQTT message \"b'{\"wb_WindSpeed\": \"\", \"wb_WindDirection\": \"0\", \"wb_Gust\": \"\", \"wb_Rain\": \"\", \"wb_RainRate\": \"\", \"wb_Sun\": \"\", \"wb_AirPressure\": \"\", \"wb_Temperature\": \"\", \"wb_Humidity\": \"\", \"wb_TemperatureInside\": \"\", \"wb_HumidityInside\": \"\"}'\" from topic \"hiveeyes/27041c2a-8afd-4a1e-b3ae-44233fa1f06b/mois/yun/message-json\".", "timestamp": "2023-11-18T20:19:03+00:00"}

hab die variablen jetzt auch in diesem script auf explizit float gestellt. werte kommen wieder rein. alles gut. nur schade: den schönen regen heute nacht nicht erfasst.