NEWS
Betatest Bright Sky v0.6.x
-
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.
-
@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.
@ticaki sagte in Betatest Bright Sky v0.6.x:
Wenn 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.
Ich hätte mir da mehr eine kontinuierliche Anpassung der Tagessummen Prognose vorgestellt (derzeit aka solar_estimationForHomoran. Der Anwendungsfall wäre nur eine optimierte Prognose der Tagessumme und ob das den Aufwand rechtfertigt kann ich schwer abschätzen. Bsp wäre. Entgegen der eigentlichen Vorhersage ist der Morgen doch sonnig dann würde die Tagesprognose schlicht über die currentwerte angepasst werden, das macht aber dann wohl nur Sinn wenn man das stündlich macht. Ich glaube das ist zuviel des Guten.
-
@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
@arteck sagte in Betatest Bright Sky v0.6.x:
dann benene es bitte ordentlich um.. ist doch kacke... da weiss keiner in 6 Monaten was der State macht
@ticaki
schmeiss ihn raus!
ich schreibe den Wert schon um 05:16 in einen eigenen DP.Hab mich schon gewundert dass er anscheinend noch drin ist. Der war ja erst nur in einen speziellen Branch
-
@ticaki sagte in Betatest Bright Sky v0.6.x:
Wenn 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.
Ich hätte mir da mehr eine kontinuierliche Anpassung der Tagessummen Prognose vorgestellt (derzeit aka solar_estimationForHomoran. Der Anwendungsfall wäre nur eine optimierte Prognose der Tagessumme und ob das den Aufwand rechtfertigt kann ich schwer abschätzen. Bsp wäre. Entgegen der eigentlichen Vorhersage ist der Morgen doch sonnig dann würde die Tagesprognose schlicht über die currentwerte angepasst werden, das macht aber dann wohl nur Sinn wenn man das stündlich macht. Ich glaube das ist zuviel des Guten.
@bushveld sagte in Betatest Bright Sky v0.6.x:
Ich hätte mir da mehr eine kontinuierliche Anpassung der Tagessummen Prognose vorgestellt (derzeit aka solar_estimationForHomoran.
Genau das Gegenteil war der Usecase!
kein Support per PN! - Fragen im Forum stellen - es gibt fast nichts, was nicht auch für andere interessant ist.
Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash -
-
@bushveld sagte in Betatest Bright Sky v0.6.x:
ForHomoran
Ich werfe dann alle States die so heißen raus - wenn sich einer beschwert kommen sie unter neuem Namen wieder rein :)
@Bushveld
current ist was anders als daily - current ist JETZT nicht gleich, nicht vorhin sondern jetzt - damit kann man nix in den Voraussagen anfangen, weil wenn JETZT 100% Wolken sind aber gleich 0% wird die ganze Stunde falsch berechnet.vielleicht mache ich da noch eine Möglichkeit das häufiger zu aktualisieren
-
Wenn jemand testen will https://github.com/ticaki/ioBroker.brightsky
da das ne 1.0.0 wird muß ich mal gucken ob ich das sunrise/sunset auch breaking mache.
WORK IN PROGRESS
- (ticaki) Customisable update interval for Daily (expert)
- (ticaki) BREAKING: remove forHomoran states
Der benutzerdefinierte Interval erscheint nur als einstellmöglichkeit, wenn expertMode an ist - sonst schreibt da jeder was rein :D
und der Interval ist das minimum von jetzt + Intervalstunden und 24:00:00 - Nach dem ersten Tageswechsel startet er immer mit der basis 0:00.
Hm - Damit meine ich - beim Starten des adapters ist der nächste Interval jetzt + eingestellter Wert auf volle stunde abgerundet - ab dem Tageswechel ist es ein vielfaches vom eingestelltem Wert.
Updateverzögerung und -streuung ist bei Daily jetzt 30-60 Sekunden.
EDIT:
Ich werde den stundeninterval nicht nutzen - da kann man nicht um 5:00 (sommer sonnenaufgang) und 18:00 einstelllen - das geht nur mit Stündlich und das brauche ich net. -
@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.
@ticaki sagte in Betatest Bright Sky v0.6.x:
Namensvorschlag?
'solar_estaminate_once_5_oclock' und in der Beschreibung 'pick up data once at 5 o'clock'
zigbee hab ich, zwave auch, nuc's genauso und HA auch
-
@ticaki sagte in Betatest Bright Sky v0.6.x:
Namensvorschlag?
'solar_estaminate_once_5_oclock' und in der Beschreibung 'pick up data once at 5 o'clock'
@arteck passt 😉
-
@bushveld sagte in Betatest Bright Sky v0.6.x:
ForHomoran
Ich werfe dann alle States die so heißen raus - wenn sich einer beschwert kommen sie unter neuem Namen wieder rein :)
@Bushveld
current ist was anders als daily - current ist JETZT nicht gleich, nicht vorhin sondern jetzt - damit kann man nix in den Voraussagen anfangen, weil wenn JETZT 100% Wolken sind aber gleich 0% wird die ganze Stunde falsch berechnet.vielleicht mache ich da noch eine Möglichkeit das häufiger zu aktualisieren
@ticaki sagte in Betatest Bright Sky v0.6.x:
weil wenn JETZT 100% Wolken sind aber gleich 0% wird die ganze Stunde falsch berechnet.
Danke damit ist dann alles was geschrieben habe hinfällig wenn current in so kleinen Scheiben gemessen wird müsste man in der gleichen Frequenz die Vorhersagen anpassen.
-
@ticaki sagte in Betatest Bright Sky v0.6.x:
weil wenn JETZT 100% Wolken sind aber gleich 0% wird die ganze Stunde falsch berechnet.
Danke damit ist dann alles was geschrieben habe hinfällig wenn current in so kleinen Scheiben gemessen wird müsste man in der gleichen Frequenz die Vorhersagen anpassen.
@bushveld
Ich hatte nicht nachgeguckt das war eine vermutung - hab mich geirrt - ist aber imho nicht brauchbar:Returns current weather for a given location.
To set the location for which to retrieve weather, you must supply both lat and lon or one of dwd_station_id, wmo_station_id, or source_id.
This endpoint is different from the other weather endpoints in that it does not directly correspond to any of the data available from the DWD Open Data server. Instead, it is a best-effort solution to reflect current weather conditions by compiling SYNOP observations from the past one and a half hours.
-
@ticaki sagte in Betatest Bright Sky v0.6.x:
weil wenn JETZT 100% Wolken sind aber gleich 0% wird die ganze Stunde falsch berechnet.
Danke damit ist dann alles was geschrieben habe hinfällig wenn current in so kleinen Scheiben gemessen wird müsste man in der gleichen Frequenz die Vorhersagen anpassen.
@bushveld sagte in Betatest Bright Sky v0.6.x:
müsste man in der gleichen Frequenz die Vorhersagen anpassen.
wieso das?
Eine Vorhersage kommt immer einiges früher, damit man sich darauf einstellen kann.
Deswegen ist der Wert um 05:00 auch festgepinnt gewesen, um am Abend noch die Genauigkeit der Vorhersage bewerten zu können.Ein ständiges Nachführen eine Vorhersage mittels aktueller Werte konterkariert die Bezeichnung Vorhersage!
kein Support per PN! - Fragen im Forum stellen - es gibt fast nichts, was nicht auch für andere interessant ist.
Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash -
-
@bushveld sagte in Betatest Bright Sky v0.6.x:
Ich hätte mir da mehr eine kontinuierliche Anpassung der Tagessummen Prognose vorgestellt (derzeit aka solar_estimationForHomoran.
Genau das Gegenteil war der Usecase!
@homoran
alles klar, ich habe den Wert so verstanden das einmal eine Prognose erstellt wird die dann für den Tag gültig bleibt. (Genau das was ich gesucht habe).Die Anregung war diese frühe Prognose laufend mit den Werten aus current abzugleichen und so den Teil der in der Vergangenheit liegt den realen Werten anzugleichen, der zukünftige Teil wäre dann immer noch die Prognose. Das Ergebnis wäre dann am Ende des Tages ein 100% match. Wobei dieser usecase nur Sinn macht wenn am Vormittag starte Abweichungen stattfinden. Also durchaus ein Edge case den ich auch nur mal in den Ring geworfen habe.
Habe deinen Ansatz verstanden, den nutze ich derzeit ja auch weil er meinem Ziel der Vorschau was in Summe in den kommenden Tagen erzeugt wird an nächsten kommt. Daher Danke fürs einbauen. Wie immer der Wert dann in Zukunft heißen wird.
Viele Grüße
Michael -
@bushveld sagte in Betatest Bright Sky v0.6.x:
müsste man in der gleichen Frequenz die Vorhersagen anpassen.
wieso das?
Eine Vorhersage kommt immer einiges früher, damit man sich darauf einstellen kann.
Deswegen ist der Wert um 05:00 auch festgepinnt gewesen, um am Abend noch die Genauigkeit der Vorhersage bewerten zu können.Ein ständiges Nachführen eine Vorhersage mittels aktueller Werte konterkariert die Bezeichnung Vorhersage!
Eine Vorhersage kommt immer einiges früher, damit man sich darauf einstellen kann.
Deswegen ist der Wert um 05:00 auch festgepinnt gewesen, um am Abend noch die Genauigkeit der Vorhersage bewerten zu können.Stimme dir zu wenn das Ziel das Messen der Qualität der Vorhersage sein soll ist der von mir gemachte Vorschlag nicht brauchbar und ein anderer usecase.
Ein ständiges Nachführen eine Vorhersage mittels aktueller Werte konterkariert die Bezeichnung Vorhersage!
Nein denn es bleibt eine Vorhersage, nur eben eine die ggf. unscharfe Altlasten bereinigt hat.
Die Diskussion ist aber müßig der Anwendungsfall ist ein Randfall und der Aufwand der Implementierung sicher hoch. -
Eine Vorhersage kommt immer einiges früher, damit man sich darauf einstellen kann.
Deswegen ist der Wert um 05:00 auch festgepinnt gewesen, um am Abend noch die Genauigkeit der Vorhersage bewerten zu können.Stimme dir zu wenn das Ziel das Messen der Qualität der Vorhersage sein soll ist der von mir gemachte Vorschlag nicht brauchbar und ein anderer usecase.
Ein ständiges Nachführen eine Vorhersage mittels aktueller Werte konterkariert die Bezeichnung Vorhersage!
Nein denn es bleibt eine Vorhersage, nur eben eine die ggf. unscharfe Altlasten bereinigt hat.
Die Diskussion ist aber müßig der Anwendungsfall ist ein Randfall und der Aufwand der Implementierung sicher hoch.@bushveld
Das ist doch schon drin, in der GitHub Version. halt nicht so wie du denkst. Die Abfrage um 5 enthält von 0-5 historisierte Tatsächliche Wert und von 5-24 Voraussagen. Lese was ich oben geschrieben habe bei dem work in progress -
@bushveld
Das ist doch schon drin, in der GitHub Version. halt nicht so wie du denkst. Die Abfrage um 5 enthält von 0-5 historisierte Tatsächliche Wert und von 5-24 Voraussagen. Lese was ich oben geschrieben habe bei dem work in progress@ticaki sagte in Betatest Bright Sky v0.6.x:
Die Abfrage um 5 enthält von 0-5 historisierte Tatsächliche Wert und von 5-24 Voraussagen. Lese was ich oben geschrieben habe bei dem work in progress
@ticaki sagte in Betatest Bright Sky v0.6.x:
Der benutzerdefinierte Interval erscheint nur als einstellmöglichkeit, wenn expertMode an ist - sonst schreibt da jeder was rein
und der Interval ist das minimum von jetzt + Intervalstunden und 24:00:00 - Nach dem ersten Tageswechsel startet er immer mit der basis 0:00.
Hm - Damit meine ich - beim Starten des adapters ist der nächste Interval jetzt + eingestellter Wert auf volle stunde abgerundet - ab dem Tageswechel ist es ein vielfaches vom eingestelltem Wert.
Updateverzögerung und -streuung ist bei Daily jetzt 30-60 Sekunden.
EDIT:
Ich werde den stundeninterval nicht nutzen - da kann man nicht um 5:00 (sommer sonnenaufgang) und 18:00 einstelllen - das geht nur mit Stündlich und das brauche ich net.Ich muss zugeben das ein paar mal gelesen zu haben. Ich bin mir nicht sicher ob ich's verstanden habe. Werde es ausprobieren müssen.
Die Abfrage um 5 enthält von 0-5 historisierte Tatsächliche Wert und von 5-24 Voraussagen.
D.h. es wird um 18:00 Uhr nicht mehr zurück gesetzt?
Support us
705
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge