Neues Modul für die WS980WiFi Wetterstation

[Waldmensch]

Cool! Schiebe ich mir gleich drauf und berichte dann.

Ich hoffe, dass wir nach dem Webinar hier bald ein paar mehr Leute im Thread haben

Zum state ein nice2have Feature Request: ein Attribut um zu definieren showInState: inside/outside für die Leute, die die Innenwerte im Status haben wollen. Ich persönlich verwende den Status gar nicht und greife immer explizit auf die Readings zu. Ich habe immer ein ungutes Gefühl verschwendeter Rechenzeit, durch parsen von formatierten Werten, wenn diese auch plain vorliegen. Wer noch mit filelog arbeitet, wird sicher anders darüber denken, weil es natürlich Zeilen spart, wenn man nur den state logged und die Readings unterdrückt.

Zum Regen: ich weiß nicht mal ob mein Regensensor überhaupt funktioniert. Seit die Station montiert ist, hat es nicht wirklich geregnet


Gesendet von iPhone mit Tapatalk

[Waldmensch]

Die 13 läuft erstmal. Status sieht gut aus, Einheiten funzen (Nachgerechnet habe ich nicht)  . Das mit dem Reconnect - keine Ahnung, default Setting macht bei mir keine Probleme. Die 12 lief jetzt ein paar Tage problemlos

Feature Request: Bei den Units Attributen - Falls möglich im im Dropdown einen Postfix "(default)" anbringen. Das erleichtert das Rücksetzen beim Experimentieren. In der "help" stehen zwar die Defaultwerte, im Dropdown wäre es aber handlicher

Zum Licht Dämmerung/dunkel habe ich im ESPEasy folgende rule hartverdrahtet

Code Auswählen Erweitern

on lu#Lux do
TaskValueSet 3,1,[lu#Lux]

if [lu#Lux]<800
   TaskValueSet 3,3,1
endif
if [lu#Lux]>820
   TaskValueSet 3,3,0
endif

if [lu#Lux]<20
   TaskValueSet 3,4,1
endif
if [lu#Lux]>30
   TaskValueSet 3,4,0
endif
endon

Kommt dann im Fhem als State und einzelreadings so raus:

Code Auswählen Erweitern

Lux: 2813 Rss: -83 low: 0 med: 0

Wobei der Lux Wert dieses Sensors erheblich (~Faktor 10)niedriger ist, als der von der Wetterstation. Das ist mit Sicherheit ein Rechenfehler im BH1750 Code von ESPEasy. Die Hysterese muss sein, sonst springt das immer zwischen 0/1 wenn der Lichtwert an der Schaltgrenze ist. Ich hab den Luxwert Der Station mal zum Vergleich in mein Lichtwert Chart gepackt um die Schaltzeitpunkte rauszufinden, wenn ich den Lichtsensor außer Betrieb nehme und durch die Station ersetze.

[Waldmensch]

Ich hätte nicht gedacht, dass ich mich mal über Regen freue. Folgende Beobachtung an einlaufenden Werten

Die "Regensache" scheint alle 10 Minuten mit einem Wert beschickt zu werden ("preprocessed input" aus dem Plot Editor) Die Bezeichnung steht immer in der letzten Zeile eines Blocks. Ich werde es noch weiter beobachten. Zu beachten ist, das bei mir nur Werte "onChange" geschrieben werden. Auffällig ist der 0,0 Wert bei rainPerWeek heute exakt 0:00 Uhr. Das sagt uns schon mal, dass für die Wetterstation die Woche am Sonntag 0:00 beginnt und der Wochencounter genullt wird. Ähnliches gilt dann sicher für den Tagescount.

Code Auswählen Erweitern

get logdb HISTORY INT 2019-03-03_00:00:00 2019-03-03_23:59:59 Wetterstation:rainRate Wetterstation:rainPerDay Wetterstation:rainPerWeek Wetterstation:rainPerMonth Wetterstation:rainPerYear

2019-03-03_14:39:23 1.8
2019-03-03_14:48:23 3.0
2019-03-03_14:49:23 1.2
2019-03-03_14:58:23 1.8
#Wetterstation:rainRate:::
2019-03-03_14:39:23 0.3
2019-03-03_14:48:23 0.5
2019-03-03_14:58:23 0.8
#Wetterstation:rainPerDay:::
2019-03-03_00:00:19 0.0
2019-03-03_14:39:23 0.3
2019-03-03_14:48:23 0.5
2019-03-03_14:58:23 0.8
#Wetterstation:rainPerWeek:::
2019-03-03_14:39:23 2.0
2019-03-03_14:48:23 2.2
2019-03-03_14:58:23 2.5
#Wetterstation:rainPerMonth:::
2019-03-03_14:39:23 2.8
2019-03-03_14:48:23 3.0
2019-03-03_14:58:23 3.3
#Wetterstation:rainPerYear::::

[limats]

Hallo zusammen,

hat schon jemand ausprobiert, ob die Station einen Windböenspeicher hat oder wird nur immer der aktuelle Wind zum Zeitpunkt der Übertragung gesendet?
Und wie häufig wird der Wind aktualisiert?

Viele Grüße
Leo

[Waldmensch]

Hallo zusammen,

hat schon jemand ausprobiert, ob die Station einen Windböenspeicher hat oder wird nur immer der aktuelle Wind zum Zeitpunkt der Übertragung gesendet?
Und wie häufig wird der Wind aktualisiert?

Viele Grüße
Leo

Windböen findest Du im Reading "windGusts". Aktualisiert werden die Windwerte je nach Intervall. Wenn Wind weht kommt da eigentlich bei jedem Intervall ein neuer/anderer Wert in (default) m/s


Nochmal zum rainRate:

Also ein Stationsmessintervall ist 10 Minuten. Es wird alle 10 Minuten ein neuer Wert für die letzten 10 Minuten geliefert. Der Wert der letzten Stunde kann also aus der Summe der letzten 6 Zehnminutenintervalle errechnet werden. Ich weiß nicht, ob die Station mit jedem Datenpaket eine Timestamp mitsendet. Daran könnte einen Ringbuffer "befestigen". Der Ringbuffer müsste 24*6 Felder groß sein und alle 10 Minuten mit dem aktuellen rainRate Wert gefüllt werden. Die Summe des Ringbuffers entspricht dann dem Niederschlag der letzten 24h in mm. Die Summe des halben Ringbuffers entsprechend den letzten 12h.

Natürlich könnte man sich mit einem Notify um 23:59 auch den rainToday Wert als rainYesterday irgendwo in einem Dummy speichern und mit dem aktuellen rainToday in einem UserReading summieren. Dann hat man allerdings Mittags um 12 den Niederschlag von 24+12= 36h und nicht die letzten 24h

Man könnte das sicher auch außerhalb des Plugins in FHEM irgendwie frickeln, muss dann aber den rainRate onUpdateReading machen (beim onChange würde der externe Ringbuffer an trockenen Tagen nicht "gepflegt") , was Last auf dem FHEM erzeugt.

Hier mal die Rohdaten aus dem PlotEditor

Code Auswählen Erweitern

2019-03-03_17:10:23 1.2
2019-03-03_17:11:23 1.2
2019-03-03_17:12:23 1.2
2019-03-03_17:13:23 1.2
2019-03-03_17:14:23 1.2
2019-03-03_17:15:23 1.2
2019-03-03_17:16:23 1.2
2019-03-03_17:17:23 1.2
2019-03-03_17:18:23 1.2
2019-03-03_17:19:23 1.2
2019-03-03_17:20:23 0.0
2019-03-03_17:21:23 0.0
2019-03-03_17:22:23 0.0
2019-03-03_17:23:23 0.0
2019-03-03_17:24:23 0.0
2019-03-03_17:25:23 0.0
2019-03-03_17:26:23 0.0
2019-03-03_17:27:23 0.0
2019-03-03_17:28:23 0.0
2019-03-03_17:29:23 0.0
2019-03-03_17:30:23 0.0
2019-03-03_17:31:23 0.0
2019-03-03_17:32:23 0.0
2019-03-03_17:33:23 1.8
2019-03-03_17:34:23 1.8
2019-03-03_17:35:23 1.8
2019-03-03_17:36:23 1.8
2019-03-03_17:37:23 1.8
2019-03-03_17:38:23 1.8
2019-03-03_17:39:23 1.8
2019-03-03_17:40:23 1.8
2019-03-03_17:41:23 1.8
2019-03-03_17:42:23 1.8
2019-03-03_17:43:23 0.0
2019-03-03_17:44:23 0.0
2019-03-03_17:45:23 0.0
2019-03-03_17:46:23 0.0
2019-03-03_17:47:23 0.0
2019-03-03_17:48:23 0.0
2019-03-03_17:49:23 0.0
2019-03-03_17:50:23 0.0
2019-03-03_17:51:23 0.0
2019-03-03_17:52:23 0.0
2019-03-03_17:53:23 0.0
2019-03-03_17:54:23 0.0
2019-03-03_17:55:23 1.2
2019-03-03_17:56:23 1.2
2019-03-03_17:57:23 1.2
2019-03-03_17:58:23 1.2
2019-03-03_17:59:23 1.2
2019-03-03_18:00:23 1.2
2019-03-03_18:01:23 1.2
2019-03-03_18:02:23 1.2
2019-03-03_18:03:23 1.2

[Bikeman]

Hallo zusammen.

Das ist ein tolles Modul für die WS980. Ich habe das heute installiert, und bin begeistert.

Aber ich habe eine Frage: Kann man die Ansicht von "DeviceOverview" anpassen, indem andere Werte oder zusätzliche Werte mit angezeigt werden können?

Vielen Dank für eure Rückmeldungen.

[Waldmensch]

Hallo zusammen.

Das ist ein tolles Modul für die WS980. Ich habe das heute installiert, und bin begeistert.

Aber ich habe eine Frage: Kann man die Ansicht von "DeviceOverview" anpassen, indem andere Werte oder zusätzliche Werte mit angezeigt werden können?

Vielen Dank für eure Rückmeldungen.

Den "state" kannst Du doch mit dem Attribut "stateFormat" nach gutdünken überschreiben?!

Bsp:

Code Auswählen Erweitern

attr Wetterstation stateFormat R: rainTotal

[Bikeman]

Da war ich mir eben nicht sicher, ob das genau so funktioniert - und ich wollte lieber vorher fragen, bevor irgendwas dann nicht mehr funktioniert 

Danke für die Rückmeldung.

[choenig]

Cool! Schiebe ich mir gleich drauf und berichte dann.

Danke für Deinen unermütlichen und unerschrockenen Testeinsatz!

Ich hoffe, dass wir nach dem Webinar hier bald ein paar mehr Leute im Thread haben

Hab's inzwischen auch gesehen, Marko war ja sehr nett zu uns  .

Zum state ein nice2have Feature Request: ein Attribut um zu definieren showInState: inside/outside für die Leute, die die Innenwerte im Status haben wollen. Ich persönlich verwende den Status gar nicht und greife immer explizit auf die Readings zu. Ich habe immer ein ungutes Gefühl verschwendeter Rechenzeit, durch parsen von formatierten Werten, wenn diese auch plain vorliegen. Wer noch mit filelog arbeitet, wird sicher anders darüber denken, weil es natürlich Zeilen spart, wenn man nur den state logged und die Readings unterdrückt.

Man kann sich den state ja auch mittels stateFormat selber definieren, wenn man es anders haben möchte. Ich möchte da niemandem etwas vorschreiben, hab' mich mit dem jetzigen Inhalt einfach an andere Wettermodule gehalten.

Feature Request: Bei den Units Attributen - Falls möglich im im Dropdown einen Postfix "(default)" anbringen. Das erleichtert das Rücksetzen beim Experimentieren. In der "help" stehen zwar die Defaultwerte, im Dropdown wäre es aber handlicher

Du kannst do das Attribut einfach wieder löschen, wenn Du es nicht brauchst. In der nächsten Version werde ich die direkte Anzeige der commandref-Hilfe, wenn Du ein Attribut im Dropdown auswählst. Da steht dann der Defaultwert ja auch wieder drin.

Zum Licht Dämmerung/dunkel habe ich im ESPEasy folgende rule hartverdrahtet
[...]
Wobei der Lux Wert dieses Sensors erheblich (~Faktor 10)niedriger ist, als der von der Wetterstation. Das ist mit Sicherheit ein Rechenfehler im BH1750 Code von ESPEasy. Die Hysterese muss sein, sonst springt das immer zwischen 0/1 wenn der Lichtwert an der Schaltgrenze ist. Ich hab den Luxwert Der Station mal zum Vergleich in mein Lichtwert Chart gepackt um die Schaltzeitpunkte rauszufinden, wenn ich den Lichtsensor außer Betrieb nehme und durch die Station ersetze.

Interessant ist, dass meine WS980 auch komplett unterschiedliche brightness-Werte anzeigt als mein Rademacher Umweltsensor. Bei mir ist es aber dann eher Faktor 5.

Deine Hysterese bei Nacht sind nur 10lux, reicht das um sicherzustellen, dass das nicht durch Wolken abends trotzdem ein/aus/ein geht?

LG
Christian

[choenig]

Auffällig ist der 0,0 Wert bei rainPerWeek heute exakt 0:00 Uhr. Das sagt uns schon mal, dass für die Wetterstation die Woche am Sonntag 0:00 beginnt und der Wochencounter genullt wird. Ähnliches gilt dann sicher für den Tagescount.

Das ist wirklich interessant. Und es scheint auch keine Möglichkeit, das umzukonfigurieren.

Ich habe heute die 24 Stunden Regenmenge eingebaut, das dauert aber jetzt 24h, bis ich es richtig testen kann. Hoffentlich regnet es dann auch heute mal (kurz). Ich berechne das, in dem ich die rainTotal-Menge als referenzwert nehme und daraus die Differenz berechne.

Nochmal zum rainRate:

Also ein Stationsmessintervall ist 10 Minuten. Es wird alle 10 Minuten ein neuer Wert für die letzten 10 Minuten geliefert.

Cool, das kann man ja schön sehen

LG
Christian

[Waldmensch]

Mit dem Faktor 10 beim Lichtwert habe ich mich vermacht. Wenn man aufs Diagramm schaut, ist es eher Faktor 5
Die Hysterese ist bei mir okay. Es kommt sehr selten vor, das der Dämmerung Wert nochmal getriggert wird. Den Wert 10 müsste man dann ja auch *5 nehmen, wenn man es auf die Wetterstation umlegt. Ich würde die Hysterese aber als Attribut rausführen, dann kann es sich jeder selbst hinfrickeln. Wenn Du einmal an Lichtschwellen rangehst - fällt mir grad ein - warum nicht beliebig viele Schwellen als Array im Attribut? Ein Attribut könnte wie folgt aussehen:

,,[low, below, 10, 10], [medium, below, 200, 10], [extreme, above, 10000, 100], ......"

Also ,,[<readingname>, < 1 bei über oder unterschreiten>, <Wert>, <Hysterese>], ..."

Dann könnte man, neben den Dämmerungsaktionen auch Verschattungen schalten (Markisen, Rollläden etc)


Gesendet von iPhone mit Tapatalk

[choenig]

Hi Waldmensch,

die Idee finde ich gut, das kann ich so machen.

Es würde dann ein event ausgelöst werden, wie z.B. "start low" und "end low"? Und zusätzlich noch ein Reading mit "event_low: start" oder "event_low: on" oder so?

[Waldmensch]

Wenn du ein Reading setzt, wird doch ein Event ausgelöst. Insofern brauchst Du nur 0 oder 1, bei jedem Intervall in das Reading schreiben. Mit onChangeReading kann man dann ja definieren, das nur bei 0->1 und 1->0 Wechsel das Event in FHEM verwurstet wird, was die Last in FHEM auf ein Minimum reduziert.
Die Readings mit 0 anlegen würde ich schon beim einlesen des Attributes tun. Bezogen auf mein Beispiel oben würden nach dem lesen des Attributs 3 Readings erstellt werden:

low 0
medium 0
extreme 0

Mir fällt schon der nächste Feature Request ein. Das Blumenfenster. Pflanzen brauchen ja eine gewisse Menge Lux pro Tag. Falls das nicht reicht, kann man mit LED Pflanzenleuchten nachhelfen. Cool wäre es nun, eine Lösung zu haben, die sagt, ,,heute sind x Lux auf der Erde angekommen, wir müssen noch für 2h die LED Lampen einschalten, damit der Ficus seine Blätter nicht abwirft". Ich habe solch eine Lampe in meinem recht düsteren Badezimmer. Momentan schalte ich die Lampe bei Dämmerung ein und 22:00 aus. Cool wäre, wenn man abhängig von der Sonneneinstrahlung die Lampe gar nicht erst einschalten müsste oder halt nur 1h, weil tagsüber genügend Lux von oben kamen. Natürlich kann so eine Steuerung nicht Aufgabe der Wetterstation sein, aber man könnte da vielleicht zusammen mit dem HourCounter und den Lichtschwellen was basteln.



Gesendet von iPhone mit Tapatalk

[choenig]

Hi,

ich hatte ganz übersehen, dass Du geschrieben hast.

Wenn du ein Reading setzt, wird doch ein Event ausgelöst. Insofern brauchst Du nur 0 oder 1, bei jedem Intervall in das Reading schreiben. Mit onChangeReading kann man dann ja definieren, das nur bei 0->1 und 1->0 Wechsel das Event in FHEM verwurstet wird, was die Last in FHEM auf ein Minimum reduziert.
Die Readings mit 0 anlegen würde ich schon beim einlesen des Attributes tun. Bezogen auf mein Beispiel oben würden nach dem lesen des Attributs 3 Readings erstellt werden:

low 0
medium 0
extreme 0

Das halte ich auch für sinnvoll.

Mein Plan säh jetzt so aus:

Code Auswählen Erweitern

dusk:brightness<4000,300|night:brightness<30,30|bright:brightness>80000,5000


also

Code Auswählen Erweitern

EventName:ReadingName[<>]Limit,Hysterese|...


Um keine Kollisionen mit vorhandenen readings zu erzeugen, möchte ich ein "is" voransetzen, d.h. für das obige Beispiel werden die Readings isDusk, isNight und isBright erzeugt, die dann jeweils 0 oder 1 sein können.

Mit der Hysterese hab ich mir das wie folgt gedacht (am Beispiel von isDusk):
Beim Unterschreiten der 4000 lux geht das Reading auf 1. Es wechselt erst wieder auf 0, wenn entweder die 4300 überschritten wird, oder zunächst die 3700 unterschritten und dann wieder die 4000 überschritten wird.

Das hat den Vorteil, dass isDusk sowohl abends bei 3000 angeht, als auch morgens bei 3000 wieder ausgeht.

Kommentare? Jetzt

Mir fällt schon der nächste Feature Request ein. Das Blumenfenster. Pflanzen brauchen ja eine gewisse Menge Lux pro Tag. Falls das nicht reicht, kann man mit LED Pflanzenleuchten nachhelfen. Cool wäre es nun, eine Lösung zu haben, die sagt, ,,heute sind x Lux auf der Erde angekommen, wir müssen noch für 2h die LED Lampen einschalten, damit der Ficus seine Blätter nicht abwirft". Ich habe solch eine Lampe in meinem recht düsteren Badezimmer. Momentan schalte ich die Lampe bei Dämmerung ein und 22:00 aus. Cool wäre, wenn man abhängig von der Sonneneinstrahlung die Lampe gar nicht erst einschalten müsste oder halt nur 1h, weil tagsüber genügend Lux von oben kamen. Natürlich kann so eine Steuerung nicht Aufgabe der Wetterstation sein, aber man könnte da vielleicht zusammen mit dem HourCounter und den Lichtschwellen was basteln.

Das klingt für mich nach einem perfekten Beispiel für das Smarte Heim! Jedoch möchte ich das gerne hinten anstellen, wenns recht ist 

Zum 24h-Regen: Da habe ich jetzt eine Version, die bei mir läuft, ich gucke mal, dass ich da morgen eine 0.14 draus erstelle .

LG
Christian

[Waldmensch]

Wie Du die Syntax des Attributes gestaltest ist letztlich egal. Ich bin aktuell in der JavaScript Welt unterwegs und würde da ein JSON Objekt Array nehmen und im Code direkt damit arbeiten. Das ist aber in Perl, glaube ich, nicht praktikabel.

Hysterese finde ich okay so. Da muss dann der Nutzer eh mit rumspielen.

Mit dem Blumenfenster habe ich mir erstmal einen Hourcounter konfiguriert, der die Zeit zählt in der über 10kLux anliegen. Damit könnte man dann zum Zeitpunkt X prüfen, ob es genügend Sonnenstunden gab und die Lampen halt solange einschalten, damit der Ficus auf seine Gesamtstunden kommt. Habe ich aber wieder verworfen und ein DOIF genommen, was die Lampe einschaltet, wenn brightness unter 10kLux fällt und das Zeitfenster innerhalb 6:00-18:00 damit sind quasi immer 12 Sonnenstunden gewährleistet. Die 10kLux habe ich genommen, weil da an der Ficus Position ca 2500Lux ankommen. Aus einer Tabelle habe ich erlesen, das sich ein Ficus zwischen 1000-2000 Lux wohlfühlt 

Übrigens habe ich heute verwundert festgestellt, dass meine Station keine Regenwerte geliefert hat. Ein Blick aufs Dach ergab, das der schwarze Trichter verschwunden war. Der Sturm hatte ihn weggepustet. Zum Glück ist er auf dem Flachdach gelandet und heil geblieben. Tipp an alle Stationsbesitzer: Der Trichter ist so locker, das es lohnt, ihn mit ein bisschen Klebeband zu sichern.


Gesendet von iPhone mit Tapatalk