Best Practice Empfehlungen i.Zshg.m.: Session, Parameter, Block, Siemens ozw672

Begonnen von Lanhydrock, 21 Januar 2015, 08:23:45

Vorheriges Thema - Nächstes Thema

Lanhydrock

Hallo,

wir bitten Euch um einen Stupser in die richtige Richtung.
Es geht um ein Modul, das (anfangs wohl rein) lesenden Zugriff auf den Siemens Webserver ozw672 erlauben soll.

Der Webserver ist bei uns per LPB/BSB-Bus an einen Brennwert-Kessel angebunden, der einen Siemens LVM15 Regler hat.
Der Webserver bietet (zumindest in der aktuellen Version 5.x) eine Web API Schnittstelle.
Er hat eine Benutzerverwaltung, die für eine Session-basierte Autorisierung bei der Web API genutzt wird; die Session lebt 15 Minuten.
Die API spricht JSON oder XML.

Bsp. (der Dank geht an Günter):
https://ipwebserver/api/auth/login.json?user=HansMuster&pwd=Passwort

liefert
{
  "SessionId": "0bc991a1-04eb-4a7c-8371-4ab648ec8a88",
  "Result": ...
}


und nur:
https://ipwebserver/api/menutree/read_datapoint.json?SessionId=xxxxxxx-xxxx-xxx-xxx-xxxxxxxx&Id=900
liefert
{
"Data":
{
  "Type": "Numeric",
  "Value": "28.0","
  "Unit": "°C",
}
"Result": ...
}


Wir wollen Bernds volkszaehler-Modul als Kopierbasis nutzen.

Fragen bitte:

1. Da wir die Session-ID für die eigentliche Wertabfrage brauchen, wo und wie legen wir diese in FHEM am günstigsten zwischen zwei Abfragen ab, um nicht jedes Mal die zweistufige Autorisierung durchlaufen zu müssen; sondern nur, wenn die mit der bekannten ID durchgeführte Abfrage scheitert.

2. Der LSP/BSB Bus ist unserer Erfahrung nach (zumindest in der WebserverUI) nicht der schnellste. Wenn man bspw. ca. 10 Parameter abfragt, so liegt die Antwort schon im Sekundenbereich. Wo gibt es gute Beispiele, wie eine solche Kaskade von Abfragen FHEM nicht lahm legt?
[EDIT: Gut, wer lesen UND suchen kann, ist im Vorteil:] http://www.fhemwiki.de/wiki/Blocking_Call

3. Der Webserver erwartet eine Parameter-ID, mit der der Rückgabewert identifiziert werden kann. Um das FHEM-Modul auch zu parametrisieren, wo und wie würde man die (vermutlich: vielzahligen) Parameter für den Anwender pflegbar ablegen?

Vielen Dank im voraus.
- FHEMs in VM @ Mac mini & RPi, fhem2fhem
- Homematic, 1wire, Hue & Lightify & Tradfri & Xiaomi & Oblo via zigbee2mqtt/Conbee II, Rademacher DuoFern, Roto i8 & Hunter Ventile via HM-LC-Sw4-DR
- Interdomo GBK (via Siemens ozw672; dank HTTPMOD, lest Post #33765)
- homebridge(-fhem), Grafana, DBLog

Lanhydrock

Ich denke, nach der Lektüre des Wiki:
http://www.fhemwiki.de/wiki/DevelopmentModuleIntro
wären 1) Internals und 3) Attribute ein erster gangbarer Weg...

;-)
- FHEMs in VM @ Mac mini & RPi, fhem2fhem
- Homematic, 1wire, Hue & Lightify & Tradfri & Xiaomi & Oblo via zigbee2mqtt/Conbee II, Rademacher DuoFern, Roto i8 & Hunter Ventile via HM-LC-Sw4-DR
- Interdomo GBK (via Siemens ozw672; dank HTTPMOD, lest Post #33765)
- homebridge(-fhem), Grafana, DBLog

Lanhydrock

zu Eurer Information: (noch?) kein FHEM Modul,- da die Details der Web API weiterhin unbekannt sind,- aber das Logging in eine mysql-DbLog-Datenbank per Skript klappt schon gut...
- FHEMs in VM @ Mac mini & RPi, fhem2fhem
- Homematic, 1wire, Hue & Lightify & Tradfri & Xiaomi & Oblo via zigbee2mqtt/Conbee II, Rademacher DuoFern, Roto i8 & Hunter Ventile via HM-LC-Sw4-DR
- Interdomo GBK (via Siemens ozw672; dank HTTPMOD, lest Post #33765)
- homebridge(-fhem), Grafana, DBLog

Lanhydrock

so, FHEM-Modul ist geschrieben und läuft gut (allerdings ob fehlender Details momentan kein SET, sondern nur GET für unterschiedliche Parameter mit unterschiedlichen Pollzyklen), bei Bedarf bitte mal per PM melden, dann können wir das auch in anderen/Euren Umgebungen einmal testen
- FHEMs in VM @ Mac mini & RPi, fhem2fhem
- Homematic, 1wire, Hue & Lightify & Tradfri & Xiaomi & Oblo via zigbee2mqtt/Conbee II, Rademacher DuoFern, Roto i8 & Hunter Ventile via HM-LC-Sw4-DR
- Interdomo GBK (via Siemens ozw672; dank HTTPMOD, lest Post #33765)
- homebridge(-fhem), Grafana, DBLog