Neues Modul für die WS980WiFi Wetterstation

Begonnen von choenig, 15 Februar 2019, 19:16:29

Vorheriges Thema - Nächstes Thema

choenig

Hi Romoker,

interessant. Ich hatte solche Werte noch kein einziges mal, hab' gerade mal meine ganze Logs durchgegreppt.

Wie geschrieben, wenn ihr mit dem hohen Log-aufkommen klar kommt, wäre es hilfreich, wenn ihr attr WS980 verbose 5 setzen könntet und mir die Logausgabe davon geben könntet, wenn das wieder auftritt.

Welche Firmware nutzt Du, Romoker? Auch 1.2.2 wie dancatt?

LG
Christian

choenig

#196
Hi Romoker, die 2.

Zitat von: Romoker am 16 August 2019, 21:00:17
Sonst könnte man den Loglevel der Meldung im WS980-Modul höher setzen. Schau Dir mal das Modul ModbusAttr an. Bei Modbus-Verbindungen verabschieden sich die Geräte öfters, was ganz normal ist. Das Modul hat mit dem Attribut "silentReconnect" eine intelligente Option geschaffen mit diesem Problem umzugehen.

Ich habe jetzt mal ein silentReconnect eingebaut. Wird es auf 1 gesetzt, loggt er die connect- und disconnect- Meldungen im LogLevel 2 statt 1.

Du findest die Version erstmal hier im Anhang zum Testen. Wäre nett, wenn Du es mal testen kannst.
Edit: Anhang gelöscht.

LG
Christian

Romoker

Hallo choenig,

erst mal danke für die Anpassung. Ich habe das aktualisierte Modul geladen und muss die nächsten Events abwarten. Ich werde dann berichten.

Was ich jetzt schon sagen kann: Wenn ich die silentReconnect-Funktion einschalte, muss ich verbose 1 setzen, damit die unerwünschten Meldungen nicht im Log erscheinen. Damit werden aber auch alle anderen Meldungen mit verbose > 1 unterdrückt. Ich würde die Reconnect-Meldungen mit der silentReconnect-Funktion statt auf verbose 2 auf verbose 4 setzen. Dann brauche ich das verbose nicht zusätzlich definieren.

Und noch eine Kleinigkeit: Wenn ich die Logmeldungen des Moduls nicht auf verbose 2 setze, werden bei mir jede Minute verbose 3 Meldungen ins Log geschrieben:
2019.09.15 11:58:40.809 3: WS980 (ws980wifi) - activeRquests: current firmware historyMax historyMin todayMax todayMin
2019.09.15 11:58:41.758 3: WS980 (ws980wifi) - activeRquests: firmware historyMax historyMin todayMax todayMin
2019.09.15 11:58:41.893 3: WS980 (ws980wifi) - activeRquests: historyMax historyMin todayMax todayMin
2019.09.15 11:58:42.016 3: WS980 (ws980wifi) - activeRquests: historyMin todayMax todayMin
2019.09.15 11:58:42.148 3: WS980 (ws980wifi) - activeRquests: todayMax todayMin
2019.09.15 11:58:42.190 3: WS980 (ws980wifi) - activeRquests: todayMin
2019.09.15 11:58:42.217 3: WS980 (ws980wifi) - activeRquests:
2019.09.15 11:59:40.812 3: WS980 (ws980wifi) - activeRquests: current firmware historyMax historyMin todayMax todayMin
2019.09.15 11:59:41.624 3: WS980 (ws980wifi) - activeRquests: firmware historyMax historyMin todayMax todayMin
2019.09.15 11:59:41.732 3: WS980 (ws980wifi) - activeRquests: historyMax historyMin todayMax todayMin
2019.09.15 11:59:41.793 3: WS980 (ws980wifi) - activeRquests: historyMin todayMax todayMin
2019.09.15 11:59:41.919 3: WS980 (ws980wifi) - activeRquests: todayMax todayMin
2019.09.15 11:59:41.976 3: WS980 (ws980wifi) - activeRquests: todayMin
2019.09.15 11:59:42.029 3: WS980 (ws980wifi) - activeRquests:

Wenn nichts dagegen spricht, würde ich diese activeRquests-Meldungen vom Standard-Verbose-Level 3 auch auf den Level 4 verbannen.

P.S.: Meine Firmwareversion ist EasyWeatherV1.4.1

Viele Grüße
BeagleBoneBlack & Raspberry Pi 4; FB7490; div. Homematic Komponenten; CUL433: CUL_TX, Conbee II, SOMFY, 1-Wire, Z-Wave, Zigbee, SmartPlugs von Sonoff und Shelly mit MQTT

FHEMAN

Hi, laut Datenblatt liefert die Anlage den UV-Index. Aber gibt es da einen eigenen Sensor für? Oder wird der UV-Index irgendwie vom LUX-Wert abgeleitet, kommt also vom Helligkeitssensor?
Habt ihr den UV-Index Wert mal vergleichen mit denen eines Wetterdienstes?
ich überlege mir gerade, die Anlage zu kaufen. Aber eigentlich nur wegen dem UV-Index. Weil den teuren HM Regensensor hab ich schon, und Wind ist mir egal (bisher).

Viele Grüße
Ronny
NUC7i5 | PROXMOX | FHEM 6.2 | 1 HMLAND | 2 UART | HM | LMS | HIFIBERRY | DOORBIRD | BLINK | BUDERUS | HUE | ALEXA | MILIGHT | LUFTDATENINFO | MQTT| ZIGBEE2MQTT | INDEGO | ROBOROCK | SMA | APC | OPENWB

Romoker

@choenig

Test positiv. Mit der Einstellung silentReconnect 1 werden die Disconnect- & Connect-Meldungen mit dem Loglevel 2 ausgegeben.

2019.09.17 00:01:01.211 2: WS980 (ws980wifi) - looks like the last request did not receive an answer, trying to reconnect
2019.09.17 00:01:01.213 2: WS980 (ws980wifi) - Socket Disconnected
2019.09.17 00:01:01.281 2: WS980 (ws980wifi) - Socket Connected


Übrigens habe ich, warum auch immer, jeden Tag um ein bis zwei Minuten nach Mitternacht diese Meldungen im Log.

Wie ich in meinem letzten Post erläutert habe, empfehle ich den Loglevel dieser Meldungen mit einem aktiven silentReconnect auf den Loglevel 4 herunterzustufen.

Viele Grüße
BeagleBoneBlack & Raspberry Pi 4; FB7490; div. Homematic Komponenten; CUL433: CUL_TX, Conbee II, SOMFY, 1-Wire, Z-Wave, Zigbee, SmartPlugs von Sonoff und Shelly mit MQTT

choenig

Hi Romoker,

danke für den Hinweis, dass 3 das default-LogLevel ist, war mir irgendwie nicht bewusst. Unter dieser Prämisse muss ich nochmal alle Loglevel korrigieren.

Ich hoffe, dass ich das diese Woche noch hinbekomme.

LG
Christian

choenig

So,

jetzt habe ich alle LogLevel nochmal unter Beachtung der Dokumentation der commandref überarbeitet:

0 - Server start/stop
1 - Fehlermeldungen oder unbekannte Pakete
2 - bedeutende Ereigbisse/Alarme.
3 - ausgesendete Kommandos werden gelogged.
4 - von den einzelnen Geräten empfangene Daten.
5 - Fehlersuche.


Die Version hängt diesem Post an.

Feedback ist wieder willkommen :)

LG
Christian

Romoker

Hallo choenig,

seit gestern läuft bei mir die neue Version. Die Unterdrückung der Reconnect-Meldungen im Log mit silentReconnect funktioniert jetzt auch ohne den Verbose-Level anpassen zu müssen. Ich habe aber jetzt eine neue verbose 1 Fehlermeldung im Log, die ich vorher noch nicht registriert habe:
2019.09.30 03:59:13.484 1: WS980 (ws980wifi) - looks like the reply could not be decoded, skipping
Die Meldung ist heute über den Tag verteilt fünf mal aufgetreten. Mein Intervall steht auf 60 Sekunden.

Viele Grüße
BeagleBoneBlack & Raspberry Pi 4; FB7490; div. Homematic Komponenten; CUL433: CUL_TX, Conbee II, SOMFY, 1-Wire, Z-Wave, Zigbee, SmartPlugs von Sonoff und Shelly mit MQTT

dsabathi

Sorry wenn offtopic, aber ich verzweifle langsam mit der Wetterstation.
Die geht täglich pünktlich um Mitternacht offline
Das WiFI Symbol geht dann aus und die Station lässt sich weder pingen noch von FHEM aus abfragen.
Ich denke allerdings nicht das es ein Problem mit dem FHEM Modul selbst ist, wenn ich das Modul disable geht die Station trotzdem offline.
Die Station hängt auf einer eigenen SSID die nur auf 2,4Ghz und nur auf einem meiner acess points ausgestrahlt wird.
FHEM greift über eine Firewall drauf. Klappt alles wunderbar genau bis Mitternacht.
Ich habe schon andere leasdauer, andere Zeitzone und sogar einen anderen DHCP Server erfolglos versucht. Auch eine andere Zeitzone bringt keine Verbesserung.
Die Station versucht laut WLAN Kontroller alle paar Minuten ein sauberes onboarding, bekommt auch die korrekte IP aber das WiFi Symbol bleibt aus und weder ping noch Datenabfrage funktionieren.
Vergebe ich allerdings über DHCP eine neue IP im selben Subnet kommt die Station nach ein paar Minuten online und lässt sich auch wieder bis Mitternacht abfragen.
Hat sonst noch jemand dieses Problem?

Danke und LG,
Dieter

Ainadilion

Hallo,

ich finde es schön, dass die Daten mit dem Modul ausgelesen werden können. Da ich die Daten in WSWIN weiterverarbeiten möchte, benötige ich eine csv-Datei, die in der Datenüberwachung automatisiert verarbeitet wird (Diagramme und Wetterauswertungen erstellen).

Das Format der Datei benötige ich, wie es in der Anlage zu sehen ist. Gibt es eine Möglichkeit auch dies über FHEM zu realisieren?



Gruß
Steffen alias Ainadilion

Waldmensch

Du könntest mit FileLog arbeiten. Infos gibts im Wiki und commandref


Gesendet von iPhone mit Tapatalk

Romoker

@choenig

Ich habe die neue Testversion schon seit ein paar Wochen erfolgreich im Einsatz. Aus meiner Sicht spricht nichts dagegen die neue Version einzuchecken.

Weihnachtliche Grüße
BeagleBoneBlack & Raspberry Pi 4; FB7490; div. Homematic Komponenten; CUL433: CUL_TX, Conbee II, SOMFY, 1-Wire, Z-Wave, Zigbee, SmartPlugs von Sonoff und Shelly mit MQTT

choenig

#207
Guten Morgen,

uuups, ich dachte, das hätte ich schon längst gemacht  :o

Mach ich heute.

Edit: Hab's eingecheckt.

LG
Christian

Waldmensch

Habt Ihr auch das Problem, dass beim derzeitigen Sonnenstand der Lichtsensor verrückt spielt? Ich habe den Verdacht, dass das Anemometer einen Schatten auf den Sensor wirft.



Gesendet von iPhone mit Tapatalk

Olli_aus_LuBu

Hallo zusammen,

erst einmal tausend Dank für die Erstellung dieses Moduls - GENIAL!

Aber ich scheitere momentan an einem Wert:
Die Basisstation zeigt auf ihrem Display einen "Licht-Wert" von z.B. 366W/m2. In den Readings finde ich aber nur "Brightness" mit z.B. 45200. Gibt es hier eine Umrechnung oder ist das gar nicht das richtige Reading für die Sonneneinstrahlung?

Viele Grüße und noch einen schönen sonnigen (und sturmfreien) Sonntag

Oliver