WS300: no data - mal geht's, dann wieder nicht

kpwg · 10 Dezember 2013, 19:05:16

Hallo Forengemeinde,

in meiner Bastelkiste fand ich noch eine WS300PC, die nun am RasPi läuft. Leider nicht so ganz zuverlässig- es gehen immer wieder Werte verloren. Zwischendurch läuft es dann wieder stunden- bis tagelang fehlerfrei. USB-Kabel wurde bereits getauscht, die Batterien in der WS300PC erneuert.

Logauszug von gerade eben:

Code Auswählen

2013.12.10 17:53:38 1: WS300: no data
2013.12.10 17:53:43 1: WS300: no data
2013.12.10 17:53:48 1: WS300: no data
2013.12.10 17:53:53 1: WS300: no data
2013.12.10 17:53:58 1: WS300: no data
2013.12.10 17:54:03 1: WS300: no data
2013.12.10 17:54:08 1: WS300: no data
2013.12.10 17:54:13 1: WS300: no data
2013.12.10 17:54:18 1: WS300: no data
2013.12.10 17:54:23 1: WS300: no data
2013.12.10 17:54:28 1: WS300: no data
2013.12.10 17:54:33 1: WS300: no data
2013.12.10 17:54:38 1: WS300: no data
2013.12.10 17:54:43 1: WS300: no data
2013.12.10 17:54:48 1: WS300: no data
2013.12.10 17:54:53 1: WS300: no data
2013.12.10 17:54:58 1: WS300: no data
2013.12.10 17:55:03 1: WS300: no data
2013.12.10 17:55:08 1: WS300: no data

Der nötige Auszug aus der fhem.cfg

Code Auswählen

define WS300Device WS300 /dev/ttyUSB0
attr WS300Device room Devices
define WS300Device_timer at +*00:00:05 get WS300Device data
define ks300 WS300 8
define ws300 WS300 9

Was könnte hier schief gehen?

Und gleich noch eine Frage: die Syntax zum Einrichten der Höhe über NN ist mir nicht ganz klar.
Ich meine, mit

Code Auswählen

set WS300Device 5 600 0 den Intervall auf 5min, die Höhe auf 600m und den Regen auf 0 setzen zu können (es ist nur ein KS200, also ohne Kaffeebecher).

Ich erhalte aber die Fehlermeldung

Code Auswählen

ERROR:
the ws300pc will now synchronize for 10 minutes

Vielen Dank schon mal für Eure Ideen.

Ricardo

kpwg · 11 Dezember 2013, 17:52:10

Heute lief das Ganze wieder "etwas" stabiler. So sieht es nach dem gestrigen rereadcfg aus:

Code Auswählen

2013.12.10 19:06:07 1: Including fhem.cfg
2013.12.10 19:06:08 3: telnetPort: port 7072 opened
2013.12.10 19:06:08 3: WEB: port 8083 opened
2013.12.10 19:06:08 3: WEBphone: port 8084 opened
2013.12.10 19:06:08 3: WEBtablet: port 8085 opened
2013.12.10 19:06:09 1: WS300 Device /dev/ttyUSB0 opened
2013.12.10 19:06:09 3: ECMD opening NETIO_WZ (protocol telnet, device 192.168.3.81:2701)
2013.12.10 19:06:09 3: ECMD device opened
2013.12.10 19:06:09 1: Including ./log/fhem.save
2013.12.10 21:01:50 1: WS300: no data
2013.12.10 21:32:20 1: WS300: no data
2013.12.10 23:29:15 1: WS300: no data
2013.12.11 06:54:05 1: WS300: no data
2013.12.11 07:34:45 1: WS300: no data
2013.12.11 08:56:05 1: WS300: no data
2013.12.11 09:21:30 1: WS300: no data
2013.12.11 09:36:45 1: WS300: no data
2013.12.11 09:57:05 1: WS300: no data
2013.12.11 10:17:25 1: WS300: no data
2013.12.11 10:58:05 1: WS300: no data
2013.12.11 11:03:10 1: WS300: no data
2013.12.11 11:08:15 1: WS300: no data
2013.12.11 11:13:20 1: WS300: no data
2013.12.11 15:45:20 1: WS300: no data

Dirk · 11 Dezember 2013, 18:07:35

Hallo Ricardo,

da der Author des Modules das ganze nicht mehr betreut, hatte ich vor einigen Wochen die Pflege übernommen.
Ich hatte hier und da auch einige Bugfixes eingecheckt.

Ich habe genau eine Installation an einem Raspberry Pi wo eine WS300 angeschlossen ist.
Die meiste Zeit läuft das Teil sauber durch, dein beobachtetes Verhalten kenne ich aber auch.

Ich habe festgestellt, dass vor allem wenn Plots gezeichnet werden, und FHEM eine Weile beschäftigt ist, anschließend dieses Phänomen auftritt.
Durch einen anschließenden Neustart von FHEM lässt sich das dann wieder "beheben".

Da das WS300-Modul aber wohl nur noch selten eingesetzt wird und von anderen Seiten hierzu keine Meldung kam, habe ich mich bis dahin nicht weiter bemüht diesem Problem auf die Spur zu gehen.

Kannst du das Verhalten durch irgendeine Useraktion reproduzieren?

Viele grüße
Dirk

kpwg · 11 Dezember 2013, 19:26:57

Hallo Dirk,

einen Zusammenhang kann ich aktuell nicht mit zB Plot's zeichnen herstellen. Gerade habe ich nochmal Plot's des gesamten Monats mehrfach zeichnen lassen- ohne Fehler. Die Pollzeit von 5sec halte ich für sehr kurz. Da Werte leider nur alle 5min bereit gestellt werden (könnte man das auch auf 3 oder 4min reduzieren?), kann man doch zB auch nur einmal pro Minute pollen.

Ich beobachte das mal weiter. Sehr schade mit der geringen Verbreitung der WS300PC- bringt sie doch einen S300TH-/KS300-Empfänger sowie einen eigenen Temperatur-/Feuchte-/Luftdrucksensor mit.

Viele Grüße,

Ricardo

Dirk · 11 Dezember 2013, 20:07:52

ZitatDie Pollzeit von 5sec halte ich für sehr kurz.

Das ist korrekt. Daher habe ich hier die entsprechenden Zeilen auskommentiert und das zugehörige at selber definiert.

Man könnte auch die Zeile im Code direkt ändern. Das sollte dann so aussehen:

Code Auswählen

Zeile 163 alt:
CommandDefine(undef,"WS300Device_timer at +*00:00:05 get WS300Device data");

Zeile 163 neu:
CommandDefine(undef,"WS300Device_timer at +*00:01:00 get WS300Device data");

Ich glaube ich schaue mir den Code über die Kommenden Feiertage mal mit an.

Zitateinen Zusammenhang kann ich aktuell nicht mit zB Plot's zeichnen herstellen.

Auf dem Pi hat das Zeichnen der logs schon mal um die 20-30 Sekunden gedauert.
Wenn das in die Zeit fällt wo die WS300 wieder Daten sendet und die nicht korrekt abgeholt werden, könnte hier irgendwas durcheinander kommen.

Gruß
Dirk

kpwg · 11 Dezember 2013, 20:34:11

Ich habe nun testweise den WS300Device_timer auf +*00:00:30 gesetzt. Mal schauen, was die nächsten Stunden/Tage passiert.

kpwg · 16 Dezember 2013, 18:08:44

So, 5 Tage Testzeit reichen für eine erste Aussage: es ist deutlich besser geworden! Ein Auszug der letzten 24h:

Code Auswählen

2013.12.15 22:03:49 1: WS300: no data
2013.12.16 00:05:49 1: WS300: no data
2013.12.16 00:36:19 1: WS300: no data
2013.12.16 01:06:49 1: WS300: no data
2013.12.16 11:44:49 1: WS300: no data
2013.12.16 12:45:49 1: WS300: no data
2013.12.16 17:51:49 1: WS300: no data
2013.12.16 17:52:19 1: WS300: no data
2013.12.16 17:52:49 1: WS300: no data
2013.12.16 17:53:19 1: WS300: no data
2013.12.16 17:53:49 1: WS300: no data
2013.12.16 17:54:19 1: WS300: no data

Seltsam ist, das ich täglich exakt zwischen 17:52 und 17:54 Probleme habe, aber noch nicht weiß, wer der Übeltäter ist.
Der Fehler tritt auch auf, wenn niemand da ist.

Gruß, Ricardo

Joachim · 17 Dezember 2013, 21:13:05

DSL Zwangsreconnect?

Dirk · 17 Dezember 2013, 22:00:54

ZitatDSL Zwangsreconnect?

Das glaube ich nicht.

Ich habe dieses Verhalten vor allem Beobachtet, wenn FHEM "ausgelastet" war. Z.B. bei unten genanntem generieren von Plots, die teilweise recht lange dauerten.

@Ricardo, vielleicht kannst du versuchen dass du das verhalten mal reproduzierbar provozieren kannst.
Ich werde mir das die nächsten tage aber auch noch mal ansehen.

Gruß
Dirk

kpwg · 19 Dezember 2013, 08:41:45

Zitat von: Joachim am 17 Dezember 2013, 21:13:05
DSL Zwangsreconnect?

Nein, der liegt fix auf nachts zwei Uhr. Hätte ausserdem nix mit dem RasPi zu tun.

Zitat von: Dirk am 17 Dezember 2013, 22:00:54
Ich habe dieses Verhalten vor allem Beobachtet, wenn FHEM "ausgelastet" war. Z.B. bei unten genanntem generieren von Plots, die teilweise recht lange dauerten.

Das habe ich bereits getestet: beim Erzeugen großer Plots kommen keine Fehler. Ich habe noch gar nicht so viele Daten, um Plots >1 Monat zu erzeugen. Habe ja erst mit FHEM begonnen... $:-\$

Zitat von: Dirk am 17 Dezember 2013, 22:00:54
@Ricardo, vielleicht kannst du versuchen dass du das verhalten mal reproduzierbar provozieren kannst.
Ich werde mir das die nächsten tage aber auch noch mal ansehen.

Gruß
Dirk

Dirk, ich wüsste jetzt nicht wie. Der RasPi hier macht ausser FHEM nix anderes. Da ich gestern noch die EDV-Ecke ein wenig umgebaut habe, musster ich auch kurz alles stromlos machen. Ich beobachte jedenfalls weiter, ob sich ein Zusammenhang erklären lässt.

Gruß, Ricardo

Joachim · 19 Dezember 2013, 10:09:55

Moin Ricardo,

ZitatDSL Zwangsreconnect?
Nein, der liegt fix auf nachts zwei Uhr. Hätte ausserdem nix mit dem RasPi zu tun.

das glaubst Du aber nur, bei mir geht der Load des Pi beim Zwangsreconnect für ca. 10 min von 0,2 auf 1,5 hoch, obwohl die Fritzbox eigentlich nichts mit dem Pi zu tun hat. Kann leider keine Grafik beilegen, da auf der Arbeit.

Gruß Joachim

kpwg · 23 Mai 2014, 21:51:17

Guten Abend,

auch wenn's lange her ist, muss ich den Thead ein letztes mal wiederbeleben. Ich hatte mittlerweile 5 Monate reibungslosen Betrieb mit der WS300PC und einem KS200. Entscheidend war ein stets sehr guter Empfang des Außensensors mit möglichst wenigen Paketverlusten. Nur dann bleibt die Kommunikation am Laufen. Bei stetigen Paketverlusten geht die Kopplung des Sensors nach einiger Zeit verloren.

Das Problem mit dem stetigen "no data" hat mir das Log gut gefüllt. Ich habe es nicht weiter verfolgt.

Geholfen hat mir:
- den WS300DeviceTimer bereits in der 50_WS300.pm auf 30sec Abfrageintervall hoch zu setzen
- das "Ok" der Batteriestatusmeldung auf "ok" zu ändern, damit es zu allen anderen Sensoren passt
- nach einem Neustart von FHEM nach kurzer Zeit ein "rereadcfg" zu machen, da die Kommunikation sonst ein "timeout" bekommt

Ein sehr großes Problem war nach nun 8-tägiger Abwesenheit und komplett stromloser Technik die Wiederinbetriebnahme. Die in der WS300PC gesammelten Daten haben den RasPi mit dauerhaft 100% load belastet, so das nach wenigen Minuten sich FHEM verabschiedet hat. Durch Neustart wurden wieder ein paar Daten ausgelesen, bis erneut der Task beendet wurde. Es blieben immer 30sec Zeit, bis der Abfrageintervall "zuschlug" und die Weboberfläche unerreichbar machte.

Die FHEM Statistik sagt, das nur noch 4x WS300 in Benutzung ist. Zudem habe ich seit geraumer Zeit zwei ungenutzte CUL liegen. Lohnt es noch, sich der Problemchen anzunehmen?

Viele Grüße, Ricardo

kpwg · 24 Mai 2014, 08:52:49

Zitat von: chris1284 am 23 Mai 2014, 22:17:47
sollte der ks200 nicht wie der ks300 einfach per cul im slowrf mitgelauscht werden können?

Klar geht das- sogar deutlich besser! Wo der CUL noch mühelos empfängt, kommt an der WS300 schon lange nix mehr. Dabei habe ich schon die Antenne modifiziert,damit es überhaupt durch 2 Wände funktioniert. Ich hatte urspünglich keinen CUL, sondern nur die WS300 mit KS200. Da unternimmt man schon was, damit es ohne Zusatzkosten als Einstieg in FHEM erst mal läuft.

Dirk · 24 Mai 2014, 09:06:53

Zitat von: kpwg am 23 Mai 2014, 21:51:17
Ein sehr großes Problem war nach nun 8-tägiger Abwesenheit und komplett stromloser Technik die Wiederinbetriebnahme.

sowas habe ich auch beobachtet.
Wenn Daten im Speicher sind, muss die WS300 die Daten erst wieder abladen bevor die Übertragung stabil läuft.
Ich hab aber keine Idee wie man das fixen könnte.
Kennt jemand eine art Protokolldoku zu dem Teil?

Zitat von: kpwg am 24 Mai 2014, 08:52:49
Klar geht das- sogar deutlich besser! Wo der CUL noch mühelos empfängt, kommt an der WS300 schon lange nix mehr.

Das wiederum ist bei mir genau anders herum. Ich empfangen die Daten von meinem KS300 mit einer FHZ1300 ziemlich problemlos.
Mit dem CUL habe ich jede Menge Paketverluste. Auch mit verschiedenen Einstellungen.

Gruß
Dirk

kpwg · 25 Mai 2014, 18:59:35

Zitat von: Dirk am 24 Mai 2014, 09:06:53
sowas habe ich auch beobachtet.
Wenn Daten im Speicher sind, muss die WS300 die Daten erst wieder abladen bevor die Übertragung stabil läuft.
Ich hab aber keine Idee wie man das fixen könnte.
Kennt jemand eine art Protokolldoku zu dem Teil?

Ich weiß nicht, ob zwischen dem Empfang einzelner Datensätze sich eine Pause einfügen lässt, damit der RasPi sich zwischendurch um alles Andere kümmern kann? Warum ist das Auslesen überhaupt so prozessorlastig?

Viele Grüße, Ricardo

Edit 29.5.14: Das Problem hat sich für mich derzeit erledigt, da ich auf CUL umgestellt habe. Seit ich vor 2 Tagen einen USB-Hub und Homematic mit CUL in Betrieb genommen habe, kam die WS300 permanent aus dem Tritt. Es war mindestens jedes zweite mal Daten abholen mit "no Data" im Log vermerkt. Wenn man einen zweiten CUL liegen hat, fällt der Schritt nicht ganz so schwer

Nachteil KS300 am CUL: kein Luftdruck mehr, kein Batterietatus des KS200/300, keine Daten aus dem Zimmer der WS300PC