Support-Thread zum OpenWeatherMap Plugin

[Sisamiwe]

Was man machen könnte, wäre folgendes:

• Entweder: wenn das Matching fehlschlägt und der Datentyp eine Liste ist, aber ein String angegeben ist, man das erste Element nimmt und dann versucht den String zu matchen. Das würde dann auch zu Erfolgen bei day/temp führen, wo das dann "heute" treffen würde.

Hallo,

ich würde es gut finden, wenn Du es so umsetzen würdest. Zusätzlich könnte man noch ein Warnung is Log schreiben, dass das erste Element verwendet wurde.

Noch eine andere Frage:
Wie stellst Du dir das struct vor? Ähnlich dem für das darksky-Plugin? Dort gibt es ein vollständiges, aber auch riesiges struct.
Da die verfügbaren Elemente/Werte im Forecast ja immer gleich sind, könnte man sich auch einen Trennung des Matchstrings vorstellen.
d.h. man könnte den ersten Teil des Matchstrings bspw "day/1" weiter oben im Itembaum definieren und dann vererben. Dann könnte man kleinere structs nur für die verfügbaren Werte machen.

Hier mal ein Beispiel:

forecast_daily1: # day after tomorrow (max index 4 = 5 days ahead)
    owm_matchstring@home: forecast/daily/1
    
    time:
        type: num
        owm_matchstring@home: dt

    temp:
        type: num
        owm_matchstring@home: main/temp

    temp_min:
        type: num
        owm_matchstring@home: main/temp_min

    temp_max:
        type: num
        owm_matchstring@home: main/temp_max

    pressure:
        type: num
        owm_matchstring@home: main/pressure

    grnd_level:
        type: num
        owm_matchstring@home: main/grnd_level

    sea_level:
        type: num
        owm_matchstring@home: main/sea_level

    humidity:
        type: num
        owm_matchstring@home: main/humidity


    wind_speed:
        type: num
        owm_matchstring@home: wind/speed

    wind_deg:
        type: num
        owm_matchstring@home: wind/deg

    clouds:
        type: num
        owm_matchstring@home: clouds/all

und dann mit struct:

forecast_daily1: # day after tomorrow (max index 4 = 5 days ahead)
    owm_matchstring@home: forecast/daily/1
    struct: forecast_daily

forecast_daily2:
    owm_matchstring@home: forecast/daily/2
    struct: forecast_daily

und das struct dazu:

struct forecast_daily:
    time:
        type: num
        owm_matchstring@home: dt

    temp:
        type: num
        owm_matchstring@home: main/temp

    temp_min:
        type: num
        owm_matchstring@home: main/temp_min

    temp_max:
        type: num
        owm_matchstring@home: main/temp_max

    pressure:
        type: num
        owm_matchstring@home: main/pressure

    grnd_level:
        type: num
        owm_matchstring@home: main/grnd_level

    sea_level:
        type: num
        owm_matchstring@home: main/sea_level

    humidity:
        type: num
        owm_matchstring@home: main/humidity


    wind_speed:
        type: num
        owm_matchstring@home: wind/speed

    wind_deg:
        type: num
        owm_matchstring@home: wind/deg

    clouds:
        type: num
        owm_matchstring@home: clouds/all

Was meinst Du?

[jentz1986]

Hi!

den ersten Teil des Matchstrings bspw "day/1" weiter oben im Itembaum definieren und dann vererben

Coole Idee!

Ich hadere noch etwas mit der Umsetzung. Im unifi-Plugin habe ich einige Attribute von den Elternelementen vererbt, ohne das explizit zu machen. Damit ist es nicht immer offensichtlich, dass das Eltern- (oder Großeltern, oder ...) -Element Einfluss auf das gerade betrachtete Element hat. Da hab ich einige Klimmzüge im Web-Interface gemacht um das debug- und nachvollziehbar zu machen. Es gibt neuerdings(? - bitte nicht lachen) ja die Möglichkeit auch der expliziten Attributvererbung. Ich würde dann ein separates Attribut owm_match_prefix machen, das (wenn vorhanden) dem matchstring vorangestellt wird. Die Vererbung im struct wäre dann explizit. Das hätte nebenbei noch den Vorteil, dass man keine Leichen-Zuordnungen hat, und man auch den "Wurzelknoten" noch nutzen kann.

Das KÖNNTE so aussehen:

forecast_daily1:
    owm_match_prefix@home: day/1
    owm_matchstring@home: /weather/description
    temp_night:
        type: num
        remark: Das hier wäre natürlich im struct
        owm_match_prefix@home: ../.
        owm_matchstring@home: /temp/night

psilo: Eigentlich ist das Plugin von Dir - Kommentare, Wünsche, Anforderungen?

Bezüglich darksky hatte ich die Idee ein Konfig-Item "hijack_darksky: yes" in der Plugin-Konfig zu haben und dann ein Mapping für jeden darksky matchstring auf den entsprechenden OWM-matchstring zu erstellen, so dass ein User nur noch das darksky-Plugin deaktivieren muss und hijack_darksky aktivieren und schon sind wieder Werte da... Über das Plugin-GUI ließe sich dann der Matchstring ablesen. Vielleicht gibts ja dann auch noch ein "like-darksky"-struct dass die Migration für das Standard-struct leicht macht. Aber ehrlich gesagt: Ich habe darksky nicht benutzt und würde daher auch das Migrationsthema lieber jemandem überlassen, der wenigstens nen API-key bei darksky hat...

[Sisamiwe]

Es gibt neuerdings(? - bitte nicht lachen) ja die Möglichkeit auch der expliziten Attributvererbung. Ich würde dann ein separates Attribut owm_match_prefix machen, das (wenn vorhanden) dem matchstring vorangestellt wird. Die Vererbung im struct wäre dann explizit. Das hätte nebenbei noch den Vorteil, dass man keine Leichen-Zuordnungen hat, und man auch den "Wurzelknoten" noch nutzen kann.

Das kannte ich auch noch nicht, finde es aber prima. So bekommen wir die Structs übersichtlich.

Was man damit allerdings noch nicht lösen kann, sind structs die für verschiedene Plugin-Instanzen verwendet werden kann. Hier muss doch die Instanz an das attribut angehangen werden, oder?

Bezüglich darksky hatte ich die Idee ein Konfig-Item "hijack_darksky: yes" in der Plugin-Konfig zu haben und dann ein Mapping für jeden darksky matchstring auf den entsprechenden OWM-matchstring zu erstellen, so dass ein User nur noch das darksky-Plugin deaktivieren muss und hijack_darksky aktivieren und schon sind wieder Werte da...

Wie meinst Du das genau? Meinst Du, dass die gleichen Item-Namen verwendet werden?

Mein Test-Status:
Ich habe nur alle Matchstrings einmal verwendet. Es gibt noch 2 Anmerkungen:

1. "rain/1h: Rain volume in mm /// snow/1h: Snow volume in mm"
   Hier klappt findet er die /1h nicht. Ist im WebIF auch nicht enthalten
2. "/snow"
   Der String ist nicht immer enthalten; Das müsste man im Plugin abfangen und auf 0 setzen

Beste Grüße
Michael

[psilo]

jentz1986 baut ruhig weiter. Ich habe das damals nur schnell runtergecodet, als ich das Darksky gebaut habe. Ohne viel Elan muss ich gestehen. Insofern freut mich, wenn sich aktiv Leute an der Verschönerung beteiligen. Ich teste gerne demnächst mal!

[jentz1986]

Meinst Du, dass die gleichen Item-Namen verwendet werden?

Ja, ich meine das so, dass das owm-plugin, dann auch die ds_matchstring Attribute aufgreift und dann übersetzt zu owm_matchstring. Das ist ein Verstoß gegen die Präfixregel, kann aber für eine schnelle Migration von darksky echt einen Vorteil bringen. Ich könnte mir vorstellen, dass wenn dieses Feature im nächsten Plugin-Release (von SHNG) drin wäre, dass dann einige nicht so versierte Anwender echt happy wären, wenn sie nur ihre plugin.yaml anpassen müssten um von darksky zu owm zu migrieren. Weil: "huch, ich wusste ja gar nicht, dass die DS-API außer Betrieb genommen wird, wie kann ich das denn jetzt schnell ändern, damit der WAF nicht kaputtgeht?"...

Was man damit allerdings noch nicht lösen kann, sind structs die für verschiedene Plugin-Instanzen verwendet werden kann.

Das sollte auch out-of-the-box funktionieren: https://www.smarthomeng.de/user/konf...-unterstutzung

Es gibt noch 2 Anmerkungen

Ich habe mal ein paar Testfälle in meine YAML eingebaut und das Problem anhand derer gelöst. In meinem Log sieht es jetzt so aus:

2021-07-23  12:15:34 WARNING  plugins.openweathermap Missing integer after 'day/' assuming 'day/0/' in matchstring day/temp/night
2021-07-23  12:15:34 DEBUG    plugins.openweathermap _update: -OK- : owm-string: day/temp/night --> daily/0/temp/night from wrk=onecall for item wetter.kaputt.no_int_after_day
2021-07-23  12:15:34 WARNING  plugins.openweathermap Integer expected in matchstring after 'daily/1/weather', inserting '/0' to match FIRST entry.
2021-07-23  12:15:34 DEBUG    plugins.openweathermap _update: -OK- : owm-string: day/1/weather/description --> daily/1/weather/0/description from wrk=onecall for item wetter.kaputt.no_int_after_weather
2021-07-23  12:15:34 DEBUG    plugins.openweathermap _calculate_eto: for day/1/eto
2021-07-23  12:15:34 DEBUG    plugins.openweathermap _calculate_eto: day/1/eto, eTo: 2.904464847016742
2021-07-23  12:15:34 DEBUG    plugins.openweathermap _update: -OK- : owm-string: day/1/eto --> day/1/eto from wrk=onecall [eto-calculation] for item wetter.kaputt.day_eto_instead_of_daily
2021-07-23  12:15:34 WARNING  plugins.openweathermap Missing integer after 'day/' assuming 'day/0/' in matchstring day/snow
2021-07-23  12:15:34 DEBUG    plugins.openweathermap No defined value for 'daily/0/snow', missing 'snow/', defaulting to 0
2021-07-23  12:15:34 DEBUG    plugins.openweathermap _update: -OK- : owm-string: day/snow --> daily/0/snow from wrk=onecall for item wetter.kaputt.any_snow_today
2021-07-23  12:15:34 WARNING  plugins.openweathermap Missing integer after 'day/' assuming 'day/0/' in matchstring day/rain
2021-07-23  12:15:34 DEBUG    plugins.openweathermap No defined value for 'daily/0/rain', missing 'rain/', defaulting to 0
2021-07-23  12:15:34 DEBUG    plugins.openweathermap _update: -OK- : owm-string: day/rain --> daily/0/rain from wrk=onecall for item wetter.kaputt.any_rain_today
2021-07-23  12:15:34 WARNING  plugins.openweathermap Missing integer after 'hour/' assuming 'hour/0/' in matchstring hour/snow/1h
2021-07-23  12:15:34 DEBUG    plugins.openweathermap No defined value for 'hourly/0/snow/1h', missing 'snow/1h', defaulting to 0
2021-07-23  12:15:34 DEBUG    plugins.openweathermap _update: -OK- : owm-string: hour/snow/1h --> hourly/0/snow from wrk=onecall for item wetter.kaputt.some_snow_soon
2021-07-23  12:15:34 DEBUG    plugins.openweathermap _update: -OK- : owm-string: day/1/rain --> daily/1/rain from wrk=onecall for item wetter.kaputt.prefixed_weather.prefixed_rain
2021-07-23  12:15:34 WARNING  plugins.openweathermap Integer expected in matchstring after 'daily/1/weather', inserting '/0' to match FIRST entry.
2021-07-23  12:15:34 DEBUG    plugins.openweathermap _update: -OK- : owm-string: day/1/weather/description --> daily/1/weather/0/description from wrk=onecall for item wetter.kaputt.prefixed_weather

Ich bin noch nicht ganz zufrieden. Das "_update: -OK-" ist ja eine DEBUG-Meldung, die die tatsächliche Übersetzung nach "Anwendung" der vorherigen Fixes / Warnings darstellt. Wird das Loglevel nun von DEBUG auf WARNING geändert, fallen die Übersetzungen und der Bezug auf die Items weg. Sollte man vom Anwender erwarten dürfen, dass er das Loglevel auf DEBUG erhöht, wenn etwas kaputt ist? Alternative Idee könnte sein, den Item-Path allen Logeinträgen voranzustellen.

[Sisamiwe]

jentz1986

Hallo,
Ich fange mal bei Deinem Post unten an mit den Antworten:

Sollte man vom Anwender erwarten dürfen, dass er das Loglevel auf DEBUG erhöht, wenn etwas kaputt ist?

Ich denke ja.

Alternative Idee könnte sein, den Item-Path allen Logeinträgen voranzustellen.

Das ist trotzdem eine gute Idee. Mit Pfad meinst Du aber den "Pfad", anhand dessen im JSON der Wert bestimmt, wird, oder?

Ich habe mal ein paar Testfälle in meine YAML eingebaut und das Problem anhand derer gelöst. In meinem Log sieht es jetzt so aus:

Kann ich bestätigen.

Das sollte auch out-of-the-box funktionieren: https://www.smarthomeng.de/user/konf...-unterstutzung

Das kannte ich auch noch nicht. Damit geht es aber. Somit könnte ich mal ein paar structs basteln.

Ja, ich meine das so, dass das owm-plugin, dann auch die ds_matchstring Attribute aufgreift und dann übersetzt zu owm_matchstring. Das ist ein Verstoß gegen die Präfixregel, kann aber für eine schnelle Migration von darksky echt einen Vorteil bringen.

Man könnte natürlich auch einfach ein owm struct generierten, dass die gleichen Items erzeugt, die das darksky struct. Ich denke, dass die meinsten Nutzer des Darksky Plugins (so wie ich auch) die mitgelieferten structs bei darksky nutzten, da einfach sehr viele Items etc generiert werden.
Wenn das owm struct die gleichen items wieder erzeugt, sollte die DB auch einfach weiter geschrieben werden.
Was meinst Du?


Und zu guter Letzt habe ich noch ein paar Findings aus dem aktuellen Test, insbesondere bzw. ausschließlich bei Verwendung der Oncall-API:

• lat // lon
  Wenn man lat und lon aus der Antwort der Oncall-API ziehen möchte, kommt auch eine Fehlermeldung. Ich glaube mit den matchstrings "verläuft" sich das Plugin, da auch bei der normalen API lat und lon möglich sind:
  

  2021-07-24 20:29:19 ERROR plugins._priv_openweathermap home@: _update: ERROR: owm-string: lat --> lat from wrk=weather, Error: Missing child 'lat' after '' for item owm_onecall.locals.lat
  	2021-07-24 20:29:19 ERROR plugins._priv_openweathermap home@: _update: ERROR: owm-string: lon --> lon from wrk=weather, Error: Missing child 'lon' after '' for item owm_onecall.locals.lon

• timezone // timezone_offset
  läßt sich nicht aus dem JSON ziehen. Hier wird er Wert der timezone_offset in die timezone zu schreiben.
  

  2021-07-24  20:24:20 WARNING  lib.item.item                  Item owm_onecall.locals.timezone: value "7200" does not match type str. Via _priv_openweathermap weather // /timezone

• alerts
  Sind die schon implementiert?
  Habs mit:
  

      alerts:
  	        remark: National weather alerts data from major national weather warning systems
  	
  	        sender_name:
  	            remark: Name of the alert source. Please read here the full list of alert sources
  	            type: str
  	            owm_matchstring@home: alerts/sender_name
  	        event:
  	            remark: Alert event name
  	            type: str
  	            owm_matchstring@home: alerts/event
  	        start:
  	            remark: Date and time of the start of the alert, Unix, UTC
  	            type: str
  	            eval: datetime.datetime.fromtimestamp(value, datetime.timezone.utc).astimezone().strftime('%Y-%m-%d %H:%M:%S %Z%z')
  	            owm_matchstring@home: alerts/start
  	        end:
  	            remark: Date and time of the end of the alert, Unix, UTC
  	            type: STR
  	            eval: datetime.datetime.fromtimestamp(value, datetime.timezone.utc).astimezone().strftime('%Y-%m-%d %H:%M:%S %Z%z')
  	            owm_matchstring@home: alerts/end
  	        description:
  	            remark: Description of the alert
  	            type: str
  	            owm_matchstring@home: alerts/description

  versucht.
  

  2021-07-24 20:29:20 ERROR plugins._priv_openweathermap home@: _update: ERROR: owm-string: alerts/sender_name --> alerts/sender_name from wrk=weather, Error: Missing child 'alerts/sender_name' after '' for item owm_onecall.alerts.sender_name
  	2021-07-24 20:29:20 ERROR plugins._priv_openweathermap home@: _update: ERROR: owm-string: alerts/event --> alerts/event from wrk=weather, Error: Missing child 'alerts/event' after '' for item owm_onecall.alerts.event
  	2021-07-24 20:29:20 ERROR plugins._priv_openweathermap home@: _update: ERROR: owm-string: alerts/start --> alerts/start from wrk=weather, Error: Missing child 'alerts/start' after '' for item owm_onecall.alerts.start
  	2021-07-24 20:29:20 ERROR plugins._priv_openweathermap home@: _update: ERROR: owm-string: alerts/description --> alerts/description from wrk=weather, Error: Missing child 'alerts/description' after '' for item owm_onecall.alerts.description
  	2021-07-24 20:29:20 ERROR plugins._priv_openweathermap home@: _update: ERROR: owm-string: alerts --> alerts from wrk=weather, Error: Missing child 'alerts' after '' for item wetter.owm.zuhause.vorhersage.alarm

• Onecall-0
  Kommt man auch an die "hourly" in der historischen Betrachtung ran?

Beste Grüße
Michael

[jentz1986]

Somit könnte ich mal ein paar structs basteln.

Attacke!

Wenn das owm struct die gleichen items wieder erzeugt, sollte die DB auch einfach weiter geschrieben werden.
Was meinst Du?

Das ist auf jeden Fall der einfachere Fall. Ich denke damit kommt man erstmal weiter - mal schauen wann die ersten DarkSky-User schreien ☺

Wenn man lat und lon aus der Antwort der Oncall-API ziehen möchte, kommt auch eine Fehlermeldung

timezone // timezone_offset
läßt sich nicht aus dem JSON ziehen.

Ups - fixed it (beides).

alerts, Sind die schon implementiert?

Jaain, die waren buggy, aaaber auch jetzt nach dem Fix sind sie nicht wirklich gut verwendbar. Das Problem ist, das "alerts" eine Liste ist, die entweder gar nicht da ist, oder auch mal mehrere Elemente beinhaltet. Jetzt könnte man auch hier nur das erste Element einfügen, aber ist das das Relevante? Und: Meistens gibts keine Alerts - zum Glück... (Schrieb's und bekam ne Gewitterwarnung ins Item, leider auf Englisch, trotz Sprache Deutsch)
Screenshot 2021-07-26 180022.png

Kommt man auch an die "hourly" in der historischen Betrachtung ran?

Jepp: day/-1/hour/11/temp, liefert die Temperatur von gestern 13 Uhr zurück. Das sind halt Stundenindizes nach UTC... Achtung, bei -0 kommst du nur soweit, wie die Zeit vorangeschritten ist. Heißt um 17:00 ist der key "16" nicht mehr definiert. Das ist echt lästig.

Das ist trotzdem eine gute Idee. Mit Pfad meinst Du aber den "Pfad", anhand dessen im JSON der Wert bestimmt, wird, oder?

Hab ich gemacht. Aber mit Pfad meine ich einerseits den Item-Pfad, andererseits den angegebenen Matchstring und dann den veränderten Matchstring.

[Sisamiwe]

Attacke!

Das mache ich.

Hast Du auch bereits die Vererbung der matchstring prefix implementieren können?

Ich würde dann ein separates Attribut owm_match_prefix machen, das (wenn vorhanden) dem matchstring vorangestellt wird. Die Vererbung im struct wäre dann explizit. Das hätte nebenbei noch den Vorteil, dass man keine Leichen-Zuordnungen hat, und man auch den "Wurzelknoten" noch nutzen kann.

Eine weitere Frage / Anregung:
Bislang habe ich eine Logik, die mir anhand der Windgeschwindigkeit die Windstärke nach Beaufort ermittelt und ausgibt. Könnte man die Logik ins Plugin integrieren oder mit dem Plugin "ausliefern"?

[bmx]

Die Logik findet man u.a. hier im Blog.

[jentz1986]

Hast Du auch bereits die Vererbung der matchstring prefix implementieren können?

Ja, eigentlich schon in der vorherigen Version, offensichtlich habe ich das funkionierende Beispiel nur kopiert, aber nicht hier eingefügt. Das hole ich dann einfach mal nach:

prefixed_weather:
            type: str
            owm_match_prefix: day/1
            owm_matchstring: /weather/description
            prefixed_rain:
                owm_match_prefix: ..:.
                owm_matchstring: /rain

Könnte man die Logik ins Plugin integrieren oder mit dem Plugin "ausliefern"?

Die Logik findet man u.a. hier im Blog.

Danke, ich hab da mal geplündert und das ganze eingebaut. So sieht dann die Nutzung in den Items aus, wenn man das Plugin "owm" nennt:

        beauforts:
            type: num
            owm_matchstring: current/wind_speed
            eval: sh.owm.get_beaufort_number(value)
            desc:
                type: str
                eval: sh.owm.get_beaufort_description(sh...())
                eval_trigger: ..

Die Beschreibung wird anhand des lang-Parameters des Plugins entweder in Deutsch oder in Englisch ausgegeben.

Sisamiwe, darf ich Dich als Tester in der plugin.yaml vermerken?

[jentz1986]

alerts
Sind die schon implementiert?

Ich hab jetzt noch einen "Placebo" Alarm eingebaut. Wenn es keine Alarm-Meldung gibt, dann wird dieser "Alarm" eingebaut.

[bmx]

So sieht dann die Nutzung in den Items aus, wenn man das Plugin "owm" nennt

Ich finde das recht unschön das eine allgemeine struct vom Namen des Plugins abhängig ist. Msinn Hast Du da eine Idee wie man es besser machen könnte?
Im Prinzip sind das ja sogar statische Funktionen die nicht einmal im Namensraum des Plugins sein müssen.

[Msinn]

bmx

eval: sh.owm.get_beaufort_number(value)

sieht für mich aber nicht nach einem struct Thema aus. Ich vermute, dass jentz1986 Funktionen in das Plugin eingebaut hat und diese von außen aufruft.

[jentz1986]

Hmm, ich war davon ausgegangen, dass das nicht im struct benötigt wird. Klar könnte man das in die matchstrings aufnehmen, so wie die ETo-Berechnung…

Gibts denn eine Möglichkeit ein „@instance“ auch in einem eval mit der instance zu ersetzen?

[Msinn]

Jetzt hast Du mich verloren…

Wozu willst Du ein @instance in einem eval verwenden?