Projekte mit ELV-WS300-Series Empfängern

Seit geraumer Zeit gibt es von ELV Wetterstationen und Sensoren, die im 868Mhz-Band senden. Diese Serie wird bei ELV mit WS300, bei Conrad mit WS555 bezeichnet. Damit kann man bis zu 8 externe Temperatursensoren der Typen S300TH,ASH2000,PS50 usw., einen Kombsensor(KS200/300) und den eingebauten Innensensor der WS300(Temperatur+Luftdruck) nutzen. Der Kombisensor kann Windgeschwindigkeit, Regenmenge und Temperaturdaten senden (KS300).

S300THPoolsensor PS50

Eine Erfassung der Windrichtung oder der Helligkeit wie beim WS2500-System ist nicht vorgesehen. Für die Nutzung mit dem PC sind der Datenlogger WS300PC und der InternetWetterEmpfänger IPWE1, seit März 2009 der USB-Empfänger WDE1 sowie ab April 2012 auch der Wetter- und FS20-Empfänger FS20WUE vorgesehen.

WS300PC

Die WS300PC ist eine im Display abgespeckte Version der WS300, aber mit USB Interface und wird mit einer Software für Windows (WeatherProfessional) geliefert, welche die Daten in einer lokalen Postgresql-DB ablegt. Die USB-Schnittstelle ist mit einem Standard-FTDI-Chip ausgestattet, allerdings ist, wie bei ELV üblich, das Schnittstellenprotokoll nicht offengelegt. Einige findige Bastler haben aber mittlerweile funktionierende Alternativlösungen im Internet veröffentlicht.
WS300PC

IPWE1

Der Wetterempfänger IPWE1 kann die gleichen externen Sensoren empfangen, hat aber keine eigenen Sensoren wie die WS300PC. Im Kern besteht er aus einer ARM7-Referenzimplementation mit Empfängermodul und Ethernetschnittstelle. Zur Übermittlung der empfangenen Daten wurde ein Mini-Webserver und ein Telnetinterface vorgesehen. Dazu wurden offenbar Komponenten aus der Entwicklungssuite von KEIL verwendet. Das Webinterface besitzt eine Statusseite mit allen aktuellen Messwerten sowie eine Historie für die letzten 5 Messwerte. Weiterhin können die Netzwerkkonfiguration (DHCP oder Statisch) und Namen für Sensoren eingestellt werden. Mehr nicht. Insbesondere kann das Layout nicht an den eigenen Geschmack angepasst werden.
Das Telnetinterface wird als "Highlight für Homeautomatition" angepriesen, ist aber meiner Meinung nach für diesen Zweck nur seeehr bedingt brauchbar. Zum einen muss man einen TelnetClient fernsteuern, der auch die Steuerzeichen versteht, dann kann man Kommandos nicht einfach automatisch absetzen, sondern muss pro Zeichen eine Pause von ca. 100ms machen und zuletzt werden einige Parameter und Ergebnisse als Binärzahlen erwartet und zurückgegeben. Das führt wiederum zur Kollision mit dem Telnetprotokoll, so das z.B. die Abfrage des Sensors 3 nachvollziehbar die Verbindung beendet. Bei Interesse kann ich ein Testprogramm in Perl anbieten. Eine Einfache TCP oder UDP-Connection wäre wesentlich einfacher gewesen.
Es ist nicht vorgesehen, die Firmware zu aktualisieren. Da aber alle dafür notwendigen Pins auf Steckerleisten geführt werden, kann man das Gerät wenigstens als günstiges ARM7-Entwicklungsplattform nehmen, wenn man nicht alle Ports des ARM braucht.
IPWE1
IPWE1 innen
IPWE1 Web Oberfläche
Ich habe ein einfaches Programm geschrieben, mit dem man die Status-Webseite automatisiert auslesen, mittels verschiedener regulärer Ausdrücke geparst und die Daten dann direkt oder über eine Textdatei weiterverarbeiten kann.
IPWE1 Gui
Das gleiche Prinzip wird auch bei meinem Modul IPWE1 WS300Series-Modul für IPSymcon angewendet. Das Programm mit einer GUI ipwe1gui.exe und eine reine Kommandozeilenversion für Windows ipwe1.exe kann man downloaden.

Auch mit dem beliebten Mini-Computer Raspberry Pi oder anderen Linux/Unix/Windows basierten Hosts kann man diese Technik dank der portablen Programiersprache Perl nutzen und die Daten des ipwe1 in ein Logfile schreiben. Dazu verwende dieses Script. Dieses Script kann z.B. unter /root als ipwe1_reader.pl auf dem raspberry abgespeichert werden.

# usage: ipwe1_reader.pl <host> <port> <logfile>
# Example: perl ipwe1_reader.pl 192.168.178.15 80 ipwe1.log
Um die Abfrage regelmäßig durchzuführen verwende ich den cron-daemon. Auf dem Raspberry reicht es aus, eine Datei in /etc/cron.d anzulegen, wenn man das Script wie oben beschrieben unter root abgelegt hat:
# run it in crontab by placing a file with the folowing contentin /etc/cron.d every 5min:
*/5 * * * * root /usr/bin/perl /root/ipwe1_reader.pl 192.168.178.15 80 /root/ipwe1.log

WDE1

Der Wetterdaten-Empfänger WDE1 (siehe ELV-Journal 2/2009) ist im Gegensatz zu den bisherigen Empfängern für eigene Entwicklungen konzipert. Er besteht aus einer Empfangseinheit mit ATMega-Prozessor und einen abtrennbaren! USB-Seriellwandler mit Cyprus Chipsatz, welcher von Linux und von Windows unterstützt wird. Der WDE1 hat keinen eigenen Puffer, sondern sendet wie der ELV-Wetterdatenempfänger unmittelbar nach dem Empfang die Daten, aber in einem textbasierten, mit Semikolon getrennten "OpenLog"-Format. Die Auswertung ist deshalb besonders einfach. Nacteilig ist, das Konsolenprogramme immer die Schnittstelle pollen müsen, was zu einer hohen CPU-Last führt. In Windows kann man Events nutzen. Beispielhaft dafür habe ich ein Kommandozeilenprogramm und eine Gui-Version erstellt, welche die gleiche Logdatei wie für den IPWE1 erstellen.
(10.09.2010: mit Fix für negative Temperaturen)
WDE1
WDE1 innen
WDE1 GUI

Wie beim ipwe1 kann man auch den wde1 mit dem Raspberry Pi auslesen und die Daten in ein Logfile schreiben. Da der WDE1 über einen standard USB Seriell Chip verfügt, dessen Treiber auf Linux idR. verfügbar ist, kann man den wde1 wie einen seriellen Port z.B. unter /dev/ttyUSB0 ansprechen. Dazu verwende dieses Script. Dieses Script kann z.B. unter /root als wde1_reader.pl auf dem raspberry abgespeichert werden. Um mir den Teil der seriellen Programmierung zu sparen, verwende ich zusätzlich das Linux-Programm socat, was ggflls erst noch nachinstalliert werden muss
Das Programm läuft in einer Endlosschleife und wartet auf die daten vom wde1. Diese werden dann in das gleiche Logformat wie bei der Windows Kommandozeilenversion transformiert.

#install socat as root on raspberry
aptitude update
aptitude install socat
# usage: wde1_reader.pl <device>  <logfile>
# Example: perl wde1_reader.pl /dev/ttyUSB0 wde1.log
Um das Programm permanent im Hintergrund unbeaufsichtigt laufen zu lassen, kann man folgendes Start-Script verwenden
#!/usr/bin/bash
nohup /usr/bin/perl wde1_reader.pl /dev/ttyUSB0 /root/wde1.log </dev/null >/root/wde1_reader.out &
echo $! >/root/wde1_reader.pid
Zum Stoppen muss man dann lediglich den Prozess mit der Prozess-ID in wde1_reader.pid beenden.

FS20WUE

Der bisher letzte Empfänger für die WS300 Serie ist der FS20WUE-Bausatz (ELV-Journal 2/2012), mit dem man die Daten von WS300 Wettersensoren und von FS20 Sendern empfangen kann. Er besteht aus einem Superhet-Empfänger und einer gleich grossen Prozessorplatine. Als Datenausgang wurde eine serielle Schnittstelle mit Digital-Pegel (je nach Versorungsspannung 3,3V oder 5V) vorgesehen. Die Einzelteile werden im Sandwich-Prinzip übereinander verbunden. Man kann nun den Ausgang direkt an einen ebenfalls günstig erhältlichen USB-Wandler (z.B ELV UM2102) mit 4 Drähten anschliessen und den FS20WUE damit auch direkt über die USB-Spannung versorgen.

FS20 WUE mit USB-Platine

Das Gerät empfängt in der default Einstellung gar nichts.Der Datenempfang muss erst mit einem Befehl aktiviert werden.
Über diese Konfigurationsbefehle kann man einstellen, dass Daten sofort gesendet werden oder bis zu 9 empfangene Datenpackete gespeichert und auf Befehl abgerufen werden können.Das Vorhandensein von gespeicherten Packeten wird am zugeordneten (FS20 bzw. Wetterdaten) LED-Ausgang signalisiert. Diese Einstellungen des Sendeverhaltens gibt es getrennt für FS20 und Wetter-Empfang. Außerdem kann das Gerät in einen Schlafmodus versetzt werden.
Im Speichermodus muss man die Daten nacheinander explizit abholen. Es gibt neben dem default Binärmodus auch einen Text Modus, bei dem die Packete als dekodierter Text ausgegeben werden
Die Default Übertragungsrate ist 4800. Die kann man zwar ändern, aber nach dem Neustart sind diese und die anderen Einstellungen wieder weg, man muss also neu konfigurieren.
Softwareseitig wird ein Binär-"Protokoll" verwendet, das mM. nach keins ist. Es gibt ein Startbyte wie bei allen ELV-Produkten, aber das kann auch innerhalb der Daten vorkommen. Es gibt kein festes Ende und auch Nullbytes sind zulässig. Wenn es bei der Übertragung via USB zu Problemen kommt, ist es schwer wieder auf den Frame zu syncronisieren, wenn die Daten zu schnell hintereinander kommen. Das Textformat ist wegen der Auslegung auf "human readable" auch wenig zur automatischen Auswertung geeignet.

Für den FS20WUE habe ich ebenfalls ein Modul für IPSymcon geschrieben.


Index
Disclaimer
© 2008-2013 Thomas Dreßler
Alle Rechte vorbehalten
letzte Änderung 08.06.2013