100 Modbus-Werte in Mysql ablegen.

[kiaralle]

Hallo,

aktuell arbeite ich mit cvs-Dateien.
Mein Ziel ist es Daten für 12h zu sammeln und diese später auszuwerten. Braucht keiner, macht man aber
Spaß am programmieren.

Wie man Werte in die Tabelle ablegt weiß ich. Funktioniert und ich bin glücklich.

Code: Alles auswählen

statement = "INSERT INTO messwandler (haus, mess_2, garage, warmwasser) VALUES (%s, %s, %s, %s)"
messung = (haus, mess_2, mess_garage, mess_heizung)
cursor.execute(statement, messung)
connection.commit()

Nur bei 100Stück, wird das nicht mehr schön. Zu viele %s und Variablen

Ich habe:
master_result.registers ... enthält 91 Modbuswerte, beginnend bei 0, also 0-90

Eine Tabelle mit Feldern reg_1 bis reg_90, da hinein sollten jetzt meine Werte aus master_result.registers.

Wie löst man das? Mit einer Schleife?

Gruß Ralf

[__deets__]

Da mag eine Schleife vorkommen, aber vor allem löst man das nicht mit einer Monster Tabelle mit so vielen Spalten. Stattdessen eine Tabelle mit Spalte Name und Spalte wert. Ggf muss das Schema noch ausgefeilter werden, wenn die Werte verschiedene Typen haben.

[kiaralle]

Ok,
ich könnte ja in 9 Tabellen mit ja 10 Spalten aufteilen.
So etwas wäre sicher einfacher und übersichtlicher.
Alle Werte haben int(6)

Oder in was für eine Richtung würdest du gehen?

[__blackjack__]

@kiaralle: Das ändert nichts. Das Problem ist die Struktur, nicht dass es zu viele Spalten sind. Das ist wahrscheinlich eine Tabelle mit ca. 4 Spalten. ID, Zeitstempel, Messwertname bzw. -ID, und Messwert.

Eine Tabelle in einer relationalen Datenbank ist was anderes als eine Tabelle in einer Tabellenkalkulation.

[kiaralle]

@blackjack

Du meinst so ähnlich wie bei Influxdb?

Da wird alles untereinander geschrieben und es wird nach Zeit, ID, Value die Daten aus der Tabelle gezogen.

[sparrow]

Nein, __blackjack__ meint wie bei Relationalen Datenbanken üblich.
Mach dich gerne mit dem Konzept vertraut.

[kiaralle]

Kurz angelesen... Wenn ich das jetzt richtig verstanden habe.

Jeder Parameter hat seine eigene Tabelle.

Tabelle VvP1
ID = z.B. 1 , Value
....
Tabelle UvP1
ID = z.B. 1 , Value
...
ID könnte dann auch timestamp sein.

Ich kann dann aus allen Tabellen nach ID und den Werten filtern.

So etwas ich hatte mal als Chemielager-Datenbank. Jeder Stoff seine eigene Tabelle.

[sparrow]

Nee, falsch eingelesen.

Du hast zwei Tabellen (oder besserer Name: Relationen. Sonst ist man gedanklich immer bei der Tabellenkalkulation).
Eine Relation, welche die Messung repräsentiert und eine Relation, die alle Werte aller Messungen enthält.
Jede Messung bekommt eine ID, die wird dann als Fremdschlüssel in der Relation der Werte verwendet. Und deren Aufbau ist wie von __blackjack__ oben beschrieben.

Jede Messung hat dann einen Eintrag in der Relation für Messungen und n Einträge in der Relation der Werte.

Wobei wahrscheinlich noch eine dritte Relation die verschiedene Messwerttypen enthält.
Daher die Unterscheidung bei __blackjack__ ob man den Namen oder die ID des Messwerttypen speichert.

Das Stichwort ist Normalisierung.

[kiaralle]

Ok, da muss ich noch mal ran.
Wird ein spannendes Projekt

[oldboyJR]

Ein Array mit 101 Elementen und das erste der Index und der Rest die Elemente die in die jeweilige Tabelle eingetragen werden?

[Dennis89]

Nö.

[DeaD_EyE]

Eine relationale Datenbank zur Speicherung von vielen Messwerten, ist einfach die falsche Wahl.
Genau aus dem Grund gibt es zeitbasierte Datenbanken, wie z.B. InfluxDB.

Messwerte schreibt man einfach dann, wenn sie verfügbar sind und jeder Messwert bekommt einen Zeitstempel. Man kann auch mehre Messwerte zusammenfassen, wenn man z.B. via Modbus mehrere discrete-inputs/coils/register liest.

[sparrow]

SCNR: Das geht auch mit PostgreSQL und timescaleDB. Wenn man eh schon PostgreSQL im Einsatz hat (weil man zum Beispiel Transaktionen braucht) dann ist es unnötig da noch ein DMBS zu betreiben.

[DeaD_EyE]

SCNR: Das geht auch mit PostgreSQL und timescaleDB. Wenn man eh schon PostgreSQL im Einsatz hat (weil man zum Beispiel Transaktionen braucht) dann ist es unnötig da noch ein DMBS zu betreiben.

Ich habe erst kürzlich gelernt, dass PostgreSQL so ziemlich alles kann. z.B. auch Message-Queues und PUB-SUB.

[sparrow]

PostgreSQL ist mein allerliebstes Betriebssystem!

Bei NOTIFY/LISTEN darauf achten, dass darauf nicht so einfach Rechte zu vergeben sind (daher am besten hinter Triggern verbergen) und dass dafür jeder Client die ganze Zeit eine Verbindung offen halten muss.