Hallo ich will mittels DMM den Stromverlauf eines selbstgebauten Geräts überwachen. Hierfür suche ich eine Software für den Pi, der mit dem DMM über RS232 verbunden ist. Es sollen sekündlich Werte geloggt und später auf einer grafischen Oberfläche angezeigt werden können. Kennt da jemand schon was fertig dafür?
GNU DataExplorer, wenn’s voll aufgeblasen sein soll. Der eigentliche Job, jede Sekunde ein Datum zu lesen und es zusammen mit einem Timestamp an eine Datei zu hängen (oder in eine Datenbank zu schreiben, oder was auch immer), ließe sich mit einem Shell-Einzeiler erledigen.
:
Bearbeitet durch User
Du hast eigentlich zwei Teilaufgaben: - Abholen der Daten vom Messgerät (+ eventuelle Aufbereitung) - Ablegen der Daten Ich bezweifle dass es eine SW gibt die genau das für genau dein Gerät schon kann. Ich würde mit einem Pythonskript die Daten abholen (das Skript per cron zyklisch triggern oder gleich als systemd-service laufen lassen) und dann entweder in eine Datenbank deines Vertrauens (z.B. influxDb) oder in ein text-/csv-File schreiben. Graphische Aufbereitung / Visualisierung zum Beispiel mit Graphana (kann dann vom PC/Tablet im Browser geöffnet werden), gnuplot oder Excel-Magic.
Tom schrieb: > und später auf einer > grafischen Oberfläche angezeigt werden können Hat dein Pi einen Bildschirm oder läuft er headless? Falls letzteres: dann würde ich die Kombi Pythonskript/influxDb/Graphana einsetzen. Graphana läuft als Dienst auf deinem Pi und stellt eine konfigurierbare Web-Oberfläche bereit. Du kannst deine Daten also von jedem PC / Tablet / Handy im Netzwerk anschauen.
Für das abholen vom DMM, aufbereiten und in die Datenbank schreiben käme auch Node Red in Frage. Sascha
Jack V. schrieb: > ließe sich mit einem Shell-Einzeiler > erledigen. Für so etwas gibt es cron. Ansonsten wäre für den TO RRD zu empfehlen. Um die Daten vom Ausleseprogramm in Datenbank zu bekommen, kann man dann ein kleines Shellscript bemühen.
Tom schrieb: > Hallo ich will mittels DMM den Stromverlauf eines selbstgebauten > Geräts überwachen. > Hierfür suche ich eine Software für den Pi, der mit dem DMM über RS232 > verbunden ist. Es sollen sekündlich Werte geloggt und später auf einer > grafischen Oberfläche angezeigt werden können. > Kennt da jemand schon was fertig dafür? Spricht das DMM Modbus als Protokoll?
Angehängte Dateien:
Hallo,
vielen Dank für eure Tipps, ich werde mir das mal ansehen. Ja ich werde
dann wohl ein Skript schreiben was die Werte in eine datenbank oder in
eine csv schreibt. CSV wäre vielleicht noch einfacher zum Händeln.
>Spricht das DMM Modbus als Protokoll?
Ich glaube nicht, ist ein altes Grundig DM100. Mir fehlt noch der
RS232-USB-Adapter..
Hallo Grafana und influxDb laufen. Ein Dashboard konnte ich auch erstellen, auch wenn es noch sehr ungewohnt ist für mich. Gibt es ein ähnliches Programm wie phpmyadmin für mySQL, um die Datenbank direkt einsehen und verwalten zu können? Ich habe diesen Befehl gefunden, um einen Eintrag erstellen zu können in der db curl -i -XPOST 'http://192.168.1.44:8086/write?db=home'; --data-binary 'sensor,ort=kueche temperatur=6.7' und würde gerne verstehen was "sensor,ort=kueche" macht
Zeno schrieb: > Jack V. schrieb: >> ließe sich mit einem Shell-Einzeiler >> erledigen. > > Für so etwas gibt es cron. Er könnte auch systemd verwenden, das hat eine umfangreiche Logging Funktion.
Schau dir dazu mal systemd-cat an: https://www.freedesktop.org/software/systemd/man/systemd-cat.html In der Bash also: deinprogramm | systemd-cat Deinprogramm muss also ne Ausgabe an die Konsole machen und dann wird es durch die Pipe zu systemd geschoben. Angucken kannst du es dann mit: journalctl -f Wie die Daten aus der RS238 Schnittstelle ausgelesen werden muss deinprogamm erfüllen. Ansonsten kannst du systemd-cat noch prioritätstufen wie info, warning usw. zuweisen.
Nano schrieb: > Deinprogramm muss also ne Ausgabe an die Konsole machen und dann wird es > durch die Pipe zu systemd geschoben. Korrektur, meinte zu systemd-cat und da macht den Rest. > Wie die Daten aus der RS238 Schnittstelle ausgelesen werden muss > deinprogamm erfüllen. Meinte natürlich RS232
Du schlägst allen Ernstes vor, das Ergebnis einer sekündlichen Abfrage in das Journal zu schreiben, um die Daten dann später zum Zweck der Visualisierung wieder da herauszupopeln? Das ist ja noch ein Ende weiter vom Vernünftigen weg, als die Idee weiter oben, für eine sekündliche Abfrage cron heranzuziehen … Wie gesagt: es ist ein simpler Shell-Einzeiler, die Daten zu lesen und sie $irgendwohin zu schreiben. Wobei $irgendwohin hier eine Textdatei sein kann (gerne auch in einem CSV-Format), eine sqlite3-Datenbank, eine ausgewachsene Datenbank, oder noch was Anderes.
:
Bearbeitet durch User
Wie gesagt letzter Stand ist: -ich habe Grafana installiert -und influxdb D.h mein Skript müsste einfach nur ein http request ausführen und das war’s Ist nur die Frage wie ich das mache, in einer Schleife per Timer bzw time.sleep Mir ist noch nicht bekannt, ob das DMM von sich den Messwert liefert, vermutlich muss ich ihn aber anfordern..sehe ich Montag wenn der RS232-USB-Adapter kommt
Jack V. schrieb: > Du schlägst allen Ernstes vor, das Ergebnis einer sekündlichen > Abfrage > in das Journal zu schreiben, um die Daten dann später zum Zweck der > Visualisierung wieder da herauszupopeln? Das ist ja noch ein Ende weiter > vom Vernünftigen weg, als die Idee weiter oben, für eine sekündliche > Abfrage cron heranzuziehen … Er wollte ja etwas fertiges.
Ich muss bei meinem Terminalprogi nur das Logging einschalten und habe fertig. Cron ist z.B. nie dafuer gedacht gewesen im "Sekundentakt" Daten wegzuloggen. Und der ganze andere vorgeschlagene Rest ist umso mehr eine Lachnummer. Da sitzt das Hirn wohl inner Unnerhoos.
Beitrag #6974150 wurde von einem Moderator gelöscht.
Jetzt fangt mal keinen Streit an. Spricht etwas dagegen das so zu machen? Das Abfragen der Daten fehlt natürlich noch. Das einpflegen in die DB würde so gehen mit python
1 | import threading, time, os |
2 | |
3 | def foo(): |
4 | os.system("curl -XPOST 'http://192.168.1.44:8086/write?db=home' --data-binary 'dmm100 messwert=6.7'")
|
5 | print time.ctime() |
6 | |
7 | WAIT_TIME_SECONDS = 0.5 |
8 | |
9 | ticker = threading.Event() |
10 | while not ticker.wait(WAIT_TIME_SECONDS): |
11 | foo() |
> Oder du Vollidiot hast dein Problem nicht verständlich formuliert...
Im Gegensatz zum allgemeinen Trend, habe ich kein Problem.
Probleme haben nur die, die nur Bestellknoepfe druecken koennen.
Tom schrieb: > Spricht etwas dagegen das so zu machen? Das hängt davon ab, ob dich der völlig nutzlose und vermeidbare Overhead durch das ständige - Erzeugen eines neues Prozesses - Aufbauen einer neuen TCP-Verbindung interessiert. Bei so einer kleinen Anwendung muss es das nicht notwendigerweise. Ich würde noch Acht auf das Fehlerverhalten geben, aber dort kann man ja unterschiedliche Anforderungen haben.
Hallo, ich würde es nur ein paar Tage laufen lassen..von daher ist das vermutlich vernachlässigbar. Wie könnte man es dennoch besser machen?
Tom schrieb: > Hallo, > ich würde es nur ein paar Tage laufen lassen..von daher ist das > vermutlich vernachlässigbar. > > Wie könnte man es dennoch besser machen? Mit einem C oder C++ Programm das alles macht. Ein Prozess der solange läuft bis alles gelogged wurde. Logs kannst du im Speicher vorhalten und dann schreibst du das ganze Blockweise auf die Platte. Das reduziert die Schreibzugriffe und schont die SD. Beim Stromausfall sind die Sachen im RAM allerdings weg. Natürlich muss man nicht alles von grundauf neu erfinden, also guck nach Bibliotheken, die dich da unterstützen. Bei vielen Werten kann sich ein Binärformat anbieten. Der PI dürfte zwischen den Sekunden Pausen machen, du kannst ihn also schlafen legen bzw. dich darum kümmern, dass der Kernel das oft machen kann.
Tom schrieb: > Jetzt fangt mal keinen Streit an. > > Spricht etwas dagegen das so zu machen? Das Abfragen der Daten fehlt > natürlich noch. Das einpflegen in die DB würde so gehen mit pythonimport > threading, time, os > def foo(): > os.system("curl -XPOST 'http://192.168.1.44:8086/write?db=home'; > --data-binary 'dmm100 messwert=6.7'") > print time.ctime() > WAIT_TIME_SECONDS = 0.5 > ticker = threading.Event() > while not ticker.wait(WAIT_TIME_SECONDS): > foo() Ich mache das eher so:
1 | import threading, time, os |
2 | |
3 | def foo(): |
4 | while True: |
5 | os.system("curl -XPOST 'http://192.168.1.44:8086/write?db=home'
|
6 | > --data-binary 'dmm100 messwert=6.7'") |
7 | time.sleep(0.5) |
8 | |
9 | # Multithreading: |
10 | thread1 = threading.Thread(target=foo) |
11 | thread1.start() |
Nano schrieb: > Mit einem C oder C++ Programm das alles macht. > Ein Prozess der solange läuft bis Mit C/C++ auf dem Pi habe ich gar keine Erfahrung. Blockweisewklingt prinzipiell nicht schlecht. Wobei ich dann die Timestamps auch in die dB bekommen muss..was jetzt automatisch geschieht
Wenn’s dann doch in eine Datenbank soll, und Python oder C++ schon im Spiel ist: warum nicht einfach sqlite3, sondern so umständlich über eine weitere Software und noch ein externes Programm, das eine HTTP-Verbindung dahin aufbaut, nur um den Wert reinzuschreiben? Ernstgemeinte Frage, denn ich sehe den Gegenwert für diese zusätzliche Komplexität gerade nicht. Wenn das so weitergesponnen wird, braucht der TE bald einen ausgewachsenen Rechner für den Job, den ein simpler Shell-Einzeiler selbst auf dem Pi der ersten Generation ohne nennenswerte Last zu verursachen erledigen würde.
:
Bearbeitet durch User
Jack V. schrieb: > Wenn’s dann doch in eine Datenbank soll, und Python oder C++ schon im > Spiel ist: warum nicht einfach sqlite3 Das waere auch meine Empfehlung. Schon dass man mit einer simplen Abfrage genau die gewuenschten Werte wieder herausbekommt, ist extrem hilfreich. z.B. mit Perl:
1 | $sth = $dbh->prepare("SELECT AVG(druck),MIN(druck),MAX(druck) FROM (SELECT druck FROM werte ORDER BY timestamp DESC LIMIT 0,1440);");
|
2 | $sth->execute() or die $DBI::errstr; |
3 | my ($druck_avg, $druck_min, $druck_max) = $sth->fetchrow(); |
holt Mittelwert, Maximum und Minimum der letzten 1440 Eintraege (24h * 60 Minuten) in der DB.
Jack V. schrieb: > Ernstgemeinte Frage, denn ich sehe den Gegenwert für diese zusätzliche > Komplexität gerade nicht. Der Gegenwert ist, dass ich in kurzer Zeit ein funktionsfähiges Skript inklusive Anzeige fertig habe was vermutlich meinen Zwecken genügt. Komplex war es dafür nicht, mich in C einarbeiten etc wäre durchaus komplexer und ich bräuchte dafür vermutlich mehrere Tage bis das läuft
Tom schrieb: > Komplex war es dafür nicht, mich in C einarbeiten etc wäre durchaus > komplexer und ich bräuchte dafür vermutlich mehrere Tage bis das läuft Prinzipiell kannst du auch jede andere Programmiersprache verwenden, Hauptsache ist, dass sie dir einen Zugriff auf die Hardware erlaubt. Du hast ja gefragt, wie man es "besser" machen könnte, deswegen habe ich dir gleich die Sprachen genannt, die man für die Systemprogrammierung verwenden würde. (Anmerkung: Rust gehört da übrigens auch noch dazu, die Sprache habe ich vergessen.) Wenn du für den Hardwarezugriff ein passendes JNI hast, kannst du bspw, auch Java nehmen. Ist halt nur irgendwie mit dem Kopf durch die Wand. Leider hast du ja auch nicht gesagt, welche Programmiersprachen du kannst. Wenn du zu den älteren Hasen gehörst, könntest du es auch mit FreePascal probieren. Und wenn du nur Skriptsprachen kannst, dann könntest du Python nehmen. Für die Aufgabenstellung reicht das im Prinzip auch.
Meine Güte – er will von ttyS0 oder ähnlichem lesen, und die Daten wegschreiben. Wie kommst du von da aus auf Systemprogrammierung? Das lässt sich mit jeder Sprache lösen, wobei eine simpel zu nutzende Scriptsprache, wie Python, da in fünf Minuten zum Ergebnis führen sollte. Zehn, wenn noch viel nachgeschaut werden muss – solide Kenntnisse der Sprache vorausgesetzt. Abgesehen davon ist das Speichern trivial – was ihm vermutlich mehr Sorgen machen wird, ist das Entgegennehmen/Auslesen der Daten. Dazu kann man mangels Kenntnis des Formats nun noch nichts sagen – bislang ist nur die Schnittstelle grob bekannt.
:
Bearbeitet durch User
Jack V. schrieb: > Meine Güte – er will von ttyS0 oder ähnlichem lesen, und die Daten > wegschreiben. Wie kommst du von da aus auf Systemprogrammierung? Er muss auf die GPIO des Raspberry Pi zugreifen, da das DMM die Daten per RS-232 Schnittstelle liefert.
Jack V. schrieb: > Wie gesagt: es ist ein simpler Shell-Einzeiler, die Daten zu lesen und > sie $irgendwohin zu schreiben. Aber, aber, aber ... Da ist kein Python dabei. Und wir alle wissen doch, dass man ohne Python nicht programmieren kann. Da ist auch kein Grafana, keine Cloud, mindestens ein Docker-Container, besser noch Kubernetes, kein direktes I/O, keine NoSql-Datenbank, keine drei Web-Frameworks, keine Low-Code Umgebung, keine KI und keine Gameification dabei. SO KANN MAN DOCH NICHT ARBEITEN.
Nano schrieb: > Er muss auf die GPIO des Raspberry Pi zugreifen, da das DMM die Daten > per RS-232 Schnittstelle liefert. RS232 über GPIO wird nicht ohne Weiteres funktionieren (alleine schon aufgrund der Pegel), also wird vermutlich ein handelsüblicher Converter zu USB (von FTDI oder Prolific oder was auch immer) zum Einsatz kommen. Da gibt es dann /dev/ttySx oder /dev/ttyACMx, und man muss lediglich diese Datei zum Lesen öffnen können.
:
Bearbeitet durch User
Nano schrieb: > Du hast ja gefragt, wie man es "besser" machen könnte, deswegen habe ich > dir gleich die Sprachen genannt, Ja du hast Recht, das lohnt sich bestimmt sich auch nochmal anzuschauen. C/C++ kenne ich nur von Arduino und habe damit auf dem Raspberry noch nicht programmiert. Mir ging es auch eher darum eine Lösung mit möglichst wenig Aufwand zu finden..die andere Baustelle ist schon komplex genug als dass ich eine neue Beschäftigung bräuchte. Den http-request könnte man ja noch ersetzen, in die DB kann man ja auch direkt schreiben. Mir ist aber auch noch nicht bekannt, ob man die DB auch über eine GUI verwalten kann, löschen etc...ähnlich phpmysql. DAs wäre noch ganz gut. Auch will ich noch eine Möglichkeit das Programm zu beenden einbauen, damit ich noch davor ein Kommando an das DMM schicken kann. Ansonsten ist das jetzt das letzte Programm. Aus dem spärlichen Handbuch des DMM konnte ich herauslesen wie man die Werte abfragt. D.h den empfangenen String muss ich dann nur noch auftrennen. Was da an Vorzeichen kommen ist mir nicht klar. Auf was da als Exponent geschickt wird nicht. Als Schnittstelle dient ein USB-Rs232 Adapter, GPIO geht nicht, weil aus dem DMM eben andere Pegel kommen. Mit meinem Skript kann ich auch zwischen Spannung und Strom umschalten. Es ist alles aus Teilen zusammengestoppelt, aber scheint soweit den Zweck zu tun. mit einem zweiten PC und zwei USB-UART-Adaptern konnte ich die Dateneingabe simulieren
1 | #!/usr/bin/python
|
2 | #-*- coding:utf-8 -*-
|
3 | |
4 | import threading, time, os, serial, sys, getopt |
5 | |
6 | |
7 | |
8 | #REN\xØA - Übergang zur Fernbedienung
|
9 | #FUNC IDC\xØA - Gleichstrommessung
|
10 | #VAL?\xØA - Anweisung zum Senden der Meßdaten
|
11 | #GTL\xØA - Übergang zur örtlichen Bedienung
|
12 | |
13 | #Empfangenes Format
|
14 | #FFF VX.XXXXEVYY
|
15 | #FFF - Meßfunktion/Meßwertdarstellung
|
16 | #V - Vorzeichen (+/−)
|
17 | #X.XXXX - Mantisse
|
18 | #E - Symbol für Exponent
|
19 | #V - Vorzeichen (+/−)
|
20 | #YY - Exponent
|
21 | |
22 | |
23 | serialPort = serial.Serial( |
24 | port="/dev/ttyUSB0", baudrate=9600, bytesize=8, timeout=2, stopbits=serial.STOPBITS_ONE |
25 | )
|
26 | serialString = "" # Used to hold data coming over UART |
27 | |
28 | |
29 | |
30 | def main(argv): |
31 | inputfile = '' |
32 | datenbankname = '' |
33 | try: |
34 | opts, args = getopt.getopt(argv,"hf:n:",["ffile=","ofile="]) |
35 | except getopt.GetoptError: |
36 | print 'dmm100.py -f <inputfile> -n <datenbankname>' |
37 | sys.exit(2) |
38 | for opt, arg in opts: |
39 | if opt == '-h': |
40 | print 'dmm100.py -f <IDC/IAC/VDC/VAC/R--> -n <Datenbankname>' |
41 | sys.exit() |
42 | elif opt in ("-f", "--ffile"): |
43 | inputfile = arg |
44 | elif opt in ("-n", "--ofile"): |
45 | datenbankname = arg |
46 | if inputfile == 'idc': |
47 | print ("Init logging DM100") |
48 | serialPort.write(b"REN\n") |
49 | time.sleep(1) |
50 | print 'Strommessung DC' |
51 | serialPort.write(b"FUNC IDC\n") |
52 | time.sleep(1) |
53 | print ("Start logging DM100") |
54 | |
55 | if inputfile == 'vdc': |
56 | print ("Init logging DM100") |
57 | serialPort.write(b"REN\n") |
58 | time.sleep(1) |
59 | print 'Spannungsmessung DC' |
60 | serialPort.write(b"FUNC VDC\n") |
61 | time.sleep(1) |
62 | print ("Start logging DM100") |
63 | |
64 | # print 'Funktion "', inputfile
|
65 | if datenbankname=='': |
66 | datenbankname='home' |
67 | print 'Verwendete Datenbank "', datenbankname |
68 | |
69 | if __name__ == "__main__": |
70 | main(sys.argv[1:]) |
71 | |
72 | def foo(): |
73 | serialPort.write(b"VAL?\n") |
74 | #Wait until there is data waiting in the serial buffer
|
75 | if serialPort.in_waiting > 0: |
76 | |
77 | # Read data out of the buffer until a carraige return / new line is found
|
78 | serialString = serialPort.readline() |
79 | |
80 | # Print the contents of the serial data
|
81 | try: |
82 | serialString = serialString.replace('\r', '') |
83 | os.system("curl -XPOST 'http://192.168.1.44:8086/write?db=home' --data-binary 'dmm100 messwert=" + serialString + "'") |
84 | print time.ctime()+" -> "+(serialString.decode("Ascii")) |
85 | except: |
86 | pass
|
87 | |
88 | |
89 | |
90 | WAIT_TIME_SECONDS = 0.5 |
91 | ticker = threading.Event() |
92 | while not ticker.wait(WAIT_TIME_SECONDS): |
93 | foo() |
94 | |
95 | serialPort.write(b"GTL\n") #Beim Schließen des Programms ausführen, damit DMM wird auf Handbetrieb umschaltet |
Als Adapter kommt dieser zum Einsatz, wenn er da ist und hoffentlich funktioniert https://www.amazon.de/gp/product/B000QU2CSC
Jack V. schrieb: > Das > lässt sich mit jeder Sprache lösen, wobei eine simpel zu nutzende > Scriptsprache, wie Python, da in fünf Minuten zum Ergebnis führen > sollte. Zehn, wenn noch viel nachgeschaut werden muss – solide > Kenntnisse der Sprache vorausgesetzt. Ich würde behaupten, dass ich auch nur grobe Kenntnisse vn Python habe und aber weiß ungefähr nach was ich suchen muss. Bin kein Profi und der Raspberry nur Hilfsmittel
Tom schrieb: > Mir ging es auch eher darum eine Lösung mit möglichst wenig Aufwand zu > finden..die andere Baustelle ist schon komplex genug als dass ich eine > neue Beschäftigung bräuchte. Dann nimm Python. Rasbian OS liefert entsprechende Bibliotheken mit um auf die GIOs via Python zuzugreifen und Zugriffsmöglichkeiten auf ein DBMS gibt es auch. > Den http-request könnte man ja noch ersetzen, in die DB kann man ja auch > direkt schreiben. Mir ist aber auch noch nicht bekannt, ob man die DB > auch über eine GUI verwalten kann, löschen etc...ähnlich phpmysql. DAs > wäre noch ganz gut. Du kannst doch phpmysql verwenden. Und wenn du es in schön willst, dann schreibst du dir halt noch ein Webinterface mit PHP und Zugriff via SQL. Das hat allerdings nichts mehr mit dem Tool zu tun, dass die Daten von den GPIOs zur DB schaufeln soll. Es sind also zwei getrennte Programme. > Auch will ich noch eine Möglichkeit das Programm zu > beenden einbauen, damit ich noch davor ein Kommando an das DMM schicken > kann. Das kannst du in Python lösen. > Als Schnittstelle dient ein USB-Rs232 Adapter, GPIO geht nicht, weil aus > dem DMM eben andere Pegel kommen. Ah okay. Dann vergiss das was ich zu den GPIOs oben geschrieben habe.
Nano schrieb: > Du kannst doch phpmysql verwenden. Korrektur, meine phpMyAdmin: https://de.wikipedia.org/wiki/PhpMyAdmin
Nano schrieb: > Korrektur, meine phpMyAdmin: Ja vielleicht stricke ich das nochmal um. Hatte jetzt halt die vorgeschlagene influxDB genommen..mit der ich allerdings noch keine Erfahrung habe..auch was es da für tools dafür gibt
Zeno schrieb: > Jack V. schrieb: >> ließe sich mit einem Shell-Einzeiler >> erledigen. > > Für so etwas gibt es cron. Nein. Der TO wollte die Daten sekündlich und die feinstmögliche Auflösung üblicher Cron-Daemons ist eine Minute.
Jack V. schrieb: > Du schlägst allen Ernstes vor, das Ergebnis einer sekündlichen Abfrage > in das Journal zu schreiben, um die Daten dann später zum Zweck der > Visualisierung wieder da herauszupopeln? Das ist ja noch ein Ende weiter > vom Vernünftigen weg, als die Idee weiter oben, für eine sekündliche > Abfrage cron heranzuziehen … Es geht... > Wie gesagt: es ist ein simpler Shell-Einzeiler, die Daten zu lesen und > sie $irgendwohin zu schreiben. Wobei $irgendwohin hier eine Textdatei > sein kann (gerne auch in einem CSV-Format), eine sqlite3-Datenbank, eine > ausgewachsene Datenbank, oder noch was Anderes. ... denn die zu sammelnden Daten sind ein klassischer Fall für ein Append-Only-Log. Und womit bietet so ein Linuxsystem bereits ein Append-Only-Log fertig an? Genau, mit den systemeigenen Logging-Möglichkeiten, bei klassischen Systemen also (r)syslogd und bei modernen Linuxsystemen mit systemd eben den journald. Und es ist durchaus sehr vernünftig, die ohnehin bereits vorhandenen Möglichkeiten des Systems zu benutzen anstatt eine zusätzliche Software installieren, konfigurieren, und dauerhaft pflegen zu müssen -- zumal ja nicht nur die Installation, Konfiguration und Pflege und zudem das Eintrageskript notwendig ist, sondern es zur Vermeidung von Überläufen auch noch eines Housekeeping bedarf, das im Falle von (r)syslogd oder journald bereits fertig vorhanden ist. Wenn man das alles zusammenrechnet, erscheint der Weg, das einfach in die bereits vorhandenen systemeigenen Logging-Facilities zu schreiben, auf einmal gar nicht mehr so unvernünftig...
Tom schrieb: > Jetzt fangt mal keinen Streit an. > > Spricht etwas dagegen das so zu machen? Ja. > Das einpflegen in die DB würde so gehen mit python Nein. curl(1) gibt die Daten auf stdout aus, aber da kommst Du mit einem Aufruf über os.system nicht daran. Zudem bringt Python leistungsfähige Standardbibliotheken zur clientseitigen Kommunikation über HTTP mit, der Aufruf von curl(1) ist also völliger Humbug, und os.system gilt als discouraged -- wenn man mit Python schon ein externes Programm aufrufen möchte, wird die Standardbibliothek subprocess empfohlen... ;-)
Rene K. schrieb: > Ich mache das eher so: > >
1 | > import threading, time, os |
2 | > |
3 | > def foo(): |
4 | > while True: |
5 | > os.system("curl -XPOST 'http://192.168.1.44:8086/write?db=home'
|
6 | >> --data-binary 'dmm100 messwert=6.7'") |
7 | > time.sleep(0.5) |
8 | > |
9 | > # Multithreading: |
10 | > thread1 = threading.Thread(target=foo) |
11 | > thread1.start() |
12 | > |
Und das Multithreading hat genau welchen Vorteil? Genau: keinen. Wenn, dann also:
1 | import time, os |
2 | |
3 | if __name__ == '__main__': |
4 | while True: |
5 | os.system("curl -XPOST 'http://192.168.1.44:8086/write?db=home'
|
6 | --data-binary 'dmm100 messwert=6.7'") |
7 | time.sleep(0.5) |
Das Zeitverhalten ist hier allerdings (bestenfalls) geschätzt und im Zweifel mehr als ungenau. Wesentlich besser wäre es deswegen, einfach die Klasse scheduler aus der Standardbibliothek sched zu benutzen. Im Übrigen möchte ich allen Anfängern der Programmiersprache Python dringend den guten Ratschlag mitgeben, Euch einmal die Standardbibliotheken anzuschauen. Die Sprache Python ist nämlich nicht zuletzt deswegen so besonders beliebt geworden, weil sie die Philosophie des "batteries included" verfolgt und insofern bereits leistungsfähige, getestete und meistens sogar sehr performante Bibliotheken für etliche übliche Programmieraufgaben (scheduling, HTTP-Requests, ...) mitbringt. Dieses ganze aufwändige, fehleranfällige und unpräzise Herumgehacke könnt Ihr Euch also komplett ersparen und anstelle dessen einfach all die feinen Dinge benutzen, die Python schon hat und Euch anbietet.
Tom schrieb: > Wobei ich dann die > Timestamps auch in die dB bekommen muss..was jetzt automatisch geschieht Das hängt von der Datenbank ab. SQL-Datenbanken kennen die Standardfunktion NOW(), PostgreSQL obendrein die Variable CURRENT_TIMESTAMP.
Jack V. schrieb: > Wenn’s dann doch in eine Datenbank soll, und Python oder C++ schon im > Spiel ist: warum nicht einfach sqlite3, sondern so umständlich über eine > weitere Software und noch ein externes Programm, das eine > HTTP-Verbindung dahin aufbaut, nur um den Wert reinzuschreiben? Naja, das wäre dann aber inkompatibel mit der Idee unserer Vorposter, die Daten per Cronjob (!) sekündlich (!!) abholen und eintragen zu wollen -- oder, allgemeiner gesagt, mit der Idee, das Skript irgendwie extern anzustoßen. Denn mit SQLite kann das zu lustigen Effekten führen, wenn ein Aufruf des Skripts aus irgendeinem Grund (Systemlast?) mal länger als eine Sekunde läuft und dann zwei Instanzen des Skripts auf dieselbe SQLite-Datei zugreifen... Man braucht dann also irgendeine Art der Synchronisierung, und die wiederum kann dann so aufwändig werden, daß das Aufsetzen einer "richtigen Datenbank" dagegen ein Kinderspiel wäre.
Ein T. schrieb: > Und womit bietet so ein Linuxsystem bereits ein > Append-Only-Log fertig an? Genau, mit den systemeigenen > Logging-Möglichkeiten, bei klassischen Systemen also (r)syslogd und bei > modernen Linuxsystemen mit systemd eben den journald Du möchtest also sekündlich einen von außen gelesenen Messwert in das Systemlog schreiben, um die Daten dann später zum Aufbereiten (grafische Darstellung, Suche nach bestimmten Ereignissen, etc.) wieder rauszupopeln? Ja – natürlich geht das. Sinnvoll ist’s jedoch nicht. Das Journal ist für Informationen das System betreffend gedacht, und nicht dazu da, irgendwelche Userdaten reinzuschreiben. Und spätestens, wenn ich noch andere Filterkriterien als den Zeitraum anbringen möchte, oder auch nur die Daten auf einer anderen Maschine weiterverarbeiten möchte, fahre ich mit einer Datenbank oder auch nur einer Textdatei schlicht besser. Und womit bietet Python eine integrierte Datenbankfunktion an? Genau: mit dem sqlite3-Modul
Tom schrieb: > Jetzt fangt mal keinen Streit an. Lass man hier gibt es einige Spezialisten die es regelmäßig darauf anlegen, die anderen zu provozieren. Der Schreiberling dieses gehaltvollen Satzes Cartman schrieb: > Da sitzt das Hirn wohl inner Unnerhoos. gerhört wohl dazu und macht damit seinem Nicknamen alle Ehre, trägt aber selbst null komma nix zum Thema bei. Nochmal zum Thema: Das mit dem sekündlich hatte ich überlesen, das kann cron nicht. Man könnte es dann so machen wie von Nano vorgeschlagen, alles in ein Programm (das alles, incl. Timerfunktion, macht) packen und das Ganze dann als Hintergrundprozeß laufen lassen. Wenn man der Meinung ist das man alles aufgezeichnet hat, beendet man einfach den Prozess.
Ein T. schrieb: > Nein. Der TO wollte die Daten sekündlich und die feinstmögliche > Auflösung üblicher Cron-Daemons ist eine Minute. Ist ja gut - sekündlich hatte ich überlesen.
Jack V. schrieb: > Ein T. schrieb: >> Und womit bietet so ein Linuxsystem bereits ein >> Append-Only-Log fertig an? Genau, mit den systemeigenen >> Logging-Möglichkeiten, bei klassischen Systemen also (r)syslogd und bei >> modernen Linuxsystemen mit systemd eben den journald > > Du möchtest also sekündlich einen von außen gelesenen Messwert in das > Systemlog schreiben, um die Daten dann später zum Aufbereiten > (grafische Darstellung, Suche nach bestimmten Ereignissen, etc.) wieder > rauszupopeln? Ja – natürlich geht das. Sinnvoll ist’s jedoch nicht. Das sehe ich anders. > Das Journal ist für Informationen das System betreffend gedacht, und > nicht dazu da, irgendwelche Userdaten reinzuschreiben. Verzeihung, aber es gibt eine ganze Reihe von Anwendungsprogrammen, die die vom System bereitgestellten Logging benutzen, und das ist auch für genau solche Daten gemacht und gedacht. Damit Shellskripts etc. in diese Logs schreiben können, stellt so ein Linux-System sogar eigens das Programm logger(1) bereit. > Und spätestens, > wenn ich noch andere Filterkriterien als den Zeitraum anbringen möchte, > oder auch nur die Daten auf einer anderen Maschine weiterverarbeiten > möchte, fahre ich mit einer Datenbank oder auch nur einer Textdatei > schlicht besser. Wenn ich die Daten auf einer anderen Maschine weiterverarbeiten möchte, ist ein klassisches SQL-RDBMS sicherlich eine feine Sache, schließlich bieten die bereits eine Möglichkeit, über das Netzwerk auf die Daten zuzugreifen. Dateien hingegen haben den Nachteil, daß ich sie erst auf die andere Maschine bekommen muß, also so etwas wie NFS, Samba, SCP/SFTP oder ähnliches benutzen müßte, um die Daten von der einen auf die andere Maschine zu bekommen. Für den vorliegenden Anwendungsfall des TO sehe ich aber keine sinnvolle Nutzung, mit der einzelne Datensätze gelesen oder gelöscht werden müßten, und daher bieten die Logging-Möglichkeiten des Systems haargenau das, was der TO braucht: Speichern, Abruf, und Housekeeping. Das benutzen etliche System- und Anwendungsprogramme, weil es exakt dafür gedacht, gemacht und vorgesehen ist. Die meisten Entwickler denken leider nicht daran, daß sie bereits ein solches Loggingsystem haben, und benutzen deswegen den einzigen Hammer, den sie kennen: ein klassisches SQL-RDBMS, ganz egal, ob das zu den zu verarbeitenden Daten paßt oder nicht. Ich bin ja schon beeindruckt daß in diesem Thread mit InfluxDB ausnahmsweise einmal etwas Passenderes als eine klassische SQL-Datenbank empfohlen wurde, auch wenn ich persönlich aus Performance- und Stabilitätsgründen eher zu PostgreSQL mit der TimescaleDB-Erweiterung geraten hätte. Wenn man es aber ganz einfach machen wollte, würde man ins Syslog oder den Journald schreiben und sich dazu dann noch ein kleines Shellskript oder Python-Progrämmchen schreiben -- Python bietet für so etwas eigens das Modul systemd.journal -- das die gefilterten Daten aus dem journald ausliest, und im einfachsten Fall mit gnuplot (oder einer der vielen Python-Libraries) plottet. > Und womit bietet Python eine integrierte > Datenbankfunktion an? Genau: mit dem sqlite3-Modul SQLite ist keine Datenbank, sondern ein "SQL-ähnliches Festplatteninterface" -- das Zitat ist nicht von mir, sondern vom Datenbankpapst Joey Celko. Der hat damit zwar MySQL gemeint, aber für SQLite gilt das noch viel mehr. Ansonsten bietet Python für die meisten klassischen SQL-RDBMS ein Datenbankinterface, das PEP 249 erfüllt, da muß man nicht unbedingt zu einer Krücke wie SQLite greifen, nur weil das auf den ersten Blick so besonders einfach erscheint... Spätestens wenn aus irgendwelchen Gründen die klassischen SQLite-Probleme mit parallelen Schreibzugriffen auftreten, wird das Ganze sehr schnell kompliziert, und häufig hat man zu diesem Zeitpunkt bereits mehr oder weniger große Datenmengen unwiederbringlich verloren. Edit: Klammersetzung korrigiert.
:
Bearbeitet durch User
> trägt aber selbst null komma nix zum Thema bei. > Ich muss bei meinem Terminalprogi nur das Logging einschalten > und habe fertig. Was an Terminalprogi und Logging ist da nicht verstanden worden? Du musst noch an deiner Lesekompetenz arbeiten.
Ein T. schrieb: > Verzeihung, aber es gibt eine ganze Reihe von Anwendungsprogrammen, die > die vom System bereitgestellten Logging benutzen, und das ist auch für > genau solche Daten gemacht und gedacht. Um ihren Status dort zu protokollieren, nicht um ihre Nutzdaten dort reinzuschreiben. Falls doch, bitte nenne eines dieser Programme, welche das machen. Ich mein – wie kommt man auf eine solche absurde Idee? Speicherst du deine PDFs und Filme und so auch im Systemlog, weil’s ja halt geht? Wie machst du das mit’m Platz? Denn einfach die nicht mehr benötigten Daten rauszulöschen, wie man’s normalerweise mit nicht mehr benötigten Nutzdaten macht, ist ja nicht vorgesehen. Lässt du also die Daten, die einen bestimmten Zeitraum zurückliegen, hinten rausfallen – wie’s ja üblicherweise mit Logs gemacht wird? Und wenn da Daten sind, die du länger behalten möchtest – schreibst du die dann ins aktuelle Log, und hast die dann solange doppelt drin, bis der alte Kram rausfällt? Auf den Rest des Romans möchte ich an dieser Stelle nicht weiter eingehen – ist mir recht egal, wem du da nachplapperst, was ’ne Datenbank sein soll, und was nicht. Ebenso, was du glaubst, was der TE brauchen würde und was nicht. Na gut, eins kommentiere ich noch: Ein T. schrieb: > Spätestens wenn > aus irgendwelchen Gründen die klassischen SQLite-Probleme mit parallelen > Schreibzugriffen auftreten, wird das Ganze sehr schnell kompliziert Ja … sehr viele parallele Schreibzugriffe – bei einem Datum pro Sekunde, das weggeschrieben wird. Hast du eigentlich mal den Eingangsbeitrag gelesen, worum es geht? Nutzdaten ins Journal schreiben, Probleme mit parallelen Datenbank-Schreibzugriffen … fehlt eigentlich nur noch, dass du zu schwurbeln anfängst :|
Jack V. schrieb: > Um ihren Status dort zu protokollieren, nicht um ihre Nutzdaten dort > reinzuschreiben. Falls doch, bitte nenne eines dieser Programme, welche > das machen. Ich mein – wie kommt man auf eine solche absurde Idee? Das ist ziemlich einfach: indem man sich fragt, welche Art von Software für ein Append-Only-Log wohl am Besten geeignet ist. Ob auch andere schon auf diese sinnvolle Idee gekommen sind, interessiert höchstens Kleingeister. Deine Behauptung, daß das eine "absurde Idee" sei, nehme ich mit Bedauern zur Kenntnis, sehe aber auch, daß Du bis auf solche Behauptungen keinerlei sachlichen Argumente gegen eine solche... sagen wir, "Zweitverwendung" vorbringen kannst. > Speicherst du deine PDFs und Filme und so auch im Systemlog, weil’s ja > halt geht? Auch dumme Polemik kann nicht darüber hinwegtäuschen, daß Du im Gegensatz zu mir bislang kein einziges sachliches Argument vorbringen konntest. Daher habe ich vor allem den Eindruck, daß Du es Dir nur nicht vorstellen kannst. > Denn einfach die nicht mehr > benötigten Daten rauszulöschen, wie man’s normalerweise mit nicht mehr > benötigten Nutzdaten macht, ist ja nicht vorgesehen. Ach, weißt Du, ich betreibe eine ganze Reihe von Systemen, die zum Logging von allerlei Daten genutzt werden, in der Regel mit PostgreSQL und in den letzten Jahren auch Elasticsearch (Graylog) und neuerdings auch OpenSearch. Auf all diesen Systemen laufen entweder periodisch Skripte (Cron, systemd-timer), um veraltete Logdaten zu löschen, oder die Software selbst hat Mechanismen zum Aufräumen veralteter Daten. Denn so ist das nun einmal mit Logdaten: mit zunehmendem Alter verlieren sie an Wert und sind irgendwann wertlos. > Auf den Rest des Romans möchte ich an dieser Stelle nicht weiter > eingehen – ist mir recht egal, wem du da nachplapperst, was ’ne > Datenbank sein soll, und was nicht. Ebenso, was du glaubst, was der TE > brauchen würde und was nicht. Oooch, hat der böse Onkel was gegen das arme SQLite gesagt? > Ein T. schrieb: >> Spätestens wenn >> aus irgendwelchen Gründen die klassischen SQLite-Probleme mit parallelen >> Schreibzugriffen auftreten, wird das Ganze sehr schnell kompliziert > > Ja … sehr viele parallele Schreibzugriffe – bei einem Datum pro Sekunde, > das weggeschrieben wird. Wir reden hier über einen Raspberry Pi, weißt Du, und da habe ich schon die abenteuerlichsten Dinge gesehen. In Situationen mit hoher Last kann es passieren, daß ein sekündlich aufgerufener Prozeß eben auch mal länger als eine Sekunde läuft. Das hatte ich zwar oben schon angedeutet, aber Du hast es anscheinend nicht gelesen oder nicht verstanden. > Hast du eigentlich mal den Eingangsbeitrag > gelesen, worum es geht? Nutzdaten ins Journal schreiben, Probleme mit > parallelen Datenbank-Schreibzugriffen … fehlt eigentlich nur noch, dass > du zu schwurbeln anfängst :| Tja, ich habe den Eingangsbeitrag nicht nur gelesen, sonder vor allem auch mal darüber nachgedacht. Das solltest Du vielleicht auch mal versuchen, wenn Du Deine Reflexe und Fixierungen überwinden kannst. ;-)
Ein T. schrieb: > daß Du im > Gegensatz zu mir bislang kein einziges sachliches Argument vorbringen > konntest. Sachliches Argument? Gab’s einige, aber deine selektive Wahrnehmung ließ sie dich offensichtlich nicht erkennen. Ich schreib’s einfach nochmal, jedoch ohne viel Hoffnung, dass du das dieses Mal aufzunehmen in der Lage bist: Das ist ein Log, kein Dateisystem für Nutzdaten. Es bietet keine sinnvolle Möglichkeit, die Daten darin zu verwalten, etwa nicht mehr benötigte Daten zu löschen, selektiv Daten zu sichern, die Daten ohne einen kompletten Suchdurchlauf auf einmal auszulesen, Daten zu bearbeiten, und selektiv Daten aufzubewahren, Daten selektiv auf ein anderes System zu bringen, etc. – weil’s halt nicht dafür gedacht ist, Nutzdaten zu halten. Wie viel sachlicher hättest du’s denn gerne dargelegt, dass das Systemlog einer der dämlichsten Plätze zum Speichern von Nutzdaten ist? Ein T. schrieb: > Denn > so ist das nun einmal mit Logdaten: mit zunehmendem Alter verlieren sie > an Wert und sind irgendwann wertlos. Genau dieses: und dann fallen sie hinten raus. Und obwohl du das selbst erkannt zu haben scheinst, möchtest du trotzdem Nutzdaten dort reinschreiben, die unter Umständen nach Jahren zum Vergleich herangezogen werden sollen? Der TE schrieb nicht, was für Daten und wofür – vielleicht will er’s ja so wie ich machen: Akkus vermessen, und nach Jahren dann schauen, wie sie sich geändert haben. Und dein „Append-Only“ – du kannst jede beliebige Datei zum Anhängen öffen. Es gibt gar das Konstrukt >> in der Shell dafür, das die übergebenen Daten an die angegebene Datei anhängt (für dich: appended). Sollte dir eigentlich bekannt sein, wenn du die Qualifikation hättest, die zu haben du hier den Eindruck zu erwecken versuchst. Ein T. schrieb: > Wir reden hier über einen Raspberry Pi, weißt Du, und da habe ich schon > die abenteuerlichsten Dinge gesehen. Wir reden hier über ’n Datum mit wenigen Bytes jede Sekunde. Das schafft selbst ein Pi der ersten Generation sicher wegzuschreiben. Und wenn er das nicht mehr schaffen sollte, dann schafft journald es erst recht nicht – der braucht nämlich etwas mehr Ressourcen, als ein einfacher Schreibzugriff auf eine Datei. Ein T. schrieb: > Ach, weißt Du, ich betreibe eine ganze Reihe von Systemen, die zum > Logging von allerlei Daten genutzt werden, in der Regel mit PostgreSQL > und in den letzten Jahren auch Elasticsearch (Graylog) und neuerdings > auch OpenSearch. So, wie du schreibst, hast du von all den Sachen allenfalls mal in ’ner Zeitschrift gelesen. Kein Angriff – nur ein Feedback, wie dein Geschreibsel hier wahrgenommen werden kann. Ein T. schrieb: > Tja, ich habe den Eingangsbeitrag nicht nur gelesen, sonder vor allem > auch mal darüber nachgedacht. Mag ich gar nicht glauben – dann sollte man eigentlich auf die Idee gekommen sein, dass das Systemlog ein denkbar ungeeigneter Wert für Messwerte von außen sein würde, die man weiterverarbeiten, und unter Umständen archivieren möchte. Im Übrigen hast du zwar viel geschrieben, aber dabei geschickt von meiner ausdrücklichen Frage an dich abgelenkt: könntest du bitte ein Programm nennen, das seine Nutzdaten ins Systemlog schreibt? Bitte ohne die nächste Nebelkerze, sondern einfach das Programm nennen. Ich gucke es mir dann an. TIA
:
Bearbeitet durch User
Nutzdaten im Syslog zur späteren Verarbeitung ablegen ist irgendwie wie sich die Haare im Backofen zu trocknen. Geht zwar irgendwie, aber sollte sich falsch anfühlen.
Abgesehen von den besseren Lösungen... Jack V. schrieb: > selektiv Daten zu sichern, Was hindert dich? Jack V. schrieb: > die Daten ohne einen kompletten Suchdurchlauf auf einmal auszulesen Journals enthalten einen Index über alle Felder Jack V. schrieb: > Daten selektiv auf ein anderes System zu bringen Was hindert dich? Du kannst dir sogar den Kram per JSON-Export direkt ins Posgres o. ä. knallen und dort weiterarbeiten.
Jemand schrieb: > Jack V. schrieb: >> selektiv Daten zu sichern, > > Was hindert dich? Die Absurdität, die Daten erst ins Systemlog zu streuen, um dann zum selektiven Sichern doch ’ne eigene Datei draus zu machen, oder sie in eine Datenbank zu schreiben. Jemand schrieb: > Jack V. schrieb: >> die Daten ohne einen kompletten Suchdurchlauf auf einmal auszulesen > > Journals enthalten einen Index über alle Felder Hast du mal einen Link zur Doku der Struktur des Journals? Jemand schrieb: > Jack V. schrieb: >> Daten selektiv auf ein anderes System zu bringen > > Was hindert dich? Siehe oben. Le X. hat schon Recht: in diesem Fall geht es, und ich habe auch nie was Anderes behauptet. Ich halte es aber schlicht für Unfug, Nutzdaten zunächst in das Systemlog zu schreiben, und sie dann im Anschluss wieder rauszupopeln, um sie weiterzuverarbeiten. Welchen Vorteil soll das haben? @Typ: die Nennung eines der vielen Programme (deine Aussage), die ihre Nutzdaten ins Syslog schreiben, steht weiterhin aus. Wenn du so lieb wärest, das mal nachzuliefern?
Ein T. schrieb: > Auf all diesen Systemen laufen entweder periodisch > Skripte (Cron, systemd-timer), um veraltete Logdaten zu löschen, oder > die Software selbst hat Mechanismen zum Aufräumen veralteter Daten. Denn > so ist das nun einmal mit Logdaten: mit zunehmendem Alter verlieren sie > an Wert und sind irgendwann wertlos. Bei RRDBs wird dem durch Verringerung der Zeitauflösung Rechnung getragen. Hoffentlich kann das Multimeter überhaupt sekündlich Werte liefern ;-) Mir scheint, dass es da noch etwas an einem Messkonzept fehlt.
Jack V. schrieb: > Hast du mal einen Link zur Doku der Struktur des Journals? Das Format ist hier beschrieben: https://www.freedesktop.org/wiki/Software/systemd/journal-files/ Jack V. schrieb: > in diesem Fall geht es, und ich habe auch nie was > Anderes behauptet. > Es bietet keine sinnvolle Möglichkeit, Das klingt aber schon so Jack V. schrieb: > Ich halte es aber schlicht für Unfug, Nutzdaten > zunächst in das Systemlog zu schreiben, Dem widerspreche ich nicht, eine Konklusion als Argument zu nehmen, halte ich aber dennoch für ziemlich unelegant.
Jemand schrieb: > eine Konklusion als Argument zu nehmen, > halte ich aber dennoch für ziemlich unelegant. Dann andersrum: was genau lässt denn das Speichern von Nutzdaten im Systemlog, wo sie dann zum Verarbeiten oder/und Archivieren ausgelesen und in eine eigene Datei geschrieben werden, sinnvoller erscheinen, als sie beispielsweise gleich in eine Datei zu schreiben? Typ hatte das Argument „da kann man Daten anhängen“ angeführt – aber man kann noch viel einfacher eine Datei zum Anhängen öffnen. Typ hatte angeführt, dass ein schwacher Rechner ein paar Bytes in der Sekunde unter Umständen nicht sicher weggeschrieben bekäme – aber wenn er das nicht schafft, schafft er’s noch weniger, unter diesen Umständen das Journal zu schreiben. Was also wäre ein sachliches Argument dafür, Nutzdaten zunächst in das Systemlog, statt gleich in eine eigene Datei zu schreiben? Jemand schrieb: > Jack V. schrieb: >> Es bietet keine >> sinnvolle Möglichkeit, die Daten darin zu verwalten, etwa nicht mehr >> benötigte Daten zu löschen, selektiv Daten zu sichern, die Daten ohne >> einen kompletten Suchdurchlauf auf einmal auszulesen, Daten zu >> bearbeiten, und selektiv Daten aufzubewahren, Daten selektiv auf ein >> anderes System zu bringen, etc. > > Das klingt aber schon so (hab zur besseren Nachvollziehbarkeit das Problem mit dem fehlerhaften Zitat behoben) Wie löscht man denn mit journalctl etwa eine bestimmte Messreihe, wie sichert man eine bestimmte Messreihe innerhalb dieses Journals, so dass die beim Rausrotieren des Zeitraums nicht verschwindet, wie ändert man einzelne Daten, und wie bringt man eine Messreihe auf ein anderes System, ohne entweder doch eine eigene Datei zu schreiben, oder den gesamten Journalauszug mitzuschicken? @Typ: bitte sei doch so gut, und benenne noch eines dieser vielen Programme, die ihre Nutzdaten in das Systemlog schreiben.
:
Bearbeitet durch User
Jack V. schrieb: > Wie löscht man denn mit journalctl etwa eine bestimmte Messreihe Gar nicht, deswegen kritisiere ich diesen Punkt auch überhaupt nicht. Jack V. schrieb: > wie sichert man eine bestimmte Messreihe innerhalb dieses Journals Sie muss mit entsprechendem Filter irgendwo hin exportiert werden. Jack V. schrieb: > wie ändert man einzelne Daten Gar nicht, deswegen kritisiere ich diesen Punkt auch überhaupt nicht. Jack V. schrieb: > und wie bringt man eine Messreihe auf ein anderes System, ohne entweder > doch eine eigene Datei zu schreiben, oder den gesamten Journalauszug > mitzuschicken? Der journalctl-Befehl gibt dir die Einträge beliebig gefiltert in einem Format deiner Wahl aus. Ob du das in eine Datei schreibst oder über TCP-Socket über die halbe Welt schickst ist journald egal, ebenso schreibt es dir nicht vor, ob du daraus mit systemd-journal-remote wieder ein neues Journal erstellst oder es direkt in eine SQL-Datenbank fütterst. Wenn es dich erheitert, kannst du sogar z. B. über die Python-API das Journal direkt lesen. Messdaten in das Systemjournal zu hämmern halte ich auch nicht für sinnvoll, aber es gibt wirklich genügend Möglichkeiten an dort geloggte Daten problemlos ranzukommen. Zumindest kann man gegenüber einer DIY-Lösung am definierten Format und die existierenden Werkzeuge für temporale Schlüssel-Wert-Paare (inklusive Binärblobs) profitieren.
Jemand schrieb: > Jack V. schrieb: >> Wie löscht man denn mit journalctl etwa eine bestimmte Messreihe > > Gar nicht, deswegen kritisiere ich diesen Punkt auch überhaupt nicht. Irgendwie scheint unser Jack eine etwas merkwürdige Vorstellung von Meßreihen zu haben. Mein Verständnis ist, daß entweder alle oder keine Datensätze gelöscht werden. Einzelne Datensätze aus einer Meßreihe zu löschen würde diese Meßreihe verfälschen und somit invalidieren -- und Ausreißer werden allenfalls während der Auswertung gefiltert, aber niemals gelöscht. > Jack V. schrieb: >> wie sichert man eine bestimmte Messreihe innerhalb dieses Journals > > Sie muss mit entsprechendem Filter irgendwo hin exportiert werden. ...was dank journalctl(1) und Pythons systemd.journal.Reader sehr einfach ist, siehe dazu auch das Progrämmchen "temperature-reader.py" im Anhang. Ein Unitfile für einen systemd-service und das Skriptlein zum Lesen des Journals liegen ebenfalls bei, um mal praktisch zu zeigen, wie einfach das ist. > Jack V. schrieb: >> wie ändert man einzelne Daten > > Gar nicht, deswegen kritisiere ich diesen Punkt auch überhaupt nicht. Ich wüßte auch gar nicht, was es da zu kritisieren gäbe? Zumal zum Ändern von geloggten Meßdaten dasselbe zu sagen ist wie oben zum Löschen. Wer kommt auf die irrwitzige Idee, geloggte Daten nachträglich manipulieren zu wollen? > Messdaten in das Systemjournal zu hämmern halte ich auch nicht für > sinnvoll, Hier wollte der TO ja nur sekündlich einzelne Meßwerte von einem DMM loggen und hat dafür etwas Fertiges gesucht. Klar, dafür kann man ein RDBMS installieren oder sich irgendwelche Behelfe mit SQLite oder CSV basteln, aber im Kern hat so ziemlich jedes Linux- und UNIX-System bereits etwas zum Loggen dabei. Für diesen Anwendungsfall kann man das schon nehmen. > aber es gibt wirklich genügend Möglichkeiten an dort geloggte > Daten problemlos ranzukommen. Zumindest kann man gegenüber einer > DIY-Lösung am definierten Format und die existierenden Werkzeuge für > temporale Schlüssel-Wert-Paare (inklusive Binärblobs) profitieren. Ich hab's mal mit Daten aus lm-sensors und in JSON gemacht, siehe Anhang.
Oh, nun hast du doch glatt schon wieder vergessen, eines der so vielen Programme zu nennen, die ihre Nutzdaten ins Journal schreiben. Könntest du das bitte noch schnell nachholen? Zu den Operationen auf den Messdaten: du hast genausowenig Ahnung, wie alle anderen hier, was der TE genau vor hat. Messreihe löschen: Testmessung, vorläufige und verworfene Testaufbauten. Einzelne Messdaten löschen: Ausreißer, etwa durch äußere Einflüsse. Messdaten ändern: etwa Daten mit anderen Daten verknüpfen. So als Beispiele. Es sei denn, dir wären Anforderungen des TE bekannt, die dem entgegenstehen, etwa dass die Daten explizit manipulationssicher gespeichert werden sollen (wobei’s auch dafür dann bessere Methoden gibt, als das Systemlog vollzuschmieren), oder dass es okay ist, dass die Daten nach einer gewissen Zeit mit dem Rest des Logs rausrotiert werden. Zumindest ich kann keine diesbezüglichen Aussagen seitens des TE erkennen. Ein T. schrieb: > Hier wollte der TO ja nur sekündlich einzelne Meßwerte von einem DMM > loggen und hat dafür etwas Fertiges gesucht. Klar, dafür kann man ein > RDBMS installieren oder sich irgendwelche Behelfe mit SQLite oder CSV > basteln, aber im Kern hat so ziemlich jedes Linux- und UNIX-System > bereits etwas zum Loggen dabei. Für diesen Anwendungsfall kann man das > schon nehmen. Ja, natürlich kann man auch das Syslog damit vollmüllen, und den Kram anschließend dann doch wieder umständlich rauspopeln, um ihn zur weiteren Verarbeitung in eine Datei zu schreiben. Aber im Kern hat so ziemlich jedes Linuxsystem die Werkzeuge zum einfachen Anhängen an eine Datei schon dabei: O_APPEND, bzw. Mode a bei fopen() (gem. POSIX-Kram) – für diesen Anwendungsfall kann man das schon nehmen. Jede gängige Sprache, incl. der Shells, bieten Zugriff auf diese Funktion. Bevor du es wieder vergisst, hier nochmal die Wiederholung der Bitte nach der Benennung einer Software, die ihre Nutzdaten in das Systemlog schreibt. Wenn du dann so gut wärest, doch zumindest ein Beispiel zur Stützung deiner Behauptung aufzählen zu können?
:
Bearbeitet durch User
Jack V. schrieb: > Oh, nun hast du doch glatt schon wieder vergessen, eines der so vielen > Programme zu nennen, die ihre Nutzdaten ins Journal schreiben. Könntest > du das bitte noch schnell nachholen? Es ist zwar lustig, aber nicht besonders seriös, meine Aussage erst gezielt falsch zu verstehen und dann zu versuchen, mich darauf festzunageln. Aber weil Du so lieb darum bittest, würden mir da etwa Auditd und PGAudit einfallen. > Zu den Operationen auf den Messdaten: du hast genausowenig Ahnung, wie > alle anderen hier, was der TE genau vor hat. Deswegen orientiere ich mich einfach an dem, was er geschrieben hat: Loggen von Meßdaten unbekannter Herkunft, besonders gern mit etwas Fertigem. > Ja, natürlich kann man auch das Syslog damit vollmüllen, und den Kram > anschließend dann doch wieder umständlich rauspopeln, um ihn zur > weiteren Verarbeitung in eine Datei zu schreiben. Um die Systemlogs nicht vollzumüllen, bietet sich ein eigener Namespace an. Darüber läßt sich bei Bedarf auch ein separates Housekeeping festlegen. Ich sehe auch kein "umständlich rauspopeln". Dafür nutze ich hier in diesem Falle ganz einfach das Syslog-Tag bzw. den SyslogIdentifier, aber man könnte natürlich auch einen Namespace nehmen -- das ist ja alles bereits vorhanden. Gerade das ist der Vorteil des strukturierten Logging im journald. > Aber im Kern hat so > ziemlich jedes Linuxsystem die Werkzeuge zum einfachen Anhängen an eine > Datei schon dabei: O_APPEND, bzw. Mode a bei fopen() (gem. POSIX-Kram) – > für diesen Anwendungsfall kann man das schon nehmen. Jede gängige > Sprache, incl. der Shells, bieten Zugriff auf diese Funktion. Richtig, aber die meisten Linuxsysteme haben eben auch ein Subsystem zum Event-Logging dabei, und so ein bisschen Pippifax wie die überschaubaren Datenmengen des TO paßt da zweifellos noch locker hinein. Am Rande bemerkt ist der Aufruf von Systembefehlen aufgrund der dafür notwendigen Kontextwechsel leider auch nicht so ganz billig, gerade das Öffnen von Dateien. Ehrlich gesagt ist es mir ein wenig unverständlich, warum Du auf meinen kleinen Hack so aggressiv und unsouverän reagierst. Hast Du da einen persönlichen Bezug?
@ von Ein T. (ein_typ): was ist eigentlich dein Problem? Dass man die Aufgabenstellung mit einem Syslog irgendwie hinkriegt haben doch mehrere der Anwesenden dir bestätigt. Einen Preis für die beste Lösung wirst du aber nicht erwarten können, egal wielange du hier noch rumschwadronierst.
:
Bearbeitet durch User
Ein T. schrieb: > Hier wollte der TO ja nur sekündlich einzelne Meßwerte von einem DMM > loggen und hat dafür etwas Fertiges gesucht. Klar, dafür kann man ein > RDBMS installieren oder sich irgendwelche Behelfe mit SQLite oder CSV > basteln, aber im Kern hat so ziemlich jedes Linux- und UNIX-System > bereits etwas zum Loggen dabei. Für diesen Anwendungsfall kann man das > schon nehmen. Moment, Stop. Du verschweigst hier die Hälfte der Aufgabenstellung. Das Loggen der Messwerte ist nur die halbe Miete. Später soll das ganze in einer GUI visualisiert werden. Und spätestens dann wird dein Syslog endgültig zur Krücke. Grafana kann direkt auf RDBMS zugreifen, Excel (oder LibreOffice Calc) kann direkt csv-Dateien lesen und graphisch darstellen. Deine Syslog-Einträge musst du erstmal herausfiltern und in ein zur Darstellung geeignetes Format konvertieren. Warum also einen Umweg gehen? Wenn man also die Aufgabenstellung komplett betrachtet verschieben sich die Vorteile schon sehr in Richtung "kein Syslog". @ TO: wie hast du das denn mittlerweile gelöst?
:
Bearbeitet durch User
Ein T. schrieb: > irgendwelche Behelfe mit SQLite Wie ich schon oben bekundet habe, das ist alles andere als ein Behelf. Das Speichern ist eine simple Zeile, die Moeglichkeiten, das gefiltert und vorbehandelt wieder abzufragen, sind Gold wert. Ich jedenfalls benutze keine CSV mehr, seit ich sqlite begriffen habe. Abspeichern, sqlite3, Wert steht in $temp_gs,Timestamp macht die DB selbst:
1 | INSERT INTO temp_gs (t_gefriers) VALUES ($temp_gs); |
Abrufen, z.B. Mittelwert, Maximum, Minimum, der letzten 1440 Werte (24h * 60):
1 | SELECT AVG(t_gefriers), MIN(t_gefriers), MAX(t_gefriers) FROM (SELECT t_gefriers FROM temp_gs ORDER BY timestamp DESC LIMIT 0,1440); |
Fuer sicher alle Programmiersprachen gibt es die Einbindung, ich selbst nutze Perlscripts und C.
:
Bearbeitet durch User
Le X. schrieb: > Du verschweigst hier die Hälfte der Aufgabenstellung. > Das Loggen der Messwerte ist nur die halbe Miete. Später soll das ganze > in einer GUI visualisiert werden. Das stimmt:
1 | #!/usr/bin/env python
|
2 | '''plot temperature from systemd journal''' |
3 | import json |
4 | import argparse |
5 | |
6 | import pandas as pd |
7 | from systemd import journal |
8 | import matplotlib.pyplot as plt |
9 | |
10 | |
11 | if __name__ == '__main__': |
12 | parser = argparse.ArgumentParser(description='read temperature logs') |
13 | parser.add_argument('identifier', default='temperature-logger', nargs='?', |
14 | help='syslog tag, default: "temperature-logger"') |
15 | args = parser.parse_args() |
16 | reader = journal.Reader() |
17 | reader.add_match(SYSLOG_IDENTIFIER=args.identifier) |
18 | datas = [] |
19 | for entry in reader: |
20 | data = {'timestamp': entry.get('__REALTIME_TIMESTAMP', None)} |
21 | data.update(json.loads(entry.get('MESSAGE', None))) |
22 | datas.append(data) |
23 | pd.DataFrame(datas).plot( |
24 | x='timestamp', y=['core_0', 'core_1', 'core_2', 'core_3']) |
25 | plt.show() |
> Und spätestens dann wird dein Syslog endgültig zur Krücke. > Grafana kann direkt auf RDBMS zugreifen, Soweit ich weiß, kann Grafana auch auf das Syslog zugreifen. > Wenn man also die Aufgabenstellung komplett betrachtet verschieben sich > die Vorteile schon sehr in Richtung "kein Syslog". Also stattdessen lieber ein DBMS und Grafana installieren und konfigurieren? Vor allem, wenn man bislang weder das Eine, noch das andere hat, und sich mit beidem (noch?) nicht auskennt? Hm, ich weiß nicht recht...
Ein T. schrieb: > Aber weil Du so lieb darum bittest, würden mir da etwa > Auditd und PGAudit einfallen. Dies sind keine Anwendungsprogramme, und sie schreiben Infos das System (auditd) bzw. darauf laufender Software (pgaudit) betreffend ins Log – keine Nutzdaten. Und natürlich ist es legitim, wenn auch tatsächliche Anwendungsprogramme, die auf dem System laufen, ihre Logdaten in das Systemlog schreiben. Du propagierst hier jedoch die ganze Zeit etwas ganz Anderes, nämlich dass von außen kommende, das System also überhaupt nicht betreffende, Messwerte in das Systemlog geschrieben werden sollen, weil das ja so toll geeignet wäre, und weil es eine Reihe von Anwendungsprogrammen geben würde, die das ja auch machten. Nun benenne bitte eines der Programme, die ihre Nutzdaten in das Systemlog schreiben.
Le X. schrieb: > @ von Ein T. (ein_typ): > was ist eigentlich dein Problem? Wie kommst Du darauf, daß ich ein Problem hätte?
Nano schrieb: > Er muss auf die GPIO des Raspberry Pi zugreifen, da das DMM die Daten > per RS-232 Schnittstelle liefert. Das ist doch falsch. Die UARTs des Rapsberry's werden wie unter allen Linuxen per "/dev/tty..." angesprochen. Dazu braucht man keine GPIOs. Die Treiber gehören zum Kernel. Auch die Treiber USB-Wandler von FTDI sind da schon integriert. Testen kann man das z.B. mit minicom. Es sind halt TTL-UART (5V oder eher sogar 3,3V) und keine RS232 o.dergl.
Wendels B. schrieb: > Ein T. schrieb: >> irgendwelche Behelfe mit SQLite > > Wie ich schon oben bekundet habe, das ist alles andere als ein Behelf. Leider hab' ich mittlerweile schon zu oft gesehen, wie am Ende mehrere schreibende Prozesse auf dieselbe SQLite-Datei zugreifen sollten und dann ein Riesenaufwand zur Synchronisation betrieben werden mußte. SQLite ist toll, wenn garantiert ist, daß immer nur ein einziger Prozeß schreibend darauf zugreift. Versteh' mich bitte nicht falsch: ich kenne und mag SQLite, aber ich kenne auch seine seine Grenzen. Für ein Append-Only-Log auf einem Raspberry Pi ist SQLite schon wegen seines Write-Ahead-Log genauso schwierig wie die klassischen SQL-RDBMS. Jeder Schreibzugriff der Applikation erzeugt drei schreibende Zugriffe auf das Persistierungemedium, das im Falle des RasPi obendrein meistens eine SD-Karte ist. Zum Sammeln von Append-Only-Logs sind klassische RDBMS nun einmal keine sonderlich sinnvolle Lösung -- AOLs benötigen weder Relationen noch Transaktionen, werden ein einziges Mal geschrieben, sind danach immutable und werden nurmehr gelesen, und eine zeilenorientierte Speicherung ist für statistische Auswertungen wesentlich weniger gut geeignet als ein spaltenorientiertes Format. Für die Bedürfnisse des TO spielt das keine große Rolle, aber wenn es um größere Datenmengen ginge, würde ich eher zu einem Spezialisten wie Apache BookKeeper oder PostgreSQL mit TimescaleDB neigen. > Das Speichern ist eine simple Zeile, Eine Zeile SQL, ja... aber zum Ausführen des SQL-Statement braucht man ja ein Connection Handle, einen Cursor, connect(), cursor(), execute(), commit(), cursor.close(), connection.close()... > die Moeglichkeiten, das gefiltert > und vorbehandelt wieder abzufragen, sind Gold wert. Das ist in vielen Fällen so, aber im vorliegenden Fall würde ich vermuten, daß das keine besonders hohe Priorität hat. Ich meine, wir reden vom Plotten eines einzigen Datenpunktes, nämlich des Meßwertes eines DMM über einen bestimmen Zeitraum. Müssen diese Daten großartig gefiltert und vorbehandelt werden? > Ich jedenfalls benutze keine CSV mehr, seit ich sqlite begriffen habe. Ja, das meinte ich ja weiter oben: wer nur einen Hammer hat, für den sieht jedes Problem wie ein Nagel aus. Aber sei unbesorgt, Du bist in bester Gesellschaft, etliche auch sehr erfahrene und fähige Entwickler aus meinem Freundes-, Bekannten- und Kollegenkreis greifen geradezu reflexartig zu relationalen SQL-Datenbanken, sobald es um die Speicherung strukturierter Daten geht. Das kann man machen, aber das ändert ja nichts daran, daß relationale SQL-Datenbanken für viele Arten von Daten nunmal nicht die ideale Wahl sind.
Jack V. schrieb: > Ein T. schrieb: >> Aber weil Du so lieb darum bittest, würden mir da etwa >> Auditd und PGAudit einfallen. > > Dies sind keine Anwendungsprogramme, und sie schreiben Infos das System > (auditd) bzw. darauf laufender Software (pgaudit) betreffend ins Log – > keine Nutzdaten. Das sind Nutzdaten, nichts anderes. Und wer Audit-Daten auf dem System speichert, auf dem sie anfallen, der hat das ganze Thema nicht verstanden. > Nun benenne bitte eines der Programme, die ihre Nutzdaten in das > Systemlog schreiben. Hab' ich gerade, und jetzt darfst Du alleine mit Deinem Strohpüppchen weiterspielen. Es scheint übrigens immer noch so zu sein, daß Du das ganze irgendwie persönlich nimmst. Was ist denn Dein Problem?
Und noch eine Kleinigkeit... wenn du sekündlich auf die SD Karte schreibst, ist sie nach einigen Jahren defekt. Das nervige - es geht so lange gut, bis du die Backups vernachlässigst und vergessen hast, wie die Kopie der SD Karte liegt.
Ein T. schrieb: > Leider hab' ich mittlerweile schon zu oft gesehen, wie am Ende mehrere > schreibende Prozesse auf dieselbe SQLite-Datei zugreifen sollten Du widersprichst Dir selbst weiter unten: Ein T. schrieb: > Ich meine, wir > reden vom Plotten eines einzigen Datenpunktes, Ein T. schrieb: > Eine Zeile SQL, ja... aber zum Ausführen des SQL-Statement braucht man > ja ein Connection Handle, einen Cursor, connect(), cursor(), execute(), > commit(), cursor.close(), connection.close()... Eine csv musst Du auch am Anfang oeffnen und am Ende schliessen. Ein Ratschlag schrieb: > wenn du sekündlich auf die SD Karte schreibst, ist sie nach einigen > Jahren defekt. Das vermeide ich, indem die aktuelle DB in /dev/shm liegt und einmal pro Tag alle Werte, die noch nicht darin sind, in die DB auf der Karte geschrieben werden. Das koennte man auch stuendlich, 2h, 4h, 6h machen, ganz wie es noetig und die Daten wichtig sind.
:
Bearbeitet durch User
Wendels B. schrieb: > Ein T. schrieb: >> Leider hab' ich mittlerweile schon zu oft gesehen, wie am Ende mehrere >> schreibende Prozesse auf dieselbe SQLite-Datei zugreifen sollten > Du widersprichst Dir selbst weiter unten: Nein, ich drücke mich mißverständlich aus... > Ein T. schrieb: >> Ich meine, wir >> reden vom Plotten eines einzigen Datenpunktes, Richtig wäre: einer Zeitreihe eines... > Ein T. schrieb: >> Eine Zeile SQL, ja... aber zum Ausführen des SQL-Statement braucht man >> ja ein Connection Handle, einen Cursor, connect(), cursor(), execute(), >> commit(), cursor.close(), connection.close()... > > Eine csv musst Du auch am Anfang oeffnen und am Ende schliessen. Ja, klar, das bestreitet ja niemand. > Ein Ratschlag schrieb: >> wenn du sekündlich auf die SD Karte schreibst, ist sie nach einigen >> Jahren defekt. > > Das vermeide ich, indem die aktuelle DB in /dev/shm liegt und einmal pro > Tag alle Werte, die noch nicht darin sind, in die DB auf der Karte > geschrieben werden. > Das koennte man auch stuendlich, 2h, 4h, 6h machen, ganz wie es noetig > und die Daten wichtig sind. Wenn es eine Option ist, die Daten erst einmal flüchtig zwischenzuspeichern, würde ich eher zu Redis greifen. Damit hätte man mit einer entsprechenden Konfiguration dann auch eine vollautomatische Persistierung, gegebenenfalls ein Housekeeping, sowie das automatische Speichern und Wiederherstellen der Daten im Falle eines geordneten Restart oder Reboot... und einen Haufen netter Dinge mehr.
Ein T. schrieb: > Nein, ich drücke mich mißverständlich aus.. Was mich da gestoert hat, war: wieso sollte ein einziges Messergebnis von mehreren Prozessen in eine DB geschrieben werden? Ein T. schrieb: > eher zu Redis greifen. Muss ich mir mal ansehen.
:
Bearbeitet durch User
Redis und ich werden zum jetzigen Zeitpunkt keine Freunde. Schon dass
1 | set time (time) |
nicht den aktuellen Zeitstempel speichert, schreckt mich ab. Das wieder zu Fuss zu machen, darauf hab ich keinen Bock mehr.
> wieso sollte ein einziges Messergebnis > von mehreren Prozessen in eine DB geschrieben werden? Irgendwann willst du grafische Auswertungen über das ganze Jahr anzeigen. Stellst fest "select max(wert) group by day" dauert viel zu lange. Falls du nun auf die Idee kommen solltest, du schreibst einen Cron-Job, der die konsolidierten Daten in zusätzliche Tabellen schreibt, hast du mehrere Prozesse, die auf die selbe DB schreiben.
Wendels B. schrieb: > Ein T. schrieb: >> Nein, ich drücke mich mißverständlich aus.. > Was mich da gestoert hat, war: wieso sollte ein einziges Messergebnis > von mehreren Prozessen in eine DB geschrieben werden? Hatte ich oben ausgeführt, als es noch darum ging, besagten Prozeß extern (etwa durch so etwas wie Cron oder einen systemd.timer) anzustoßen. So ein Raspberry Pi ist ja je nach Modell leider nicht allzu performant, und so kann es je nach Last und nach der Zuverlässigkeit des auszulesenden DMM durchaus dazu kommen, daß der Prozeß länger als eine Sekunde braucht, um das Meßergebnis zu lesen. In diesem Fall kann es dazu kommen daß ein zweiter Prozeß gestartet wird, während der erste noch läuft, so daß die Datei von beiden Prozessen zur gleichen Zeit... you get the idea.
Wendels B. schrieb: > Redis und ich werden zum jetzigen Zeitpunkt keine Freunde. > Schon dass >
1 | set time (time) |
> nicht den aktuellen Zeitstempel speichert, schreckt mich ab. > Das wieder zu Fuss zu machen, darauf hab ich keinen Bock mehr. Redis ist nun einmal kein SQL-RDBMS. Was Du möchtest, läßt sich aber sehr leicht mit einem serverseitigen EVAL-Script oder, ab Redis Version 7.0 vermutlich sogar noch komfortabler, einer benutzerdefinierten Redis-Funktion erledigen.
Le X. schrieb: > @ TO: wie hast du das denn mittlerweile gelöst? Wie schon weiter oben beschrieben mit meinem Skript, Influxdb und Grafana. Es hat noch einen Moment gedauert, weil das DMM ein spezielles Kabel brauchte und einen 25pol Stecker bereitstellt, mein billig USB Adapter ebenfalls nur einen Stecker hatte. Nun habe ich einen Adapter gebaut und das funktioniert mit meinem rudimentären Skript wunderbar. Kann über Argumente angeben, ob die Datenbank gelöscht wird, ein neuer Name vergeben wird und ob Strom oder Spannungsmessung angefortert werden soll. Aktuell wird sogar alle 0.5s abgerufen. Bei 0.25 streikt das Messgerät, aber 0.5 ist für meinen Zweck total ausreichend. Es ist auch nicht geplant das ganze 345 Tage durchlaufen zu lassen mit der SD Karte und wenn dann hätte ich noch eine HDD für den Raspberry. Mir ging es wirklich darum schnell eine Lösung zu finden. Von Influx und Grafana hatte ich noch nie gehört und hatte da aber in kurzer Zeit alles fertig inklusiver Darstellung. Perfekt, danke für die Empfehlung
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.