Webservices mit dem Gira X1 oder L1 abfragen

[uzi10]

gut zu wissen, dass sich da was ändern wird. hab derzeit meinen per Edomi eingebunden aber bei Kunden würde ich gerne andere Lösungen machen

[cybersmart]

So, jetzt habe ich doch ein eigenartiges Verhalten meiner Logik im X1.
Trotz funktionierender Simulation (und auch die Logik lief schon) bekomme ich derzeit keine Ausgabe in die GA geschrieben und weiss nicht warum.

Da mein X1 sich schonmal abgeschossen hatte bin ich da jetzt etwas angespannt, gerade wenn es um Funktionen geht die durchaus wichtig sind (wurde hier auch schonmal angemerkt).
Generell funktioniert der X1 aber z.B. über die App kann ich alles steuern, auch Alexa tut ihren Dienst, aber diese Logik hier will nicht mehr.

Ich hole mit Daten von Openweathermap onecall API und hole aus dem JSON die relevanten Werte (Niederschlag nächste 10 Minuten und nächste 30 Minuten sowie Windgeschwindigkeiten). In der simulation sieht man wunderbar, dass die Werte kommen und am Ausgang für Regen eine 1 anliegt die auf GA 15/1/0 gesendet wird (da hört der Regen-Sperreingang des Aktor).

Aber der X1 sendet im Livebetrieb die "1" nicht auf den Bus, sehe auch nichts in den ETS-Logs ....

Hat jemand eine Idee woran das liegen kann oder wo ich Ursachenforschung betrieben kann?

EDIT:
- Ursachenforschung war mit X1-Interface und Details zu den Logikbausteinen möglich!

- bei mir hatte zunächst der Fehler im XML/JSON Parser zugeschlagen da im JSON "1h" einen Laufzeitfehler provoziert.
Habe das mit einem Textformatierer vor dem XML/JSON Baustein dann zwar gerade gelöst, aber schon kam der nächste String der einen Laufzeitfehler provoziert (siehe Screenshot).


Fazit:
Da man nie weiss was, wann einen solchen Fehler im XML/JSON Parser provoziert ist meine Lösung zur proaktive Markisensteuerung basierend auf der OWM Onecall API dann gestorben :-(
Hätte mir ergänzend zur Wetterstation gut gefallen, aber die XML API gibt die Date die ich bräuchte (minütlich) so leider nicht her.

[hyman]

Da man nie weiss was, wann einen solchen Fehler im XML/JSON Parser provoziert ist meine Lösung zur proaktive Markisensteuerung basierend auf der OWM Onecall API dann gestorben :-(

Dem kann ich nicht zustimmen, schon gar nicht in der verallgemeinerten Form Deiner Aussage.

Wenn man Daten von einem definierten API holt, ist das Format genau definiert. Ebenso ist das Verhalten des Parsers in der Dokumentation genau definiert. Dort steht auch, dass er mit Keys, die keine gültigen XML Keys wären, nicht umgehen kann. Man kann solche Keys in der Regel durch gültige Keys ersetzen. In den meisten Fällen gibt es also für solche Probleme eine Lösung, wenn sie auch leider manchmal komplizierter ist, als sie sein sollte.

Im Fall des OpenWeatherMap One Call API kann ich schon gar nicht nachvollziehen, warum es nicht funktionieren soll. Laut API-Beschreibung werden keine numerischen Keys im Stile von "1622822400" verwendet. Wo kommen die bei Dir also her?

Grüße von Horst

[cybersmart]

Hallo Horst,

es stecken in der API Response 2x diese ungültigen Werte.

“1h“ und der Unix-Zeitstempel in Anführungszeichen.

Da manche Werte von OWM nicht immer geliefert werden, sondern nur in speziellen Wetterlagen (gestern kam zB Warntext vom DWD auch mit) ist mir das zu heikel die Markise darüber zu steuern, da ich nicht weiss ob irgendwann ne andere Meldung kommt und dann läuft die Logik nicht durch … zumindest solange ich keine Wetterstation habe die das Risiko abfängt.

Die Unwägbarkeiten liegen für mich also in dem was OWM liefert und dass ich das nicht proaktiv abfangen kann. Ich bin mit den Spezifikationen im Detail auch nicht ausreichend vertraut um das 100% sicher abzufangen.

Ich habe nun mal “16 noch in “_16 geändert, dann ist der Laufzeitfehler erstmal weg.

Schicke Dir noch ne PM.

[fgoettel]

Wenn nur der forecast gebraucht wird, würde ich auch nur den abfragen (zB 5 Day / 3 Hour Forecast) den gibts auch direkt als XML und so spart man sich das „String gehacke“.

[cybersmart]

Für meinen Anwendungsfall reicht das so nicht. Ich habe mit der OWM App mal die kurzfristigen Vorhersagen einige Zeit beobachtet und die sind relativ verlässlich wenn man wissen möchte ob es in den kommenden 0-60 Minuten Regen oder Wind gibt - als gute Ergänzung zu einer Wetterstation.
Die Daten bekommt man leider nur als JSON :-(

Ohne Wetterstation traue ich dem Frieden derzeit aber nicht vollständig und fahre bei Abwesenheit die Markise dann immer ein (zukünftig wegen Raumtemperatur im Wintergarten und angrenzendem Raum soll die Markise auch bei Abwesenheit ihren Zweck erfüllen, aber eben erst mit Wetterstation. Wenn im zukünftig unerwartet von OWM BSON noch weitere nicht verarbeitbare Werte kommen steht die Logik …

Ich werte aber die Laufzeitfehler jetzt mal längere Zeit aus und sehe ja ob da was kommt was die Logik stört und lasse wohl auch einen Alarm aufs Smartphone senden bei Laufzeitfehler, so kriege ich das gleich mit. und kann mit dem Textformatierer weiter Finetuning betreiben.
Die Bausteine von Horst erlauben ja volle Flexibilität - nur die Daten die reinkommen sind bei OWM nicht immer gleich … je nach Wetter- und Warnlage kommen da weitere Infos die sonst fehlen.

Bei Abwesenheit wird halt erstmal konsequent die Markise eingefahren, fertig.

[hyman]

“1h“ und der Unix-Zeitstempel in Anführungszeichen.

Den Key 1h finde ich in der API-Beschreibung, den kann man leicht ersetzen.

Die ganze Liste minutely_agrigate (worin dann der Unix-Zeitstempel als key vorkommen soll) finde ich dagegen nicht.

[cybersmart]

Den Key 1h finde ich in der API-Beschreibung, den kann man leicht ersetzen.

Die ganze Liste minutely_agrigate (worin dann der Unix-Zeitstempel als key vorkommen soll) finde ich dagegen nicht.

1h Ersetzung ist umgesetzt, zu der anderen Liste siehe PM.
Heute ist die Logik aus dem Tritt gekommen, weil der Pfad für wind_gust heute nicht beliefert wurde von der API:

Pfad 4: "/root/current/wind_gust" wurde im Eingabetext nicht gefunden.

Das sind die Unwägbarkeiten, dass manchen Pfade nur dann geliefert werden wenn wohl auch Daten vorliegen. wind_speed kommt immer, wind_gust eben nur manchmal. Wie könnte ich sowas geschickt abfangen sodass dann nicht die ganze Verarbeitung stehenbleibt?

[hyman]

zu der anderen Liste siehe PM

Das interessiert bestimmt nicht nur Dich, also lieber hier. Woher die Liste minutely_agrigate kommt, ist mir unklar. In der API-Beschreibung gibt es sie nicht.

... Pfade nur dann geliefert werden wenn wohl auch Daten vorliegen. wind_speed kommt immer, wind_gust eben nur manchmal. Wie könnte ich sowas geschickt abfangen sodass dann nicht die ganze Verarbeitung stehenbleibt?

Da könnte der Parser in der Tat etwas mehr Komfort bieten, indem er für diesen Fall statt der Fehlermeldung auch einen Default-Wert ermöglicht. Da er das momentan nicht kann, bleibt Dir nur, selbst den Default-Wert zu erzeugen. Wenn Du die Abfrage in regelmäßigen Zeitabständen machst, dürfte ein Watchdog und ein Wertgenerator dafür die einfachste Möglichkeit sein.

[cybersmart]

Puh, wie ich das Workaround mit Watchdog und Wertgenerator bauen müsste ist mir noch etwas zu hoch … hast Du ein Beispiel für mich?

Die Liste minutely_agrigate wird von der API geliefert die die OWM App benutzt. Laut Doku der App ist dies auch die Onecall API aber offenbar dann doch etwas abgewandelt. Ich verwende den von der API der OWM App genutzten API Key (TLS intercepted).

[hyman]

Poste doch mal Deine Abfrage-URL hier (ohne API-Key), dann probier' ich das mal aus...

[cybersmart]

Also, die Abfrage URL die ich verwende ist die der OWM App:
https://app.owm.io/app/1.0/weather?l...ic&&appid=(aus der App-Kommunikation intercepted)

Warum: Da ich mit dem App internen API Key keine Restriktionen habe bzgl.Häufigkeit der Abfragen

Mit dieser URL funktionieren die anderen API Keys vermutlich nicht.
Laut OWM App Beschreibung wird die Onecall API verwendet, aber wie schon geschrieben ist diese wohl noch etwas aufgebohrt.

Ich frage aktuell folgendes ab:

Pfad 1: /root/minutely/item[position()<11]/precipitation => wenn Summe > 0 fahre ich die Markise ein, da Regen in den nächsten 10 Minuten wahrscheinlich
Pfad 2: /root/minutely/item[position()<31]/precipitation => wenn Summe = 0 fahre ich zukünftig die Markise wieder auf vorherige Position, da über 30 Minuten kein Regen war (abhängig noch von anderen Bedingungen wie Sonnenstand)
Pfad 3: /root/current/wind_speed => wenn >= 10,8m/s fahre ich die Markise ein
Pfad 3: /root/current/wind_gust => wenn >= 13,8m/s fahre ich die Markise ein !!! dieser Wert kommt nicht immer mit, wenn er fehlt steht die Logik komplett solange bis er wieder kommt

[hyman]

Gut, das ist schon mal nicht das One Call API -- das verwendet eine andere URL (https://api.openweathermap.org/data/2.5/onecall?...). Wenn Du sowas undokumentiertes verwendest, darfst Du Dich nicht wundern, dass unerwartete Sachen passieren.

Alles, was Du abfragen willst, ist auch im "richtigen" dokumentierten One Call API enthalten Damit kannst Du zwar kostenlos nicht minütlich abfragen, aber locker z. B. alle 5 Minuten -- sollte reichen. Keys, die einen Zeitstempel darstellen, kommen dort laut Doku nicht vor. Den Key "1h" kannst Du statisch ersetzen, dann ist der auch kein Problem. /root/minutely/item[position()<31]/precipitation sagt Dir übrigens nicht, ob in den letzten 30 Minuten Regen war, sondern ob in den nächsten 30 Minuten Regen zu erwarten ist. Vermutlich ist das auch genau, was Du möchtest.

Bleibt das Problem, dass wind_gust nicht immer kommt. Ich denke nicht, dass die Logik wirklich komplett steht, wenn er nicht kommt. Der Parser-Baustein spuckt einen Fehler aus und macht weiter, ohne eine Wert auf den entsprechenden Ausgang zu schreiben. Damit steht nur das, was diesen Wert verwendet. D. h. das System verhält sich so, als wären die Böen immer noch unverändert da. Das will man nicht, daher hatte ich ja schon vorgeschlagen

• den wind_gust-Wert auf einen Watchdog zu geben, ...
• ... dessen Zeitspanne so eingestellt ist, dass er kurz nach dem einmaligen Ausbleiben des Werts ...
• einen Wertgenerator triggert, der wahlweise Null oder den aktuellen wind_speed-Wert an alle sendet, die sonst mit dem wind_gust-Wert arbeiten.

Damit sollte dann alles stabil laufen.

[cybersmart]

Danke Horst für die Analyse und die Erläuterung zum Watchdog.

Die Logik gibt nach meiner Einschätzung auf den anderen Ausgängen vermutlich auch nichts aus wenn Pfad 4 klemmt weil wind_gust fehlt, zumindest ist es mir genau in so einer Situation aufgefallen.

Es fing an zu regnen und Markise war draussen, obwohl auch die Summe über 10 Minuten >0 war.
Also habe ich auf Laufzeitfehler geprüft und dort war der Fehler mit Pfad 4 eingetragen.

Wenn das so ist hilft der Watchdog auch nicht, aber ich müsste das erst nochmal wirklich genauer validieren ob meine Einschätzung wirklich stimmt.

Alternativ verzichte ich auf wind_gust generell.

Wird Zeit für die Wetterstation … die dann immer am Ende das Sagen hat.

[hyman]

Die Logik gibt nach meiner Einschätzung auf den anderen Ausgängen vermutlich auch nichts aus wenn Pfad 4 klemmt weil wind_gust fehlt, zumindest ist es mir genau in so einer Situation aufgefallen.

Das kann ich so nicht beobachten. Wenn ein Ausgang seinen Pfad nicht findet, geben die anderen ihre Werte trotzdem aus.