Suche Erfahrungsaustausch zum Modul WS2000 - wer nutzt es noch?

[Pfriemler]

Moinsen!
Laut http://fhem.de/surveyresults.html gibt es noch mindestens 18 WS2000-Nutzer ... ich rede von dem gleichnamigen Modul von T. Dressler, welches den längst nicht mehr erhältlichen WS/FS10(?)-Empfänger zum Direktanschluss an einen seriellen Port ausliest und die Daten der Sensoren in Readings darstellt.
Ich habe diese Platine, unter Umgehung des dort verbauten MAX232, direkt mit einer einfachen Pegelanpassung am seriellen Port auf dem GPIO des Raspi am Laufen, die Platine wird auch vom Raspi gespeist, ist sehr praktisch so. Ich bekomme nun die Daten von 9 von 11 teilweise sehr veralteten Sensoren (der Empfang ist sehr standortabhängig wegen einer grottigen Empfindlichkeit der Empfänger), von denen ich vor Jahresfrist nur die wenigsten mit einem CUL433 empfangen hätte - anscheinend hat man ihm inzwischen die veralteten Protokolle der 1.1er-Sensoren nachgerüstet. Aber ich habe derzeit noch keinen CUL433.

Da das Modul nicht mehr weiterentwickelt wird, muss ich mich um eine Anpassung der Daten wohl selbst kümmern. Denn die derzeitige Ausgabe ist für ein sparsames Logging und eine SVG-Auswertung recht ungeeignet, wie ich finde. Ich könnte mir jetzt eine anpassende Sub selbst schreiben oder direkt Hand am Modul 87_ws2000 anlegen (lokal, da eine globale Änderung per SVN etablierte Nutzer sicher sehr verärgern würde).
Vielleicht hat aber schon jemand eine anpassende Sub geschrieben, die ich nachnutzen könnte.

Konkret würde ich gern die RAW-Messages komplett unterdrücken und das wirklich gut gemeinte Klarschriftdesign etwas anpassen, also etwa aus
I7 => T:22.9 C, H:37 %, D:1007 hPa lieber so etwas wie I7 T: 22.9 H: 37 D: 1007
oder statt W7 => S:7.8 km/h, BF:2(leichte Brise) ,R:355 Grad(N) +/-0 lieber W7 S: 7.8 R: 355 0 (Beaufort halte ich für komplett entbehrlich für's Logging) machen, was sich ohne Kopfstände in SVGs leichter zur Anzeige definieren lässt. Einheiten gibt's ja dann dort, und fürs Frontend würde ich die lieber z.B. per userReading wieder lesbarer machen.

Auch sonstige Erfahrungen, Wünsche, etc. wären mir sehr willkommen. Man darf mir auch gern mitteilen, warum und in welche Richtung man sich von den alten Dingern verabschiedet hat. Aber meine Sensoren sind wie alte VW Käfer: sie laufen, und laufen, und laufen, und laufen ....

[Pfriemler]

Ich habe mal ein bisschen bei den KS300- &Co-Definitionen geschaut und bin dann mal mutig an die Code-Modifikation gegangen. Demnach würde es ja wohl Sinn machen, die Bezeichnungen einheitlicher zu gestalten, also T: für temperature, H: für humidity, AP: für airpressure, W: für Wind, WD: für wind direction, WDR: wind direction range, B: für brightness und R: für Rain zu verwenden - und wenn betateilchen erst 2014 den Wi: wind index im KS300 nachgerüstet hat, natürlich auch hier.

Nebenbei habe ich durch Deaktivierung der sub WS2000_set auch keine "=> No Set function (?) implemented"-Fehler mehr im Log, wenn man die Moduldefinition zur Bearbeitung im Fenster offen hat.


Statt diesen Originmeldungen (mein Device habe ich MWS genannt):

Code Auswählen Erweitern

2015-04-30_15:55:29 MWS I7 => T:23.1 C, H:34 %, D:1005 hPa
2015-04-30_15:55:29 MWS RAW => Typ:79,W1:1,W2:103,W3:34,W4:7,W5:109
...
2015-04-30_15:56:02 MWS TH3 => T:19.9 C, H:38 %
2015-04-30_15:56:02 MWS RAW => Typ:27,W1:1,W2:71,W3:38,W4:0,W5:0
...
2015-04-30_15:56:11 MWS L7 => L:58300Lux
2015-04-30_15:56:11 MWS RAW => Typ:95,W1:4,W2:71,W3:2,W4:12,W5:66
...
2015-04-30_15:56:34 MWS R7 => M:937.21 l/m2(2533 Imp x Faktor 370), C:2533, P:0
2015-04-30_15:56:34 MWS RAW => Typ:47,W1:19,W2:101,W3:0,W4:0,W5:0
...
2015-04-30_15:57:03 MWS W7 => S:0 km/h, BF:0(Windstille) ,R:355 Grad(N) +/-0
2015-04-30_15:57:03 MWS RAW => Typ:63,W1:0,W2:0,W3:0,W4:2,W5:99


wirft das Modul jetzt also (ebenfalls beispielhaft)

Code Auswählen Erweitern

2015-04-30_16:55:54 MWS R7 R: 937.21
2015-04-30_16:56:24 MWS TH7 T: 19 H: 38
2015-04-30_16:56:33 MWS L7 B: 7840
2015-04-30_16:57:24 MWS I7 T: 23 H: 35 AP: 1005
2015-04-30_16:57:44 MWS W7 W: 0 Wi: 0 WD: 355 WDR: 0

aus, ähnlich der Summary-Zeile des KS300. Die einzelnen Werte lassen sich so bequem mit der "Input Column" in der SVG-Definition auswählen.

Ebenfalls funktioniert jetzt - warum auch immer - die Event-Erzeugung für readingsGroup und notify - bislang sammelte eventTypes nichts, warum auch immer.

to be continued ...

[phantom]

Hi,

hier ist ein Nutzer des 14_CUL_WS.pm  Ich wollte damit übe rein CUL433 die Sensoren der (alten) ELV-Wetterstation einlesen. WS2000/WS2500/WS7000 mit S2000I, S2000IA, S2000A, WS7000ID sowie den Wind- und den Helligkeits- den Regensensor. Die Sensoren laufen bisher an einem WS2500PC-Interface am alten WinXP-Rechner.

Das 14_CUL_WS.pm liest im Original nur über die Sensornummer die Thermo-/Hygrosensoren 1 bis 8 ein. Daher habe ich ein wenig am Modul rumgebastelt und die anderen 4 Sensoren über den Sensortyp hinzugefügt.

Als Newbie mit FHEM und PERL ist dies sicher nicht perfekt, aber bis auf den Regensensor klappt es erstmal.

Wenn ist raus habe, wie man hier Codeschnipsel einstellt oder Attachments, kann ich meine Versuche auch bereitstellen ....           (ist 'halt der erste Besuch in diesem Forum)

[phantom]

Nachtrag,

das WS2000-Modul ist sicherlich besser im Empfang, da meine derzeitige Lösung mit CUL433 und CUL_WS  recht häufig Telegramme der Wettersensoren unterschlägt. Das liegt wohl am CUL433, der bekommt schnell hintereinander kommende Telegramme nicht mit. Ich habe einen ELV-WS2000-Repeater im Einsatz; evtl. ist der CUL433 damit überfordert??

Für das WS2000 bräuchte ich einen neuen Atmel AT89C2051 mit der Firmware ELV00185 für den erforderlichen Wettersensor-Testempfänger; aber den finde ich leider nirgendwo mehr 

Oder gibt es evtl. eine Anbindung des WS2000PC-Empfängers an FHEM ?
...

[rabbe]

Hallo,

hört sich interessant an. Ich benutze zur Zeit die V 1.04.00 a-culfw. Ich hatte auch mal diese von hier http://forum.fhem.de/index.php/topic,24436.75.html. Die erkannte auch die Sensoren mit den alten Protokoll. Hast du mit deinen Veränderungen die Beschränkungen, was die Sensoranzahl betrifft aufgehoben? Ansonsten wird ja unter Sensor 8 auch ein Reading für den Wind-, den Regen und den Helligkeitssensor neben den T/H(/P)-Sensor hinzugefügt. Ich habe ja mehrere T/H/P-Sensoren, was bei Benutzung des WS2000PC-Interfaces die Nutzung von max. 16 Sensoren, 8 T/H und 8 T/H/P, zulässt. Beim CUL-Modul funktionieren ja leider nur 8, deshalb bin ich teilweise auf 868MHz ausgewichen bzw. nutze TX3-Sensoren, welche den Nachteil haben, dass diese keine feste Kodierung haben.

[phantom]

Hi raabe,

zur Erweiterung über die 8 Temp/Hum-ensoren hinaus, habe ich kurzerhand die 4 Wind- / Brightness- / Temp+Hum+Pressure- / Rain - Sensoren fest auf die CUL_WS_Nummern 9-12 gelegt. Ich habe je nur einen dieser Typen. Ein 'diff' der angehängten 14_CUL_WS.pm mit dem Original zeigt die "einfachen" Änderungen. Sieht dann in FHEM so aus:

CUL433 Initialized
CUL_WS_1 - Dach T: 22.1 H: 20
CUL_WS_10 - Regen R: 25
CUL_WS_11 - Wind W: 20.3 D: 260 A: 1
CUL_WS_12 - Helligkeit B: 32
CUL_WS_2 - Terrasse T: 16.4 H: 79.3
CUL_WS_3 - Kaminzimmer T: 23.7 H: 39.7
CUL_WS_4 - Aussen T: 23.0 H: 43.6
CUL_WS_5 - Wellness T: 24.4 H: 52.7
CUL_WS_6 - Dusche T: 24.0 H: 54.8
CUL_WS_7 - Lüftung T: 23.7 H: 0
CUL_WS_8 - Kühlschrank T: 14.9 H: 0
CUL_WS_9 - Schlafzimmer T: 21.1 H: 45 P: 1010

Als CUL-Firmware habe ich die "V 1.65 CUL433" geladen. Mit anderen Firmwareversionen habe ich keine Erfahrung. Die Spezialfirmware werde ich nächstes WE mal probieren.

Zum Empfang habe ich mal das probiert:
CUL433 ccconf => freq:433.920MHz bWidth:232KHz rAmpl:38dB sens:12dB
bringt aber nicht wirklich mehr Empfang (unabhängig von der Entfernung zum CUL am RasPi).

Dirk

[rabbe]

Hallo Dirk,

das wäre ja immerhin ein Zugewinn von einen Temperatursensor.  Deine Änderung kommt meiner Wunschvorstellung aber schon etwas näher, 9-16 für die T/H/P-Sensoren und 17-19 für Regen, Wind und Helligkeit zu den bisherigen 8 Sensoren.
Ich verwende bei 433MHz folgende Einstellungen

freq:433.920MHz bWidth:406KHz rAmpl:42dB sens:8dB

mit der oben genannten Firmware http://forum.fhem.de/index.php/topic,35064.0.html. Es kann Einbildung sein, aber im Gegensatz zur vorher genutzen V1.61 hat sich der Empfang verbessert und ist zuverlässiger geworden. Ich benutze als Antenne eine GP433 http://www.winklerantennenbau.de/gp868.htm. Am kritischsten sind bei mir der Aussensensor, ca. 30m durch mehrere Wände und der in der Garage (ca.75m Luftlinie, wenig Hindernisse, Wände).

rabbe

PS: Irgendwie ist dein Anhang verloren gegangen.

[Pfriemler]

Irgendwie bin ich leicht erschüttert, dass mein Beitrag von gestern komplett verschwunden ist ...

Ich wollte eigentlich nur kurz anmerken:
a) Dieses alte ELV-Empfangsmodul ist praktisch nicht mehr zu bekommen. Ein Ersatzprozessor wäre nett, zumal die Hardware drumrum ja wirklich übersichtlich ist. Als Funkempfänger nutze ich einen aus einem überzähligen WS2000PC (3-V-Empfänger, hier mit leichter Spannungsreduzierung auf 4V statt der sonst üblichen 5V) - das Modul empfängt trotz vieler Justageversuche einfach besser (ist aber in jedem Fall eines von den älteren billigen, leider).
b) Telegramme kriege ich hier teilweise 3 in einer Sekunde, kein Problem. Reichweiten sind aber, s. a), sehr lausig, kriege den Außensensor in 10 m nicht mehr. 75 m - da träume ich von ...
c) Von einer Unterstützung des WS2000PC-Moduls weiß ich nichts. Es gab da mal was, aber wenn es brauchbar gewesen wäre, hätte ich sicher nicht ein halbes Jahr auf meine Platine gewartet ...
d) CUL würde ich nun auch gern probieren, mal sehen, vielleicht kann ich irgendwo mal einen günstig schießen.

Abgesehen davon ist der Wettersensorempfang per CUL eigentlich nicht Thema dieses Threads. Ich hatte aber nach Alternativen gefragt, insofern - danke!

[phantom]

@Pfriemler:
wenn ich dich richtig verstehe, kommen dein WS2000-Daten über den nicht mehr verfügbaren ELV-Testempfänger in das FHEM-System.
falls sich doch noch irgendwo so einer auftreiebn läßt, oder zumindest der Atmel-Chip darsu, werde ich das auch mal versuchen

@raabe:
ich versuche es nochmal mit dem Dateianhang 14_CUL_WS.pm (modifiziert)
wenn weiter Interesse am CUL_WS da ist, könntest Du ggf. heraus einen neuen Thread  "WS2000 mit CUL_WS" machen

Dirk

[rabbe]

Hallo Dirk,

erst einmal recht vielen Dank für dein modifiziertes File. Ich habe mir es auch gleich mal angeschaut und verglichen. Deine Änderungen kann ich auch halbwegs nachvollziehen, soweit es in meiner Ahnungslosigkeit, was Programmierung betrifft, möglich ist.
@Pfriemler hat ja im Grunde genommen nichts dagegen, dass der Thread genutzt wird. Kann man den Threadtitel eigentlich noch ändern, erweitern.
Das hatte ich noch vergessen, nur der T/H/P-Sensor mit Kodierung 8 wird richtig als Sensortyp 4 erkannt, die anderen als Sensortyp 7.     

[rabbe]

Hallo Dirk,

ich habe dein modifiziertes File getestet. Der Regensensor wurde angelegt und auch WS_9, wobei sich hier meine verschiedenen T/H/P-Sensoren mit den oben beschriebenen Unterscheiden im gleichen File verewigt haben, der mit Kodierung als Typ 4 und die anderen als Typ 7.

[phantom]

Hallo rabbe,

es werden NUR die Temperatur/Humidity-Sensoren 1-8 (im Standard-Modul) und danach fest-verdrahtet 9-12 für die anderen Sensortypen abgefragt. Temp/Hum-Sensoren von 9-16 landen ggf. auch auf den Plätzen 1-8.
Wie hast du denn einen WS2000-Sensor auf eine Nummer von 9-16 umstellt? Die Jumper darin lassen doch nur 1-8 zu, oder?

Zur Analyse welcher Sensor wo landet, kann du mit  "attr CUL433 verbose 5" die Empfangsdaten loggen (Auch für CUL_WS_8, da landet stets der letzte Temp/Hum).
Wenn ich einen Sensor auf 9-16 umstellen könnte, ließe sich dessen Nummer/Typ herausfinden (vermutlich hex 9 - F)

[rabbe]

Hallo Dirk,

auf WS_09 landeten quasi alle T/H/P-Sensoren mit ihren Werten, obwohl der Druckwert nur bei dem mit Kodierung 8 übertragen wurde.

Kurzer Mitschnitt von Kodierung 4 und Kodierung 8

2015-06-03_17:21:37 CUL_WS_9 T: 20.8  H: 53.9 D: 11.1 A: 9.8
2015-06-03_17:23:39 CUL_WS_9 T: 21.6  H: 66.7  P: 994 D: 15.1 A: 12.7
2015-06-03_17:24:20 CUL_WS_9 T: 20.8  H: 53.9 D: 11.1 A: 9.8
2015-06-03_17:26:20 CUL_WS_9 T: 21.6  H: 66.7  P: 994 D: 15.1 A: 12.7

Ähnlich verhält es sich, wenn man einen ASH2000 und einen T/H/P-Sensor mit der gleichen Kodierung gleichzeitig in Betrieb hat. Bei den Readings wechseln dann die Werte entsprechend (Sensortyp etc.). Dieses Problem tritt auch auf, wenn man gleiche Sensortypen, z.Bsp. ASH2000 und ASH2200 verwendet. Dies kann man aber umgehen, da es "attr IODev" gibt und man die verschiedenen CULs (Frequenzen) auswählen kann. Keine Ahnung, aber vielleicht wäre eine Möglichkeit, eine Art "attr Sensortyp" oder ähnliches in Analogie dazu.
Wie gesagt, ich habe absolut keine Ahnung von Programmierung, aber das ist doch der entsprechende Code für "attr IODev"?

CUL_WS_Attr(@)
{
  my @a = @_;

  # Make possible to use the same code for different logical devices when they
  # are received through different physical devices.
  return if($a[0] ne "set" || $a[2] ne "IODev");
  my $hash = $defs{$a[1]};
  my $iohash = $defs{$a[3]};
  my $cde = $hash->{CODE};
  delete($modules{CUL_WS}{defptr}{$cde});
  $modules{CUL_WS}{defptr}{$iohash->{NAME} . "." . $cde} = $hash;
  return undef;
}