NEWS
[Linux Shell-Skript] WLAN-Wetterstation
-
@sborg ok, dann werde ich das mal die Tage in Angriff nehmen und die neuste Version aufspielen und hoffe das mir nicht wieder die vm/proxmox irgendwo nen Strich durch die Rechnung macht.
Danach wäre ich ebenfalls an "pimp my station interessiert. Hab das allerdings nur oberflächlich verfolgt.@crunchip sagte in [Linux Shell-Skript] WLAN-Wetterstation:
@sborg ok, dann werde ich das mal die Tage in Angriff nehmen und die neuste Version aufspielen und hoffe das mir nicht wieder die vm/proxmox irgendwo nen Strich durch die Rechnung macht.
Danach wäre ich ebenfalls an "pimp my station interessiert. Hab das allerdings nur oberflächlich verfolgt.Mein Skript läuft auch auf Proxmox. Also keine Angst. :grin:
-
@crunchip sagte in [Linux Shell-Skript] WLAN-Wetterstation:
@sborg ok, dann werde ich das mal die Tage in Angriff nehmen und die neuste Version aufspielen und hoffe das mir nicht wieder die vm/proxmox irgendwo nen Strich durch die Rechnung macht.
Danach wäre ich ebenfalls an "pimp my station interessiert. Hab das allerdings nur oberflächlich verfolgt.Mein Skript läuft auch auf Proxmox. Also keine Angst. :grin:
@a200 sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Mein Skript läuft auch auf Proxmox. Also keine Angst.
Dito :grin:
...alerdings VM, nicht LXC ;) -
Neue Version des Wetterstation WLAN-Skriptes auf GitHub V2.1.0
- + zusätzliches Protokoll "9" für userspezifische Abfrage
- ~ Fix Reset kumulierte Regenmenge zum Jahresanfang
- ~ Fix für DP100 Bodenfeuchte
Wie immer zu finden im GitHub
Neue Beta-Version des Wetterstation WLAN-Skriptes auf GitHub V2.2.0
- ~ Fix Batteriestatus
- ~ Chillfaktor umbenannt auf Windchill/gefühlte Temperatur
- + Berechnung Windchill + Taupunkt für Ecowitt-Protokoll
Wie immer zu finden im GitHub
Bei der Beta ist folgendes zu beachten:
Der Batteriestatus funktioniert nun (Auszug Ecowitt)

und wird nur noch mit "0" (Batterie Ok) und "1" (Batterie wird leer) im DP angezeigt. "OK/Alarm" habe ich entfernt, da es in Grafana so nicht verwendbar ist und 0/1 sich auch in der VIS einfacher in ein beliebiges Format umsetzen lässt. true/false wollte ich hier nicht nutzen, ev. kommt ja Ecowitt auf die Idee da auch mal einen Level zu übertragen (+ hätte man für Grafana wieder umsetzen müssen...).
Wg. der (falschen) Bezeichnung "Chillfaktor" und Umbenennung in "gefühlte Temperatur" muss auch das wetterstation.js ersetzt und einmalig ausgeführt werden ("gefühlte Temperatur" ist halt ein neuer DP).
OSEM-Nutzer müssen sich auch in ihren Account einloggen und dort die Bezeichnung des Sensors "Chillfaktor" in "gefühlte Temperatur" ändern, sonst wird dieser Wert nicht mehr aktualisiert:

Es kann bis zu 5-10 Minuten dauern bis hier die Änderung auf OSEM greift (ich weiß nicht wann sie ihre Datenbank aktualisieren), also ein wenig Geduld. Danach ist auch der Verlauf in OSEM wieder sichtbar.@sborg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Neue Beta-Version des Wetterstation WLAN-Skriptes auf GitHub V2.2.0
Hallo
Seit dem Update werden die Werte nicht mehr aktualisiert.Kommando retour! .sh & .sub vergessen zu kopieren.

-
@rand sagte in [Linux Shell-Skript] WLAN-Wetterstation:
@SBorg
Im aktuellen Grafana Dashboard wird für das Panel Temperatur Min/Max der Wert
"measurement": "javascript.0.Statistik.Temperatur.Außen.Min_24h", (bzw Max)
gesucht, aber ich glaube den gibt es nicht - müsste das nicht eher 0_userdata.0.Statistik.Wetter.VorTag.Temperatur_Hoechstwert sein?Oder wird da gerade was umgebaut?
Nein, das ist einfach nur mein eigenes Dashboard. Ich habe noch ein separates Skript welches mir den min/max der letzten 24h generiert. Man kann natürlich auch wie von dir vorgeschlagen einfach die passenden Werte vom Vortag nutzen. Ist im Grunde gleich. Mit einer der nächsten Versionen ist allerdings schon der Min-/Max-Wert der letzten 24h geplant ;)
Aktuell aber lieber mehrere zeitnahe kleinere Releases (+damit auch bessere Übersicht bei auftretenden Fehlern), als dann alle x Monate ein Monsterrelease mit xx neuen Funktionen :)
@sborg said in [Linux Shell-Skript] WLAN-Wetterstation:
Aktuell aber lieber mehrere zeitnahe kleinere Releases (+damit auch bessere Übersicht bei auftretenden Fehlern), als dann alle x Monate ein Monsterrelease mit xx neuen Funktionen :)
Gerne :)
Beta 220 sieht gut aus bei mir, warte schon gespannt auf die neuen Sensoren in den nächsten Versionen :)
Danke sehr! -
@SBorg
Neueste Version 2.2.0 eingebaut und läuft. Danke dafür. Und natürlich aufs Ecowitt-Protokoll umgestellt. Auf die nächste Version, in der'allerdings schon der Min-/Max-Wert der letzten 24h geplant'ist, warte ich gerne noch - also keine Hetze. -
-
@crunchip sagte in [Linux Shell-Skript] WLAN-Wetterstation:
ich war hier ja ne Weile nimmer aktiv, bis auf, vor paar Tagen nen Kommentar(den ich mir nicht verkneifen konnte) hinterlassen.
Nun bin ich ganz schön hinterher und hab leicht den Überblick verloren.Habe dich schon vermisst :)
+ @wendy2702es spricht eigentlich nichts gegen die V2.1.0, die läuft stabil, selbst die V2.2.0 (beta) läuft bei mir problemlos. Bei so einem großen Versionssprung empfehle ich aber "tabularasa", also alles ersetzen und die paar nötigen Einstellungen in der *.conf vorzunehmen. Man kann sich die *.conf ja vorher sicherheitshalber noch mal sichern.
Alle Änderungen stehen eigentlich auf GitHub bei den Versionen.- - Funktion entfernt
- + Funktion hinzugefügt
- ~ Änderung an der Funktion, bspw. Bug-Fixing oä.
Falls da(nn noch) Fragen aufkommen sollten, nur zu.
-
@sborg Wo liegen denn zusammengefasst die Vorteile/Nachteile zwischen Wunderground oder Ecowitt Protokoll ?
@wendy2702 sagte in [Linux Shell-Skript] WLAN-Wetterstation:
@sborg Wo liegen denn zusammengefasst die Vorteile/Nachteile zwischen Wunderground oder Ecowitt Protokoll ?
Wenn du zusätzliche Sensoren hast, dann brauchst du Ecowitt.
Ecowitt einige zusätzliche Parameter wie z.B. Batterie-Info (Gut/Schwach).
Wenn de eine Gateway hast, dann brauchst du Ecowitt. -
@wendy2702 sagte in [Linux Shell-Skript] WLAN-Wetterstation:
@sborg Wo liegen denn zusammengefasst die Vorteile/Nachteile zwischen Wunderground oder Ecowitt Protokoll ?
Wenn du zusätzliche Sensoren hast, dann brauchst du Ecowitt.
Ecowitt einige zusätzliche Parameter wie z.B. Batterie-Info (Gut/Schwach).
Wenn de eine Gateway hast, dann brauchst du Ecowitt. -
@SBorg
Neueste Version 2.2.0 eingebaut und läuft. Danke dafür. Und natürlich aufs Ecowitt-Protokoll umgestellt. Auf die nächste Version, in der'allerdings schon der Min-/Max-Wert der letzten 24h geplant'ist, warte ich gerne noch - also keine Hetze.@rene55 sagte in [Linux Shell-Skript] WLAN-Wetterstation:
@SBorg
Neueste Version 2.2.0 eingebaut und läuft. Danke dafür. Und natürlich aufs Ecowitt-Protokoll umgestellt. Auf die nächste Version, in der'allerdings schon der Min-/Max-Wert der letzten 24h geplant'ist, warte ich gerne noch - also keine Hetze.Das war eigentlich sogar fertig, mittlerweile ist es in der Tonne gelandet. 2 Tage Arbeit "für die Katz". Das sind halt die Dinge die man zum Schluss nicht sieht. Wie sagte mal einer so schön beim fehlgeschlagenen Versuch #426: Das waren keine 426 Fehlschläge, sondern 426 Lösungen wie es nicht geht...
Mein "Fehler" war recht trivial. Funktionieren tut es, solange der "Skript-Rechner" derselbe ist auf dem auch die InfluxDB läuft. Was aber wenn dem nicht so ist...?
...und ja, man wird dafür eine InfluxDB brauchen. Werden die meisten eh schon zumindest wg. Grafana haben. -
@rene55 sagte in [Linux Shell-Skript] WLAN-Wetterstation:
@SBorg
Neueste Version 2.2.0 eingebaut und läuft. Danke dafür. Und natürlich aufs Ecowitt-Protokoll umgestellt. Auf die nächste Version, in der'allerdings schon der Min-/Max-Wert der letzten 24h geplant'ist, warte ich gerne noch - also keine Hetze.Das war eigentlich sogar fertig, mittlerweile ist es in der Tonne gelandet. 2 Tage Arbeit "für die Katz". Das sind halt die Dinge die man zum Schluss nicht sieht. Wie sagte mal einer so schön beim fehlgeschlagenen Versuch #426: Das waren keine 426 Fehlschläge, sondern 426 Lösungen wie es nicht geht...
Mein "Fehler" war recht trivial. Funktionieren tut es, solange der "Skript-Rechner" derselbe ist auf dem auch die InfluxDB läuft. Was aber wenn dem nicht so ist...?
...und ja, man wird dafür eine InfluxDB brauchen. Werden die meisten eh schon zumindest wg. Grafana haben.@sborg
wenns was zu testen gäbe, mein iob, influx und grafana ist je n eigener Docker -
Hallo @SBorg ,
ist das so gewollt dass der Wert "Rekordwerte - Regenmengemonat" immer einen Tag nach dem Wert "aktueller Monat - Regenmenge_monat" berechnet wird? Müsste doch, da erster Monat, beides immer identisch sein oder?
@sonystar sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Hallo @SBorg ,
ist das so gewollt dass der Wert "Rekordwerte - Regenmengemonat" immer einen Tag nach dem Wert "aktueller Monat - Regenmenge_monat" berechnet wird? Müsste doch, da erster Monat, beides immer identisch sein oder?
Gewollt nicht unbedingt, aber dem System, Timing, Umständen... geschuldet.
Die beiden Werte werden auch unterschiedlich sein, denn der eine wird einfach von der Station gelesen (inkl. der Rundungsdifferenzen), der Rekordwert von mir anhand der täglichen Regenmengen berechnet (simple Addition). Da kommt dann leider die Statistik durch, denn für den (ggf. neuen) Rekordwert brauche ich ja den alten Wert. Da die addierte Regenmenge aber von Gestern ist (ich brauche halt die Regenmenge des (oder eines) gesamten Tages), ist der alte Wert von Vorgestern. Somit habe ich nicht den Statistikversatz von 0-24h je nachdem wann man sich die Statistik anschaut (die Werte sind ja immer nur bis 23:59:59 berücksichtigt), sondern einen Tag mehr.
Eigentlich müsste ich den Monatsrekordwert bis zum folgenden Monatsersten unterdrücken, aber ich fand einfach einen "verschleppten" Rekord (um besagten einen Tag) schöner als gar keinen. Nächsten Monat wird es schon weniger auffallen, da sich der Rekordwert nur noch ändert wenn ein neuer Spitzenwert erreicht wird. Das wird mit jedem mal später im Monat werden (oder auch gar nicht wenn es im Monat weniger geregnet hat als der Rekordwert), bis er gar nicht mehr geknackt wird. -
@sborg
wenns was zu testen gäbe, mein iob, influx und grafana ist je n eigener Docker@amiethaner sagte in [Linux Shell-Skript] WLAN-Wetterstation:
@sborg
wenns was zu testen gäbe, mein iob, influx und grafana ist je n eigener DockerDanke für das Angebot. Zu testen gibt es eigentlich immer die Version auf GitHub im Branch "master". Die hat Beta-Status und kann Fehler enthalten, läuft aber meist schon recht stabil. Je mehr aber testen, desto eher fallen halt auch Fehler auf.
Die aktuelle V2.3.0 (oder andere) sind reine Developer-Versionen. Die enthalten in dem frühen Stadium meist noch sog. hardcoded Programmzeilen. Sprich da wird zB. explizit auf meine IP des ioB zugegriffen, was in der Beta-Version dann bspw. durch die Konfiguration geschieht. Aktuell steht da zB. mein Influx-Username und -Password im Klartext drin...
Da kann so keiner testen (und die möchte ich auch für mich behalten) ;) -
@rene55 sagte in [Linux Shell-Skript] WLAN-Wetterstation:
@SBorg
Neueste Version 2.2.0 eingebaut und läuft. Danke dafür. Und natürlich aufs Ecowitt-Protokoll umgestellt. Auf die nächste Version, in der'allerdings schon der Min-/Max-Wert der letzten 24h geplant'ist, warte ich gerne noch - also keine Hetze.Das war eigentlich sogar fertig, mittlerweile ist es in der Tonne gelandet. 2 Tage Arbeit "für die Katz". Das sind halt die Dinge die man zum Schluss nicht sieht. Wie sagte mal einer so schön beim fehlgeschlagenen Versuch #426: Das waren keine 426 Fehlschläge, sondern 426 Lösungen wie es nicht geht...
Mein "Fehler" war recht trivial. Funktionieren tut es, solange der "Skript-Rechner" derselbe ist auf dem auch die InfluxDB läuft. Was aber wenn dem nicht so ist...?
...und ja, man wird dafür eine InfluxDB brauchen. Werden die meisten eh schon zumindest wg. Grafana haben.@sborg
Ich hab ja für fast alles nen eigenen Container. Grafana & Influx in einem, das Script in einem anderen. Von Daher warte ich auch gerne noch die 4xx te Lösung ab. Nur blöd, wenn man soviel Zeit reinsteckt und hinterher war's das nicht. Dewegen möchte ich nochmals Mut zusprechen und ganz deutlich DANKE sagen. -
@rene55 sagte in [Linux Shell-Skript] WLAN-Wetterstation:
@SBorg
Neueste Version 2.2.0 eingebaut und läuft. Danke dafür. Und natürlich aufs Ecowitt-Protokoll umgestellt. Auf die nächste Version, in der'allerdings schon der Min-/Max-Wert der letzten 24h geplant'ist, warte ich gerne noch - also keine Hetze.Das war eigentlich sogar fertig, mittlerweile ist es in der Tonne gelandet. 2 Tage Arbeit "für die Katz". Das sind halt die Dinge die man zum Schluss nicht sieht. Wie sagte mal einer so schön beim fehlgeschlagenen Versuch #426: Das waren keine 426 Fehlschläge, sondern 426 Lösungen wie es nicht geht...
Mein "Fehler" war recht trivial. Funktionieren tut es, solange der "Skript-Rechner" derselbe ist auf dem auch die InfluxDB läuft. Was aber wenn dem nicht so ist...?
...und ja, man wird dafür eine InfluxDB brauchen. Werden die meisten eh schon zumindest wg. Grafana haben. -
@sborg
Ich hab ja für fast alles nen eigenen Container. Grafana & Influx in einem, das Script in einem anderen. Von Daher warte ich auch gerne noch die 4xx te Lösung ab. Nur blöd, wenn man soviel Zeit reinsteckt und hinterher war's das nicht. Dewegen möchte ich nochmals Mut zusprechen und ganz deutlich DANKE sagen.@rene55 sagte in [Linux Shell-Skript] WLAN-Wetterstation:
@sborg
Ich hab ja für fast alles nen eigenen Container. Grafana & Influx in einem, das Script in einem anderen. Von Daher warte ich auch gerne noch die 4xx te Lösung ab. Nur blöd, wenn man soviel Zeit reinsteckt und hinterher war's das nicht. Dewegen möchte ich nochmals Mut zusprechen und ganz deutlich DANKE sagen.Ich sehe fast alles immer positiv. Durch Fehler lernt man ja auch ;)
...und weil es so schön ist:

Lüppt 8)
Da dies allerdings vom WLAN-Skript getriggert wird und wohl keiner im 30 Sekundenraster (oder wie oft ihr die Daten vom Display empfangt) die Werte braucht (es braucht zwar kaum Ressourcen auf dem Influx-Client, aber wenig ist halt auch nicht nichts), lasse ich sie nur im 15 Minutenraster generieren (also xx:00, xx:15,...xx:45 Uhr).
Dafür lohnt aber aktuell noch kein neues Release, wenigstens noch einen Sensor mit dazu packen :grin:Wer wollte denn Zugriff auf "PimpMyStation"? Bitte hier oder per Chat die Wünsche mitteilen, ich editiere es dann hinein. Ich musste leider schon öfters bei Google-Spreadsheets die Erfahrung machen, dass mehrere Köche doch den Brei verderben. Ich habe es auch schon öfters mal zerschossen, ist halt EXCEL ähnlich, aber halt kein EXCEL...
...und wegen Zeitmangels aktuell hier nichts Neues :( -
@rene55 sagte in [Linux Shell-Skript] WLAN-Wetterstation:
@sborg
Ich hab ja für fast alles nen eigenen Container. Grafana & Influx in einem, das Script in einem anderen. Von Daher warte ich auch gerne noch die 4xx te Lösung ab. Nur blöd, wenn man soviel Zeit reinsteckt und hinterher war's das nicht. Dewegen möchte ich nochmals Mut zusprechen und ganz deutlich DANKE sagen.Ich sehe fast alles immer positiv. Durch Fehler lernt man ja auch ;)
...und weil es so schön ist:

Lüppt 8)
Da dies allerdings vom WLAN-Skript getriggert wird und wohl keiner im 30 Sekundenraster (oder wie oft ihr die Daten vom Display empfangt) die Werte braucht (es braucht zwar kaum Ressourcen auf dem Influx-Client, aber wenig ist halt auch nicht nichts), lasse ich sie nur im 15 Minutenraster generieren (also xx:00, xx:15,...xx:45 Uhr).
Dafür lohnt aber aktuell noch kein neues Release, wenigstens noch einen Sensor mit dazu packen :grin:Wer wollte denn Zugriff auf "PimpMyStation"? Bitte hier oder per Chat die Wünsche mitteilen, ich editiere es dann hinein. Ich musste leider schon öfters bei Google-Spreadsheets die Erfahrung machen, dass mehrere Köche doch den Brei verderben. Ich habe es auch schon öfters mal zerschossen, ist halt EXCEL ähnlich, aber halt kein EXCEL...
...und wegen Zeitmangels aktuell hier nichts Neues :( -
@rene55 Auf die kommende V2.3.0 warten :grinning:
Hat mal wer eine Aufstellung über alle Zusatzsensoren? Ich bräuchte
- Bezeichnung (DP50, DP100, DP60)
- was der Sensor eigentlich kann
- am idealsten wäre natürlich der --data/--debug String
- maximal mögliche Anzahl der Sensoren
Bezeichnung Beschreibung Datenstring max. Anzahl DP50 / WH31A Temperatur + Luftfeuchte --- 8 DP60 Blitzsensor &lightning_time=1611479261&lightning_num=16&lightning=12 &wh57batt=5 1 DP100 Bodenfeuchte --- 8 DP200 PM2.5 Feinstaub &pm25_ch1=29.0&pm25_avg_24h_ch1=22.0&pm25batt1=5 4 -
@rene55 Auf die kommende V2.3.0 warten :grinning:
Hat mal wer eine Aufstellung über alle Zusatzsensoren? Ich bräuchte
- Bezeichnung (DP50, DP100, DP60)
- was der Sensor eigentlich kann
- am idealsten wäre natürlich der --data/--debug String
- maximal mögliche Anzahl der Sensoren
Bezeichnung Beschreibung Datenstring max. Anzahl DP50 / WH31A Temperatur + Luftfeuchte --- 8 DP60 Blitzsensor &lightning_time=1611479261&lightning_num=16&lightning=12 &wh57batt=5 1 DP100 Bodenfeuchte --- 8 DP200 PM2.5 Feinstaub &pm25_ch1=29.0&pm25_avg_24h_ch1=22.0&pm25batt1=5 4 @sborg
for Gateway DP1500/GW1000:
humidityin
tempincsoil moisture sensors DP100/WH51:
soilbatt1..8 (battery in volt)
soilmoisture1..8for Multi-Temp/Hum-sensors DP50/WH31:
batt1..8 (battery-Status; 1 = Alarm, 0 = ok)
humidity1..8
temp1..8cfor PM-sensors DP200/WH41/WH43:
pm25_avg_24h_ch1..4
pm25_ch1..4
pm25batt1..4 (Battery-Status; 5 = max)
pm25_AQI_ch1..4
pm25_AQI_avg_24h_ch1..4
pm25_AQIlvl_ch1..4 (Level 1..6)
pm25_AQIlvl_avg_24h_ch1..4 (Level 1..6)Status/Activity/Tracker:
running (1 = startet, 0 = stopped)
loxtime (Loxone-time)
wswarning (weather station does not send data)
sensorwarning (mandatory sensor is missing)
batterywarning (Battery-warning)
stormwarning (Stormwarning)
tswarning (Thunderstorm-warning)
updatewarning (Firmware-update available)for lightning sensor WH57/DP60:
lightning (distance last lightning in km)
lightning_time (time of last lightning Unixtime)
lightning_loxtime (time of last lightning Loxone-time)
lightning_num (count of lightnings)
wh57batt (Battery-Status; 5 = max)for soil/water-temp-sensor WH34:
tf_chNc (temperature in °C; N=1..8)
tf_battN (battery; N=1..8)Quelle: (Hier)
-
@sborg
for Gateway DP1500/GW1000:
humidityin
tempincsoil moisture sensors DP100/WH51:
soilbatt1..8 (battery in volt)
soilmoisture1..8for Multi-Temp/Hum-sensors DP50/WH31:
batt1..8 (battery-Status; 1 = Alarm, 0 = ok)
humidity1..8
temp1..8cfor PM-sensors DP200/WH41/WH43:
pm25_avg_24h_ch1..4
pm25_ch1..4
pm25batt1..4 (Battery-Status; 5 = max)
pm25_AQI_ch1..4
pm25_AQI_avg_24h_ch1..4
pm25_AQIlvl_ch1..4 (Level 1..6)
pm25_AQIlvl_avg_24h_ch1..4 (Level 1..6)Status/Activity/Tracker:
running (1 = startet, 0 = stopped)
loxtime (Loxone-time)
wswarning (weather station does not send data)
sensorwarning (mandatory sensor is missing)
batterywarning (Battery-warning)
stormwarning (Stormwarning)
tswarning (Thunderstorm-warning)
updatewarning (Firmware-update available)for lightning sensor WH57/DP60:
lightning (distance last lightning in km)
lightning_time (time of last lightning Unixtime)
lightning_loxtime (time of last lightning Loxone-time)
lightning_num (count of lightnings)
wh57batt (Battery-Status; 5 = max)for soil/water-temp-sensor WH34:
tf_chNc (temperature in °C; N=1..8)
tf_battN (battery; N=1..8)Quelle: (Hier)
@a200 und @SBorg und alle anderen Freunde der gepflegten Wetterdokumentation,
inzwischen habe ich das Übermittlungsproblem der Regenwerte meiner Sainlogic FT 0300 mit Einlöten einer besseren Antenne lösen können. Das verbaute Dingen ist ner Kugelschreiberfeder ähnlich oder auf deutsch: Schrott...
Wie auch immer werden nun Werte übermittelt. Allerdings fällt mir auf, dass einige DPs ungefüllt bleiben:

In Ermangelung ausreichender JS-Kenntnisse kann ich leider das Script nicht verstehen. Werden bei Euren Stationen die fehlenden Werte von der Station übermittelt oder werden sie berechnet? Wenn sie übermittelt werden, dann schreibe ich mir zur Selbstberechnung ein Skript in Blockly, da ich die Werte ganz spannend finde. Ich möchte eben nur ausschließen, dass bei mir mit dem Skript was nicht stimmt. Bei mir wird in der Wallbox die Tagesmenge aufsummiert und am Ende des Tages der Wert auf 0 gesetzt. Man kann der Box wohl auch Monats- und sonstige Werte entlocken. Ich zweifle aber, dass die übermittelt werden.
Ansonsten auch von mir definitiv Daumen hoch und weiter so, erwarte mit Freude die nächste Version :+1: :clap: :facepunch: