QNAP NAS FHEM mit FHT + Oregon WMR928nx

Begonnen von wolfi999999, 08 März 2013, 22:56:42

Vorheriges Thema - Nächstes Thema

wolfi999999

Hallo FHEM Gemeinde,
ich bin neu in diesem Forum und habe eine Fragen zu den Möglichkeiten von FHEM.

Ich habe vor kurzem ein FS20 Heizungsregler FHT mit einem CUL an einem QNAP NAS TS119P+ zum laufen bekommen. Vielen Dank an den Beitrag mit dem Tipp die cdc-acm.ko einzubinden.
Dies funktioniert so nun seit ein paar Tagen auch problemlos.

Außerdem habe ich noch eine Wetterstation von Oregon (WMR928nx), mit den Aussensensor, Regenmesser, Windmesser und Innensensor. Die WMR928nx gibt die von den Sensoren empfangenen Messwerte über eine RS232 Schnittstelle an die Aussenwelt weiter.
Diese habe ich seit einigen Monaten mit einem RS232/Ethernet Konverter auf einem Port in meinem Netzwerk zur Verfügung und kann die Daten mit dem TS119P+ empfangen.
Dazu benutze ich derzeit ein Perlscript, dass für die serielle Schnittstelle geschrieben war. Dies habe ich auf die Ethernet Schnittstelle geändert (CPAN IO::Socket), so dass dieses Perlscript die Daten von dem RS232/Ethernet Konverter abgreift und in lesbare Werte dekodiert und dann in eine RoundRobinDatenbank und eine SQLite-Datenbank wegschreibt.

Mir ist bekannt, dass diese Sensoren über Sende- / Empfangsstationen wie RFXTXRUSB oder RFXCOM direkt an FHEM gekoppelt werden können. Dies würde jedoch eine zusätzliche Investition bedeuten.

Meine Frage geht jetzt in die Richtung: Ich habe ja alle Daten schon auf dem TS119P+ verfügbar. Ist es mit einem erträglichen Programmieraufwand möglich diese Daten so in das FHEM Paket einzuschleusen, als würden diese Daten direkt von den Sensoren kommen; sprich über eine der Sende- / Empfangsstationen wie RFXTXRUSB oder RFXCOM.

Wo wäre ein Ansatz dazu. Ich muss dazu sagen ich bin kein ausgewiesener Perl - Programmierer habe aber dann schon die Geduld mich auch in so was einzuarbeiten.

Willi

Hallo,

ich habe die Modulserien RFXCOM, TRX und USBWDE1 geschrieben.

In dieser Untergruppe tummeln sich eigentlich nur die Leute, die entweder einen RFXtrx433 haben oder einen kaufen wollen. Eine Integration der seriellen Schnitstelle in die Module RFXCOM oder TRX macht m.E. keinen Sinn, da die Übertragsverfahren (Übertragung der Daten an FHEM) sehr unterschiedlich ist. RFXCOM hat ein eigenes Protokoll für Multiprotokollübertragungen festgelegt, was aber nichts mit Oregon zu tun hat.

Du müßtest m.E. ein komplett neues FHEM-Modul schreiben.

Als ich mich damals entschlossen habe die Module RFXCOM zu schreiben und später TRX und USBWDE1, habe ich mir ein paar Module angesehen und versucht diese zu verstehen. Dann habe ich eines kopiert und es nach und nach geändert. Perl ist eigentlich auch nicht meine favorisierte Programmiersprache, aber FHEM ist nun mal in Perl geschrieben.

Eine wirkliche Anleitung gibt es dazu m.E. nicht. Es gibt aber die Development-Guidelines, in denen einiges beschrieben ist: http://www.fhemwiki.de/wiki/DevelopmentGuidelines

Ich würde an Deiner Stelle in der Untergruppe FHEM-Develeopment die Frage stellen, welches Modul als Vorlage für Dein Modul am besten passt und es dann entsprechend angehen.

Der Grund FHEM zu verwenden war damals auch, dass ich eine Oregon-Wetterstation hatte (WMR100). Nach einigen Basteleien mit einer eigenen Auswertung über die USB-Schnittstelle der WMR100-Konsule unter Unix, habe ich mich dann für den RFXCOM-Receiver (jetzt RFXtrx433) entschieden, weil ich so auch billigere Oregon-Sensoren nutzen kann, die mit der WMR100 nicht funktionieren.

MfG Willi
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433