neue WS90/WS85 Funktionalitäten

[Gyvate]

Die 8,5s sind also auch bei diesem Ereignis fix. Schade. Es hätte ja durchaus sein können, dass es für diese Meldung eine Ausnahme gibt.

bis jetzt nicht, aber ich werde das mal als Anregung an Ecowitt weiterleiten, dass analog zum WH57 bei der ersten Registrierung (hier srain 0 -> 1) das dann existierende Datenpaket sofort gesendet wird und dann wieder in den üblichen Rhythmus verfallen wird - sofern das so einfach geht. Beim WH57 ist es nur ein Datum (genau genommen zwei, aber vom gleichen Typ und gleichzeitig anfallend) , hier sind es ~7 unterschiedliche Werte, die unterschiedlichen Erfassungsregeln unterliegen und ja auch zusammengestellt werden müssen.
Bei einem WS85 wäre das wahrscheinlich einfacher.
Mal sehen, was dazu gesagt wird.

[Gyvate]

Ergebnis einer Unterhaltung mit dem Ecowitt-Support:
man steht einer solchen Lösung grundsätzlich offen gegenüber, möchte aber auch vermeiden, dass es dadurch zu erhöhten Falschmeldungen kommt (gerade mal zwei Tropfen und dann nichts mehr, was im Reportingintervall von 8,5 Sekunden natürlich besser verifiziert werden könnte).
Möglicherweise müssen dazu etwas längere Tests durchgeführt werden, da man Beschwerden über zu viele Falschmeldungen vermeiden möchte, die dann den EIndruck eines unausgereiften Features erwecken.
Mal sehen, was daraus wird.

[mitschke]

Wir hatten doch einiges an Regen in letzter Zeit (>500mm in 30 Tagen, >300mm in 7 Tagen) und wenn man dem Regen so zusieht, wie er runter kommt, die Konsole aber teilweise in 0,5mm oder sogar größeren Schritten nach oben zählt, würde man sich vielleicht auch für den WH40 wünschen, dass dieser nicht (nur) im fixen Intervall sendet, sondern jedes Mal, wenn der Löffel kippt. Die 15k bis 20k zusätzlichen Auslösungen, die bei mir stattfinden würden, sind im niedrigen, einstelligen Prozentbereich.

Aber das fällt für mich dann wirklich in das Thema "Spielereien"

[RunMike]

Hallo!
Weiß jemand von euch, ob der Parameter "srain" bereits vom Sensor (in meinem Fall WS90) übermittelt wird, oder erst vom Gateway erzeugt wird?
Da ich die WS90-Daten nur in Home-Assistant nutze, kann ich das neue Feature momentan nicht sehen (außer der Web-UI des GW2000). Dazu müsste erst die Integration upgedatet werden. Käme "srain" bereits vom Sensor, könnte ich schon selber mal versuchen, via rtl_433 in den packets danach zu suchen. Vielleicht weiss einer der Spezialisten da schon Bescheid?

Gruß

Mike

[olicat]

Hi!

Die "eigentlichen" Daten kommen vom WS90.
Wie die da aber im Paket codiert sind, weiss ich nicht. Auch nicht, ob dieses Feature bereits durch rtl433 unterstuetzt wird.
Der srain_piezo-Event selbst kommt natuerlich von der Konsole (hier GW2000) auf Grundlage der Daten des WS90/WS85.

Du koenntest die MQTT-Anbindung an HomeAssistant via FOSHKplugin nutzen. Da wird srain_piezo bereits unterstuetzt.
Wobei da aktuell noch ein kleiner Fehler drin ist, der mit der naechsten Beta behoben ist.

Oliver

[RunMike]

Auch nicht, ob dieses Feature bereits durch rtl433 unterstuetzt wird.

Nein, sonst wäre meine Frage ja quasi mehr als flüssig. Wenn man sich die fineoffset_ws90.c ansieht, dann ist das noch nicht implementiert. Die ist auch schon 7 Monate alt. Wer sich mit dem Projekt beschäftigt hat, und damit meine ich den Empfang von Ecowitt-Sensoren, der hat festgestellt, dass das Daten-Paket des WS90 noch nicht vollständig dekodiert wurde. Da ist noch ein ganz schöner Brocken enthalten, der zwar Regen-abhängig ist, aber eben nicht zweifelsfrei zugeordnet werden kann.
Daher auch meine Frage, ob jemand weiß, ob dieser Parameter (womöglich schon längst) im Datenpaket vom WS90 steckt und erst jetzt vom Gateway ausgewertet wird. Mit diesem Wissen könnte ich (bei gleichzeitiger Kontrolle durch die Anzeige im Web-UI) durch Benetzung des WS90 vielleicht das "kippende Bit" selbst detektieren.
Wenn dem aber nicht so ist, dann brauche ich auch nicht einem Phantom hinterher zu jagen.

Trotzdem danke für deine Antwort.


Um das FOSHKplugin habe ich mich bisher absolut nicht gekümmert. Da muss ich mich erst mal schlau lesen, bevor ich Fragen stelle oder mitdiskutiere.
Zum jetzigen Zeitpunkt wäre das wohl eine ernstzunehmende Alternative; ich gehe mal davon aus, dass die Einarbeitung in die Ecowitt-Integration noch ein Weilchen dauern wird. Und ich wäre ein dankbarer Nutzer des Parameters ...


Gruß

Mike

[Gyvate]

Daher auch meine Frage, ob jemand weiß, ob dieser Parameter (womöglich schon längst) im Datenpaket vom WS90 steckt und erst jetzt vom Gateway ausgewertet wird. Mit diesem Wissen könnte ich (bei gleichzeitiger Kontrolle durch die Anzeige im Web-UI) durch Benetzung des WS90 vielleicht das "kippende Bit" selbst detektieren.
Wenn dem aber nicht so ist, dann brauche ich auch nicht einem Phantom hinterher zu jagen.

Da es kein Firmware-Upgrade des WS90 und des WS85 gegeben hat und eine bi-direktionale Kommunikation (noch) nicht implementiert wurde, muss die Info einfach im Datenpaket stecken. Sie wurde nur bislang nicht auswertet. Was allerdings WS85/WS90 genau senden und wie das auf Konsolenseite verarbeitet wird ist auch nicht klar. Möglicherweise ist der Datenstrom vom Sensor hier nicht so trivial wie bislang bei anderen Sensoren.
Was kann denn rtl_433 von WS90 Sensorsignal bislang auswerten ?

[Wetterchen]

https://github.com/merbanan/rtl_433/blo ... set_ws90.c

Da kann man herauslesen was RTL_433 mit der WS90 anfangen kann.
Gibt noch andere Files für die anderen WS Sensoren.

[Gyvate]

es gibt also 9 bytes mit unbekannter Bedeutung ...
Die Ladung (payload) eines Datenpakets sieht ja danach folgendermassen aus:

Code: Alles auswählen

00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
YY II II II LL LL BB FF TT HH WW DD GG VV UU UU R0 R1 R2 R3 R4 SS UU UU UU UU UU UU UU ZZ AA XX
90 00 34 2b 00 77 a4 82 62 39 00 3e 00 00 3f ff 20 00 ba 00 00 26 02 00 ff 9f f8 00 00 82 92 4f
    

U = unbekannt
genügend "Platz" für entsprechende Info, so man den Inhalt übersetzen kann ...

[RunMike]

U = unbekannt
genügend "Platz" für entsprechende Info, so man den Inhalt übersetzen kann ...

Ja, genau daran hängt es. Als ich im Dezember 2023 das Datenpaket "erforscht" habe (Ursache war damals die Erweiterung der Paket-Länge nach Firmware-Update), habe ich ja sogar selber die Firmware-Version detektiert. Damals waren "ZZ" noch "UU". An den restlichen Bytes habe ich mir mangels Skills die Zähne ausgebissen und aufgegeben.
Mein persönliches Ziel ist es, auch den noch in Betrieb befindlichen GW2000 einzumotten. Allerdings habe ich Gefallen an den Regen-Parametern gefunden; Gesamtregenmenge reicht mir nicht mehr ...

Wir wissen also nach wie vor nicht, ob es sich um ein "kippendes Bit" im Datenpaket des WS90 handelt, oder ob zB schlicht "X Impulse in Y Sekunden = Regen" in der Auswertung des Gateway zur Anzeige "Es regnet" führen ...

Dann werde ich da wohl nochmal analytisch ran gehen müssen.

Ach ja, ganz vergessen:
Damals hatte ich die Frage der Bedeutung der unbekannten Bits/Bytes auch an den Ecowitt-Service gestellt. Da kam nur eine ziemlich saure, wenig hilfreiche Antwort zurück ...

Gruß

Mike