Ja, das sieht doch gut aus. Sauber formatiert:
Code: Alles auswählen
{
"senrows": [
{
"area": 2,
"zone": 43,
"type": 33,
"type_f": "{D_TYPE_33}",
"name": "Garagentor",
"cond": "",
"cond_ok": "1",
"battery": "",
"battery_ok": "1",
"tamper": "",
"tamper_ok": "1",
"bypass": 0,
"rssi": "{WEB_MSG_STRONG} 8",
"resp_mode": [
0,
0,
0,
0,
0,
0
],
"ammeter": "0",
"ver": "",
"bypass_tamper": 0,
"sid": "RF:0016fd10",
"su": 1,
"alarm_status": "",
"status_ex": "0",
"hue": "-1",
"sat": "-1",
"ctemp": "-1",
"hue_cmode": "-1",
"hue_cie_x": "-1",
"hue_cie_y": "-1",
"hue_color_cap": "0",
"nuki": "-1",
"shutter_turn": 0,
"status": "{WEB_MSG_DC_CLOSE}"
},
{
"area": 1,
"zone": 7,
"type": 4,
"type_f": "{D_TYPE_4}",
"name": "Kellertür",
"cond": "",
"cond_ok": "1",
"battery": "",
"battery_ok": "1",
"tamper": "",
"tamper_ok": "1",
"bypass": 0,
"rssi": "{WEB_MSG_STRONG} 8",
"resp_mode": [
0,
5,
1,
1,
1,
0
],
"ammeter": "0",
"ver": "",
"bypass_tamper": 0,
"sid": "RF:05671d10",
"su": 1,
"alarm_status": "",
"status_ex": "0",
"hue": "-1",
"sat": "-1",
"ctemp": "-1",
"hue_cmode": "-1",
"hue_cie_x": "-1",
"hue_cie_y": "-1",
"hue_color_cap": "0",
"nuki": "-1",
"shutter_turn": 0,
"status": "{WEB_MSG_DC_CLOSE}"
}
]
}
(leichter lesbar. z.B. für VSCode gibt es dafür Plugins, die das übernehmen)
Du musst dieses JSON Objekt nach openHAB bekommen. Das Script kümmert sich auch um das Login, man könnte das sicher leicht auch mit python bauen (dann braucht es keinen extra Webserver dazu).
Beim Weg über den Webserver verwendest Du das http-Binding und einen http-Cache.
Das http Binding muss installiert sein, ebenso die jsonpath Transformation.
./services/http.cfg:
Code: Alles auswählen
# timeout in milliseconds for the http requests (optional, defaults to 5000)
#timeout=
# the interval in milliseconds when to find new refresh candidates
# (optional, defaults to 1000)
#granularity=
# whether to substitute the current time or state value into the URL
# (optional, defaults to true)
#format=
# configuration of the first cache item
#<id1>.url=
#<id1>.updateInterval=
# configuration of the second cache item
#<id2>.url=
#<id2>.updateInterval=
# Lupus XT2 per php-Script auslesen
lupus.url=http://lupus-webserver/pfad/zum/php-script
lupus.updateInterval=30000
Der obere Teil der Datei wird bei er Installation des Bindings automatisch generiert. die letzten drei Zeilen sind das entscheidende, hier schreibst Du die Webadresse hin, mit der Du das JSON Objekt erhältst. Das Updateinterval ist in Millisekunden anzugeben. Hier sollte man einen guten Kompromiss zwischen Aktualität und Netzlast finden, keine Ahnung, ob die Lupus da bestimmte Obergrenzen hat.
Wenn Du mehrere verschiedene Scripte aufrufen möchtest (Stichwort Gesamtstatus) legst Du dafür einen zweiten cache an. Natürlich musst Du dann berücksichtigen, dass doppelt so viele Anfragen auf die Lupus einprasseln (bei gleich gesetztem Cache Updateinterval)
Am besten sollten die Cache-IDs nur englische Kleinbuchstaben und Zahlen enthalten, wobei das erste Zeichen auf jeden Fall ein Buchstabe sein muss.
Nun kannst Du Items definieren:
Code: Alles auswählen
String Alarm_Kellertuer "Keller Alarm [%s]" { http="<[lupus:30000:JSONPATH($.senrows[?(@.name=='Kellertür')].alarm_status)]" }
lupus ist der Name des http-Caches, 30000 das Updateinterval in Millisekunden (das ist unabhängig vom Cache), JSONPATH() die Transformation, welche angewendet werden soll.
$ ist das gesamte JSON Objekt, also quasi die Wurzel
senrows ist ein Kind der Wurzel (in diesem Fall das einzige) und hat mehrere Kinder (die sind mit 0 und 1 durchnummeriert, vermutlich gibt es dann noch mehr davon
. Nun könntest Du die Nummern direkt eingeben, aber vielleicht änderst Du ja mal was an der Konfiguration... Deshalb ist es eleganter, hier einen Filter zu verwenden, in diesem Fall also nach dem Name, der hoffentlich eindeutig ist. Ansonsten könnte man natürlich auch nach der sid gehen oder area und zone zum filtern heranziehen, Hauptsache, die Zuordnung ist eindeutig. Es gibt Geräte, die das JSON hochgradig dynamisch erzeugen, in dem Sinn, dass vielleicht die Reihenfolge der Knoten variiert. Deshalb ist die direkte Verknüpfung mit der Zahl eher kritisch
alarm_status ist schlussendlich das auszulesende Feld im JSON Objekt.
Nun befindet sich dieser Wert im Item Alarm_Kellertuer und wird als Status angezeigt, wenn Du das Item in eine Sitemap einbaust.
Das Item ist nur lesend - klar.
Bei logischen Feldern (z.B. battery_ok) kommt offensichtlich 0 oder 1 zurück, das sollte openHAB automatisch nach OFF/ON bzw. OPEN/CLOSED übersetzen, wenn man ein Switch bzw. Contact Item verwendet. Mit einem Mapping kann man daraus in der Anzeige dann ein OK/nicht OK machen (oder was man da halt sehen haben möchte)
