http Binding und Abfrage einer URL unter openHAB 4

[kdb]

Hallo,
scheinbar war es ungeschickt gleich mit openHAB 4 zu starten. Denn alle Beispiele zu Abfrage einer URL mittels http Binding sowie Kommentare oder Tutorials, die ich finde, beziehe sich auf ältere Versionen.
nodeMCU Sensoren liefern Messdaten, die ich über HTTP in openHAB 4 lesen und auswerten will. ( plain Text oder JSON als Format der Antwort kann gewählt werden )
Das Http Binding ist installiert. Welche Kanäle muss ich für das Ergebnis auswählen ? Bisherige Auswahl von Kanälen gibt keine Ergebnisse.
Gibt es irgendwo eine Beschreibung für openHAB 4 hierzu ?
Danke im Voraus

[udo1toni]

Also grundsätzlich wäre die beste Quelle für Informationen die offizielle Dokumentation, nicht irgendwelche Seiten im Internet... https://www.openhab.org/addons/bindings/http/ wäre in diesem Fall die korrekte Adresse.
Ja, die Doku ist auf englisch, aber dafür ist sie immer aktuell, und zwar, weil sie automatisch bei einem Build mit gebaut wird. Außerdem ist diese Doku auch versioniert, Du kannst also sowohl in die Zukunft schauen (Milestone Build) als auch in die Vergangenheit, bis hin zu openHAB 2.5, welches die einzige Version ist, bei der das http Binding noch anders konfiguriert wurde (und openHAB2.5 wurde Mitte 2020 abgelöst... oder war es Ende 2020? jedenfalls sicher schon drei Jahre her...)

Mein Tipp für die Auswertung: Nimm das JSON Format.
Wichtig sind die URLs und die Art des Zugriffs, wenn Du das hier notierst, kann ich Dir eine Beispielkonfiguration zeigen.
Damit Du JSON sinnvoll nutzen kannst, muss außerdem noch das JSONPath Transformation Addon installiert werden, damit kannst Du dann auf jeden Wert im JSON gezielt zugreifen. Du kannst auch gerne hier ein Beispiel Output mit posten, am besten als Code markiert.

[kdb]

Hallo udo1toni !
Vielen Dank für die schnelle Antwort.
Die Quellen habe ich gefunden und englisch ist nach Berufsleben in der IT kein Problem. Wahrscheinlich auf Grund meiner „Windows  Erfahrung“ ( u.a. beim Aufbau einer PKI für Hessen ) habe ich mich für UI zur Implementierung entschieden. Und hierfür finde ich kaum Beispiele für OpenHAB 4 oder aber ich habe noch nicht den Zusammenhang zwischen Dokumenten und „Masken“ zur Konfiguration erkannt.
Mir gelingt es zwar immer über http Binding  ein Thing zu erstellen und dem Modell hinzufügen, aber außer dem Label wird nichts angezeigt. Fehlermeldungen erscheinen keine. Im log file von meinem die JSON Daten sendenden NodeMCU sind keine Zugriffe von openHAB zu erkennen. Wo könnte mein Fehler sein ?
Welchen Code sollte ich senden, da ich alles über UI ausgewählt habe ?
Bei Bedarf können Antworten direkt an meine Mail-Adresse geschickt werden-
Vielen Dank im Voraus
Klaus-Dieter Brinkmann

[udo1toni]

In der UI gibt es im Thing oben die Code Ansicht (links Thing, mitte Channels, rechts Code). Das yaml kannst Du von dort bequem kopieren und hier als Code einfügen.

Was die Ansichten in der Doku betrifft, das ist tatsächlich noch in den Anfängen, aber teilweise auch schon vorhanden. Das Ding ist halt: mit einem Bild kann man nichts anfangen (außer es zu betrachten). Codebeispiele, die als Text vorliegen kann man hingegen leicht kopieren und einfügen. Auch das Ändern von Teilen ist dann kein Problem.
Die Feldbezeichnungen in der UI sind leider nicht 1:1 die gleichen wie die Schlüsselworte in der yaml Ansicht, aber sie sind dicht (genug) dran.

Bei http ist es so, dass Du ein Thing pro baseURL erstellen musst. Die baseURL ist letztlich meist der fqdn, ergänzt um das Protokoll, sie kann aber auch noch beliebig viele Unterverzeichnisse beinhalten, z.B. https://www.meineseite.de:4051/mein/unterVerzeichnis/
Weiterhin braucht es immer noch mindestens einen Channel. Der Channel kann, muss aber nicht unbedingt noch Teil-URLs beinhalten, und zwar getrennt für beide Richtungen. MAn kann also für einen Status eine andere URL verwenden als für einen Steuerbefehl. Die stateURLExtension bzw. commandURLextension wird einfach an die baseURL angehängt. Im Thing kannst Du über die advanced Options festlegen, wie der Aufruf erfolgt (GET oder POST) und auch, ob z.B. im Header des Aufrufs z.B. Daten zur Authentisierung übergeben werden sollen.
Im Channel kannst Du die Art der übertragenen Information auswählen, und ob die Daten (getrennt für Sende- und Empfangsrichtung) noch irgendwie umgeformt werden müssen. Ein Switch Item kennt z.B. nur ON und OFF als Status (und als Befehl), ein per http steuerbarer Schalter versteht aber vielleicht nur 0 und 1 als Kommando oder liefert als Antwort auf die Anfrage nach seinem Zustand ein JSON Objekt zurück, das muss dann halt entsprechend im Channel eingetragen werden, damit aus ON/OFF 1/0 wird oder aus {"power": 1} eben ein ON.

[oliverbaush]

auch wenn ich den Thread kapern muss (ich stehe vor der gleichen Herausforderung)

Quelle ist die API https://www.eiswarnung.de/rest-api/

Dazu hab ich ein Thing angelegt (der Refresh macht vermutlic wenig Sinn, am Ende soll das zu einer gewissen Zeit aufgerufen werden):

Code: Alles auswählen

UID: http:url:EiswarnungAPI
label: Eiswarnung
thingTypeUID: http:url
configuration:
  authMode: BASIC
  ignoreSSLErrors: false
  baseURL: https://api.eiswarnung.de/
  delay: 0
  stateMethod: GET
  refresh: 30
  commandMethod: GET
  timeout: 3000
  bufferSize: 2048

Für die Abfrage werden 3 Parameter benötigt: der API Key, sowie die Koordinaten / Höhen und Breitengrade. Der RAW Request wurde mit https://reqbin.com/#pills-req-headers erfolgreich mit den richtigen Daten getestet und sieht etwa so aus
(es wurde Form URL Encoded verwendet. Mit JSON wurde der Key nicht erkannt)

Code: Alles auswählen

POST / HTTP/1.1
Host: api.eiswarnung.de
Content-Type: application/x-www-form-urlencoded
Content-Length: 80

key=ayb31c194cfd75b112328285094299ac&lat=50.40268210082059&lng=8.196340680476686

Als Antwort kam etwa folgendes:

Code: Alles auswählen

HTTP/1.1 200 OK
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=15
Date: Thu, 07 Mar 2024 19:30:39 GMT
Server: Apache

{"success":true,"message":"Request successful!","code":200,"callsLeft":44,"callsDailyLimit":50,"callsResetInSeconds":12561,"result":{"requestDate":"2024-03-07 20:30:39","forecastId":1,"forecastText":"Eis!","forecastCity":"HalliGalli","forecastDate":"2024-03-08"}}

oder als JSON

Code: Alles auswählen

{
    "success": true,
    "message": "Request successful!",
    "code": 200,
    "callsLeft": 44,
    "callsDailyLimit": 50,
    "callsResetInSeconds": 12561,
    "result": {
        "requestDate": "2024-03-07 20:30:39",
        "forecastId": 1,
        "forecastText": "Eis!",
        "forecastCity": "HalliGalli",
        "forecastDate": "2024-03-08"
    }
}

Interessant ist bei erfolgreicher Abfrage (Code = 200) ob als forecastText etwa ein "Eis!" oder ein "Kein Eis." geliefert wird. Mit dem Hintergedanken,dass es sich um einen Switch handelt, hab ich den folgenden Channel dazu erstellt:

Code: Alles auswählen

UID: http:url:EiswarnungAPI
label: Eiswarnung
thingTypeUID: http:url
configuration:
  authMode: BASIC
  ignoreSSLErrors: false
  baseURL: https://api.eiswarnung.de/
  delay: 0
  stateMethod: GET
  refresh: 30
  commandMethod: GET
  timeout: 3000
  bufferSize: 2048
channels:
  - id: EiswarnungForecast
    channelTypeUID: http:switch
    label: EiswarnungForecast
    description: ""
    configuration:
      mode: READONLY
      onValue: Eis!
      escapedUrl: false
      stateContent: key=ayb31c194cfd75b112328285094299ac,lat=50.40268210082059,lng=8.196340680476686
      commandTransformation: result.forecastText
      offValue: Kein Eis.

Anhand der verfügbaren Requests sehe ich zumindest, dass es aktuell nicht funktioniert. Könnt ihr mir hier auf die Sprünge helfen, wie die Parameter beim Binding im Item richtig eingetragen werden?

[peter-pan]

...ich hab mir mal einen API-Key geholt und diesen auch erfolgreich eingesetzt. Ohne mich jetzt näher mit der Auswertung bzw. der Analyse der Daten zu beschäftigen, denke ich, dass das von dir angesprochene Feld auf keinen Fall ein "Switch"-Feld sein kann. In den Erläuterungen ist das Feld wie folgt definiert:

Code: Alles auswählen

forecastText 	string 	Vorhersage in Worten

Der gesamte (interessante) JSON-String sieht doch so aus:

Code: Alles auswählen

Result Objekt (JSON):
Schlüssel 	Typ 	Beschreibung
requestDate 	string (YYYY-mm-dd HH:ii:ss) 	Zeitpunkt der Anfrage
forecastId 	int 	Vorhersage 0 = kein Eis, 1 = Eis, 2 = evtl. Eis
forecastText 	string 	Vorhersage in Worten
forecastCity 	string 	Erkannter Ort zu den Geokoordinaten
forecastDate 	string (YYYY-mm-dd) 	Tag, für welchen die Vorhersage gültig ist

Einen numerischen Wert gibt es lediglich für das Feld "forecastId", welches 3 Status annehmen kann.

Wenn ich dem API-Call glauben darf, gibt es bei mir aus momentaner Sicht auch "Eis!". Wenn ich meiner lokalen Wetter-App glauben kann, sind es 0 Grad.
Die Werte sind ja eine Vorhersage für einen Wert in 8 - 10 Stunden.

Code: Alles auswählen

success	true
message	"Request successful!"
code	200
callsLeft	48
callsDailyLimit	50
callsResetInSeconds	6564
result	
requestDate	"2024-03-07 22:10:36"
forecastId	1
forecastText	"Eis!"
forecastCity	"Isny da gewesen"
forecastDate	"2024-03-08"

Da die Daten anscheinend aus OWM gezogen werden, ist hier sicherlich auch zu berücksichtigen, ob eine genaue Messung an deinem Standort erfolgt.

Ich muss ehrlich dazu sagen, dass ich das OWM/OneCall-Binding bei mir "abgeschaltet" habe, weil mir die Daten zu ungenau waren.

[udo1toni]

Ein paar Dinge, die mir auffallen (ohne Anspruch auf Vollständigkeit...)

1. Wenn Du beim erfolgreichen Test per POST zugreifst, warum konfigurierst Du dann die stateMethod auf GET?
2. Ein READONLY Channel hat per Definition keine command Konfiguration. Auch eine Transformation kann hier nur eine stateTransformation sein, keine commandTransformation
3. Es gibt viele unterschiedliche Transformation Services. Woher soll openHAB wissen, welchen Du verwenden willst?

Ich würde also erwarten, dass das Thing so aussieht:

Code: Alles auswählen

UID: http:url:EiswarnungAPI
label: Eiswarnung
thingTypeUID: http:url
configuration:
  authMode: BASIC
  ignoreSSLErrors: false
  baseURL: https://api.eiswarnung.de/
  delay: 0
  stateMethod: POST
  refresh: 3600
  commandMethod: GET
  contentType: application/json
  timeout: 5000
  bufferSize: 2048
channels:
  - id: EiswarnungForecast
    channelTypeUID: http:switch
    label: Eiswarnung Forecast
    description: ""
    configuration:
      onValue: Eis!
      stateContent: key=ayb31c194cfd75b112328285094299ac,lat=50.40268210082059,lng=8.196340680476686
      offValue: Kein Eis.
      stateTransformation: JSONPATH:$.result.forecastText

und natürlich muss der JSONPATH Transformation Service auch installiert sein

[udo1toni]

Und mit der Erkenntnis von @madmike wäre es vermutlich sinnvoller, einen Number Channel zu verwenden und die forecastId auszuwerten, 0, 1 oder 2.
Daraus kann man dann im Link zwischen Number Channel und Switch Item (!) per SCALE Transformation (ja, auch die muss dafür installiert sein) bei 0 OFF und bei Werten über 0 ON setzen (wobei ON dann nicht für Eis steht, sondern für Eisgefahr.)
Man kann dann auch noch weitere Items mit dem Number Channel verlinken und z.B. per MAP Transformation Klartext für ein String Item erzeugen, also ohne einen weiteren Channel dafür anzulegen.

[peter-pan]

Ich hab mal das Ganze per HTTP bei mir aufgesetzt. Natürlich die Transformationen, wie von Udo beschrieben voraus gesetzt.
Wie bereits weiter oben erwähnt ist aus meiner Sicht kein Switch-Channel möglich (standardmässig), lässt sich ggf. per Rule und ungebundenem Item oder weiterer Anhängsel (z.B. Profile) realisieren. Das kommt halt auf den Grund an.

.things

Code: Alles auswählen

Thing http:url:eis "Eiswarnung" [
    baseURL="https://api.eiswarnung.de?key=<KEY>&lat=<GPS_LAT>&lng=<GPS_LNG>,refresh=2000 ]
	{
    Channels:
        Type string   : requestDate   "Anfrage Datum"    [ stateTransformation="JSONPATH:$.result.requestDate"]
        Type number   : forecastId    "Vorschau ID"      [ stateTransformation="JSONPATH:$.result.forecastId"]
        Type string   : forecastText  "Vorschau Text"    [ stateTransformation="JSONPATH:$.result.forecastText"]
        Type string   : forecastCity  "Vorschau Ort"     [ stateTransformation="JSONPATH:$.result.forecastCity"]
        Type datetime : forecastDate  "Vorschau Datum"   [ stateTransformation="JSONPATH:$.result.forecastDate"]

    }

...das sieht dann als YAML-Code so aus:

Code: Alles auswählen

UID: http:url:eis
label: Eiswarnung
thingTypeUID: http:url
configuration:
  authMode: BASIC
  ignoreSSLErrors: false
  baseURL: https://api.eiswarnung.de?key=<KEY>&lat=<GPS_LAT>&lng=<GPS_LNG>
  delay: 0
  stateMethod: GET
  refresh: 2000
  commandMethod: GET
  timeout: 3000
  bufferSize: 2048
channels:
  - id: requestDate
    channelTypeUID: http:string
    label: Anfrage Datum
    description: null
    configuration:
      mode: READWRITE
      stateTransformation: JSONPATH:$.result.requestDate
      escapedUrl: false
  - id: forecastId
    channelTypeUID: http:number
    label: Vorschau ID
    description: null
    configuration:
      mode: READWRITE
      stateTransformation: JSONPATH:$.result.forecastId
      escapedUrl: false
  - id: forecastText
    channelTypeUID: http:string
    label: Vorschau Text
    description: null
    configuration:
      mode: READWRITE
      stateTransformation: JSONPATH:$.result.forecastText
      escapedUrl: false
  - id: forecastCity
    channelTypeUID: http:string
    label: Vorschau Ort
    description: null
    configuration:
      mode: READWRITE
      stateTransformation: JSONPATH:$.result.forecastCity
      escapedUrl: false
  - id: forecastDate
    channelTypeUID: http:datetime
    label: AVorschau Datum
    description: null
    configuration:
      mode: READWRITE
      stateTransformation: JSONPATH:$.result.forecastDate
      escapedUrl: false

Die dazugehörigen Items sind

Code: Alles auswählen

String       requestDate   "Anfrage Datum"                {channel="http:url:eis:requestDate"}  
Number       forecastId    "Vorschau ID"                  {channel="http:url:eis:forecastId"}
String       forecastText  "Vorschau Text"                {channel="http:url:eis:forecastText"} 
String       forecastCity  "Vorschau Ort"                 {channel="http:url:eis:forecastCity"}
DateTime     forecastDate  "AVorschau Datum"              {channel="http:url:eis:forecastDate"}

Der Gesamt-String/Array, den du bekommst, sieht so aus

Code: Alles auswählen

[true, Request successful!, 200, 33, 50, 57398, {requestDate=2024-03-08 08:03:22, forecastId=1, forecastText=Eis!, forecastCity=Isny da gewesen, forecastDate=2024-03-08}]
[true, Request successful!, 200, 24, 50, 39398, {requestDate=2024-03-08 13:03:22, forecastId=2, forecastText=Vielleicht Eis., forecastCity=Isny da gewesen, forecastDate=2024-03-09}]

Du kannst, wie von Udo beschrieben, das Item "forecastId" mit einer MAP-Transformation ändern, aber eigentlich wird die entsprechende Texttransformation bereits im Feld "forecastText" bereitgestellt.

Was den Refresh-Intervall betrifft, so habe ich den Wert in meinem Beispiel auf 2000 Sekunden gesetzt. Du kannst das aber noch ein bisschen ändern.
Du hast ja 50 Abfragemöglichkeiten pro Tag frei. Genau ist der Wert - 86400 Sekunden pro Tag / 50 Abfragen = 1728 Sekunden. Das wäre dann der Minimal-Refresh-Wert. (Ich hoffe das stimmt so )

[udo1toni]

Ich denke, eine Abfrage pro Stunde ist mehr als ausreichend, die entsprechenden Warnungen werden mutmaßlich nicht ständig revidiert. Man sollte auch nicht aus dem Blick verlieren, dass openHAB unmittelbar nach einem Neustart eine Abfrage generiert; genauso nach einem "Pausieren" des Things. Man kann also durch notwendige Neustarts leicht unbeabsichtigt mehrere Abfragen generieren und so die freien Abfragen pro Tag "aufbrauchen".

Switch Item:

Code: Alles auswählen

Switch       EisWarnung    "Eis Gefahr"                  {channel="http:url:eis:forecastId"[profile="transform:SCALE",function="eis.scale"]}

$OPENHAB_CONF/tranform/eis.scale:

Code: Alles auswählen

[..0]=OFF
]0..]=ON

Wahlweise kann man die Scale Konfiguration auch direkt über die UI eingeben