HTTP JSON mit Authentifikation

[MonkeyT]

Hallo zusammen,

ich möchte Informationen, welche ich als JSON über HTTP bekomme weiterverarbeiten.

Sobald ich das JSON habe, kann ich das mittels JSONPATH weiterverarbeiten. Meine Idee ist es, die JSON mittels HTTP-Cache abzufragen.
Allerdings muss man sich vorher authentifizieren:

Schritt 1:
https://URL/api?action=authenticate&use ... ord=SECRET
Man erhält ein JSON mit Authentifizierungscode

Schritt 2
https://URL/api?auth=AUTHCODE&action=de ... s&device=1
Man erhält ein JSON für Gerät 1. Für jedes weitere Gerät benötige ich einen weiteren HTTP-Cache.

Ist es möglich mehrere HTTP-Caches zu erstellen, oder gibt es hier einen eleganteren Weg?
Wie bekomme ich den Authentifizierungscode in die HTTPS Abfrage in der http.cfg, oder geht das nicht?

Falls das nicht geht, kann ich mittels rule, welche alle 5 Minuten ausgeführt wird, die Daten abfragen? Wie kann ich in einer rule die Antwort auf meinen HTTPS-Request in einen String schreiben?


Vielen Dank
grz Monkey

[udo1toni]

Also, erst mal ist die Frage, mit welchem openHAB Du unterwegs bist...

[MonkeyT]

Es handelt sich um openHAB 3.

[udo1toni]

Dann gibt es keine Datei http.cfg
openHAB3 unterstützt ausschließlich Bindings mit dem Thing-Modell, und das Binding muss für OH3 kompiliert sein. Es gibt aber alle thingbasierten Bindings schon lange auch für openHAB3, so dass die letzte Einschränkung eher akademischer Natur ist

Ob du den Zugang direkt automatisiert bekommst, muss ich leider stark anzweifeln. Meines Wissens gibt es bisher keine Option, Things dynamisch zu verändern (das wäre hier ja der Fall... Zugangsdaten abhängig vom Status eines Things setzen...)

Natürlich kann man auch weiterhin (wie schon unter OH1 und OH2) über Rules eine http Action ausführen. Da die Actions in diesem Fall direkt im Core integriert sind, muss man noch nicht mal ein Objekt dafür kreieren. Allerdings gibt es dann auch keinen Cache. Du kannst aber die komplette Antwort auf einen Request in einem String Item ablegen und dieses als Cache verwenden.

[MonkeyT]

Vielen Dank für die Infos. Funktioniert auch so, wie ich es mir vorgestellt hatte.

Gibt es bei openHAB auch Funktionen? Kommen die in den Ordner "scripts"?
Ich habe diverse Aufrufe mehrmals und würde diese gerne in eine Funktion packen.

Auch die Abfrage für ein Gerät würde ich gerne in einen Funktion packen, die mir einen String zurück gibt. Funktioniert das in openHAB?

Stelle mir das so vor:
devideID = 1
responseString = getDeviceInfo(deviceID)

[udo1toni]

Nein. Scripts sind Scripts. Man kann Scripts keine Werte übergeben (jedenfalls nicht beim Aufruf). Der Sinn eines Scripts ist eher fragwürdig, weil man fast immer eine elegantere Möglichkeit findet, zu programmieren.

Innerhalb der Rules DSL kannst Du Lambdas als Funktionsersatz verwenden, aber auch da gilt fast sicher, dass man ohne auskommt, wenn man den Code anders gestaltet.

Beispiel: Ich habe Raumthermostate, welche ihren Betriebsmodus umschalten können (Komfort, Nachtabsenkung, Frostschutz...). Allerdings erfolgt die Rückmeldung in einem anderen Format als die Steuerung. Deshalb brauche ich eine Rule, welche bei einem Status Update das Steuer-Item passend umstellt. Die Rule dazu:

Code: Alles auswählen

rule "Betriebsart RTR"
 when
    Member of GHeat_Mode changed
 then
    var Integer newMode 
    val mode = (triggeringItem.state as DecimalType).toBigDecimal.toBigInteger
    val iName = triggeringItem.name.split("_").get(0).toString
    logDebug("rtr","Name is: {}, Mode is: {}",iName,mode)
    switch (mode) {
        case mode.testBit(0) : newMode = 1
        case mode.testBit(2) : newMode = 3
        case mode.testBit(3) : newMode = 4
        default : newMode = 2
    }
    var myItem = GHeat_Set.members.filter[ f | f.name.startsWith(iName) ].head
    var Integer oldMode = 0
    if(myItem.state instanceof Number) oldMode = (myItem.state as Number).intValue
    if(oldMode != newMode) {
        logDebug("rtr","Name is: {}, oldMode is: {}, newMode is: {}",myItem.name,oldMode,newMode)
        myItem.postUpdate(newMode)
    }	
end

Es ist egal, wie viele RTR ich damit steuere, jeder RTR hat zwei Items (hier mal als Beispiel)

Code: Alles auswählen

Number TS2plusBadEG_OpMode "Betriebsart ist"  (GHeat_Mode) {channel="knx:device:bridge:GiraTSplus1_1_120:opMode"}
Number TS2plusBadEG_OpSet  "Betriebsart soll" (GHeat_Set) {channel="knx:device:bridge:GiraTSplus1_1_120:opSet"}

Die Items haben jeweils einen identischen Namensteil und einen, in dem sie sich unterscheiden. Man kann also aus dem einen Namen auf den anderen Namen schließen. Alle Items einer Sorte sind jeweils in einer Gruppe zusammengefasst. Die Rule arbeitet nun ausschließlich mit den Gruppen, womit sie für alle Items gleichermaßen gilt.
Üblicherweise würde man eine Namensunabhängige Funktion schreiben, welche man dann jeweils mit dem Namen aufruft und die Antwort ins entsprechende Item speichert. Aber der Ansatz oben ist wesentlich eleganter...