Oregon Wetterdaten mit Arduino in Fhem einbinden

Begonnen von Bennemannc, 21 April 2014, 12:36:30

Vorheriges Thema - Nächstes Thema

Bennemannc

Hallo,

ich wollte die Daten meiner Oregon Wettersensoren in Fhem anzeigen lassen. Als Hardware habe ich eine Arduino nano und einen 433 Mhz Empfänger (xy-mk-5V).
Im Netz habe ich einen Sketch gefunden, der (anscheinend) die Rohdaten ausgibt. Einlesen wollte ich die Daten über das RFXTRX Modul.
Wie muss der Startstring, den der Sketch sendet, aussehen damit das RFXTRX Modul einen 433Mhz Empfänger für Oregondaten richtig erkennt?
Wie müssen die Datenpakete aussehen, damit sie von dem Oregon-Modul richtig dargestellt werden ? Kann mir jemand Rohdatenbeispiele posten ?

Gruß Christoph
Cubietruck, Fhem 5.8
CC-RT-DN|LC-SW2-FM|RC-12|RC-19|LC-SW4-BA-PCB|LCp-SW1-BA-PCB|ES-PMSw1-Pl|LC-Bl1PBU-FM|PBI-4-FM|CC-VD|CC-TC|SEC-SC(2)|RC-KEY3-B|LC-Sw1PBU-FM|PB-2-FM|WDS100-C6-O|WDC7000|LC-Bl1-FM
Module: Dewpoint,FB_Callmonitor,HCS,Panstamp,at,notify,THRESHOLD,average,DOIF

Willi

#1
Zitat von: Bennemannc am 21 April 2014, 12:36:30
Hallo,

ich wollte die Daten meiner Oregon Wettersensoren in Fhem anzeigen lassen. Als Hardware habe ich eine Arduino nano und einen 433 Mhz Empfänger (xy-mk-5V).
Im Netz habe ich einen Sketch gefunden, der (anscheinend) die Rohdaten ausgibt. Einlesen wollte ich die Daten über das RFXTRX Modul.
Ich habe die Module geschrieben.

Das TRX-Modul kannst Du dazu nicht benutzen. Die dort übertragenen Bytes haben nichts mit dem propritären Rohdatenformat von Oregon zu tun, die von den Sensoren übertragen werden. RFXCOM hat dazu ein eigenes Datenformat erfunden und konvertiert in der Firmware die Oregon-Bytes in das eigene Format. Das hat den Vorteil, dass man die Hardware anderer Hersteller leicht einbinden kann. Wer einen RFXTRX kauft, kann das SDK mit der Beschreibung anfordern, verpflichtet sich aber auch im Gegenzug dazu diese Informationen nur in Verbindung eines RFXCOM-Receivers zu nutzen.
Aus Sicht von RFXCOM wäre es illegal meine Module mit anderer Hardware zu nutzen.

Die Firma RFXCOM ist eine sehr kleine Firma, die viel Aufwand in das Reverse-Engineering der Protokolle gesteckt hat. Man verdient nur Geld mit der eigenen Hardware in Verbindung mit der Firmware, die sehr viele Protokolle versteht. Dieses Geschäftsmodell könnte schnell wegbrechen, wenn jemand sich dieses Know-How einverleibt. Ich will nicht in Konkurrenz dazu treten.

Ich würde Dir daher generell empfehlen ein eigenes FHEM-Modul zu schreiben. Als Basis kannst Du andere kleinere Module nehmen und Dich langsam voranarbeiten. So habe ich vor mehreren jahren auch begonnen. Schau mal in den Developer-Thread. Informationen zum Aufbau des Bytestreams der Oregon-Protokolle findest Du leicht per Google.

Grüße

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

Bennemannc

Hallo Willi,

Danke für Deine Antwort. Dann werde ich mich wohl intensiver mit des Sache beschäftigen müssen (als mir eigentlich lieb ist).
Vermutlich ist es dann am einfachsten, das Oregon Modul zu nehmen und um zu schreiben. Ich habe zwar schon etwas Programmiererfahrung, aber Perl ist für mich immer noch sehr kryptisch.

Gruß Christoph
Cubietruck, Fhem 5.8
CC-RT-DN|LC-SW2-FM|RC-12|RC-19|LC-SW4-BA-PCB|LCp-SW1-BA-PCB|ES-PMSw1-Pl|LC-Bl1PBU-FM|PBI-4-FM|CC-VD|CC-TC|SEC-SC(2)|RC-KEY3-B|LC-Sw1PBU-FM|PB-2-FM|WDS100-C6-O|WDC7000|LC-Bl1-FM
Module: Dewpoint,FB_Callmonitor,HCS,Panstamp,at,notify,THRESHOLD,average,DOIF