Awattar

Einrichtung der openHAB Umgebung und allgemeine Konfigurationsthemen.

Moderatoren: seppy, udo1toni

Maggi
Beiträge: 27
Registriert: 22. Okt 2019 20:09
Answers: 0
Wohnort: Hanau

Re: Awattar

Beitrag von Maggi »

Hi und frohes Neues,

wie ist es möglich die Daten von der URL: https://api.awattar.de/v1/marketdata in eine Datei runter zu laden, damit ich die http abfrage lokal machen kann?
Dafür müsste es bei Linux doch einen Befehl geben, den ich dann per Cronjob ausführen kann.

Benutzeravatar
udo1toni
Beiträge: 13989
Registriert: 11. Apr 2018 18:05
Answers: 222
Wohnort: Darmstadt

Re: Awattar

Beitrag von udo1toni »

Das macht man so nicht :)

openHAB hat bereits in http1 einen entsprechenden cache-Mechanismus eingebaut. Man kann die Abfragefrequenz einstellen, in der der Cache gefüllt wird. Die Items werden dann aus dem Cache gefüllt.

Wenn Du schon auf openHAB3 umgestiegen bist, ist dieser Cache Mechanismus verpflichtend, die URL wird im Thing hinterlegt, gemeinsam mit der Abfragefrequenz. Die Channel enthalten. Dann die Selektion der einzelnen Werte.


Gesendet von iPad mit Tapatalk
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet

Maggi
Beiträge: 27
Registriert: 22. Okt 2019 20:09
Answers: 0
Wohnort: Hanau

Re: Awattar

Beitrag von Maggi »

Okay verstehe. Ich habe noch OH2.5 und werde mich dann mit OH3 beschäftigen wenn ich mal mehr Zeit habe, da sich doch einiges geändert hat.

das Http Binding verwendet ja den Befehl: "awattar.updateInterval" mit Angabe in Millisekunden.

Gibt es auch eine Möglichkeit die URL nur um eine bestimmte Uhrzeit abzufragen?

Benutzeravatar
udo1toni
Beiträge: 13989
Registriert: 11. Apr 2018 18:05
Answers: 222
Wohnort: Darmstadt

Re: Awattar

Beitrag von udo1toni »

Maggi hat geschrieben: 10. Jan 2021 15:11 Gibt es auch eine Möglichkeit die URL nur um eine bestimmte Uhrzeit abzufragen?
Nein, das geht leider nicht.

Achso, man kann natürlich eine Rule verwenden und dann mit einem http Request arbeiten https://next.openhab.org/docs/configura ... tp-actions. Man muss dann halt ein ungebundenes Itemüber die Rule füllen. Den Response kann man auhc mit der Transform Action per JSONPATH zerlegen lassen. Ist halt umständlicher...
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet

wolfii
Beiträge: 2
Registriert: 1. Sep 2020 15:20
Answers: 0

Re: Awattar

Beitrag von wolfii »

Hallo zusammen,

ich habe angefangen, ein aWATTar Binding zu implementieren. Eine erste Beta für openHAB 3.0 gibt es hier.

https://community.openhab.org/t/awattar ... -it/110497

Kommentare und Feature Requests sind immer willkommen, idealerweise direkt im dortigen Thread.

Viele Grüße

Wolfgang

Quautiputzli
Beiträge: 317
Registriert: 29. Okt 2020 19:53
Answers: 2

Re: Awattar

Beitrag von Quautiputzli »

udo1toni hat geschrieben: 10. Jan 2021 21:30 Achso, man kann natürlich eine Rule verwenden und dann mit einem http Request arbeiten https://next.openhab.org/docs/configura ... tp-actions. Man muss dann halt ein ungebundenes Itemüber die Rule füllen. Den Response kann man auhc mit der Transform Action per JSONPATH zerlegen lassen. Ist halt umständlicher...
Hallo,
ich würde diese Möglichkeit gerne aufgreifen für die Abfrage der Solarprognosedaten. Derzeit lese ich sie ganz normal über den http Service aus. Leider ist es so, dass die Werte in der erste Stunde nach Mitternacht noch nicht aktualisiert sind. Deshalb würde ich die gerne zu bestimmten Zeiten abfragen.

Derzeit sieht es so aus:

Code: Alles auswählen

UID: http:url:solarprognose
label: Solarprognose
thingTypeUID: http:url
configuration:
  authMode: BASIC
  ignoreSSLErrors: false
  baseURL: https://www.solarprognose.de/web/solarprediction/api/v1?access-token=XYZ&type=daily&_format=json
  delay: 0
  stateMethod: GET
  refresh: 7200
  commandMethod: GET
  timeout: 40000
  bufferSize: 2048
channels:
  - id: solarprognose_schupfa
    channelTypeUID: http:string
    label: Solarprognose Schupfa
    description: ""
    configuration:
      stateExtension: "&item=module_field&id=3581"
      stateTransformation: JSONPATH:$.data.*
  - id: solarprognose_haus
    channelTypeUID: http:string
    label: Solarprognose Haus
    description: null
    configuration:
      stateExtension: "&item=module_field&id=3556"
      stateTransformation: JSONPATH:$.data.*
  - id: solarprognose_garage_nord
    channelTypeUID: http:string
    label: Solarprognose Garage Nord
    description: null
    configuration:
      stateExtension: "&item=module_field&id=3582"
      stateTransformation: JSONPATH:$.data.*
  - id: solarprognose_garage_sued
    channelTypeUID: http:string
    label: Solarprognose Garage Süd
    description: null
    configuration:
      stateExtension: "&item=module_field&id=3583"
      stateTransformation: JSONPATH:$.data.*
Jeden dieser Channel habe ich mit 2 Items verbunden:
Bild_2023-01-22_141451387.png
Dabei splite ich den string nochmal auf, der eine Wert für heute, der 2te für morgen:
Bild_2023-01-22_141539824.png

Code: Alles auswählen

(function(string) {
    var value = string.replace("["," ").replace("]"," ");
    var myval = value.split(", ");
    var val = myval[1];
    return val*1;
})(input)
Nun habe ich es schonmal soweit in einer rule zusammengefasst, dass ich die Werte auslesen kann. Ist es nun möglich den string gleich in der rule aufzusplitten, um dann an 2 Item (heue und morgen) weiterzugeben?

Code: Alles auswählen

rule "solarprog"
when
    Item test changed to ON
//    Time cron "0 1 0 * * *"    

then
    val output = sendHttpGetRequest("https://www.solarprognose.de/web/solarprediction/api/v1?access-token=XYZ&type=daily&_format=json&item=module_field&id=3581", 1000)
    logInfo("rules", "solarprognose - Auslesen ({})", output)
    val newValue = transform("JSONPATH", "$.data.*", output)
    logInfo("rules", "solarprognose - Umrechnen ({})", newValue)
end
log:

Code: Alles auswählen

2023-01-22 14:08:08.315 [INFO ] [org.openhab.core.model.script.rules ] - solarprognose - Auslesen ({"preferredNextApiRequestAt":{"secondOfHour":2071,"epochTimeUtc":1674394471},"status":0,"iLastPredictionGenerationEpochTime":1674392780,"weather_source_text":"Kurzfristig (3 Tage): Powered by <a href=\"https://www.weatherapi.com/\" title=\"Free Weather API\">WeatherAPI.com</a> und Langfristig (10 Tage): Powered by <a href=\"https://www.visualcrossing.com/weather-data\" target=\"_blank\">Visual Crossing Weather</a>","datalinename":"Schupfa","data":{"20230122":6.204,"20230123":8.958,"20230124":5.571}})
2023-01-22 14:08:08.322 [INFO ] [org.openhab.core.model.script.rules ] - solarprognose - Umrechnen ([6.204, 8.958, 5.571])
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Servus

Quautiputzli
Beiträge: 317
Registriert: 29. Okt 2020 19:53
Answers: 2

Re: Awattar

Beitrag von Quautiputzli »

Hab selber schon etwas erreicht. Die Testrule sieht nun so aus:

Code: Alles auswählen

rule "solarprog"
when
    Item test changed to ON
//    Time cron "0 1 0 * * *"    

then
    val output = sendHttpGetRequest("https://www.solarprognose.de/web/solarprediction/api/v1?access-token=XYZ&type=daily&_format=json&item=module_field&id=3581", 1000)
    logInfo("rules", "solarprognose - Auslesen ({})", output)
    val newValue = transform("JSONPATH", "$.data.*", output)
    logInfo("rules", "solarprognose - Umrechnen ({})", newValue)
    val newString = newValue.replace("["," ").replace("]"," ")
    logInfo("rules", "solarprognose - klammern weg ({})", newString)
    var myval0 = newString.split(", ").get(0)
    var myval1 = newString.split(", ").get(1)
    logInfo("rules", "solarprognose - split ({}) und ({})", myval0, myval1)
end
Das Ergebnis im log:

Code: Alles auswählen

23-01-22 16:02:52.496 [INFO ] [org.openhab.core.model.script.rules ] - solarprognose - Auslesen ({"preferredNextApiRequestAt":{"secondOfHour":2071,"epochTimeUtc":1674401671},"status":0,"iLastPredictionGenerationEpochTime":1674399693,"weather_source_text":"Kurzfristig (3 Tage): Powered by <a href=\"https://www.weatherapi.com/\" title=\"Free Weather API\">WeatherAPI.com</a> und Langfristig (10 Tage): Powered by <a href=\"https://www.visualcrossing.com/weather-data\" target=\"_blank\">Visual Crossing Weather</a>","datalinename":"Schupfa","data":{"20230122":6.204,"20230123":8.958,"20230124":5.571}})
2023-01-22 16:02:52.502 [INFO ] [org.openhab.core.model.script.rules ] - solarprognose - Umrechnen ([6.204, 8.958, 5.571])
2023-01-22 16:02:52.506 [INFO ] [org.openhab.core.model.script.rules ] - solarprognose - klammern weg ( 6.204, 8.958, 5.571 )
2023-01-22 16:02:52.511 [INFO ] [org.openhab.core.model.script.rules ] - solarprognose - split ( 6.204) und (8.958)
jetzt muss ich es noch irgendwie in die Items bekommen.
Servus

Quautiputzli
Beiträge: 317
Registriert: 29. Okt 2020 19:53
Answers: 2

Re: Awattar

Beitrag von Quautiputzli »

Ich antworte mir ständig selber :D
Ich habs nun nochmal abgeändert/erweitert:

Code: Alles auswählen

rule "solarprog"
when
    Item test changed to ON
//    Time cron "0 1 0 * * *"    

then
    val output1 = sendHttpGetRequest("https://www.solarprognose.de/web/solarprediction/api/v1?access-token=XYZ&type=daily&_format=json&item=module_field&id=3581", 1000) // Schupfa
    logInfo("rules", "solarprognose - Auslesen ({})", output1)
    val String1 = transform("JSONPATH", "$.data.*", output1)
    logInfo("rules", "solarprognose - JSON Umrechnen ({})", String1)
    val Values1 = String1.replace("[","").replace("]"," ")
    logInfo("rules", "solarprognose - Klammern enfernen ({})", Values1)
    var Val_10 = Values1.split(", ").get(0)
    var Val_20 = Values1.split(", ").get(1)
    logInfo("rules", "solarprognose - Solarprognose für Schupfa heute ({}) und morgen ({})", Val_10, Val_20)
    Solarprognose_Schupfa_today.sendCommand(Val_10)
    Solarprognose_Schupfa_tomorrow.sendCommand(Val_20)
end
Die Werte werden geschrieben, aber nicht übernommen. Warum?

Code: Alles auswählen

2023-01-22 16:24:21.348 [INFO ] [org.openhab.core.model.script.rules ] - solarprognose - Auslesen ({"preferredNextApiRequestAt":{"secondOfHour":2071,"epochTimeUtc":1674401671},"status":0,"iLastPredictionGenerationEpochTime":1674400783,"weather_source_text":"Kurzfristig (3 Tage): Powered by <a href=\"https://www.weatherapi.com/\" title=\"Free Weather API\">WeatherAPI.com</a> und Langfristig (10 Tage): Powered by <a href=\"https://www.visualcrossing.com/weather-data\" target=\"_blank\">Visual Crossing Weather</a>","datalinename":"Schupfa","data":{"20230122":6.204,"20230123":8.958,"20230124":5.571}})
2023-01-22 16:24:21.354 [INFO ] [org.openhab.core.model.script.rules ] - solarprognose - JSON Umrechnen ([6.204, 8.958, 5.571])
2023-01-22 16:24:21.359 [INFO ] [org.openhab.core.model.script.rules ] - solarprognose - Klammern enfernen (6.204, 8.958, 5.571 )
2023-01-22 16:24:21.365 [INFO ] [org.openhab.core.model.script.rules ] - solarprognose - Solarprognose für Schupfa heute (6.204) und morgen (8.958)
2023-01-22 16:24:21.371 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'Solarprognose_Schupfa_today' received command 6.204
2023-01-22 16:24:21.372 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Solarprognose_Schupfa_today' predicted to become 6.16
2023-01-22 16:24:21.375 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'Solarprognose_Schupfa_tomorrow' received command 8.958
2023-01-22 16:24:21.377 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Solarprognose_Schupfa_tomorrow' predicted to become 10.533
Servus

Quautiputzli
Beiträge: 317
Registriert: 29. Okt 2020 19:53
Answers: 2

Re: Awattar

Beitrag von Quautiputzli »

Mit

Code: Alles auswählen

postUpdate
scheint es zu funktionieren anstatt

Code: Alles auswählen

sendCommand
Offensichtlich hab ich den Unterschied immer noch nicht begriffen.
Servus

Benutzeravatar
udo1toni
Beiträge: 13989
Registriert: 11. Apr 2018 18:05
Answers: 222
Wohnort: Darmstadt

Re: Awattar

Beitrag von udo1toni »

Ganz einfach.

postUpdate() setzt den Status eines Items.
sendCommand() sendet einen Befehl über ein Item an die daran gebundenen Channel.

Weiterhin lösen beide Befehle unterschiedliche Trigger aus:
postUpdate() löst ein received update aus, außerdem ein changed, falls sich durch das postUpdate() der Status geändert hat.
sendCommand() löst ein received command aus.

Zu guter Letzt wird openHAB als Default Verhalten nach einem sendCommand() automatisch ein postUpdate() für das selbe Item generieren, wobei der konkrete Wert errechnet wird. Diese Berechnung kann korrekt sein oder auch nicht (ist auch abhängig vom Itemtyp).
Diese Funktion (autoupdate) dient vor allem der minimierten Reaktionszeit. Sie führt aber auch durchaus zu Problemen, beispielsweise wenn man einen Dimmer hat, dessen Einschaltlevel konfigurierbar ist (Standard bei knx). Dann führt ein ON Befehl eben nicht unbedingt zu einem Dimlevel von 100, sondern einem beliebigen anderen Wert, der frei konfigurierbar ist. Das führt dann zu Hin- und Herspringen des Status.
Abgesehen davon ist es eigentlich besser, den echten Status den angebundenen Channels zu kennen, und nicht einen, den openHAB errechnet hat.
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet

Antworten