NEWS
Betatest Bright Sky v0.6.x
-
Naja, die gefühlte Temperatur und der Windchill sind ja eigentlich stark subjektiv.
Ob das wirklich rein mathematisch abgebildet werden kann ist für ich nicht ganz klar.Hab mal kurz die Kommentare im Skript gelesen
@armilar sagte in Betatest Bright Sky v0.3.x:
Die gefühlte Temperatur oder Windchill bezieht neben der Lufttemperatur auch die Windgeschwindigkeit mit ein.
@armilar sagte in Betatest Bright Sky v0.3.x:
Der Hitzeindex ist die gefühlte Temperatur in Abhängigkeit von der Lufttemperatur und der relativen Luftfeuchtigkeit.
Das Wärmeempfinden, ins beso dere bei hohen Temperaturen ist natürlich von der relativen Luftfeuchtigkeit abhängig, da der Körper mit zunehmender Umgebungsfeuchte den Schweiss, den er zu Kühlung produziert nicht mehr ausreichend verdunsten kann.
(deswegen reicht im Sommer oft ein Entfeuchter, kühler muss es gar nicht sein)Aber auch beim Windchill spielt IMHO die relative Luftfeuchtigkeit eine Rolle.
Ist die zu hoch, bleibt ja der Schweiß (auch wenn noch unsichtbar) auf der Haut, und dann reicht schon ein geringerer Luftzug um es als unangenehm kalt zu empfinden.Die aktuell zur Diskussion stehende Berechnung sieht so aus - ist aber noch nirgendwo drin - chatGPT baut auch genug mist :)
Die von Armilar ist lange getestet.
/** * Convert kWh/m² per day to average W/m² (instantaneous mean over 24h). * If your kWh/m² is for a different period, adjust `hours`. * * @param kwhPerM2 kWh per m² (e.g. daily total) * @param hours number of hours for the period (default 24) * @returns average W/m² */ function kwhm2_per_day_to_Wm2(kwhPerM2, hours = 24) { return (kwhPerM2 * 1000) / hours; } /** * Calculate saturation vapor pressure (Magnus formula) and vapor pressure e (hPa). * * @param T temperature in °C * @param RH relative humidity in % (0-100) * @returns vapor pressure e in hPa */ function vaporPressure_hPa(T, RH) { const es = 6.105 * Math.exp((17.27 * T) / (237.7 + T)); return (RH / 100) * es; } /** * Apparent Temperature (Steadman). * Inputs: temperature °C, RH %, wind in km/h. * * @param T temperature in °C * @param RH relative humidity in % * @param wind_kmh wind speed in km/h (10-min avg ok) * @returns apparent temperature in °C */ function apparentTemperature(T, RH, wind_kmh) { const v_ms = wind_kmh / 3.6; const e = vaporPressure_hPa(T, RH); // hPa return T + 0.33 * e - 0.70 * v_ms - 4.0; } /** * Wind Chill Temperature (WS/meteorological standard). * Validity: T <= 10°C and wind > ~4.8 km/h. * * @param T temperature in °C * @param wind_kmh wind speed in km/h * @returns wind chill in °C or NaN if outside typical validity */ function windChill(T, wind_kmh) { if (T > 10 || wind_kmh < 4.8) return NaN; const v16 = Math.pow(wind_kmh, 0.16); return 13.12 + 0.6215 * T - 11.37 * v16 + 0.3965 * T * v16; } /** * Heat Index (NOAA / Rothfusz), expects T in °C and RH in %. * Typical validity: T >= 27°C and RH reasonably high. * * @param T temperature in °C * @param RH relative humidity in % * @returns heat index in °C */ function heatIndex(T, RH) { const T_f = (T * 9) / 5 + 32; const R = RH; let HI_f = -42.379 + 2.04901523 * T_f + 10.14333127 * R - 0.22475541 * T_f * R - 6.83783e-3 * T_f * T_f - 5.481717e-2 * R * R + 1.22874e-3 * T_f * T_f * R + 8.5282e-4 * T_f * R * R - 1.99e-6 * T_f * T_f * R * R; if (R < 13 && T_f >= 80 && T_f <= 112) { HI_f -= ((13 - R) / 4) * Math.sqrt((17 - Math.abs(T_f - 95)) / 17); } else if (R > 85 && T_f >= 80 && T_f <= 87) { HI_f += ((R - 85) / 10) * ((87 - T_f) / 5); } return ((HI_f - 32) * 5) / 9; } /** * Pragmatic "feels-like" chooser: * - if T <= 10°C -> use Wind Chill (if valid) * - else if T >= 27°C -> use Heat Index * - else -> use Apparent Temperature (Steadman) * * Solar input (kWh/m² per day) is converted to average W/m² and returned, * but NOT applied automatically to the index (proper inclusion needs MRT/UTCI). * * @param T temperature in °C * @param RH relative humidity in % * @param wind_kmh wind speed in km/h (10-min) * @param solar_kwh_m2_per_day optional solar in kWh/m² (daily). pass null if none. * @returns object { indexName, value_C, solar_Wm2 (or null) } */ function feelsLike(T, RH, wind_kmh, solar_kwh_m2_per_day = null) { const solar_Wm2 = solar_kwh_m2_per_day !== null ? kwhm2_per_day_to_Wm2(solar_kwh_m2_per_day, 24) : null; if (T <= 10) { const wc = windChill(T, wind_kmh); if (!Number.isNaN(wc)) return { indexName: 'WindChill', value_C: wc, solar_Wm2: solar_Wm2 }; // fallback to apparent temperature if wind chill out of range } if (T >= 27) { return { indexName: 'HeatIndex', value_C: heatIndex(T, RH), solar_Wm2: solar_Wm2 }; } return { indexName: 'ApparentTemperature', value_C: apparentTemperature(T, RH, wind_kmh), solar_Wm2: solar_Wm2 }; }EDIT: Das mit windchill und schweiß stimmt natürlich - fraglich ist halt ob das bei < 10°C ne rolle spielt, weil da kann ich dir schon jetzt sagen - im boxershirt wird dir kalt sein :)
Da wird auch die reduktion der isolierung der kleidung durch feuchtigkeit - ok das wird dann echt komplex - da brauchste paar sensoren an dir die das dann korrekt berechnen.EDIT2: die <10°C nimmt auch chatGPT als hürde für die berechnung von windchill
-
Die aktuell zur Diskussion stehende Berechnung sieht so aus - ist aber noch nirgendwo drin - chatGPT baut auch genug mist :)
Die von Armilar ist lange getestet.
/** * Convert kWh/m² per day to average W/m² (instantaneous mean over 24h). * If your kWh/m² is for a different period, adjust `hours`. * * @param kwhPerM2 kWh per m² (e.g. daily total) * @param hours number of hours for the period (default 24) * @returns average W/m² */ function kwhm2_per_day_to_Wm2(kwhPerM2, hours = 24) { return (kwhPerM2 * 1000) / hours; } /** * Calculate saturation vapor pressure (Magnus formula) and vapor pressure e (hPa). * * @param T temperature in °C * @param RH relative humidity in % (0-100) * @returns vapor pressure e in hPa */ function vaporPressure_hPa(T, RH) { const es = 6.105 * Math.exp((17.27 * T) / (237.7 + T)); return (RH / 100) * es; } /** * Apparent Temperature (Steadman). * Inputs: temperature °C, RH %, wind in km/h. * * @param T temperature in °C * @param RH relative humidity in % * @param wind_kmh wind speed in km/h (10-min avg ok) * @returns apparent temperature in °C */ function apparentTemperature(T, RH, wind_kmh) { const v_ms = wind_kmh / 3.6; const e = vaporPressure_hPa(T, RH); // hPa return T + 0.33 * e - 0.70 * v_ms - 4.0; } /** * Wind Chill Temperature (WS/meteorological standard). * Validity: T <= 10°C and wind > ~4.8 km/h. * * @param T temperature in °C * @param wind_kmh wind speed in km/h * @returns wind chill in °C or NaN if outside typical validity */ function windChill(T, wind_kmh) { if (T > 10 || wind_kmh < 4.8) return NaN; const v16 = Math.pow(wind_kmh, 0.16); return 13.12 + 0.6215 * T - 11.37 * v16 + 0.3965 * T * v16; } /** * Heat Index (NOAA / Rothfusz), expects T in °C and RH in %. * Typical validity: T >= 27°C and RH reasonably high. * * @param T temperature in °C * @param RH relative humidity in % * @returns heat index in °C */ function heatIndex(T, RH) { const T_f = (T * 9) / 5 + 32; const R = RH; let HI_f = -42.379 + 2.04901523 * T_f + 10.14333127 * R - 0.22475541 * T_f * R - 6.83783e-3 * T_f * T_f - 5.481717e-2 * R * R + 1.22874e-3 * T_f * T_f * R + 8.5282e-4 * T_f * R * R - 1.99e-6 * T_f * T_f * R * R; if (R < 13 && T_f >= 80 && T_f <= 112) { HI_f -= ((13 - R) / 4) * Math.sqrt((17 - Math.abs(T_f - 95)) / 17); } else if (R > 85 && T_f >= 80 && T_f <= 87) { HI_f += ((R - 85) / 10) * ((87 - T_f) / 5); } return ((HI_f - 32) * 5) / 9; } /** * Pragmatic "feels-like" chooser: * - if T <= 10°C -> use Wind Chill (if valid) * - else if T >= 27°C -> use Heat Index * - else -> use Apparent Temperature (Steadman) * * Solar input (kWh/m² per day) is converted to average W/m² and returned, * but NOT applied automatically to the index (proper inclusion needs MRT/UTCI). * * @param T temperature in °C * @param RH relative humidity in % * @param wind_kmh wind speed in km/h (10-min) * @param solar_kwh_m2_per_day optional solar in kWh/m² (daily). pass null if none. * @returns object { indexName, value_C, solar_Wm2 (or null) } */ function feelsLike(T, RH, wind_kmh, solar_kwh_m2_per_day = null) { const solar_Wm2 = solar_kwh_m2_per_day !== null ? kwhm2_per_day_to_Wm2(solar_kwh_m2_per_day, 24) : null; if (T <= 10) { const wc = windChill(T, wind_kmh); if (!Number.isNaN(wc)) return { indexName: 'WindChill', value_C: wc, solar_Wm2: solar_Wm2 }; // fallback to apparent temperature if wind chill out of range } if (T >= 27) { return { indexName: 'HeatIndex', value_C: heatIndex(T, RH), solar_Wm2: solar_Wm2 }; } return { indexName: 'ApparentTemperature', value_C: apparentTemperature(T, RH, wind_kmh), solar_Wm2: solar_Wm2 }; }EDIT: Das mit windchill und schweiß stimmt natürlich - fraglich ist halt ob das bei < 10°C ne rolle spielt, weil da kann ich dir schon jetzt sagen - im boxershirt wird dir kalt sein :)
Da wird auch die reduktion der isolierung der kleidung durch feuchtigkeit - ok das wird dann echt komplex - da brauchste paar sensoren an dir die das dann korrekt berechnen.EDIT2: die <10°C nimmt auch chatGPT als hürde für die berechnung von windchill
Hallo,
ich habe heute den Bright Sky Adapter installiert. Als ich mir die Wetterinformationen für die Vis einrichten wollte, bin ich auf ein paar Probleme gestoßen, die ich auch hier durch diese Seite nicht lösen konnte.
Das erste Problem war das Einbinden der Icons. Dieser Datenpunkt auf dem Bild fehlt bei mir in den bright sky Ordner.
Das nächste Problem ist das die Datenpunkte "dayName_long " und "dayName_short" bei mir auch im Ordner Bright Sky fehlen.
Also Zusammengefasst, mir fehlen die Datenpunkte dayName_long , dayName_short und iconUrl.Warum werden die Datenpunkte nicht angezeigt ich habe den bright sky 0.3.5 . ich bin für jede Hilfe dankbar
FG
Maro -
Hallo,
ich habe heute den Bright Sky Adapter installiert. Als ich mir die Wetterinformationen für die Vis einrichten wollte, bin ich auf ein paar Probleme gestoßen, die ich auch hier durch diese Seite nicht lösen konnte.
Das erste Problem war das Einbinden der Icons. Dieser Datenpunkt auf dem Bild fehlt bei mir in den bright sky Ordner.
Das nächste Problem ist das die Datenpunkte "dayName_long " und "dayName_short" bei mir auch im Ordner Bright Sky fehlen.
Also Zusammengefasst, mir fehlen die Datenpunkte dayName_long , dayName_short und iconUrl.Warum werden die Datenpunkte nicht angezeigt ich habe den bright sky 0.3.5 . ich bin für jede Hilfe dankbar
FG
MaroIst ja auch ein wenig alt:
0.6.6 ist aktuell die Version
Geh mal über Adapter und ziehe dir die:
https://github.com/ticaki/ioBroker.brightsky
EDIT:
0.3.5 ist stable... Da ist das nicht drin... Also "latest" (Beta) wie oben beschrieben installieren...
-
Hi danke cool . Aber mit welchem Widget und wie funktioniert das . Html- und Image- Widget haben nicht funktioniert.
diese Inventwo auch nicht. Auch ein Wetter Widget aus der Time and weather Serie hat nicht funktoiniert .
Vielen dank nochmal für die Hilfe
FGMaro
-
Hi danke cool . Aber mit welchem Widget und wie funktioniert das . Html- und Image- Widget haben nicht funktioniert.
diese Inventwo auch nicht. Auch ein Wetter Widget aus der Time and weather Serie hat nicht funktoiniert .
Vielen dank nochmal für die Hilfe
FGMaro
-
Hallo,
erstmal danke für den Adapter!
Eine Frage: Manche Datenpunkte, wie z.B. "icon" oder "timestamp", sind auf englisch. Bleibt es so? Muss man dann es selbst durch Scripts erledigen?@andre1de
icon ist ein token, das so von der Api kommt. condition könnte ich in einem weiteren Feld übersetzen - bei icon macht das jetzt nicht wirklich sinn.timestamp ist nicht übersetzbar - das ist ein ISO-Date-String
2025-10-21T10:30:00+00:00das wird vom Admin so dargestellt wie du es siehst, wenn das im Datenfeld anderes aussehen soll ist das ein Adminproblem. Der Datenpunkt inhalt lässt sich per Blockly oder Javascript so formatierten wie man es will. z.B.new Date('2025-10-21T10:30:00+00:00').toLocaleDateString('de', { weekday: 'long', day: '2-digit', month: 'long', year: 'numeric' }); -
@andre1de
icon ist ein token, das so von der Api kommt. condition könnte ich in einem weiteren Feld übersetzen - bei icon macht das jetzt nicht wirklich sinn.timestamp ist nicht übersetzbar - das ist ein ISO-Date-String
2025-10-21T10:30:00+00:00das wird vom Admin so dargestellt wie du es siehst, wenn das im Datenfeld anderes aussehen soll ist das ein Adminproblem. Der Datenpunkt inhalt lässt sich per Blockly oder Javascript so formatierten wie man es will. z.B.new Date('2025-10-21T10:30:00+00:00').toLocaleDateString('de', { weekday: 'long', day: '2-digit', month: 'long', year: 'numeric' }); -
@ticaki
Danke für die Antwort!
Ich wollte noch wie z.B. bei anderen Wetter-Adapter den aktuelle Wetterzustand in Textform haben. Z.B "Sonnig" oder "Bewölkt" usw.
Aber das kann ich auch mit Blockly realisieren.in condition gehen folgende Werte:
dry fog rain sleet snow hail thunderstorm nullin icon:
clear-day clear-night partly-cloudy-day partly-cloudy-night cloudy fog wind rain sleet snow hail thunderstorm nullist halt kein Problem da was in einem weiteren State zu übersetzen aber nicht in die Orginalfelder.
icon z.B. in localLanguageCondition oder so :)Aber nicht diesen Monat - eröffne ein Issue dann lass ich das nächsten Monat Copilot einbauen. Der übersetzt das dann auch ordentlich in die verschiedenen Sprachen.
-
in condition gehen folgende Werte:
dry fog rain sleet snow hail thunderstorm nullin icon:
clear-day clear-night partly-cloudy-day partly-cloudy-night cloudy fog wind rain sleet snow hail thunderstorm nullist halt kein Problem da was in einem weiteren State zu übersetzen aber nicht in die Orginalfelder.
icon z.B. in localLanguageCondition oder so :)Aber nicht diesen Monat - eröffne ein Issue dann lass ich das nächsten Monat Copilot einbauen. Der übersetzt das dann auch ordentlich in die verschiedenen Sprachen.
-
@ticaki
Danke für die Antwort!
Ich wollte noch wie z.B. bei anderen Wetter-Adapter den aktuelle Wetterzustand in Textform haben. Z.B "Sonnig" oder "Bewölkt" usw.
Aber das kann ich auch mit Blockly realisieren. -
hier siehst du auch den Wetterstatus, ist ganz einfach
Das ist meine Wettervorschau für die Startseite
das Datum habe ich aus dem Timestamp Datenpunkt und mit javascript und blockly so verändertFG
Maro@matze-r
Danke!
Wochentag wäre kein Problem. Das habe ich nur als Beispiel dazu geschrieben (dass auch auf englisch ist). Hauptsätzlich interessierte mich Wetterzustand in Textform. Bei dir hast du deine "Klarer Tag" durch Blockly hingekriegt oder?
Aber damit kann ich erst abwarten oder Blockly schreiben. Es wäre kein Problem. -
Ich habe gestern an meiner Konfig herumgespielt um "bessere" Werte zu erhalten und eine fixe Wetterstation eingegeben.
jetzt abe ich dauend
brightsky.0 2025-10-25 17:07:48.968 error Error fetching weather data: {} brightsky.0 2025-10-25 17:07:48.968 error Error fetching weather data: {}im log.
leider ohne mehr InfosLoglevel auf debug zeigt massig input.
ich habe jetzt die Station wieder herausgenommen, aber die error message bleibt.
habe noch v0.5.2
-
Ich habe gestern an meiner Konfig herumgespielt um "bessere" Werte zu erhalten und eine fixe Wetterstation eingegeben.
jetzt abe ich dauend
brightsky.0 2025-10-25 17:07:48.968 error Error fetching weather data: {} brightsky.0 2025-10-25 17:07:48.968 error Error fetching weather data: {}im log.
leider ohne mehr InfosLoglevel auf debug zeigt massig input.
ich habe jetzt die Station wieder herausgenommen, aber die error message bleibt.
habe noch v0.5.2
@homoran
Ist das gleiche falsche Errorhandling was ich auch in pirate-weather hatte. Muß ich hier auch anpassen - mache ich später. Dann gibts zumindest mal ne brauchbare ErrormessageEDIT:
Da sind noch 2 Issue offen die bearbeite ich auch noch (morgen) bevor es eine neue Version gibt. -
0.6.7 (2025-10-26)
- (ticaki) Corrected some roles for Lovelance
- (ticaki) Added conditionUI
- (ticaki) Air pressure and humidity are now integers
- (ticaki) Added air pressure to daily data
- (ticaki) Improved error logging
-
Ich hänge mich da mal nahtlos an die geballte Ladung an Infos von @ticaki ;-)
Was ist die Bright Sky API:
Die Bright Sky API ist eine kostenlose, öffentliche API, die Wetterdaten des Deutschen Wetterdienstes (DWD) bereitstellt. Sie wurde entwickelt, um den Zugriff auf diese Daten zu vereinfachen, da die Originaldaten des DWD oft in schwer zu interpretierenden Formaten vorliegen. Bright Sky wandelt diese Daten in ein einfach nutzbares JSON-Format um und macht sie über eine API zugänglich.
Hier ist eine detailliertere Erklärung:Ziel:
Die Bright Sky API zielt darauf ab, Wetterdaten des Deutschen Wetterdienstes (DWD) für Entwickler und andere Interessierte leicht zugänglich zu machen.Datenquelle:
Die Daten stammen vom DWD und umfassen Wetterbeobachtungen von Stationen und Wettervorhersagen, wie z.B. die MOSMIX-Modelle.Format:
Die Bright Sky API stellt die Daten im JSON-Format bereit, was die Integration in Anwendungen und Websites erleichtert.Zugriff:
Die API ist öffentlich und kann ohne API-Schlüssel genutzt werden, was die Einstiegshürde niedrig hält.Open Source:
Das Projekt ist Open Source, was bedeutet, dass der Quellcode öffentlich zugänglich ist und von der Community weiterentwickelt werden kann.Vorteile:
Die Bright Sky API bietet eine einfache Möglichkeit, auf Wetterdaten zuzugreifen, die andernfalls schwer zu handhaben wären, und ist kostenlos, was sie zu einer attraktiven Option für viele Projekte macht.Welche Daten lassen sich gegenüber anderen Adaptern verwenden?
Die aktuellen Wetterdaten werden 2x je Stunde zyklisch durch den DWD aktualisiert. Hierbei werden die Wetterdaten der nahegelegensten Wetter-Station des DWD (Deutscher Wetterdienst) berücksichtigt. Sind Wetterwerte nicht verfügbar, so werden diese automatisch über die 2. entfernteste, 3. entfernteste, usw. Wetterstation als Fallback aufgefüllt. Die Fallbackdaten für die entsprechenden Wetterdaten sind im Adapter ersichtlich.
Neben der hohen Qualität der Daten sind insbesondere die Solar- und Sonnendaten interessant:
Da die Werte aus dem Datenpunkt:
brightsky.0.current.solar_60z.B. in kWh/m² und bereits auf Energie / 1h angegeben sind lässt sich der Wertmit 1000 multipliziert auch in W/m²darstellen.Beispiel für Globalstrahlung (W/m²)
Adapter:
Installation:
Im Gegensatz zu vielen anderen Adaptern ist kein Account notwendig
Die Geokoordinaten für die Position können entweder direkt aus dem Browser oder aus dem ioBroker übernommen werden
Die Objektstruktur:
Die Daten werden wie folgt bereitgestellt:
- current - das aktuelle Wetter ( siehe auch: https://brightsky.dev/docs/#/operations/getCurrentWeather )
- daily - der aktuelle Wetter-Forecast über die nächsten 8 Tage (wird durch den Adapter erstellt und ist kein Bestandteil der API)
- hourly - der aktuelle Wetter-Forecast über die nächsten definierten n Stunden (siehe auch: https://brightsky.dev/docs/#/operations/getWeather )
Hallo zusammen,
vielen Dank erstmal für den Adapter der ist richtig gut! Eine kleinen Teil habe ich leider nicht verstanden. Das ist wann sich die Werte ändern. Die Beiträge bzgl der Struktur habe ich gelesen. Nun wollte ich solar_estimate (was ja der prognostizierte Ertrag sein müsste) mit den Echtdaten vergleichen.
Heute war der erste Lauf, ich glaube um 18:00 Uhr ist dann der Wert von solar_estimate start gefallen und der Wert von solar_estimateForHomoran blieb konstant.
War das eine zufällige Beobachtung oder ist das Absicht und ich habe die Logik dahinter nicht verstanden? Irgendwo habe ich gelesen das um 00:00, 5:00 und 18:00 Uhr irgendwas neu berechnet wird. Die Stelle finde ich leider nicht mehr.Die Werte in estimateForHomoran scheinen besser zu meinen aktuellen Erträgen zu passen.
Somit habe ich am Ende zwei Fragen:
- Warum hat der der Wert von solar_estimate geändert? Das hätte ich beim daily total nicht erwartet.
- Was ist der Unterschied zwischen solar_estimate und solar_estimateForHomoran
Ich hoffe meine Fragen verständlich notiert zu haben und hoffe dass @Homoran hier Licht ins Dunkel bringen kann. Oder jeder andere der es weiß :-)
Viele Grüße
Michael
-
Hallo zusammen,
vielen Dank erstmal für den Adapter der ist richtig gut! Eine kleinen Teil habe ich leider nicht verstanden. Das ist wann sich die Werte ändern. Die Beiträge bzgl der Struktur habe ich gelesen. Nun wollte ich solar_estimate (was ja der prognostizierte Ertrag sein müsste) mit den Echtdaten vergleichen.
Heute war der erste Lauf, ich glaube um 18:00 Uhr ist dann der Wert von solar_estimate start gefallen und der Wert von solar_estimateForHomoran blieb konstant.
War das eine zufällige Beobachtung oder ist das Absicht und ich habe die Logik dahinter nicht verstanden? Irgendwo habe ich gelesen das um 00:00, 5:00 und 18:00 Uhr irgendwas neu berechnet wird. Die Stelle finde ich leider nicht mehr.Die Werte in estimateForHomoran scheinen besser zu meinen aktuellen Erträgen zu passen.
Somit habe ich am Ende zwei Fragen:
- Warum hat der der Wert von solar_estimate geändert? Das hätte ich beim daily total nicht erwartet.
- Was ist der Unterschied zwischen solar_estimate und solar_estimateForHomoran
Ich hoffe meine Fragen verständlich notiert zu haben und hoffe dass @Homoran hier Licht ins Dunkel bringen kann. Oder jeder andere der es weiß :-)
Viele Grüße
Michael@bushveld
Das ist ein State für Homoran - wenn du den nutzen willst musste Lizenz... hahaha :DHomoran wollte einen State haben der sich morgens einmalig befüllt und dann stehen bleibt - wird um ca. um 5:00 gesetzt. Die anderen States werden um 5:00, 18:00 und 0:00 gesetzt + 3-90 Sekunden
-
@bushveld
Das ist ein State für Homoran - wenn du den nutzen willst musste Lizenz... hahaha :DHomoran wollte einen State haben der sich morgens einmalig befüllt und dann stehen bleibt - wird um ca. um 5:00 gesetzt. Die anderen States werden um 5:00, 18:00 und 0:00 gesetzt + 3-90 Sekunden
Hallo @ticaki
da mache doch beide Varianten Sinn. Ohne dass ich hier @Homoran und "seinen" Objekten was möchte. Wäre ein sprechender Namen nicht auch eine Option, ggf. additiv damit nichts bricht?
Ich könnte mir sogar eine weitere Variante vorstellen die sich über die current Werte anpasst damit würde die Tagssumme im Verlauf sich den realen Werten anpassen. Über den Bedarf kann man diskutieren. Der der's baut entscheidet :-)
Vielen Dank für die schnelle Antwort
Michael -
@bushveld
Das ist ein State für Homoran - wenn du den nutzen willst musste Lizenz... hahaha :DHomoran wollte einen State haben der sich morgens einmalig befüllt und dann stehen bleibt - wird um ca. um 5:00 gesetzt. Die anderen States werden um 5:00, 18:00 und 0:00 gesetzt + 3-90 Sekunden
@ticaki sagte in Betatest Bright Sky v0.6.x:
Homoran wollte einen State haben der sich morgens einmalig befüllt und dann stehen bleibt
dann benene es bitte ordentlich um.. ist doch kacke... da weiss keiner in 6 Monaten was der State macht
zigbee hab ich, zwave auch, nuc's genauso und HA auch
-
Hallo @ticaki
da mache doch beide Varianten Sinn. Ohne dass ich hier @Homoran und "seinen" Objekten was möchte. Wäre ein sprechender Namen nicht auch eine Option, ggf. additiv damit nichts bricht?
Ich könnte mir sogar eine weitere Variante vorstellen die sich über die current Werte anpasst damit würde die Tagssumme im Verlauf sich den realen Werten anpassen. Über den Bedarf kann man diskutieren. Der der's baut entscheidet :-)
Vielen Dank für die schnelle Antwort
Michael@bushveld sagte in Betatest Bright Sky v0.6.x:
Ich könnte mir sogar eine weitere Variante vorstellen die sich über die current Werte anpasst damit würde die Tagssumme im Verlauf sich den realen Werten anpassen. Über den Bedarf kann man diskutieren. Der der's baut entscheidet :-)
Vielen Dank für die schnelle Antwort
MichaelWenn ich eine Aktualisierung um 12:00 einbauen würde wären 12 Werte tatsächliche Werte und 12 Werte voraussagen - kann ich gerne machen - die frage ist halt ob man es braucht - den Server zu belasten nur weils nix kostet ist nicht so mein Ding :) - um 5 weil man will morgens das wetter für den Tag sehen - 18:00 weil mans für die Abend gestaltung sehen will - 0 Uhr wegen Tageswechsel.
und verbinde "Objekt ID" mit "brightsky.0.current.iconUrl"
Support us
660
Online32.6k
Benutzer82.0k
Themen1.3m
Beiträge