Ankündigung

Einklappen
Keine Ankündigung bisher.

Support-Thread zum OpenWeatherMap Plugin

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    #76
    Zitat von jentz1986 Beitrag anzeigen
    Hab ein Regen-Widget gebaut, was auch die letzten 12h und die kommenden 12h Regen anzeigt - sinnvoll?
    Sehr cool!
    Da werde ich dann wohl langsam mal den Umstieg von Darksky wagen... Danke!

    Kommentar


      #77
      Zitat von Onkelandy Beitrag anzeigen
      Sehr cool!
      Gibt es noch andere Widget-Anforderungen, die sinnvoll zum Plugin passen?
      Bitte nicht die Wetter-Widgets aus der SmartVisu replizieren...

      Die Bewässerungssteuerung, die aus dem irrigation-struct kommt hat folgendes Widget (rot eingerahmt, ein Klick auf die Zahnräder öffnet das Popup von oben, das gehört hier nat. zum Gewächshaus):
      Screenshot 2021-07-30 180734.png

      PHP-Code:
      {% import "widgets_openweathermap.html" as owm %}
      <
      h1><img class="icon" src='{{ icon0 }}sani_irrigation.svg' />Bewässerung</h1>
      <
      h2>Regen</h2>
      {{ 
      owm.rain_overview('regengraph''wetter.regen.letzte_12h''wetter.regen.naechste_12h''wetter.von') }}
      <
      h2>Wasserkreise ohne Regen</h2>
      {{ 
      owm.irrigation('ventil_1''Im Gewächshaus''garten.geraet.bewaesserung.am_gewaechshaus.ventil _1') }}
      <
      h2>Wasserkreise mit Regen</h2>
      Bauchfaktor
      {{ basic.slider('''garten.geraet.bewaesserung.bauchfaktor'020.1''''0200) }}

      ... 
      Zuletzt geändert von jentz1986; 30.07.2021, 17:25. Grund: bugfix

      Kommentar


        #78
        Zitat von jentz1986 Beitrag anzeigen
        OK, ich würde für Instanzen einfach nur mehrere Instanzen des gleichen Verzeichnisses machen. Ich habe alle Plugins nur einmal, entweder in meinem "Frickel"-Zustand oder eben aus dem offiziellen Release - daher ändert sich der Name des Plugins nicht.
        So hatte ich das auch, bis ich mal aus Versehen ein "git update" gemacht habe und alle meine Änderungen weg waren. Seit dem lege ich meine "Eigenkreationen" in eigenen Ordnern an. Und Plugin-Name und Order identisch bzw entspricht der Name der Ordner.
        Zitat von jentz1986 Beitrag anzeigen
        Nein - das ist ein und die selbe Fehlermeldung für alle Fälle. Die Matchstrings sollten dann berichtigt werden. - klar es funktioniert, das ist der Sinn der gemachten Implementierung, weil man das mit der Liste gerne übersieht. Aber der korrekte Matchstring ist dann "alerts/0/event" und nicht "alerts/event". "alerts/0/..." ist jetzt auch immer gesetzt, d.h. man kann das Element auch wirklich in einem Item nutzen. Im struct sollten auch nur korrekte Matchstrings sein und nicht solche, die durch interne Korrekturen bereinigt werden.
        Ok

        Kommentar


          #79
          Nur für den Fall das jemand mittesten möchte und nicht so richtig weiß, wie er/sie/es das anstellen soll:

          Um den Entwicklungsstand von jentz1986 herunterzuladen ist es am einfachsten ein neues privates Plugin zu erstellen.
          1. Unterverzeichnis in smarthom/plugins mit Namen priv_openweathermap erstellen
          2. Eine Zip Datei des Plugins vom Entwicklungsstand erstellen lassen, dazu auf Downgit gehen und dort als URL https://github.com/jentz1986/smartho...openweathermap eingeben.
          3. Den Inhalt der Zipdatei dann in priv_openweathermap reinkopieren, darauf aufpassen, das dort dann nicht nur openweathermap drinsteht sondern die gleiche Struktur wie in anderen Plugin Ordnern auch.
          4. Sofern openweathermap als Plugin aktiviert ist, sollte das in der items.yaml nun entsprechend geändert s.u. und anschliessend kann SmartHomeNG neu gestartet werden.
          5. Entsprechende Items müssen nun konfiguriert werden. Einige structs sind von Sisamiwe in Arbeit und ich denke die werden sicher im Repo Einzug halten wenn die fertig sind.
          Code:
          #owm:
          # plugin_name: openweathermap
          # key: bb7fd7dc....
          # plugin_enabled: false
          
          owm:
              plugin_name: priv_openweathermap
              key: bb7fd7dc....xyz
              plugin_enabled: true

          Kommentar


            #80
            jentz1986 Onkelandy
            ,

            Hallo,

            der erste Wurf der structs ist fertig und diese hier zu finden.

            Es gibt dort 3 Dateien:
            A) Eine aktualisierte plugin.yaml für das owm_plugin. Dort sind die structs enthalten.
            B) Eine Item-Datei, die diese structs nutzt und die Items so erstellt, wie es das darksky_struct gemacht hat. Das wäre also der "Konverter".
            C) Eine Item-Datei, die ebenfalls diese structs (aber andere) nutzt und alle Informationen liefert, die die onecall-api von owm bereitstellt.

            jentz1986
            Könntest Du auch noch die air_pollution api ins Plugin integrieren?

            Bitte mal testen und Feedback an mich.

            DANKE

            Michael

            Kommentar


              #81
              Es ist noch mindestens ein Rechtschreibfehler in der struct für darksky: darksky2owm_lcoals

              Kommentar


                #82
                Zitat von Sisamiwe Beitrag anzeigen
                Könntest Du auch noch die air_pollution api ins Plugin integrieren?
                Ich versuchs. Leider gibt's ja nicht nur die eine, sondern sowohl history als auch forecast. Als ich gerade mit der Implementierung angefangen habe, fiel mir auf, dass das für die mögliche Datenmenge komfortabel 6 weitere Calls sind, die jedes mal abgesetzt werden. Ich habe nur die freie Lizenz und daher nur 1000 Calls/Tag. Wenn SmartVisu Calls macht und meine Handy App Calls macht und SHNG so viele macht, kann das das Kontingent strapazieren. Braucht man alle diese Daten immer? Die Funktionalität vorsehen: Gerne! Alles immer in jedem struct haben? Weiß nicht...

                Ich baue erstmal das Webinterface um, dass man auch wirklich alle abgerufenen JSONs anschauen kann. Das geht ja gerade nicht, weil es nur 6 Tabs gibt.

                Noch eine Beobachtung aus den structs:
                day-0 ist tatsächlich heute, nicht gestern. Es gibt zu heute als zwei relevante Datenmengen: Zukunft (day/0) und Vergangenheit (day/-0).
                Code:
                today_minus_1d:
                    instance: home
                    owm_match_prefix@home: day/-0
                    struct: _priv_openweathermap.historical_daily
                Zuletzt geändert von jentz1986; 01.08.2021, 11:32. Grund: Formatierung des YAML gefixt

                Kommentar


                  #83
                  Zitat von jentz1986 Beitrag anzeigen
                  Braucht man alle diese Daten immer? Die Funktionalität vorsehen: Gerne! Alles immer in jedem struct haben?
                  Sicher nicht. Deshalb habe ich das struct auch erstmal so gestaltet, dass man mehr Möglichkeiten hat, SEINE Items zu definieren.

                  Zitat von jentz1986 Beitrag anzeigen
                  day-0 ist tatsächlich heute, nicht gestern. Es gibt zu heute als zwei relevante Datenmengen: Zukunft (day/0) und Vergangenheit (day/-0).
                  Zitat von bmx Beitrag anzeigen
                  Es ist noch mindestens ein Rechtschreibfehler in der struct für darksky: darksky2owm_lcoals
                  Es war beides mal falsch, d.h. der struct name als auch der struct-Aufruf. Ist bei mir korrigiert.

                  Habe ich bei mir korrigiert. Lade bei Gelegenheit eine neuer Version hoch.

                  Kommentar


                    #84
                    Zitat von Sisamiwe Beitrag anzeigen
                    Könntest Du auch noch die air_pollution api ins Plugin integrieren?
                    Ja, ist jetzt gemacht. Allerdings ist die API etwas seltsam. Über forecast bekommt man Werte von 6 Tage in die Vergangenheit bis 4 Tage in die Zukunft. Über history kann man Abfragezeiträume definieren - auch in die Zukunft.

                    Soll uns nicht weiter stören:
                    Code:
                    aqi_gestern_11:
                        type: num
                        owm_matchstring: airpollution/day/-1/hour/11/main/aqi
                    aqi_neulich:
                        type: num
                        owm_matchstring: airpollution/day/-4/hour/11/main/aqi
                    aqi_in_11h:
                        type: num
                        owm_matchstring: airpollution/hour/11/main/aqi
                    aqi_jetzt:
                        type: num
                        owm_matchstring: airpollution/main/aqi
                    airpollution/day/-x (kann 1 - 4 sein, weder 0 noch 5 und auch keine positiven Werte)
                    airpollution/hour/x kann nur in die Zukunft, dafür aber bis zu 3 Tage (eigentlich sogar vier, der vierte ist aber im Zweifel nicht da)

                    Das Web-Interface zeigt jetzt auch alle Datenquellen an und ist "etwas" wartbarer geworden...

                    Zitat von Sisamiwe Beitrag anzeigen
                    Deshalb habe ich das struct auch erstmal so gestaltet, dass man mehr Möglichkeiten hat, SEINE Items zu definieren.
                    Das gefällt mir auch sehr gut! Im Zweifel (Wenig RAM, Wunsch nach wenigen Items) nutzt man die structs um rauszubekommen, was man so alles abfragen kann und pickt sich dann nur noch die relevanten Matchstrings über das Web-Interface raus. Bei genug Ressourcen ist das struct aber sicher sehr gut!

                    Ach ja, one more thing: Das mit dem @count von oben hatte ich implementiert - geht auch:
                    Code:
                    alerts_present:
                        type: num
                        owm_matchstring: alerts/@count
                    hours_present:
                        type: num
                        owm_matchstring: day/-0/hour/@count
                    Noch was:
                    Ein Weg sich die Alerts in der SmartVisu anzeigen zu lassen (wetter.alerts ist das Item vom type list das den Matchstring 'alerts' hat):
                    PHP-Code:
                    {{ status.activelist('''wetter.alerts''event''start''description''') }} 
                    Das kann man ja dann auch mit dem alerts/@count verbinden und nur dann anzeigen lassen, wenn auch alerts da sind. Der @count geht auch auf 0 wenn nur das Placebo eingefügt wird.

                    Kommentar


                      #85
                      jentz1986

                      Prima. Ich arbeite nach meinem Urlaub weiter. Bin dann erst mal für 3 Wochen weg.

                      Kommentar


                        #86
                        Sisamiwe Schönen Urlaub!

                        Kommentar


                          #87
                          Ich habe jetzt den Stand der plugin.yaml aus dem gist in meinen Fork gepackt und die README.md soweit auf Stand gebracht. Ab jetzt warte ich wieder demütig auf Feedback :-)

                          Kommentar


                            #88
                            Hi jentz1986 ,

                            Guten Abend, erstmal danke für deine Arbeit. Trifft sich gut, da ich gerade eine Gartenbewässerung installiert habe

                            So nun aber zum Feedback: Die OWM Daten kommen rein. bzw kamen, da mein Account nun die maximalen Anfragen erreicht hat. Ich habe jetzt das Intervall mal auf 600s gesetzt. Mit dem "alten" OWM Plugin habe ich nie eine Mail bei 300s wegen Limitüberschreitung bekommen.

                            Zum: rain_overview-widget

                            In deiner Anleitung auf Github stimmen die Items nicht:
                            rain_past_12h (hier muss statt h = hrs hin) und die Bezeichnung im Widgetcode von Wetter.as_of (hier muss Weather.as.of hin)

                            So und nun zum wichtigen Teil: Das Irrigation Struct funktioniert bei mir weder mit den Originaldaten aus der Anleitung noch mit meinen eigenen. Er rechnet dort scheinbar immer 0 oder-0 aus.

                            Beim Widget ist mir aufgefallen, dass für mich die Litermenge als auch die Quadratmetermenge zu niedrig einstellbar ist. QM sind max 30 und Liter glaub ich 10
                            Ich hatte angedacht die Lösung für meine Rasenberegnung zu nutzen. Dafür habe ich je 2 Gardena OS 140 an einem Ventil, die laut Gardena bei 4 Bar jeweils bis 800L Wasser durchlassen. Die Flächen sind einmal 192m² und 42m².

                            Kommentar


                              #89
                              Zitat von Jackhammer Beitrag anzeigen
                              Zum: rain_overview-widget

                              In deiner Anleitung auf Github stimmen die Items nicht:
                              rain_past_12h (hier muss statt h = hrs hin) und die Bezeichnung im Widgetcode von Wetter.as_of (hier muss Weather.as.of hin)
                              Danke - habs behoben

                              Zitat von Jackhammer Beitrag anzeigen
                              So und nun zum wichtigen Teil: Das Irrigation Struct funktioniert bei mir weder mit den Originaldaten aus der Anleitung noch mit meinen eigenen. Er rechnet dort scheinbar immer 0 oder-0 aus.
                              In einer Version hatte ich im struct mal die Instanzzuordnung vergessen. Ist gefixt.

                              Zitat von Jackhammer Beitrag anzeigen
                              Ich hatte angedacht die Lösung für meine Rasenberegnung zu nutzen. Dafür habe ich je 2 Gardena OS 140 an einem Ventil, die laut Gardena bei 4 Bar jeweils bis 800L Wasser durchlassen. Die Flächen sind einmal 192m² und 42m².
                              Ich hab nur Tropfbewässerungen, aber klar, das macht so viel mehr Sinn. Da das ne reine Widget-Sache ist und Rasen wahrscheinlich das einzig Große ist, mache ich einfach ein weiteres Widget dazu, kommt demnächst. Solange kann einfach jeder im Plugin-Pfad das Widget entsprechend anpassen :-) Ist ja gerade eh nich so weit her mit Bewässerungsbedarf, das macht der große Automat da oben...

                              Kommentar


                                #90
                                Ich habe nun doch eine neue struct „irrigation_weekly“ für Rasenbewässerung gemacht, ohne den ganzen Pflanzdichte-Kram, dafür aber mit nem wöchentlichen Gießraster. Nun wird vier Tage in die Vergangenheit und drei Tage in die Zukunft geschaut und danach bewässert. Vorher musste ich erstmal lernen, was das ist, dieser „Rasen“. Wir haben nur Wiese und die wächst/verbrennt ganz von alleine…

                                Code:
                                rasenbewaesserung:
                                    struct:
                                        - openweathermap.irrigation_weekly
                                        - uzsu.child
                                    rain:
                                        exposure_factor:
                                            initial_value: 1
                                    evaporation:
                                        exposure_factor:
                                            initial_value: 1
                                    factors:
                                        flowrate_l_per_min:
                                            initial_value: 20
                                        area_in_sqm:
                                            initial_value: 350
                                        gut_feeling:
                                            eval: sum
                                            eval_trigger: garten.geraet.bewaesserung.bauchfaktor
                                Das Widget ist dann:

                                Code:
                                {{ owm.irrigation_weekly('rasen', 'Rasenbewässerung', 'garten.geraet.bewaesserung.rasenbewaesserung ') }}
                                Zuletzt geändert von jentz1986; 24.08.2021, 06:47. Grund: Typos

                                Kommentar

                                Lädt...
                                X