Navigation

    Logo
    • Register
    • Login
    • Search
    • Recent
    • Tags
    • Unread
    • Categories
    • Unreplied
    • Popular
    • GitHub
    • Docu
    • Hilfe
    1. Home
    2. Deutsch
    3. ioBroker Allgemein
    4. Vergleich Solarprognosen Solarwetter und brightsky

    NEWS

    • Monatsrückblick – September 2025

    • Neues Video "KI im Smart Home" - ioBroker plus n8n

    • Neues Video über Aliase, virtuelle Geräte und Kategorien

    Vergleich Solarprognosen Solarwetter und brightsky

    This topic has been deleted. Only users with topic management privileges can see it.
    • K
      klassisch Most Active @Homoran last edited by

      @homoran Temperaturkompensation ist mein kleinstes Problem. Einen Nebel- und Wolkeschieber bräuchte ich. Tage wie letzten November / Dezember
      Zurzeit wieder 30% unter dem mageren Forecast.
      Was soll daraus noch werden?
      6eeca6f8-bf28-4aff-aee3-28127fe9d24e-grafik.png

      Und zur Temperaturkompensation: Merksatz (= auswendig lernen) der Messtechniker: So genau wie nötig, so ungenau wie möglich.

      1 Reply Last reply Reply Quote 1
      • T
        ticaki Developer last edited by

        Seit mal so gut und schreibt in eurem nächsten Position, ob das berechnen im Brightsky Sinn macht oder nur eine weitere Wahrsagung enthält an die man glauben kann - oder nicht. 😄

        Homoran K 2 Replies Last reply Reply Quote 0
        • Homoran
          Homoran Global Moderator Administrators @ticaki last edited by Homoran

          @ticaki den daily Forecast (solar_estimate) halte ich für durchaus brauchbar.
          Bis auf einzelne Ausreißer, die absolut in der Natur von Wettervorhersagen liegen, liegen die Werte (lila) in akzeptablen Bereichen
          Screenshot_20250924-160715_Firefox.jpg
          die grünen Punkte sind von mir per Faktor berechnete Werte, bevor der Estimate angeboten wurde.

          Die stündlichen Werte sind dagegen mir immer noch sehr suspekt.
          Die beobachte ich weiterhin

          EDIT:
          Meine Werte sind die Prozente meines Ertrages zu der Vorhersage!

          1 Reply Last reply Reply Quote 2
          • K
            klassisch Most Active @ticaki last edited by klassisch

            @ticaki sagte in Vergleich Solarprognosen Solarwetter und brightsky:

            Seid mal so gut und schreibt in eurem nächsten Position, ob das berechnen im Brightsky Sinn macht oder nur eine weitere Wahrsagung enthält an die man glauben kann - oder nicht. 😄

            Also ich arbeite damit. Mit den daily und hourly.

            Der Adapter macht auf jeden Fall Sinn. Bringt viele Werte der lokalen DWD-Station, die ich oft gesucht und sonst noch nirgends gefunden habe.
            Inwiefern DWD Dichtung und Wahrheit liefert, ist eine andere Sache. Aber daran arbeitet DWD ja und wurde ja auch schon besser - in den letzten Jahrzehnten. Also nur eine Frage der Zeit und der Rechenleistung.

            Jedenfalls waren die Werte der vergangenen paar Tage deutlich besser als solarwetter. Das ist schon mal ein Fortschritt.

            Ich beobachte weiter. In einem Jahr wissen wir mehr. In der Zwischenzeit passe ich meinen Algo und die Schwellwerte an die Erfahrungen an.

            Edit: Naja, heute lag die 05:00 daily nur 4% zu hoch am Ende des Tages.

            1 Reply Last reply Reply Quote 2
            • Homoran
              Homoran Global Moderator Administrators @klassisch last edited by

              @klassisch sagte in Vergleich Solarprognosen Solarwetter und brightsky:

              Und so sieht es aus, wenn ich reich versuchsweise die gelbe IST-Kurve um 30 Minuten nach rechts schiebe. Das passt zeitlich besser.

              welche Ausrichtung hat deine Anlage?

              Mir ist aufgefallen, dass der Apex der Vorhersagekurve immer um 13:00 liegt
              Screenshot_20250928-092210_Firefox.jpg
              Das ist auch für die DWD Rohdaten für die Insolation passend, weil dann die Sonne im Maximum der Elevation steht.

              Das Maximum meiner Berechnung des maximal möglichen Ertrags liegt bei ca. 12:00
              Screenshot_20250928-092334_Firefox.jpg
              Auch das passt bei einer Ausrichtung der Anlage nach 130°. Hier läge der optimale Auftreffwinkel vom Azimut, der von der Elevation bei 13:00, 12:00 dann der beste Gesamtwirkungsgrad

              Es muss nicht unbedingt am Algorithmus des Adapters für die individuell eingegebenen Daten der PV Anlage liegen.

              Auch bei dem Skript, das @paul53 damals für mich erstellt hatte, musste ich das Haus um ca. 10° drehen.

              K 1 Reply Last reply Reply Quote 1
              • K
                klassisch Most Active @Homoran last edited by

                @homoran sagte in Vergleich Solarprognosen Solarwetter und brightsky:

                welche Ausrichtung hat deine Anlage?

                Süd, 10° nach Ost.

                Mir ist aufgefallen, dass der Apex der Vorhersagekurve immer um 13:00 liegt

                Bei mir liegt der gemessene Maximalpunkt an schönen Tagen (aber ohne Clipping) bei 13:30 MESZ. Und das zeigt so etwa auch die praktische App SuOnTrack für vollen Süden = max Elevation. Schwankt etwas über die Monate. Zur Sommersonnenwende ziemlich genau 13:30, derzeit fast 10 Minuten früher. Bester Azimut wäre fast 30 Minuten früher. Die Elevation änerst sich in diesen 10° kaum (wir sind ja am Maximum mit Steigung der Kurve um 0). Dennoch habe ich gegen 13:30 den besten Ertrag. Aber der Unterschied zu 13:00 ist recht gering. Und an guten Tage ist die Anlage dann ohnehin im Clipping.

                Wenn ich als die Vorhersagekurven um 30 Min verschiebe, passt das etwas besser - aber natürlich nicht immer. Wettervorhersage halt; da erwarte ich keine Wunder.

                Gestern kam 6% mehr als Frickelskript und 22% mehr als Adapter.
                203f6195-af91-48cf-ad97-72e1442c4fd9-grafik.png

                Heute morgen große Voreilung, dann Wolkengezappel

                a7f1ba24-1f5b-4eca-bb65-be63615cf671-grafik.png

                Gestern

                Screenshot_20250928-092210_Firefox.jpg
                Das ist auch für die DWD Rohdaten für die Insolation passend, weil dann die Sonne im Maximum der Elevation steht.

                Da steht die realtiv lang, weil das ein Maximum ist und sich um ein Maximum herum nicht viel tut. Steigung gegen 0.

                Das Maximum meiner Berechnung des maximal möglichen Ertrags liegt bei ca. 12:00
                Screenshot_20250928-092334_Firefox.jpg
                Auch das passt bei einer Ausrichtung der Anlage nach 130°. Hier läge der optimale Auftreffwinkel vom Azimut, der von der Elevation bei 13:00, 12:00 dann der beste Gesamtwirkungsgrad

                Es muss nicht unbedingt am Algorithmus des Adapters für die individuell eingegebenen Daten der PV Anlage liegen.

                Auch bei dem Skript, das @paul53 damals für mich erstellt hatte, musste ich das Haus um ca. 10° drehen.

                Das Drehen des Hauses wäre auch eine Methode. Ich habe jetzt die Kurve etwas verschoben.

                Mein derzeitige Vorgehen:

                • Forcast_Ertrag - Speicherbedarf - Typischer_Tagesbedarf muß größer als ein Schwellwert sein.
                  ** falls kleiner: Eigensicherung geht vor
                  ** fass größer: Netzdienliche Steuerung
                Homoran 1 Reply Last reply Reply Quote 1
                • Homoran
                  Homoran Global Moderator Administrators @klassisch last edited by Homoran

                  @klassisch sagte in Vergleich Solarprognosen Solarwetter und brightsky:

                  Das Drehen des Hauses wäre auch eine Methode.

                  ich hab's versucht!
                  um 15° nach Süden, also 145 statt 130 Grad
                  Screenshot_20250929-165629_Firefox.jpg
                  Der Apex liegt immer noch um 13:00 und laut hourly Forecast soll jetzt noch fast 1/5 der Tagesproduktion kommen!

                  da ist doch was faul.

                  1 Reply Last reply Reply Quote 0
                  • Homoran
                    Homoran Global Moderator Administrators last edited by Homoran

                    Gegenprobe!
                    Für heute habe ich das Haus 15° gegen Norden gedreht, also -30° im Vergleich zu gestern
                    Screenshot_20250930-084626_Firefox.jpg
                    Der Apex ist nach wie vor bei 13:00, allerdings etwas schärfer als gestern (als natürlich nicht der gleiche Sonnenschein zu erwarten war)

                    1 Reply Last reply Reply Quote 0
                    • Homoran
                      Homoran Global Moderator Administrators last edited by

                      Statt Edit, ein neuer Post!

                      ich bin jetzt total verwirrt!
                      Was mache/denke ich falsch?

                      Nach der Wettervorhersage in Android
                      Screenshot_20250930-100918_Weather.jpg
                      (zu spät gescreenshottet! Heute morgen 8:00 Nebel, von 9:00 bis 16:00 durchgehend bedeckt)

                      Da passt die Hourly Vorhersage vom DWD überhaupt nicht. Diese müsste dann eher so
                      20250930_102143.jpg
                      aussehen.

                      Nach dem Blick auf Zahlen
                      Screenshot_20250930-103646_Firefox.jpg
                      läge ich doch gut im Rennen, möglicherweise am Ende des Tages sogar über Estimate.

                      ABER wieso??

                      Nach dem Chart
                      Screenshot_20250930-103751_Firefox.jpg
                      Ist doch bisher etwa nur 50% des estimates eingetroffen!!

                      Wo ist mein Denkfehler?

                      K 1 Reply Last reply Reply Quote 0
                      • K
                        klassisch Most Active @Homoran last edited by

                        @homoran Sorry, hatte die letzten Tage viel zu tun.

                        • Haus Drehen: Ich hatte mich dagegen entschieden, weil

                          • Um die Mittagszeit hat die Kurve P(t) ein Maximum. Die Steigung ist also recht klein. Die Leistung reagiert nicht so empfindlich auf die Zeit
                          • deshalb eignet sich dieser Punkt - so wichtig er auch für die Produktion ist, nicht so gut zum Kalibrieren einer Zeitverschiebung
                          • die Kurvenflanken der Sonnenauf- und untergänge reagieren empfindlicher auf Zeitverschiebungen
                          • Haus drehen kann noch andere Nebenwirkungen auf andere Funktionen oder Skripte haben
                          • Verschiebung der Zeitachse gleicht den Schönheitsfehler - woher er auch immer kommt - kosmetisch etwas aus. Für mich ist allerdings der ermittelte Gesamtertrag entscheidend
                        • Nebel

                          • Ich habe die DWD App. Und bereits innerhalb dieser App gibt es Inkonsistenzen zwischen den verschiedenen Ansichten, z.B. Wolkensymbolen auf dem Zeitgraphen und der Kartenansicht mit Bewölkung
                          • Nebel, bsonders der Morgennebel wird zumindest in meiner Gegend nicht so genau vorausgesagt. Ortsrandlage mit Wiesen, Übergang zwischen Tal und Bergland oder warum auch immer
                        1 Reply Last reply Reply Quote 0
                        • Homoran
                          Homoran Global Moderator Administrators last edited by

                          @ticaki
                          @klassisch

                          ich hatte in den letzten Tagen ein paar Minuten Zeit mich mit der Vorhersage zu beschäftigen und habe ein wenig gespielt.

                          Statt Erleuchtung zu bekommen bin ich noch verwirrter!
                          Eine Berechnung der stündlichen Leistung nach dem hourly Forecast sieht so aus
                          -> lila Kurve
                          Screenshot_20251002-200502_Firefox.jpg
                          weitere Forecasts
                          weiss: jahreszeitlich maximal erreichbare Leistung bei optimalen Bedingungen
                          grau: hourly estimate 05:00 des brightSky Adapters
                          gelb: tatsächliche Leistung

                          Die lila Kurve habe ich gemäß der Formel azs dem PV-Forum
                          Screenshot_20251002-195440_Firefox.jpg

                          wie folgt umgesetzt
                          Screenshot_20251002-195806_Firefox.jpg
                          Der Basiswert ist hourly.00.solar (solar radiation)
                          nach meinem Verständnis ist das die aktuelle Leistung der Sonne in kW/m²

                          javascript.1
                          	2025-10-02 09:00:05.360	info	script.js.Solaranlage.pEst_Fassade: 0.05
                          javascript.1
                          	2025-10-02 10:00:08.049	info	script.js.Solaranlage.pEst_Fassade: 0.181
                          javascript.1
                          	2025-10-02 11:00:08.478	info	script.js.Solaranlage.pEst_Fassade: 0.328
                          javascript.1
                          	2025-10-02 12:00:07.152	info	script.js.Solaranlage.pEst_Fassade: 0.467
                          javascript.1
                          	2025-10-02 13:00:08.577	info	script.js.Solaranlage.pEst_Fassade: 0.539
                          javascript.1
                          	2025-10-02 14:00:05.045	info	script.js.Solaranlage.pEst_Fassade: 0.558
                          javascript.1
                          	2025-10-02 15:00:06.537	info	script.js.Solaranlage.pEst_Fassade: 0.531
                          javascript.1
                          	2025-10-02 16:00:07.515	info	script.js.Solaranlage.pEst_Fassade: 0.45
                          javascript.1
                          	2025-10-02 17:00:07.640	info	script.js.Solaranlage.pEst_Fassade: 0.325
                          javascript.1
                          	2025-10-02 18:00:06.282	info	script.js.Solaranlage.pEst_Fassade: 0.183
                          javascript.1
                          	2025-10-02 19:00:04.417	info	script.js.Solaranlage.pEst_Fassade: 0.056
                          

                          (im Vergleich dazu wird die Leistung eines Panels In Wp bei 1000W/m² senkrechter Bestrahlung angegeben.

                          Was mir gefällt ist, dass jetzt der Apex bei ca.12:00 Uhr liegt, obwohl die höchste Sonneneinstrahlung um 14:00 zu erwarten ist. Die Winkelabweichungen bezogen auf die Panels werden also berücksichtigt.

                          Was mir nicht gefällt ist die geringe Gesamtfläche der Vorhersage im Vergleich zum Ist und zum Estimate des Adapters.
                          (wo) Habe ich da einen Denk-/Rechenfehler?

                          K 2 Replies Last reply Reply Quote 1
                          • K
                            klassisch Most Active @Homoran last edited by klassisch

                            @homoran So sah das heute bei mir aus:
                            f30b58d0-87d9-455f-8698-da35aacb2174-grafik.png

                            Gelb ist die PV-DC Leistung die Fronius Gen24 meldet. Ich hatte heute genügend interne Abnahme gegen Mittag (auch Laden der Batterie), so daß kaum Clipping zu sehen ist.
                            Dunkelblau ist die Kurve, die ich aus den hourly "solar" ('brightsky.0.hourly.xy.solar' ; xy von 00 bis 24) (Global horizontal irradiance (GHI)) mit meinen Dach-PV-Daten berechne. Das müssten jetzt die 08:00 Werte sein, da ich die Kurve immer überschreibe. Dabei rechne ich auch die Fläche unter der Stufenkurve (Stundensteps, nicht die hier gezeigte interpolierte Kurve) um 05:00 und um 08:00 neu. Diese Werte nehme ich als Forecast für den Tagesertrag

                            Die hellblaue Kurve kommt aus den hourly "solar_estimate" (brightsky.0.hourly.xy.solar_estimate ; xy von 00 bis 24). Allerdings bin ich dort bequem und rechne den Flächeninhalt nicht selbst.
                            Stattdessen nutze ich den 'brightsky.0.daily.00.solar_estimate' von DWD, welchen der Adapter liefert.

                            Die Kurven werden in der Graphik um 30 Minuten verschoben, damit es visuell besser passt. Reine Empirie (Vermutung Lage der Abtastwerte), keine Physik, kein Einfluß auf die Flächenwerte.

                            Heute lag mein 05:00 Wert um 5,6% und der 08:00 Wert um 5,3% zu hoch.
                            Der Adapter 'brightsky.0.daily.00.solar_estimate' von 05:00 lag um 5,1% zu niedrig.
                            Spasseshalber rechne ich auch noch den Mittelwert von Adapter und eigener Berechnung und der lag heute bei den 05:00 bei 0,5% Abweichung. Also "exakt" im Umfeld einer Wettervorhersage.

                            Ich kann aber auch ganz andere Bilder mit 60% Abweichung und mehr zeigen. Besonders, wenn sich der Nebel hier festfrisst und nicht weggeblasen wird. Diese Abweichungen können lokal sein und mit der Entfernung zur DWD Station oder der lokalen Nebellage oder der DWD Performance zusammen hängen.

                            Fazit:

                            • An schönen Tagen passt das recht gut.
                              • Meine eigene grobe Berechnung (nur aus GHI hourly Werten, also direkte Strahlung) ist meist etwas höher,
                              • der Adapter 05:00 daily solar_estimate Wert meist geringer
                            • Es gibt aber auch zum Teil drastische Ausreißer weil die DWD Vorhersagen nicht passen. Da liegt dann die Realität deutlich unter den Vorhersagen und damit auch deutlich unter den beiden Kurvenflächen.

                            Ich bin es soweit zufrieden. Besser als alles was ich vorher hatte.
                            Ich beobachte das weiter über den Jahresverlauf.

                            Für den Use Case "netzdienliches Verhalten" halte ich das pragmatisch. Priorität hat die Vermeidung von Netzbezug. Wenn die Prognesen nicht genügend Abstand von (ca 1 Tagesbedarf + (Akkukapazität - AkkuSOC)) hat, kümmere ich mich nicht um Netzdienlichkeit.
                            Es gibt also jede Menge Näherungen und Annahmen in der Kette. Aber die größte Fehlerquelle sind wohl noch immer die DWD Vohersagewerte. qee.

                            1 Reply Last reply Reply Quote 1
                            • K
                              klassisch Most Active @Homoran last edited by klassisch

                              @homoran sagte in Vergleich Solarprognosen Solarwetter und brightsky:

                              Der Basiswert ist hourly.00.solar (solar radiation)
                              nach meinem Verständnis ist das die aktuelle Leistung der Sonne in kW/m²

                              Ja, der Global horizontal irradiance (GHI) Wert. Gemessen auf einer horizontal liegenden Ebene. Dadurch wir man den Azimut los. Was bleibt ist die Elevation der Sonne.

                              (im Vergleich dazu wird die Leistung eines Panels In Wp bei 1000W/m² senkrechter Bestrahlung angegeben.

                              Ja, genau. Also muß man sowohl die Sonnenelevation als auch den Azimut relativ zur Dachlage berücksichtigen.

                              Was mir nicht gefällt ist die geringe Gesamtfläche der Vorhersage im Vergleich zum Ist und zum Estimate des Adapters.
                              (wo) Habe ich da einen Denk-/Rechenfehler?

                              Wahrscheinlich gibt es da irgendwo einen Rechenfehler, denn meine grob genäherte Rechnung bringt keine so großen Abweichungen.
                              Edit: s.u. Bogenmass vs. Grad bei den Winkelfunktionen?

                              1 Reply Last reply Reply Quote 0
                              • K
                                klassisch Most Active last edited by klassisch

                                @Homoran

                                Edit: Bitte auch https://forum.iobroker.net/post/1297842 anschauen

                                So sehen meine Definitionswerte aus. Geodaten (Breite, Länge) werden aus dem Adapter gezogen und sind die der DWD Station

                                const AREA_M2             =  36* 1.755 * 1.038;    // Fläche A in m²
                                console.log('Modulfläche: '+ AREA_M2);
                                const EFFICIENCY          =  0.20;  // Wirkungsgrad (z. B. 20% -> 0.20)
                                const ALPHA_DEG           = -10; //(255-180)+90; // -10;     // Azimut der Fläche (0 = Süd, negativ Ost, positiv West)
                                const BETA_DEG            = 25;    // Neigung in Grad gegen Horizontal
                                const inverterPowerLimit  = 10; // 10kW is the max potential of the Gen24
                                
                                

                                Dann habe ich einige Tests gemacht

                                * For testing purposes there is a local python script on the ioBroker host d:\Auswertungen\Solar-ghi-poa-transformation.py 
                                *  using the python pvlib which also calculates albedo and diffuse light etc. That means, it produces higher values in the lower range (expectation)
                                *
                                *
                                * recommenden test conditions
                                * 1 Test for horizontal panels
                                *    const AREA_M2             =  1 // Sensor Fläche A in m²
                                *    const EFFICIENCY          =  1 // Sensor efficiency
                                *    const ALPHA_DEG           =  0; // value just to be in allowed range)
                                *    const BETA_DEG            =  0 ; // horizontal plane
                                *    Expected results: poa = ghi = energy_kWh   
                                *
                                * 2 Panel upright position in line with the azimuth direction: Expectation: zero output
                                *
                                *    first select an hour, e.g. 13:00 and calculate (using a 3rd party program) 
                                      the azimuth of this date and time at the location 
                                      of the sourced weather station. lets call it solar_azimuth_here_and_now 
                                *
                                *    const AREA_M2             =  1 // Sensor Fläche A in m²
                                *    const EFFICIENCY          =  1 // Sensor efficiency
                                *    const ALPHA_DEG           =  90 + solar_azimuth_here_and_now calculated by a third party app
                                *    const BETA_DEG            =  90 ; // panel upright
                                *    
                                *    Expected result: poa = 0 = energy_kWh
                                *
                                *
                                *
                                *
                                ***/
                                
                                
                                

                                Ich habe also

                                • Test 1: Module haben 1 m² und liegen flach. Also müssen die gleichen Werte rauskommen wie beim GHI
                                • Test 2: Das Modul mit 1m² wird senkrecht aufgestellt und streifend in die Sonne gedreht. Idealerweise sollte also gar kein Licht auf die Module fallen und die Erträge gehen gen 0.
                                • Test mit anderen Orientierungen: Vergleich mit einem Python Programm, welches eine hoffentlich anerkannte Bibliothek verwendet, die allerdings Albedo und andere Finessen kann. Also werden die Werte nicht ganz identisch sein
                                1 Reply Last reply Reply Quote 0
                                • K
                                  klassisch Most Active last edited by klassisch

                                  @Homoran
                                  Mit Blockly bin ich nicht vertraut.
                                  Aber im Blockly hantierst Du mit Winkelfunktionen. Klar, sowas muß sein.
                                  Bei Javascript wird (wie auch in xls) im Bogenmaß und nicht in Grad gerechnet.
                                  Ich habe also jeweils Funktionen zur Umwandlung

                                  function deg2rad(d){ return d * Math.PI / 180; }
                                  function rad2deg(r){ return r * 180 / Math.PI; }
                                  

                                  Ich weiß jetzt nicht, wie das in Blockly gehandhabt wird.

                                  Edit: ChatGPT behauptet, ioBroker Blocky arbeite wie auch JavaScript im Bogenmass. Dein Blockly macht mich glauben, Du verwendest Grad. Wäre das ein erster Schritt?

                                  Homoran T 2 Replies Last reply Reply Quote 0
                                  • Homoran
                                    Homoran Global Moderator Administrators @klassisch last edited by

                                    @klassisch sagte in Vergleich Solarprognosen Solarwetter und brightsky:

                                    Wäre das ein erster Schritt?

                                    muss ich mir ansehen!
                                    Danke

                                    1 Reply Last reply Reply Quote 0
                                    • T
                                      ticaki Developer @klassisch last edited by ticaki

                                      @klassisch

                                      Blockly ist ein Hybrid aus Javascript und Lego.

                                      Homoran 1 Reply Last reply Reply Quote 1
                                      • Homoran
                                        Homoran Global Moderator Administrators @ticaki last edited by

                                        @ticaki sagte in Vergleich Solarprognosen Solarwetter und brightsky:

                                        @klassisch

                                        Blockly ist ein Hybrid aus Javascript und Lego.

                                        genau deswegen hilft es mir.

                                        Ich komme mit der js-Syntax selber einfach nicht klar.
                                        Deswegen nutzt mir dein Skript auch leider nichts, Sorry!
                                        Auch wenn lesen deutlich einfacher als schreiben ist 😞

                                        ich bin aber der Meinung, dass genau dieses Snippet mit den Winkelfunktionen an anderer Stelle für die maximal erreichbare Leistung funktioniert.

                                        K T 2 Replies Last reply Reply Quote 0
                                        • K
                                          klassisch Most Active @Homoran last edited by

                                          @homoran Kannst ja mal ein Probeblockly zu Winkelfunktionen machen, dann siehst Du, ob es lieber Grad oder rad verspeist. Ich tippe auf rad
                                          Oder @paul53 weiß das natürlich.

                                          Was ich als Excerpat meines Skripts gepostet habe, war nur der Erklärungsteil, die Daten des Daches und mit welchen einfachen Tests mal einiges sehen kann.
                                          Natürlich habe ich noch mehr Test gemacht, aber dazu braucht es halt eine Referenz, für die ich das Python Skript genutzt habe.

                                          1 Reply Last reply Reply Quote 1
                                          • T
                                            ticaki Developer @Homoran last edited by

                                            @homoran sagte in Vergleich Solarprognosen Solarwetter und brightsky:

                                            @ticaki sagte in Vergleich Solarprognosen Solarwetter und brightsky:

                                            @klassisch

                                            Blockly ist ein Hybrid aus Javascript und Lego.

                                            genau deswegen hilft es mir.

                                            Ich komme mit der js-Syntax selber einfach nicht klar.
                                            Deswegen nutzt mir dein Skript auch leider nichts, Sorry!

                                            Jeder wie er mag - ich tue mir schwer mit blockly deshalb gibts da wenig von mir 🙂

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post

                                            Support us

                                            ioBroker
                                            Community Adapters
                                            Donate
                                            FAQ Cloud / IOT
                                            HowTo: Node.js-Update
                                            HowTo: Backup/Restore
                                            Downloads
                                            BLOG

                                            514
                                            Online

                                            32.2k
                                            Users

                                            80.9k
                                            Topics

                                            1.3m
                                            Posts

                                            7
                                            234
                                            7108
                                            Loading More Posts
                                            • Oldest to Newest
                                            • Newest to Oldest
                                            • Most Votes
                                            Reply
                                            • Reply as topic
                                            Log in to reply
                                            Community
                                            Impressum | Datenschutz-Bestimmungen | Nutzungsbedingungen
                                            The ioBroker Community 2014-2023
                                            logo