Datenaustausch mit externem Programm (z.B. weewx)

[olwaldi]

Ich überlege, ob ich einige Daten aus meiner Wettersoftware weewx in fhem verfügbar machen sollte. Dazu gibt es viele Möglichkeiten. Meine Idee ist, daß weewx automatisch regelmäßig die interessierenden Daten als fhem-Skript generiert und fhem diese automatisch lädt. Die Daten sollen in einem dummy in einer readingList abgespeichert werden. Das Ganze sind nur 2..3 Zeilen fhem-Code:

Code Auswählen Erweitern

define weewx dummy
attr weewx readingList temp1 temp2 ...
define updateWeewx at +*00:05:00 include /var/www/html/weewx/fhem.cfg
In der Datei fhem.cfg (vielleicht ungeschickt gewählter Dateiname) werden die Werte durch z.B.

Code Auswählen Erweitern

set weewx temp1 23
set weewx temp2 10gesetzt. All das funktioniert prima, allerdings wird jeder include-Aufruf im log protokolliert. Laut KI könnte ich temporär den globalen Loglevel auf 0 erniedrigen. Ginge das auch eleganter? Auch unschön: keine Fehlerbehandlung, falls die Datei nicht existiert.

An meiner Lösung gefällt mir die extreme Kürze. Eleganter wären sicherlich mqtt oder json oder http.

Ein zweites Problem könnte im readingList liegen, etwa wenn ich 20 oder 30 Variablen übergeben will.


Grüßle, Michael

[Beta-User]

Kommt mir überkomplex vor.

Falls es nicht irgendwo eine MQTT-Lösung geben sollte (was ich annehme), würde ich inotify und/oder jsonMod/HTTPMOD als Stichwort in den Raum stellen...

[olwaldi]

Naja, diese Alternativen kommen mir komplexer vor. Für weewx gibt es ansatzweise MQTT-Support, und in meinem fhem müßte ich MQTT erst aktivieren. Ähnlich bzgl. json, gibts nur ansatzweise.

Daher empfinde ich ja meine include-Lösung ja als wesentlich unter-komplexer. Auf weewx-Seite hingegen ist es sehr einfach, ein beliebiges Outputformat erzeugen zu lassen, könnte auch problemlos ein json sein. Aber das müßte man auf fhem-Seite wieder dekodieren. Und genau das spare ich mit dem include. Aber json gucke ich mir mal an, da mir json als Standard auch recht gut gefällt.

Nachtrg: Habe mir JsonMod kurz angeschaut - würde mein Problem lösen. Und ich habe auch meine Idee auf die Schnelle programmiert. Beides hat Vor- und Nachteile. Durch die Nutzung von include spare ich mir das zusätzliche json-Parsen und eine etwas  aufwendigere Konfiguration in fhem. Andererseits muß ich den globalen verbose-Level VOR jedem include auf 0 setzen und hinterher wieder auf 3 (mein default). Das erledigt mein at automatisch, ist aber nicht wirklich elegant.

Letzendlich wollte ich ja nur wissen, ob man leicht Daten mit weewx austauschen kann, was ich klar bejahen kann. Aber aktuell habe ich keinen konkreten Bedarf.

Grüßle, Michael

[olwaldi]

Da mir Skripten Spaß macht (insbesondere hier das Durchreichen von Kommandos durch verschiedene Tool-Ebenen), habe ich meine Schnittstelle zwischen weewx & fhem in ein reines weewx-Template gegossen (anbei für Interessierte). Aktiviert wird das template einmalig in der skin.conf von weewx durch

Code Auswählen Erweitern

   [[ToDate]]
        ...
[[[weewxdata]]]
            template = weewxdata.cfg.tmpl
und in fhem durch einmaliges

Code Auswählen Erweitern

include /var/www/html/weewx/weewxdata.cfgAb dann generiert weewx regelmäßig zusammen mit dem "normalen" HTML-Output für den Web-Server alle 5min die Datei weewxdata.conf. Und fhem lädt diese Datei jeweils 1min später.

Mir persönlich gefällt an dieser Lösung, daß das Alles in eine Datei (Python Cheetah template in weewx) gesteckt werden kann. Nicht gefällt mir, daß ich den verbose-Level von fhem regelmäßig auf 0 setzen muß, um Einträge im Logfile vom include zu unterdrücken.

[Beta-User]

Mir persönlich gefällt an dieser Lösung, daß das Alles in eine Datei (Python Cheetah template in weewx) gesteckt werden kann. Nicht gefällt mir, daß ich den verbose-Level von fhem regelmäßig auf 0 setzen muß, um Einträge im Logfile vom include zu unterdrücken.

Mal unterstellt, deine Basisannahmen wären korrekt, dass a) die Aktivierung von MQTT in FHEM kompliziert wäre, und b) die MQTT-Integration in weewx "rudimentär" ist, hätte ich ein paar Fragen zu dieser Lösung:
- Wie stellst du sicher, dass die in der Datei enthaltenen Daten tatsächlich aktuell sind?
- Warum machst du das mit der "include"-Anweisung und liest die Daten nicht mit einem (fhem-) script ein? M.E. ist "include" nicht dafür gedacht, derartige Daten zu lesen. Sonst wäre es nicht notwendig, den verbose-level anzupassen. Hintergrund der Frage: Wenn man alle Readings "in einem Rutsch" setzt (readingsBulkUdate()), gibt es auch nur eine Event-loop, was deutlich effizienter ist, wie für jede einzelne Reading-Aktualisierung (hier: per set) eine Event-loop zu starten.

Beispielcode (aus MQTT2_DEVICE geklaubt:)

Code Auswählen Erweitern

my $ret = AnalyzePerlCommand(undef, $code);
          if($ret && ref $ret eq "HASH") {
            readingsBeginUpdate($hash);
            foreach my $k (keys %{$ret}) {
              readingsBulkUpdate($hash, makeReadingName($k), $ret->{$k});
              my $msg = ($ret->{$k} ? $ret->{$k} : "");
              checkForGet($hash, $k, $ret->{$k});
            }
            readingsEndUpdate($hash, 1);Da müßte (mehr oder weniger) nur die erste Zeile durch Code ersetzt werden, der die Datei einliest (und ggf. vorab auf Aktualität geprüft hat), und "$hash" durch '$defs{"dein_ziel-device"}' ersetzt werden...

[olwaldi]

Mal unterstellt, deine Basisannahmen wären korrekt, dass a) die Aktivierung von MQTT in FHEM kompliziert wäre, und b) die MQTT-Integration in weewx "rudimentär" ist, hätte ich ein paar Fragen zu dieser Lösung:
- Wie stellst du sicher, dass die in der Datei enthaltenen Daten tatsächlich aktuell sind?
- Warum machst du das mit der "include"-Anweisung und liest die Daten nicht mit einem (fhem-) script ein?

Ich hatte mal MQTT aktiv für den Shelly-Wassersensor, war nicht wirklich kompliziert. Mir geht's darum, daß durch das include direkt die Daten durch Standard-fhem Funktionen verarbeitet werden ohne zusätzliche Parser. Da ich eh' auf weewx-Seite die Daten aufbereiten muß, war meine Idee, dort gleich fhem-Kommandos zu erzeugen. Genausogut ginge auch json oder irgendein anderes ASCII-Format. Da ich in einem anderen Zusammenhang schon das telnet-Interface von fhem nutze, könnte ich meinen weewx-Output genausogut darüber transportieren. Mir war dabei quasi das source-Kommando von Shells im Kopf, so daß ich darüber aufs include gekommen bin.

Bzgl. Datenaktualität: Da wär' ich erstmal blauäugig, das hängt daran, wie gut weewx tut. Gut wiederum an fhem finde ich das alignTime, so daß fhem synchron zu weewx immer genau 1min nach dem Generieren durch weewx (exakt alle 5min um 05,10,15, usw) die Daten lädt.

Letztendlich war das sowieso nur ein Experiment. Konkret brauchen tue ich die weewx Daten aktuell nicht in fhem.


Grüßle, Michael

[olwaldi]

Gerade nochmal genauer auf JsonMod geguckt - das dortige Beispiel paßt ziemlich gut auf meinen Anwendungsfall https://forum.fhem.de/index.php/topic,109412.0.html

Hat aber eben den Nachteil, daß ich auf fhem-Seite die Daten via json mit (zugegeben sehr moderatem) Zusatzaufwand extrahieren muß.

Auch Dein Vorschlag, einfach mein weewxdata.cfg "selber" via Perl-Routine als Name/Wert-Paare zu lesen, hört sich gut an. Allemal besser als den verbose-Level ständig umzubiegen (wie bei meinem include). Der Charme des include ist für mich nunmal, daß das ganz ohne Zusatzaufwand in fhem täte.


Grüßle, Michael