Zustände erfassen mittels QR-Codes

Begonnen von fhemRigge, 09 Januar 2022, 19:01:37

Vorheriges Thema - Nächstes Thema

fhemRigge

Hallo zusammen,

ich habe im Beitrag https://forum.fhem.de/index.php/topic,96535.0.html meinen Vorschlag für einen smarten Briefkasten vorgestellt. Darin habe ich nebenbei die QR-Codes erwähnt, die ich für die Zustandserfassung verwende. In diesem Beitrag stelle ich diese Lösung näher vor.

Problembeschreibung
Viele von uns verwenden batteriebetriebene Aktoren und Sensoren. Immer wenn ein Aktor oder Sensor "low battery" meldet, wird einfach die Batterie ausgetauscht. Aber niemand macht sich Notizen, wie oft an welchem Gerät die Batterie gewechselt wird. Dadurch fehlt die Möglichkeit festzustellen, ob es Auffälligkeiten gibt. Beispielsweise ein besonders hoher Energieverbrauch, weil besonders häufig agiert werden muss, etc.

Lösungsvorschlag und technische Umsetzung
Aus Projekten im Umfeld von "Industrie 4.0" kenne ich die Erfassung von Zuständen mittels QR-Codes. In meiner Heimautomation verwende ich diese Technik z.B. für:

  • die Erfassung der Anzahl an Batteriewechseln
  • den Zustand des Ventils der Außenwasserleitung

Für jedes zu überwachende Gerät wird ein Counter-Dummy angelegt. Ein Counter speichert Zeitpunkt und Zustand in Readings.

Beispiel:
Die Definition des Briefkastenschlitzes lautet:

define Briefkastenschlitz MAX ShutterContact xxxxxx
attr Briefkastenschlitz IODev CULMAX
attr Briefkastenschlitz alias Briefkastenschlitz


Die allgemeine Definition des Counters lautet:

define <Gerät>_Batteriewechsel_Counter dummy
attr <Gerät>_Batteriewechsel_Counter readingList Counter,Datum01,Datum02,Datum03,Datum04,Datum05,Datum06,Datum07,Datum08,Datum09,Datum10

Alle Counter-Dummies enden also mit dem selben Substring, das erleichert später die Definition des Notify.
Mit dieser Definition läßt sich ablesen, wie häufig die Batterie gewechselt wurde und wann sie die letzten 10 Mal gewechselt wurde.

Der Counter-Dummy für meinen Briefkastenschlitz sieht also so aus:

define Briefkastenschlitz_Batteriewechsel_Counter dummy
attr Briefkastenschlitz_Batteriewechsel_Counter readingList Counter,Datum01,Datum02,Datum03,Datum04,Datum05,Datum06,Datum07,Datum08,Datum09,Datum10


Das Notify, welches die URL-Aufrufe, die hinter den QR-Codes liegen, registriert, wird wie folgt definiert:

define Batteriewechsel_Event notify .*_Batteriewechsel_Counter {
my $cnt = ReadingsVal($NAME,"Counter","") + 1;
my $date00 = FmtDateTime(time());
my $date01 = ReadingsVal($NAME,"Datum01","");
my $date02 = ReadingsVal($NAME,"Datum02","");
my $date03 = ReadingsVal($NAME,"Datum03","");
my $date04 = ReadingsVal($NAME,"Datum04","");
my $date05 = ReadingsVal($NAME,"Datum05","");
my $date06 = ReadingsVal($NAME,"Datum06","");
my $date07 = ReadingsVal($NAME,"Datum07","");
my $date08 = ReadingsVal($NAME,"Datum08","");
my $date09 = ReadingsVal($NAME,"Datum09","");
fhem("set $NAME $cnt");
fhem("setreading $NAME Counter $cnt");
fhem("setreading $NAME Datum01 $date00");
fhem("setreading $NAME Datum02 $date01");
fhem("setreading $NAME Datum03 $date02");
fhem("setreading $NAME Datum04 $date03");
fhem("setreading $NAME Datum05 $date04");
fhem("setreading $NAME Datum06 $date05");
fhem("setreading $NAME Datum07 $date06");
fhem("setreading $NAME Datum08 $date07");
fhem("setreading $NAME Datum09 $date08");
fhem("setreading $NAME Datum10 $date09");
}

Da alle Counter-Dummies auf den selben Substring enden, reicht 1 Notify.

Da die QR-Codes teilweise für alle (Gäste) sichtbar sind und ich Missbrauch vermeiden möchte, habe ich mir ein spezielles FHEMWEB definiert:

define WEBapi FHEMWEB 8088 global
attr WEBapi allowfrom xxx.xxx.xxx.xxx|xxx.xxx.xxx.xxx|127.0.0.1
attr WEBapi csrfToken csrf_xxxxxxxxxxxxxxx

Im Attribut allowfrom habe ich die IP meines Smartphones hinterlegt.
Im Attribut csrfToken habe ich ein eiges Token hinterlegt, andernfalls vergibt FHEM dynamisch Tokens.

URLs und QR-Codes
Für jedes Gerät (genauer, für jeden Counter-Dummy) gibt es eine eigene URL. Ihr allgemeiner Aufbau sieht so aus:
http://fhem:8088/fhem?cmd=trigger%20<Gerät>_Batteriewechsel_Counter&fwcsrf=csrf_xxxxxxxxxxxxxxx
Domain und Port muss natürlich jeder für sich anpassen.
Es wird das Kommando trigger verwendet.
Es wird einer der definierten Counter-Dummies getriggert.
Der CSRF-Token wurde zuvor im FHEMWEB definiert.

Für meinen Briefkastenschlitz sieht die URL so aus:
http://fhem:8088/fhem?cmd=trigger%20Briefkastenschlitz_Batteriewechsel_Counter&fwcsrf=csrf_xxxxxxxxxxxxxxx

Im Internet gibt es QR-Code Generierer, mit deren Hilfe sich die QR-Codes erstellen und als Bild speichern lassen. Ich notiere mir neben dem QR-Code dann immer noch den Alias des Geräts, zur Kontrolle.

Ablauf

  • Batterieabdeckel abnehmen
  • Batterie wechseln
  • QR-Code im Batterieabdeckel mit dem Smartphone scannen
  • Batterieabdeckel einsetzen
Die App, mit der ich den QR-Code scanne, lädt die im QR-Code hinterlegte URL. Ein Notify in FHEM registriert den Aufruf, wertet ihn aus und erhöht entsprechend den Batteriewechsel-Zähler für dieses Gerät.

Erfahrung
Die Lösung funktioniert prima für mich :-)
Das Bild 01_Briefkasten_mit_geoeffneter_Tuere.jpg zeigt den aufgeklebten QR-Code auf der Abdeckung des MAX ShutterContact. In 02_Batterwiewechsel_Status_in_FHEM.png sieht man die Counter, wie sie auf meiner Status-Seite in FHEM eingebunden sind. Und Bild 03_Readings_Briefkastenschlitz.png zeigt die Readings für den Briefkastenschlitz.

Vor- und Nachteile
Evtl. läßt sich der Code des Notify mit einem schönen Loop verbessern.
Die Lösung ermöglicht es, Prozesse quasi zu "digitalisieren". Beispielsweise wüsste ich im Moment nicht, wie ich das Absperrventil der Außenwasserleitung ersetzen könnte. Trotzdem möchte ich aber aus FHEM heraus über den Zustand informiert werden können und mich z.B. bei drohendem Frostschaden warnen lassen.
FHEM 6.1, Raspi Model B Rev 2 bullseye, CUL, nanoCUL, SIGNALduino, RFXtrx433, 1xHM-LC-Sw1-PI-DN-R1, 3xHM-LC-BL1PBU-FM, 1xMAX! Wandthermostat, 10xMAX! Heizkörperthermostat und einiges mehr.

MadMax-FHEM

#1
Zitat von: fhemRigge am 09 Januar 2022, 19:01:37
Problembeschreibung
Viele von uns verwenden batteriebetriebene Aktoren und Sensoren. Immer wenn ein Aktor oder Sensor "low battery" meldet, wird einfach die Batterie ausgetauscht. Aber niemand macht sich Notizen, wie oft an welchem Gerät die Batterie gewechselt wird. Dadurch fehlt die Möglichkeit festzustellen, ob es Auffälligkeiten gibt. Beispielsweise ein besonders hoher Energieverbrauch, weil besonders häufig agiert werden muss, etc.

Automatisch und ganz ohne QR-Codes (oder sonstige manuelle Abläufe, außer nat. Batterie wechseln ;) ):
https://forum.fhem.de/index.php/topic,82637.msg747514.html#msg747514

Allerdings (nur) mit meinen mittlerweile vorgenommenen Erweiterungen:
https://forum.fhem.de/index.php/topic,125227.msg1198471.html#msg1198471

"Berechnung" der Haltbarkeit in Wochen und auch "Prüfung", ob noch Batterien vom notwendigen Typ vorhanden sind, wenn nicht, wird bei der "Vorwarnung" (-> demnächst wechseln) eine "Bitte Batterie XYZ kaufen" mitgesendet :)

Aber: Befehle aufrufen per QR-Code ist ja sehr schick! :)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

rob

Klasse Idee und Anleitung. Gefällt mir :)

Kann man sich ja auf vieles adaptieren: wurde die Mülltonne lt. Kalender wirklich raus-/ reingestellt oder der Zähler (Gas|Strom|Wasser) abgelesen etc. pp.

Und wer die Webdienste scheut, installiert sich unter Linux "qrencode":
apt-get install qrencode
Start mit z.B.:

qrencode -t SVG --svg-path -o /tmp/myQR.svg "Hello world!"


Damit kann man aus FHEM heraus QRs automatisch generieren. Und wer ESPs + e-Ink-Displays sein Eigen nennt und vor Ort einsetzen mag, könnte die QR fortan auch automatisch verteilen wo nötig.

z.B. oben genannte dummies erweitern in der setList:

attr Briefkastenschlitz_Batteriewechsel_Counter setList generateQR:noArg

und via notify QR generieren

define nfyGenerateQR notify .*:generateQR {\
my $myurl="http://fhem:8088/fhem?cmd=trigger%20".$NAME."&fwcsrf=csrf_xxxxxxxxxxxxxxx";;\
qx(qrencode -t SVG --svg-path -o /opt/fhem/www/images/myQR.svg $myurl);;\
fhem(Log 1, "$EVENT was started for $NAME");;}


Da fallen mir doch gleich ein paar Use-Cases ein :D