Hauptmenü

FHEM parse JSON

Begonnen von globus243, 06 Juni 2016, 16:57:52

Vorheriges Thema - Nächstes Thema

globus243

Hallo,

Ich habe einen kleinen Dienst der auf Anfragen (an http://host/rest/getColors) die Farben eines angeschlossenen LED Streifens als JSON ausgibt. ein Beispieljson:
{"action":"getColors","status":"success","color":"#000000"}

Ich möchte jetzt den Wert "color" in diesem Fall also #000000 in meinem FHEM ausgeben.
Dafür habe ich bereits folgendes gebastelt gehabt:

#RGB Strip Balkon
define httpmod_Balkon_RGB_Streifen HTTPMOD http://HOST/rest/getColors 5
attr httpmod_Balkon_RGB_Streifen userattr event-on-change-reading reading01JSON reading01Name requestHeader1 stateFormat
attr httpmod_Balkon_RGB_Streifen alias LED Streifen
attr httpmod_Balkon_RGB_Streifen event-on-change-reading Farbe
attr httpmod_Balkon_RGB_Streifen reading01Name Farbe
attr httpmod_Balkon_RGB_Streifen reading01JSON color
attr httpmod_Balkon_RGB_Streifen requestHeader1 Content-Type: application/json
attr httpmod_Balkon_RGB_Streifen room Balkon,Licht
attr httpmod_Balkon_RGB_Streifen stateFormat {sprintf("Farbe %s", ReadingsVal($name,"Farbe",0))}


Diese Zeilen haben schon einmal funktioniert. nach einem Neuaufsetzen des Rechners auf dem auch FHEM läuft. schlägt das ganze jetzt aber fehl.
Im Log steht dazu:

2016.06.06 16:49:12.086 3: httpmod_Balkon_RGB_Streifen: Read found inconsistant attributes for reading01Name
2016.06.06 16:49:12.086 3: httpmod_Balkon_RGB_Streifen: Read response to Update didn't match any Reading(s)


Dazu habe ich natürlich schon gegoogled und diese Meldung auch im wiki  gefunden (http://www.fhemwiki.de/wiki/HTTPMOD) dort wird aber gesagt
das wenn soetwas auftritt und das internal "buf" gefüllt ist, was sie ist, mein regex falsch sein soll, den ich ja aber gar nicht habe (oder doch?).
folgendes steht in der "buf"-internal:

HTTP/1.1 200 OK Date: Mon, 06 Jun 2016 14:52:20 GMT Server: Apache/2.2.22 (Debian) X-Powered-By: PHP/5.4.45-0+deb7u2 Set-Cookie:
PHPSESSID=HIERSTÜNDEEINEID; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0,
pre-check=0 Pragma: no-cache Access-Control-Allow-Origin: * Content-Length: 59 Content-Type: application/json
{"action":"getColors","status":"success","color":"#000000"}

(man achte auf das korrekte JSON am Ende)

So sah das aber schon immer aus, also auch hier nichts neues.

Deshalb: Was läuft da schief? Hoffe ihr wisst weiter.

LG
Tim

Mario67

Hallo Tim,

für JSON-Ausdrücke existiert seit einiger Zeit das Modul JSONREADINGS von bgewehr. Ich kann allerdings nicht sagen, ob der Header vor dem JSON in der Antwort des Servers vorher abgetrennt werden muss.

Siehe: https://forum.fhem.de/index.php/topic,38463.msg306731.html#msg306731

Gruß,
Mario
FHEM auf Raspberry Pi 4 mit CUL868, WMBUS,
FS20 ST, FS20 AS4-3, FS20 SU-2, FS20 DF, 1-Wire + RS-232: AB Electronics Com Pi RS232, Brandmelder + Fenster: AB Electronics IO Pi 32
BUDERUS GB142 über EMS/AVR-NET-IO, WESTAFLEX WAC250 über RS232, MySensors
mit fhem.cfg & includes glücklich

globus243

#2
Zitat von: Mario67 am 06 Juni 2016, 17:26:46
für JSON-Ausdrücke existiert seit einiger Zeit das Modul JSONREADINGS von bgewehr. Ich kann allerdings nicht sagen, ob der Header vor dem JSON in der Antwort des Servers vorher abgetrennt werden muss.

Hallo Mario,

was mich halt so wundert ist, dass es vorher funktioniert hat zumal es exakt (hoffe ich) der HTTPMOD Doku aus dem Wiki entspricht.
Auch die MeldungRead found inconsistent attributes for reading01Nameist relativ nichts sagend... inkonsistente Attribute für reading01Name,?? reading01Name hat doch wenn überhaupt nur ein Attribut: Farbe. wie kann das inkonsistent sein?

globus243

Weis denn keiner Rat?  :(

linuxpaul

#4
Hi,

Evtl irgendwas mit der Reihenfolge der Initialisierung in der config?
Das ist aber nur geraten,

:)
linuxpaul

globus243

Zitat von: linuxpaul am 06 Juni 2016, 21:31:33
Evtl irgendwas mit der Reihenfolge der Initialisierung in der config?

Hallo linuxpaul,

darüber habe ich auch schon theorisiert, leider ist jede "Kombination" der Zeilen erfolglos.

globus243

so, das war mir jetzt irgendwie zu doof. habe es mit einem regex gemacht, das klappte auf Anhieb.
trotzdem danke an alle.

nochmal zusammen gefasst:

an den Wert color, aus dem folgendem JSON:
{"action":"getColors","status":"success","color":"#976800"}
bin ich mit dem Regex "color":+"(.*)" gekommen. der sucht das Wort color innerhalb von zwei Anführungszeichen und dann er matched auf alles was hinter dem Doppelpunkt in Anführungszeichen steht.
D.h. mein vollständiger HTTPMOD sieht nun so aus:

define httpmod_Balkon_RGB_Streifen HTTPMOD http://192.168.1.5/rest/getColors 5
attr httpmod_Balkon_RGB_Streifen userattr reading01Name reading01Regex requestHeader1 stateFormat
attr httpmod_Balkon_RGB_Streifen reading01Name Farbe
attr httpmod_Balkon_RGB_Streifen reading01Regex "color":+"(.*)"
attr httpmod_Balkon_RGB_Streifen requestHeader1 Content-Type: application/json
attr httpmod_Balkon_RGB_Streifen room Balkon,Licht
attr httpmod_Balkon_RGB_Streifen stateFormat {sprintf("Farbe %s", ReadingsVal($name,"Farbe",0))}


schätze mal leicht abgewandelt kann man mit dem regex in jedem json so ziemlich alles matchen, insofern der Bezeichner einmalig/unique ist.
An dieser Stelle möchte ich auch noch mal die Wikiseite zum HTTPMOD rügen: der dort Beschriebene Regex ist wirklich, Verzeihung, ziemlich dumm,
er geht davon aus, das zwischen dem key und dem value ein oder mehrere Tabs sind. Sowas gibt ein Webserver aber niemals aus. Vlt sollte jemand mit Wiki-Account das mal aufarbeiten.