Neues Modul JSONREADINGS zur Einbindung beliebiger json-Daten per URL

Begonnen von bgewehr, 24 Juni 2015, 15:46:38

Vorheriges Thema - Nächstes Thema

maddhin

OK, danke! Werde es später auch mal mit HTTPMOD probieren.

Von der Logik her mag ich ArchLinux, aber mit meinen erweiterten copy&paste Linux Kenntnissen war ich mehr als ein mal sehr nahe wieder Raspbian aufzuspielen. Aber Stretch scheint ja auch noch ein paar Macken zu haben, da habe ich mich durchgebissen und versuche jetzt bei Arch zu bleiben :)

maddhin

Nochmal kurze Rückmeldung: JSONREADINGS.PM funktioniert nun auch mit dem richtigen API link.

Habe mir auch HTTPMOD angeguckt, aber Bgewehr's Modul funktioniert so super da macht es keinen Sinn das jetzt noch über HTTPMOD manuell zu versuchen...

Danke für das Modul und die Korrekturen!

Wzut

Das ist doch schön :) allerdings das mit dem "macht es keinen Sinn" sehe ich etwas anders.
Du hast jetzt die Chance wieder etwas dazu zu lernen, du kannst nie wissen wann du das nächste Problem hast und das sich dann vllt. nur mit Hilfe von HTTPMOD lösen lässt. Also weiter üben, kannst ja beides gleichzeitig laufen lassen und an HTTPMOD so lange schrauben bis es mit der Ausgabe von JSONREADINGS zusammen passt.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

maddhin

Zitat von: Wzut am 18 Oktober 2017, 08:46:58
Das ist doch schön :) allerdings das mit dem "macht es keinen Sinn" sehe ich etwas anders.
Du hast jetzt die Chance wieder etwas dazu zu lernen, du kannst nie wissen wann du das nächste Problem hast und das sich dann vllt. nur mit Hilfe von HTTPMOD lösen lässt. Also weiter üben, kannst ja beides gleichzeitig laufen lassen und an HTTPMOD so lange schrauben bis es mit der Ausgabe von JSONREADINGS zusammen passt.

Richtig. Und das war auch der Grund wieso ich mir HTTPMOD angesehen hatte.

Für mich ist Feinstaub - auf Grund meines Wohnortes - auch eine wichtige Komponente, und was ich eigentlich sagen wollte (fand ich aber zu lang!) ist: "da ich im Moment wenig Zeit habe macht es für mich keinen Sinn nun auch noch HTTPMOD parallel einzurichten, weil erst noch andere Baustellen zu flicken sind und ich das Ganze mit dem Feinstaub überhaupt erstmal implementieren muss"  :o ;D

HTTPMOD scheint flexibler und "sicherer" ("definierter" Support) und ich werde das darüber auch implementieren. Aber für dem Moment finde ich die JSONREADINGS "quick & dirty"-Methode genial  8)

maddhin

Nochmal eine kurze Nach- bzw Verständinsfrage zum Modul, weil ich ein Problem mit einem Notify habe, dass nicht triggert (https://forum.fhem.de/index.php/topic,78281.0.html):

bei mir werden die via JSON abgeholten Werte weder im Eventmonitor noch im Log angezeigt. Im Log gibts immer nur

2017-10-23_23:06:47 AQI get_new_data
2017-10-23_23:06:49 AQI new_data


Ist dieses Verhalten so gewünscht/geplant? Oder liegt der Fehler bei mir?

Ich vermute, dass deswegen das Notify bei Änderung eines (via JSON abgeholten) Wertes nicht triggert. Es scheint kein "Event" zu geben?!


(für Interessierte: CoolTux hat für die AQI Abfrage gerade superschnell ein tolles Modul zusammengebaut -> AQICN.pm ab heute/morgen via update, https://forum.fhem.de/index.php/topic,78201.msg703190.html#msg703190)

dev0

Ist im Modul zZ. abgeschaltet:
readingsEndUpdate($hash,0);
Um Events zu generieren müßte der 2. Parameter auf 1 gesetzt werden.

maddhin

Zitat von: dev0 am 24 Oktober 2017, 05:16:54
Ist im Modul zZ. abgeschaltet:
readingsEndUpdate($hash,0);
Um Events zu generieren müßte der 2. Parameter auf 1 gesetzt werden.

ah! Super, wieder was gelernt!!

Damit sollte es dann auch mit dem Notify funktionieren! Danke!

Wzut

Zitat von: dev0 am 24 Oktober 2017, 05:16:54
Um Events zu generieren müßte der 2. Parameter auf 1 gesetzt werden.
ähh Radio Eriwan .. im Prinzip ja, allerdings gab es bei meinen Tests keine. Ich habe das darauf zurückgeführt das es wohl in der Callback Sub von NonBlocking Get nicht greift. Aus dem Grund hatte ich den oben genannten neuen Event "new_data" via state erzeugt. Der sollte ausreichen um einem notify mitzuteilen das ab jetzt neue Daten zur Verfügung stehen.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

maddhin

Zitat von: Wzut am 24 Oktober 2017, 07:19:05
ähh Radio Eriwan .. im Prinzip ja, allerdings gab es bei meinen Tests keine. Ich habe das darauf zurückgeführt das es wohl in der Callback Sub von NonBlocking Get nicht greift. Aus dem Grund hatte ich den oben genannten neuen Event "new_data" via state erzeugt. Der sollte ausreichen um einem notify mitzuteilen das ab jetzt neue Daten zur Verfügung stehen.

hm, ich kann das jetzt nicht ausprobieren, ob die "1" den Unterschied macht. Aber die Diskussion zum Notify ist hier: https://forum.fhem.de/index.php/topic,78281.0.html - das Notify triggert, wenn ich "triggern bei change" "device:.*" einstelle. Dann triggert es aber 3 mal bei jedem Abrufen der JSON Daten.

Ich will aber das Notify nur triggern, wenn sich ein bestimmtes reading ändert (device:reading:.*).Bei mir triggert das notify aktuell nur, wenn ich das reading manuell ändere, weil es wohl nur dann ein Event gibt.

D.h. das Notify sollte funktionieren, aber es fehlt das Event halt.


dev0

Zitat von: Wzut am 24 Oktober 2017, 07:19:05
Ich habe das darauf zurückgeführt das es wohl in der Callback Sub von NonBlocking Get nicht greift.
Ich müßte mich schwer täuschen, wenn es wirklich an NonblockingGet() liegen sollte. Innerhalb einer NotifyFn muss man zB mit InternalTimer() aus der "Event Loop Detection" ausbrechen, damit Events sauber erzeugt werden, aber bei NonblockingGet() mWn nicht.

Wzut

na dann testet doch mal bei Euch :) Ich hatte mir bei diesem Schnellschuss nicht so große Gedanken darüber gemacht,
vllt ist mein Testsystem auch keine gute Refrenz soviel wie ich an dem schon geschraubt habe. 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

dev0

Zitat von: Wzut am 24 Oktober 2017, 08:47:55
na dann testet doch mal bei Euch
Das müsste maddhin schon machen, ich nutze das Modul nicht und woltte nur behilflich sein.

maddhin

Und Maddhin ist gerade fertig mit einem Test!

Mit
readingsEndUpdate($hash,1);

Werden Werte ins Log geschrieben und das Notify funktioniert!!!

Habe nur einen Pull getestet, weil erst in 60min neue Daten kommen, aber das Problem sollte damit erledigt sein. DANKE, wäre ich nie selbst drauf gekommen!

Waldmensch

Wird an dem Modul noch gearbeitet? Ich habe meinen FHEM auf einen anderen Raspi umgezogen und da ist eine neuere Perl Version. Jetzt wird das Modul nicht mehr geladen. Falls das Modul obsolet ist, gibt es etwas anderes (ein anderes Modul um einen simplen JSON in readings aufzudröseln), was in der Funktionalität ähnlich ist?

Der Fehler:
2018.10.12 18:46:57 1: reload: Error:Modul 70_JSONREADINGS deactivated:
Experimental each on scalar is now forbidden at /media/usbdisk/fhem/FHEM/70_JSONREADINGS.pm line 122.

2018.10.12 18:46:57 0: Experimental each on scalar is now forbidden at /media/usbdisk/fhem/FHEM/70_JSONREADINGS.pm line 122.

schwatter

Zum einen expandJSON.

https://forum.fhem.de/index.php?topic=69067.0

Oder wenn es sich um MQTT handelt, dann kann ich MQTT2_SERVER und MQTT2_DEVICE empfehlen.