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...