[erledigt] JsonMod - Daten von mehreren Quellen/urls einlesen (ähnlich get0x)?

Begonnen von MadMax-FHEM, 14 April 2023, 15:32:46

Vorheriges Thema - Nächstes Thema

MadMax-FHEM

Hallo,

der Titel sagt es eigentlich ;)

Hintergrund:

ich lese meinen Wechselrichter mittels AhoyDTU aus, welches ein REST-API bietet (gut mqtt würde noch gehen aber ich brauche will ja gar nicht viele Daten usw. egal).

Bisher hatte ich das mit einem HTTPMOD ausgelesen, da ich das schon ein wenig kannte. Dazugelernt, wie man das mit 2 unterschiedlichen urls macht usw. :)
Allerdings habe ich (immer noch nicht verstanden) wie reading0xJSON funktionieren soll, also wie dort einen JSON-Pfad angeben, egal.
Habe es daher mittels RegEx "gelöst" (naja: es tut/tat) ;)

Nun wurde umgestellt und da funktioniert RegEx (für mich) nicht (mehr), siehe Daten unten...
Daher wieder: reading0xJSON probiert aber da kam/komme ich auf keinen grünen Zweig... :-\


Dann habe ich mich erinnert: JsonMod 8)
Gesagt getan...
Nach ein wenig Rumprobieren habe ich es dann hinbekommen :)

Aber: ich habe ja 2 urls/Endpoints die ich abfrage(n muss). Mit HTTPMOD kein Problem aber geht das mit JsonMod? Und wenn ja: wie?

Ich habe mal (noch) kein(e) list(s) eingestellt, da es ja erst mal eine generelle Frage ist:

kann ich mit EINEM JsonMod-Device von ZWEI unterschiedlichen "Endpunkten" Daten holen?

Endpunkte wären:
http://192.168.10.210/api/index
http://192.168.10.210/api/inverter/id/0
(davor war es: http://192.168.10.210/api/record/live -> da war es [für mich] noch mit RegEx möglich)

Alternativ (sollte es nicht mit JsonMod gehen), "nehme" ich auch gerne wie ich ein reading0xJSON angeben müsste :)
Hier die (neuen) Daten:
{"id":0,"enabled":true,"name":"HM-600","serial":"12345678","version":"10010","power_limit_read":100,"ts_last_success":1681479058,"ch":[[232.4,0.03,7.4,50.01,1,17.5,2.795,52,7.7,96.104,0],[35,0.17,5.8,39,2.603,1.415],[33.5,0.06,1.9,13,0.192,0.463]],"ch_name":["AC","01","02"],"ch_max_pwr":[null,410,410]}

Die JSON-Path Angaben die mich interessieren (und in dem JsonMod auch tun :)  ) lauten:
single(jsonPath('$.ch[0][6]'), 'YieldTotal', 'unknown');
single(jsonPath('$.ch[0][7]'), 'YieldDay', 'unknown');
single(jsonPath('$.ch[0][2]'), 'P_AC', 'unknown');

Danke, 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)

MadMax-FHEM

Also ich habe jetzt noch ein wenig mit RegEx rumgetan und das ursprüngliche HTTPMOD wieder hinbekommen.
Etwas "irre" die RegEx aber naja: again what learned ;) :D

Interessieren würde mich das bzgl. JsonMod aber trotzdem (noch), daher lasse ich die Frage mal offen 8)

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)

betateilchen

Zitat von: MadMax-FHEM am 14 April 2023, 15:32:46kann ich mit EINEM JsonMod-Device von ZWEI unterschiedlichen "Endpunkten" Daten holen?

JsonMod kann m.W. nicht selbst zwei URL innerhalb eines device abfragen. Aber man könnte einen Umweg gehen: Die beiden URL per http (mit FHEM Bordmitteln) abfragen, deren Ergebnisse zusammenfügen und die Summe dann als Text-Input an JsonMod zur Verarbeitung übergeben.

Verstanden habe ich noch nicht, welche Daten, die Du verarbeiten möchtest, von welcher URL kommen?
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

MadMax-FHEM

Danke, dachte ich mir schon...
Schade... :-\

Hmm, das mit dem Abgreifen und weiterverarbeiten, mal sehen... :)

Wie geschrieben, habe ich aktuell wieder ein (paar) RegEx das tut...
...trotzdem:

Von hier http://192.168.10.210/api/inverter/id/0
Kommt das:

{"id":0,"enabled":true,"name":"HM-600","serial":"12345678","version":"10010","power_limit_read":100,"ts_last_success":1681479058,"ch":[[232.4,0.03,7.4,50.01,1,17.5,2.795,52,7.7,96.104,0],[35,0.17,5.8,39,2.603,1.415],[33.5,0.06,1.9,13,0.192,0.463]],"ch_name":["AC","01","02"],"ch_max_pwr":[null,410,410]}

Da möchte ich die 2.795 (YieldTotal), die 52 (YieldDay) und die 7.4 (AC_Power).
Das geht mit dem geposteten JsonMod List-Attribut wunderbar.
Habe das jetzt auch per Regex (wieder im ursprünglichen HTTPMOD) hinbekommen...

Vorher kamen die Daten über diese url: http://192.168.10.210/api/record/live
Aber eben in einem ganz anderen Format (für mich) leichter bzgl. RegEx...

Zusätzlich kommen von hier: http://192.168.10.210/api/index
Angaben wie:
Available true/false (-> erreichbar)
Producing true/false (-> produziert)

Beides zusammen hätte ich halt gerne in einem Device und wenn möglich mit Mitteln eines Devices :)

Aktuell habe ich das ja (wieder) 8)

Einfacher finde ich halt den Zugriff über JSON-Path denn per RegEx aber geht auch...
D.h. Alternaitve zu 2 urls (oder mehr) per JsonMod wenn ich wüsste wie ich Json-Path (z.B. eben $.ch[0][6]) in reading0xJSON bei HTTPMOD angebe :)
Habe rumgesucht und rumprobiert aber irgendwie hat es nicht wollen...
Bei JsonMod dann eben "sofort" (nachdem ich kapiert hatte, dass man einfach mehrere single-Aufrufe angeben kann)...

Setze es mal auf erledigt...

Danke, 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)

betateilchen

Zitat von: MadMax-FHEM am 14 April 2023, 18:24:08Zusätzlich kommen von hier: http://192.168.10.210/api/index
Angaben wie:
Available true/false (-> erreichbar)
Producing true/false (-> produziert)

Nur mal blöd gefragt:

Frage 1: wenn das device nicht erreichbar ist, wie kann es dann eine entsprechende Meldung zurückgeben?
Frage 2: welche Leistungswerte werden geliefert, wenn das device nicht produziert?
Frage 3: welche Bedeutung hat der Wert "ts_last_success"? Kannst Du die Verfügbarkeit und die Produktion nicht aus diesem Timestamp ableiten und auf die /index Abfrage komplett verzichten?

Grundsätzlich bin ich ja ein Freund von möglichst simplen Lösungen, deshalb interessiert mich einfach, ob man wirklich mit zwei URL arbeiten muss, um die gewünschten Informationen zu erhalten  8)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

MadMax-FHEM

Naja, dann (noch) ausführlich(er) ;)

Also folgender "Aufbau":

Solarpanels -> Wechselrichter -> Steckdose (klar ;)  )

ESP32 mit "AhoyDTU" verbindet sich per 2,4GHz NRF (proprietär) mit dem Wechselrichter (statt einer möglichen "echten" DTU).
AhoyDTU hat ein Webinterface, kann per mqtt senden und bietet ein REST-API.

Webinterface per HTTPMOD: ja könnte gehen (wobei ich jetzt nicht mehr sicher bin, ob da die Daten nicht per Script nachgeladen werden, sei's drum).
MQTT: das ist mir rigentlich zu geschwätzig (und es wird an allen Fronten "gebastelt": mqtt-Topics bei AhoyDTU und attrTemplates usw.)
REST-API: für die paar Werte die ich (alle 5min oder so) mal haben will völlig ausreichend...

Gut, ich habe mir das REST-API nicht ausgedacht, auch nicht das mit den vielen (es gibt ja noch weitere) Endpunkten.
Ja, evtl. kann man auch den einen Endpunkt finden wo man alles rauskitzeln kann aber das ist ja noch mehr Aufwand (für mich), als die beiden urls abfragen und ein wenig (oder ein wenig mehr) RegEx drüber zu jagen...
(vermutlich aber der, der hier genannt ist / die anderen enthalten keine "Produktionsdaten")

Nun zu: wie kann er nicht verbunden sein usw.
(denke ist aber schon klar ;)  )

AhoyDTU kann den Wechselrichter nur erreichen, wenn zumindest ein wenig was von den Panels kommt (damit wird wohl das Wechselrichterfunkmodul gespeist)...
...kommt ausreichend, wird auch eingespeist -> "producing".
...kommt zu wenig, ist zwar der Wechselrichter erreichbar aber eben keine "Produktion"...
...kommt für beides zu wenig: weder erreichbar und klar keine "Produktion" ;)

REST-API, Doku usw.: https://ahoydtu.de/
(wobei eben die letzte Änderung: andere urls für "Produktionsdaten" und wie die so aufgebaut ist und dass die "alte" url nicht mehr mit aktuellen Daten versorgt wird ist noch nicht dokumentiert. Da bin ich nur drauf gekommen, weil eben [deutliche] Abweichungen zwischen Weboberfläche und fhem bestanden und eine Suche hat mich dann zu git-Issues oder so geleitet wo andere auch das Problem hatten)

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)

betateilchen

Ok, ich habs weitgehend verstanden.

Zitat von: MadMax-FHEM am 14 April 2023, 18:42:01MQTT: das ist mir rigentlich zu geschwätzig (und es wird an allen Fronten "gebastelt": mqtt-Topics bei AhoyDTU und attrTemplates usw.)

Naja, das mit dem Umbau an allen Fronten hast Du ja jetzt auch bei Deiner JSON-Abfrage erlebt, das scheint also kein Ausschlusskriterium zu sein.
Zumal die MQTT Daten laut Beschreibung aus den JSON Daten erzeugt werden - insofern gibt es da einen Zusammenhang.

attrTemplates "muss" man glücklicherweise nicht verwenden,

attr global disableFeatures attrTemplate
damit hat man die Freiheit, sich aus den MQTT Eingangsdaten genau das auszusuchen, was man braucht. Der Rest wird einfach ignoriert und tut nicht weh. Und MQTT hat den Charme, dass man nicht aktiv die Werte pollen muss, sondern dass sie einfach geliefert werden. Wäre sicher einfacher als hochverwirrende regex basteln zu müssen :) Vielleicht ist es doch nochmal einen Gedanken wert, das Thema MQTT in Deinem Vorhaben zu bewerten.

Aber ich will Dich in nichts reinreden, wovon Du nicht überzeugt bist.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

MadMax-FHEM

Naja, mal sehen...
Ja "nachbasteln" "muss" ich jetzt auch: korrekt ;)

Aber das was ich habe verstehe ich halbwegs 8)

Ja pollen vs. pushen...
Aber: mqtt sendet ja "dauernd" wenn sich was ändert, so oft/viel Daten brauche ich gar nicht...
Ja, ignorieren seitens fhem: ok
Aber die Daten werden ja verarbeitet (ESP) und gesendet (Netz: ok, egal ;) ) und mindestens mal empfangen und verarbeitet (fhem) und sei es nur um sie (anschließend) zu "ignorieren"...
...vs.: ich frage alle 5min mal 2 JSON-Konstrukte mit ein paar Byte ab (und spare mir dann das ganze event-on- / einschränken / verwerfen / ignorieren ;)  )...

Und ja, kein MUSS die Templates zu nehmen und wenn es "nur" um das Abholen von Daten geht, auch ok, das habe ich auch schon mal gemacht (bevor es [für mich offensichtlich] attrTemplates gab) aber bei komplizierteren Devices/Topics/Geräten bin ich schon froh, ein Template zu haben :)

Vielleicht im nächsten Urlaub 8)

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)