Seit Buster läuft Script nicht mehr

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
PromiseYou
User
Beiträge: 4
Registriert: Mittwoch 9. Oktober 2019, 16:20

Hi Ho und Hallo :)

Ich habe da ein Problem, und komme irgend wie nicht weiter :(

Ich hatte (habe) RPi 3 und nun auch RPi 4. Auf dem 3 hatte ich einen Sambaserver, und eine MariaSQL DB laufen. In der DB wurden Temperatur und Luftfeuchtigkeitsdatengesammelt.
Diese Daten wurden vom SDR Tool rtl_433 empfangen und im JSON-Format an meine PIPE geschickt, welche den Eintrag in die Datenbank vornimmet.
Nach der Umstellung auf Buster haut das Script jedoch nicht mehr hin :(

Hier das Script, welches vorher monatelang einwandfrei lief:

Code: Alles auswählen

#!/usr/bin/env python

import pymysql
import json
import sys

dbConn = pymysql.connect(host='192.168.2.11',
                         user='p??,
                         password='??????',
                         db='TemperaturenDB',
                         charset='utf8mb4',
                         cursorclass=pymysql.cursors.DictCursor)
#Cursor einrichten
dbCur = dbConn.cursor()

for line in sys.stdin:
    daten = json.loads(line.strip())
    dbCur.execute('insert into mitschnitt (inhalt) values (%s)', (str(daten)))
    dbConn.commit()
aufgerufen wurde das Script via 'rtl_433 -R 01 -R91 -F json | kurzschreiben.py' (kurzschreiben ist das obige Listing)
Nach dem Start bricht das Script ohne eine Fehlermeldung ab. Bei dem Test das IMPORT falsch zu schreiben bekam ich jedoch eine Fehlermeldung.
Somit habe ich mit rtl_433 eine Ausgabedatei erstellt, und diese Zeilen dann als 'line' beim Debugen in der IDE wieder eingefügt. Jede Zeile, konnte ich auf dieser Weise der Datenbank hinzufügen.
Also muss die Datenbank funktionieren :) und das Script auch.
Somit habe ich dann versucht

Code: Alles auswählen

for line in sys.stdin:
	print(line)
jedoch auch hier bricht das Script einfach ab.

Hat jemand eine vielleicht einen Vorschlag, wohin ich meinen Blick richten soll?
Sirius3
User
Beiträge: 18270
Registriert: Sonntag 21. Oktober 2012, 17:20

„Einfach abbrechen” sagt ja, dass die for-Schleife niemals durchlaufen wird.
Was gibt denn nur 'rtl_433 -R 01 -R91 -F json' aus?

Zum Skript:
Das strip ist beim Laden von JSON unnötig.
Es ist wenig sinnvoll, eine Datenbank zu verwenden, wenn man nur Strings speichern will.
Noch weniger sinnvoll ist es, gut definierten JSON-Strings in die nur für debugging-Zwecke gedachte interne Repräsentation von Python-Strukturen umzuwandeln.

Wie sind die JSON-Daten strukturiert? Welche Einträge gibt es, die man als Datenbank-Felder definieren könnte?

Wenn ich das richtig nachgelesen habe, sollte das so aussehen:

Code: Alles auswählen

dbCur.execute('insert into mitschnitt (id, rid, channel, time, model, battery, temperature_C, humidity) values (%(id)s, %(rid)s, %(channel)s, %(time)s, %(model)s, %(battery)s, %(temperature_C)s, %(humidity)s)', daten)
Mit der passenden Tabelle und den passenden Feldern.
PromiseYou
User
Beiträge: 4
Registriert: Mittwoch 9. Oktober 2019, 16:20

Hallo Sirius,

vielen Dank für die Antwort.

Die Tabelle 'mitschnitt' ist eine temporäre Tabelle, aus der die Daten wieder ausgelesen werden.
Die Sensoren senden verschiedene Daten, also müsste ich beim Eingang der Daten prüfen, welcher Sender gerade sendet, um diese Daten zuzuordnen.
Leider gelingt es mir nicht, einen Code hinzubekommen, der es schafft, alle Routinen abzuarbeiten, bevor ein neues Signal kommt. Hinderlich daran ist, dass gewisse Sender bis zu vier Mal hintereinander das selbe Signal senden, welche herausgefiltert werden müssen. Das ist alles sehr zeitkritisch, und es brach immer ab.

Deshalb der Umweg über diese Tabelle.
Hier schreibt sozusagen das rtl_tool rein, wie in eine Datei, jedoch kann ich durch ein weiteres Script diese Zeilen dann in "Ruhe" abarbeiten.
Wie bereits geschrieben, ich habe die Datenbank im April in Betrieb genommen, und solange funktionierte dieses Umschreiben sehr gut. Das zweite Script füllt dann die eigentlichen Tabellen der Datenbank, wo die Temperaturdaten, Luftfeuchtigkeit, Luftdruck, etc ind entsprechende Zeittabellen eingetragen werden zur grafischen Auswertung, sowie die restlichen Daten zur Stammdatenverwaltung.

Mich irritiert nur, dass ich keinerlei Fehlermeldung erhalte, warum das Script nicht läuft.

In /var/log habe ich alle Dateien durchsucht, ob ich einen Eintrag finde, wo ich etwas herausfinden kann, leider ohne Erfolg :(

Tabelle 'mitschnitt' ist wie folgt aufgebaut:

Code: Alles auswählen

CREATE TABLE `mitschnitt` (
	`stempel` INT(11) NOT NULL AUTO_INCREMENT,
	`inhalt` VARCHAR(255) NOT NULL,
	`geschrieben` TINYINT(1) NULL DEFAULT 0 COMMENT '0 = neu; 1 = in DB; 2 = geprellt; 3 = unbekannter Sender',
	PRIMARY KEY (`stempel`),
	INDEX `inhalt` (`inhalt`(191)),
	INDEX `geschrieben` (`geschrieben`)
)
COLLATE='utf8mb4_general_ci'
ENGINE=InnoDB
ROW_FORMAT=COMPACT
AUTO_INCREMENT=1927387
;
Somit wird alles in das Feld "inhalt" geschrieben was dann wie folgt ausschaut:

Code: Alles auswählen

{"time" : "2019-10-06 13:34:23", "model" : "inFactory sensor", "id" : 129, "temperature_F" : 63.600, "humidity" : 60}
(nur eine Beispielzeile aus der Datenbank mit 'SELECT inhalt FROM mitschnitt LIMIT 1' abgefragt)

Bei der Fehlersuche habe ich auch das JSON raus genommen, und versucht die 'line' aus 'stdin' gleich in die Tabelle zu schreiben, jedoch auch ohne erfolg.
Derzeit schreibt rtl_433 in eine Datei mit der Ausgabe als JSON, somit kann ich diese Datei nun auch als neuen Input definieren, jedoch empfand ich die alte Lösung als die bessere.

Kann ich in MariaDB verfolgen, wann sich welcher User angemeldet hat? Also aknn ich nachvollziehen, ob das Script die Anmeldung an die DB vornimmt, und danach abbricht, oder schon vorher?
Sirius3
User
Beiträge: 18270
Registriert: Sonntag 21. Oktober 2012, 17:20

Ich glaube kaum, dass das Parsen von JSON und wieder serialisieren als String und schreiben in die Datenbank als String viel schneller geht, als das Parsen von JSON und das Schreiben von 5 Feldern in eine Datenbank.

Sollte das doch zu lange dauern, dann wäre das direkte Schreiben von rtl_433 in eine Datei und das "langsame" Verarbeiten dieser Datei wohl die beste Lösung.

Diese Mischmasch von verschiedenen Varianten ist aber undurchsichtig und fehleranfällig.

Liefert nun `rtl_433 -R 01 -R91 -F json` die gewünschten Daten, oder nicht?
PromiseYou
User
Beiträge: 4
Registriert: Mittwoch 9. Oktober 2019, 16:20

Hallo :)

Ja, rtl_433 liefert die richtigen Daten ! Das habe ich geprüft.
Jedoch habe ich nun Fehlermeldungen :)

Wenn ich das Tool mit meinem Script als Pipe starte, bekomme ich folgenden Fehler angezeigt:

Code: Alles auswählen

bash: /usr/local/sbin/kurzschreiben.py: /usr/bin/python3^M: Defekter Interpreter: Datei oder Verzeichnis nicht gefunden
dieses '^M' weiß ich nicht woher es kommt. Wenn ich nun ein Leerzeichen am Ende der Shebang Zeile stehen lasse erhalte ich folgenden Fehler:

Code: Alles auswählen

Registered 98 out of 125 device decoding protocols [ 1-4 8 11-12 15-17 19-21 23 25-26 29-36 38-60 62-63 67-71 73-100 102-103 108-116 119 121 124-125 ]
': [Errno 2] No such file or directory
Detached kernel driver

die erste Zeile stammt noch vom rtl_433, und besagt, dass ich keine Vorauswahl an decodern getroffen habe, dann kommt die Fehlermeldung, das rtl_433 die datei nicht finden kann.
Ich denke hier muss ich suchen ....
vielen Dank !
__deets__
User
Beiträge: 14545
Registriert: Mittwoch 14. Oktober 2015, 14:29

Das ^M zeugt davon, dass du die Datei mit Windows bearbeitet hast, mit einem ungeeigneten Editor. Windows fuehrt ein unnoetiges carriage return (\r in Python, ^M in vielen Editoren) ein. Das muss da raus. Stell also den Editor entsprechend ein, oder benutz einen, der das kann (wie zB notepad++).

Zur zweite Meldung kann ich nix sagen.
PromiseYou
User
Beiträge: 4
Registriert: Mittwoch 9. Oktober 2019, 16:20

Hallo __deets__

Das war es !!!! Vielen vielen Dank !!!!
Ich habe GEANY genutzt, und dort ist "windowskompatibel" angegeben gewesen ....
Und Thony hat mir keinen Fehler gemeldet ....

Nun läuft auch wieder das Script !!!!
Antworten