Neue Modul TRX* für RFXCOM RFXtrx433 transceiver

[Sini]

                                                         

Hallo Willi,

ich hatte mir ja auch überlegt, aus "Log 1..." einfach "Log 4..." zu
machen, geht halt beim nächsten Update vom Modul wieder verloren.

Vielen Dank für deine Mühe, das neue Modell zu integrieren. Wäre es
vielleicht dennoch eine Idee, das Ganze auf default "Log 4.." zu stellen?
Sollte jemand ein unbekanntes Gerät einsetzen wollen, dann kann man ja mit
Verbose 4 immer noch das Ergebnis geloggt bekommen...


Grüße...


Sini

Am Mittwoch, 7. November 2012 21:28:16 UTC+1 schrieb Willi:
>
> Am Mittwoch, 7. November 2012 20:17:26 UTC+1 schrieb Sini:
>
>> Hallo Willi,
>>
>> ich nutze das Modul seit ein paar Tagen, alle meine Oregon-Sensoren
>> funktionieren einwandfrei.
>>
>> Allerdings habe ich das Problem, dass wohl in der Nachbarschaft ein
>> unbekanntes Gerät vorhanden ist, welches mir alle 40 Sekunden einen
>> Log-Eintrag beschert:
>>
>> 2012.11.07 20:10:42 1: RFX_WEATHER: common_temp error undefined subtype=0a
>>
>> Gibt es eine Möglichkeit, diese Ausgabe zu unterbinden?
>
>  
> Hallo Sini,
>
> tja, leider war RFXCOM fleissig und hat neue Sensoren impelementiert
>
> Dein Nachbar hat einen "TFA 30.3133"-Sensor.
>
> Damit es schnell geht, einfach in 46_TRX_WEATHER.pm die Zeile 486 wie
> folgt auskommentieren:
> #Log 1,"RFX_WEATHER: common_temp error undefined subtype=$subtype";
> und FHEM oder das Modul neu starten.
>
> Ansonsten habe ich gerade den Sensor im Modul implementiert. Sollte also
> nach dem morgigen Update verfügbar sein. Dann kannst Du nach einem Update
> entweder den Sensor mitverwenden (ween es ein Aussensensor ist) oder per
> ignore-Attribut ignorieren.
>  
> MfG Willi
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Am Mittwoch, 7. November 2012 21:34:39 UTC+1 schrieb Sini:

> Hallo Willi,
>
> ich hatte mir ja auch überlegt, aus "Log 1..." einfach "Log 4..." zu
> machen, geht halt beim nächsten Update vom Modul wieder verloren.
>
> Vielen Dank für deine Mühe, das neue Modell zu integrieren. Wäre es
> vielleicht dennoch eine Idee, das Ganze auf default "Log 4.." zu stellen?
> Sollte jemand ein unbekanntes Gerät einsetzen wollen, dann kann man ja mit
> Verbose 4 immer noch das Ergebnis geloggt bekommen...
>

Da schwanke ich. Ich finde es eigentlich gut, wenn man erkennt, dass es
neue Sensoren gibt.

Evtl. wäre ja auch eine Lösung für diese Sensoren ein Gerät mit dem Namen
TRX_UNKNOWN_ID zu generieren.
Dann sieht man, dass da ein neues Gerät ist, welches nicht implementiert
ist. Andererseits werden die Daten geloggt und wenn man will kann man es
mit dem Attribut ignore ignorieren.

Was hälst Du davon?

MfG willi

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[WiKa]

                                               

Halli Sini,

OT
welche Oregon Sensoren und in welcher Anzahl hast Du in Betrieb?
Ich bin zur Zeit noch auf der Suche nach 4 kostengünstigen Sensoren für
Temp und Feuchte.

Gruß,
WiKu

Am Mittwoch, 7. November 2012 20:17:26 UTC+1 schrieb Sini:
>
> Hallo Willi,
>
> ich nutze das Modul seit ein paar Tagen, alle meine Oregon-Sensoren
> funktionieren einwandfrei.
>
> Allerdings habe ich das Problem, dass wohl in der Nachbarschaft ein
> unbekanntes Gerät vorhanden ist, welches mir alle 40 Sekunden einen
> Log-Eintrag beschert:
>
> 2012.11.07 20:10:42 1: RFX_WEATHER: common_temp error undefined subtype=0a
>
> Gibt es eine Möglichkeit, diese Ausgabe zu unterbinden?
>
>
> Grüße...
>
> Sini
>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Sini]

                                                         

Die Idee ist auch gut und man "sieht" die unbekannten Sensoren ohne
weiteres Zutun...

Also von mir ein klares "Ja, gerne"...

Und danke dafür...

Eine Frage noch: Du wusstest ja sofort, welcher Sensor da Daten schickt.
Auf der Homepage von RFXCOM ist die Beschreibung ja eher dünn, daher meine
Frage, ob du diese Liste zur Verfügung stellen kannst? So könnte man
schneller prüfen, welche Geräte genau unterstützt werden?


Grüße...

Sini


Am Mittwoch, 7. November 2012 21:39:25 UTC+1 schrieb Willi:
>
> Am Mittwoch, 7. November 2012 21:34:39 UTC+1 schrieb Sini:
>
>> Hallo Willi,
>>
>> ich hatte mir ja auch überlegt, aus "Log 1..." einfach "Log 4..." zu
>> machen, geht halt beim nächsten Update vom Modul wieder verloren.
>>
>> Vielen Dank für deine Mühe, das neue Modell zu integrieren. Wäre es
>> vielleicht dennoch eine Idee, das Ganze auf default "Log 4.." zu stellen?
>> Sollte jemand ein unbekanntes Gerät einsetzen wollen, dann kann man ja mit
>> Verbose 4 immer noch das Ergebnis geloggt bekommen...
>>
>
> Da schwanke ich. Ich finde es eigentlich gut, wenn man erkennt, dass es
> neue Sensoren gibt.
>
> Evtl. wäre ja auch eine Lösung für diese Sensoren ein Gerät mit dem Namen
> TRX_UNKNOWN_ID zu generieren.
> Dann sieht man, dass da ein neues Gerät ist, welches nicht implementiert
> ist. Andererseits werden die Daten geloggt und wenn man will kann man es
> mit dem Attribut ignore ignorieren.
>
> Was hälst Du davon?
>
> MfG willi
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Sini]

                                                         

Hallo WiKu,

also richtig günstig sind die Oregon-Sensoren nicht, aber sie scheinen im
Vergleich zu den wirklich billigen Sensoren genauer zu sein...

Also ich hab folgende Sensoren:

1x THGN 500 (Außensensor)
1x THGR 122N
1x THGR 228N
1x THGR 122NX

Die Sensoren 1 + 2 Waren bei der Wetterstation dabei, den Rest habe ich
nachgekauft. Trotz der hohen Sendehäufigkeit halten die Batterien lang,
also die im Außensensor jetzt schon seit zwei Jahren, und das auch bei
wirklich tiefen Temperaturen...

Ich würde die jederzeit wieder kaufen...


Grüße...


Sini

Am Mittwoch, 7. November 2012 21:40:10 UTC+1 schrieb WiKa:
>
> Halli Sini,
>
> OT
> welche Oregon Sensoren und in welcher Anzahl hast Du in Betrieb?
> Ich bin zur Zeit noch auf der Suche nach 4 kostengünstigen Sensoren für
> Temp und Feuchte.
>
> Gruß,
> WiKu
>
> Am Mittwoch, 7. November 2012 20:17:26 UTC+1 schrieb Sini:
>>
>> Hallo Willi,
>>
>> ich nutze das Modul seit ein paar Tagen, alle meine Oregon-Sensoren
>> funktionieren einwandfrei.
>>
>> Allerdings habe ich das Problem, dass wohl in der Nachbarschaft ein
>> unbekanntes Gerät vorhanden ist, welches mir alle 40 Sekunden einen
>> Log-Eintrag beschert:
>>
>> 2012.11.07 20:10:42 1: RFX_WEATHER: common_temp error undefined subtype=0a
>>
>> Gibt es eine Möglichkeit, diese Ausgabe zu unterbinden?
>>
>>
>> Grüße...
>>
>> Sini
>>
>>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Am Mittwoch, 7. November 2012 21:46:58 UTC+1 schrieb Sini:

> Eine Frage noch: Du wusstest ja sofort, welcher Sensor da Daten schickt.
> Auf der Homepage von RFXCOM ist die Beschreibung ja eher dünn, daher meine
> Frage, ob du diese Liste zur Verfügung stellen kannst? So könnte man
> schneller prüfen, welche Geräte genau unterstützt werden?
>
>
Auf der Homepage stehen
in http://www.rfxcom.com/Documents/RFXtrx%20User%20Guide.pdf alle
unterstützten Sensoren. Leider muss man sich selbst heraussuchen,  was das
jeweils für ein Sensortyp ist. Ansonsten ist das aber m.E. vollständig.

Das ist den Sensor so schnell gefunden habe, liegt daran, dass ich in die
SDK-Dokumentation geschaut habe. Diese darf ich aber nicht weitergeben bzw.
veröffentlichen.

Wenn Du selbst programmieren willst, kannst Du diese SDK-Dokumentation aber
kostenfrei von RFXCOM bekommen.

Ich habe aber versucht alle von meinem Modul unterstützten Modelle
unter http://www.fhemwiki.de/wiki/RFXtrx aufzuführen. Weiterhin stehen die
unterstützten Sensoren als Kommentare am Anfang meiner Module.
Mehr als diese Sensoren funktionieren erst mal nicht mit FHEM, bis ich oder
jemand anders diese in die Module einpflegt.

MfG Willi

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Sini]

                                                         

Vielen Dank für die Info...

Grüße...

Sini

Am Mittwoch, 7. November 2012 22:02:48 UTC+1 schrieb Willi:
>
> Am Mittwoch, 7. November 2012 21:46:58 UTC+1 schrieb Sini:
>
>> Eine Frage noch: Du wusstest ja sofort, welcher Sensor da Daten schickt.
>> Auf der Homepage von RFXCOM ist die Beschreibung ja eher dünn, daher meine
>> Frage, ob du diese Liste zur Verfügung stellen kannst? So könnte man
>> schneller prüfen, welche Geräte genau unterstützt werden?
>>
>>
> Auf der Homepage stehen in
> http://www.rfxcom.com/Documents/RFXtrx%20User%20Guide.pdf alle
> unterstützten Sensoren. Leider muss man sich selbst heraussuchen,  was das
> jeweils für ein Sensortyp ist. Ansonsten ist das aber m.E. vollständig.
>
> Das ist den Sensor so schnell gefunden habe, liegt daran, dass ich in die
> SDK-Dokumentation geschaut habe. Diese darf ich aber nicht weitergeben bzw.
> veröffentlichen.
>
> Wenn Du selbst programmieren willst, kannst Du diese SDK-Dokumentation
> aber kostenfrei von RFXCOM bekommen.
>
> Ich habe aber versucht alle von meinem Modul unterstützten Modelle unter
> http://www.fhemwiki.de/wiki/RFXtrx aufzuführen. Weiterhin stehen die
> unterstützten Sensoren als Kommentare am Anfang meiner Module.
> Mehr als diese Sensoren funktionieren erst mal nicht mit FHEM, bis ich
> oder jemand anders diese in die Module einpflegt.
>
> MfG Willi
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Eine sehr gute Übersicht ist auch unter http://www.rfxcom.com/oregon.htm zu
finden.

MfG Willi

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Du hast eine PM dazu.....

Am Samstag, 15. Dezember 2012 17:43:51 UTC+1 schrieb Marc:
>
> Hi Willi,
> wäre es ein grosser Aufwand für die IT noch den on-till Befehl zu
> realisieren?
> VG,
> Marc
>
> Am Samstag, 25. Februar 2012 16:21:03 UTC+1 schrieb Willi:
> > Hallo,
> >
> >
> >
> > nachdem mein alter RFXCOM-Receiver in die Jahre gekommen ist und ich
> >
> > jetzt auch senden wollte (Meine ELRO-Funksteckdosen schalten), habe
> >
> > ich
> >
> > mir den RFXCOM RFXtrx433 (433 Mhz) Transceiver besorgt und
> >
> > entsprechende FHEM-Module geschrieben. Zu dem Gerät siehe
> http://www.rfxcom.com
> >
> > bzw. http://www.rfxcom.com/transceivers.htm#12103 .
> >
> > Der kleine Sender/Receiver (84 x 42 x 15mm ohne Antenne gemessen) für
> >
> > 433 Mhz hat einen Mini-USB-Anschluss (Adapterkabel für USB wurde bei
> >
> > mir mitgeliefert) und braucht kein eigenes Netzteil.
> >
> >
> >
> > Implementiert habe ich aktuell den Empfang von Wettersensoren (Oregon,
> >
> > Lacrosse), den Empfang von Security-Sensoren (X10Sec, KD101 and
> >
> > Visonic), sowie den Empfang und das Senden der Protokolle X10, ARC,
> >
> > ELRO AB400D, Waveman, Chacon EMW200 and IMPULS für Schaltsteckdosen
> >
> > bzw. Fernbedienungen. Das  ARC-Protokoll umfasst Geräte von HomeEasy,
> >
> > KlikAanKlikUit, ByeByeStandBy, Intertechno, ELRO, AB600, Duewi,
> >
> > DomiaLite and COCO, die man am Sender per Kodierrad konfiguriert
> >
> > (housecode A-P, sowie Unit-Code 1-16). Dies nutze ich derzeit für
> >
> > meine ELRO AB600-Funksteckdosen. Die Konfiguration ist einfach, da
> >
> > FHEM die Steckdose per autocreate lernt, wenn man den entsprechenden
> >
> > Taster an der zugehörigen Fernbedienung drückt.
> >
> >
> >
> > Die übrigen Protokolle wie beispielsweise AC, HomeEasy EU, ANSLUT,
> >
> > Koppla, LightwaveRF, etc. habe ich noch nicht in den Modulen
> >
> > realisiert. Dazu habe ich keine Geräte. Wenn hier Bedarf besteht,
> >
> > sollte es kein grosser Aufwand sein, dies auch zu implementieren.
> >
> > Solange ich der einzige Nutzer von RFXtrx433 mit FHEM bin,
> >
> > implementiere ich erst mal nur die Routinen für meinen eigenen
> >
> > Bedarf.........
> >
> >
> >
> > Die Module sind im SVN und können auch per updatefhem installiert
> >
> > werden. Anbei die Erklärung der Module aus dem aktuellen
> >
> > commandref.html. Das ganze läuft auch per FHEM2FHEM in RAW-Modus, wenn
> >
> > man mehrere FHEMs koppeln will. RFXtrx433 wird automatisch per
> >
> > autocreate (siehe usb create) erkannt.
> >
> >
> >
> > Aktuell habe ich den RFXtrx433 an meiner Fritzbox 7390 im Einsatz und
> >
> > empfange damit meine Oregon-Sensoren, meine X10Sec-Alarmsensoren und
> >
> > schalte meine ELRO-Funksteckdosen.
> >
> >
> >
> > Bitte beachten: Das Gerät ist kein Ersatz für einen CUL, CUNO, etc.,
> >
> > da es im 433 Mhz-Bereich funktioniert und die Protokolle des HomeMatic-
> >
> > System sowie FS20 (beide 868 Mhz) nicht kann.
> >
> >
> >
> > MfG Willi
> >
> > ------------------ Auszug aus commandref.html:
> >
> > TRX
> >
> >
> >
> > This module is for the RFXCOM RFXtrx433 USB based 433 Mhz RF
> >
> > transmitters. This USB based transmitter is able to receive and
> >
> > transmit many protocols like Oregon Scientific weather sensors, X10
> >
> > security and lighting devices, ARC ((address code wheels) HomeEasy,
> >
> > KlikAanKlikUit, ByeByeStandBy, Intertechno, ELRO, AB600, Duewi,
> >
> > DomiaLite, COCO) and others.
> >
> > Currently the following parser modules are implemented:
> >
> > 46_TRX_WEATHER.pm (see device TRX): Process messages Oregon Scientific
> >
> > weather sensors. See http://www.rfxcom.com/oregon.htm for a list of
> >
> > Oregon Scientific weather sensors that could be received by the
> >
> > RFXtrx433 tranmitter. Until now the following Oregon Scientific
> >
> > weather sensors have been tested successfully: BTHR918, BTHR918N,
> >
> > PCR800, RGR918, THGR228N, THGR810, THR128, THWR288A, WTGR800, WGR918.
> >
> > It will also work with many other Oregon sensors supported by
> >
> > RFXtrx433. Please give feedback if you use other sensors.
> >
> > 46_TRX_SECURITY.pm (see device TRX_SECURITY): Receive X10, KD101 and
> >
> > Visonic security sensors.
> >
> > 46_TRX_LIGHT.pm (see device RFXX10REC): Process X10, ARC, ELRO AB400D,
> >
> > Waveman, Chacon EMW200 and IMPULS lighting devices (switches and
> >
> > remote control). ARC is a protocol used by devices from HomeEasy,
> >
> > KlikAanKlikUit, ByeByeStandBy, Intertechno, ELRO, AB600, Duewi,
> >
> > DomiaLite and COCO with address code wheels.
> >
> > 46_TRX_ELSE.pm: Process and display all other messages. This module
> >
> > shows you messages that could not be handled by the other modules. It
> >
> > is useful to see RF receiption problems.
> >
> >
> >
> > Note: this module requires the Device::SerialPort or Win32::SerialPort
> >
> > module if the devices is connected via USB or a serial port.
> >
> >
> >
> > Define
> >
> > define TRX [noinit]
> >
> >
> >
> > USB-connected:
> >
> > specifies the USB port to communicate with the RFXtrx433
> >
> > receiver. Normally on Linux the device will be named /dev/ttyUSBx,
> >
> > where x is a number. For example /dev/ttyUSB0.
> >
> >
> >
> > Example:
> >
> > define RFXTRXUSB TRX /dev/ttyUSB0
> >
> >
> >
> > Network-connected devices:
> >
> > specifies the host:port of the device. E.g. 192.168.1.5:10001
> >
> > noninit is optional and issues that the RFXtrx433 device should not be
> >
> > initialized. This is useful if you share a RFXtrx433 device via LAN.
> >
> > It is also useful for testing to simulate a RFXtrx433 receiver via
> >
> > netcat.
> >
> >
> >
> > Example:
> >
> > define RFXTRXTCP TRX 192.168.1.5:10001
> >
> > define RFXTRXTCP2 TRX 192.168.1.121:10001 noinit
> >
> >
> >
> > Attributes
> >
> > dummy
> >
> >
> >
> > longids
> >
> > Comma separates list of device-types for TRX_WEATHER that should be
> >
> > handles using long ids. This additional ID is a one byte hex string
> >
> > and is generated by the Oregon sensor when is it powered on. The value
> >
> > seems to be randomly generated. This has the advantage that you may
> >
> > use more than one Oregon sensor of the same type even if it has no
> >
> > switch to set a sensor id. For example the author uses two BTHR918N
> >
> > sensors at the same time. All have different deviceids. The drawback
> >
> > is that the deviceid changes after changing batteries.
> >
> > Example:
> >
> > attr RFXTRXUSB longids BTHR918N
> >
> >
> >
> >
> >
> > TRX_SECURITY
> >
> >
> >
> > The TRX_SECURITY module interprets X10, KD101 and Visonic security
> >
> > sensors received by a RFXCOM RFXtrx433 RF receiver. You need to define
> >
> > an RFXtrx433 receiver first. See TRX.
> >
> >
> >
> > Define
> >
> > define TRX_SECURITY [
> >
> > ]
> >
> >
> >
> >
> >
> > specifies one of the following security devices:
> >
> > DS10A (X10 security ds10a Door/Window Sensor or compatible devices.
> >
> > This device type reports the status of the switch [Open/Closed],
> >
> > status of the delay switch [min|max]], and battery status [ok|low].)
> >
> > MS10A (X10 security ms10a motion sensor. This device type reports the
> >
> > status of motion sensor [normal|alert] and battery status [ok|low].))
> >
> > SD90 (Marmitek sd90 smoke detector. This device type reports the
> >
> > status of the smoke detector [normal|alert] and battery status [ok|
> >
> > low].)
> >
> > KR18 (X10 security remote control. Report the Reading "Security" with
> >
> > values [Arm|Disarm], "ButtonA" and "ButtonB" with values [on|off] )
> >
> > KD101 (KD101 smoke sensor. Report the Reading "smoke" with values
> >
> > [normal|alert])
> >
> > VISONIC_WINDOW (VISONIC security Door/Window Sensor or compatible
> >
> > devices. This device type reports the status of the switch [Open/
> >
> > Closed] and battery status [ok|low].)
> >
> > VISONIC_MOTION (VISONIC security motion sensor. This device type
> >
> > reports the status of motion sensor [normal|alert] and battery status
> >
> > [ok|low].))
> >
> >
> >
> >
> >
> > specifies the first device id of the device. X10 security (DS10A,
> >
> > MS10A) and SD90 have a a 16 bit device id which has to be written as a
> >
> > hex-string (example "5a54"). All other devices have a 24 bit device
> >
> > id.
> >
> >
> >
> >
> >
> > is the name of the Reading used to report. Suggested: "Window" or
> >
> > "Door" for ds10a, "motion" for motion sensors, "smoke" for sd90.
> >
> >
> >
> >
> >
> > is optional and specifies the second device id of the device if it
> >
> > exists. For example sd90 smoke sensors can be configured to report two
> >
> > device ids.
> >
> >
> >
> >
> >
> > is optional for the name used for the Reading of .
> >
> >
> >
> > Example:
> >
> > define livingroom_window TRX_SECURITY ds10a 72cd Window
> >
> > define motion_sensor1 TRX_SECURITY ms10a 55c6 motion
> >
> > define smoke_sensor1 TRX_SECURITY sd90 54d3 Smoke 54d3 Smoketest
> >
> >
> >
> > Set
> >
> > N/A
> >
> >
> >
> > Get
> >
> > N/A
> >
> >
> >
> > TRX_LIGHT
> >
> >
> >
> > The TRX_LIGHT module receives and sends X10, ARC, ELRO AB400D,
> >
> > Waveman, Chacon EMW200 and IMPULS lighting messages by a RFXtrx433 RF
> >
> > transceiver. ARC is a protocol used by devices from HomeEasy,
> >
> > KlikAanKlikUit, ByeByeStandBy, Intertechno, ELRO, AB600, Duewi,
> >
> > DomiaLite and COCO with address code wheels.
> >
> > You need to define an RFXtrx433 transceiver receiver first. See TRX.
> >
> >
> >
> > Define
> >
> > define TRX_LIGHT [
> >
> > ]
> >
> >
> >
> >
> >
> > specifies the type of the device:
> >
> > X10 lighting devices:
> >
> > MS14A (X10 motion sensor. Reports [normal|alert] on the first deviceid
> >
> > (motion sensor) and [on|off] for the second deviceid (light sensor))
> >
> > X10 (All other x10 devices. Report [on|off] on both deviceids.)
> >
> > ARC (ARC devices. ARC is a protocol used by devices from HomeEasy,
> >
> > KlikAanKlikUit, ByeByeStandBy, Intertechno, ELRO, AB600, Duewi,
> >
> > DomiaLite and COCO with address code wheels. Report [on|off] on both
> >
> > deviceids.)
> >
> > AB400D (ELRO AB400D devices. Report [on|off] on both deviceids.)
> >
> > WAVEMAN (Waveman devices. Report [on|off] on both deviceids.)
> >
> > EMW200 (Chacon EMW200 devices. Report [on|off] on both deviceids.)
> >
> > IMPULS (IMPULS devices. Report [on|off] on both deviceids.)
> >
> >
> >
> >
> >
> > specifies the first device id of the device. A lighting device has a
> >
> > house code A..P followed by a unitcode 1..16 (example "B1").
> >
> >
> >
> >
> >
> > is the name of the Reading used to report. Suggested: "motion" for
> >
> > motion sensors.
> >
> >
> >
> >
> >
> > is optional and specifies the second device id of the device if it
> >
> > exists. For example ms14a motion sensors report motion status on the
> >
> > first deviceid and the status of the light sensor on the second
> >
> > deviceid.
> >
> >
> >
> >
> >
> > is optional for the name used for the Reading of .
> >
> >
> >
> > Example:
> >
> > define motion_sensor2 TRX_LIGHT MS14A A1 motion A2 light
> >
> > define Steckdose TRX_LIGHT ARC G2 light
> >
> >
> >
> > Set
> >
> > set
> >
> >
> >
> > where value is one of:
> >
> >     off
> >
> >     on
> >
> >     dim                # only for X10
> >
> >     bright             # only for X10
> >
> >     all_off            # only for X10, ARC, EMW200
> >
> >     all_on             # only for X10, ARC, EMW200
> >
> >     chime              # only for ARC
> >
> >
> >
> > Example:
> >
> > set Steckdose on
> >
> >
> >
> > Get
> >
> > N/A
> >
> >
> >
> > TRX_WEATHER
> >
> >
> >
> > The TRX_WEATHER module interprets weather sensor messages received by
> >
> > a RTXtrx receiver. See http://www.rfxcom.com/oregon.htm for a list of
> >
> > Oregon Scientific weather sensors that could be received by the
> >
> > RFXtrx433 tranmitter. You need to define a RFXtrx433 receiver first.
> >
> > See See TRX.
> >
> >
> >
> > Define
> >
> > define OREGON
> >
> >
> >
> > is the device identifier of the Oregon sensor. It consists
> >
> > of the sensors name and (only if the attribute longids is set of the
> >
> > RFXtrx433) an a one byte hex string (00-ff) that identifies the
> >
> > sensor. If an sensor uses an switch to set an additional is then this
> >
> > is also added. The define statement with the deviceid is generated
> >
> > automatically by autocreate. The following sensor names are used:
> >
> > "THR128" (for THR128/138, THC138),
> >
> > "THGR132N" (for THC238/268,THN132,THWR288,THRN122,THN122,AW129/131),
> >
> > "THWR800",
> >
> > "RTHN318",
> >
> > "TX3_T" (for LaCrosse TX3, TX4, TX17),
> >
> > "THGR228N" (for THGN122/123, THGN132, THGR122/228/238/268),
> >
> > "THGR810",
> >
> > "RTGR328",
> >
> > "THGR328",
> >
> > "WTGR800_T" (for temperature of WTGR800),
> >
> > "THGR918" (for THGR918, THGRN228, THGN500),
> >
> > "TFATS34C" (for TFA TS34C),
> >
> > "BTHR918",
> >
> > "BTHR918N (for BTHR918N, BTHR968),
> >
> > "RGR918" (for RGR126/682/918),
> >
> > "PCR800",
> >
> > "TFA_RAIN" (for TFA rain sensor),
> >
> > "WTGR800_A" (for wind sensor of WTGR800),
> >
> > "WGR800_A" (for wind sensor of WGR800),
> >
> > "WGR918_A" (for wind sensor of STR918 and WGR918),
> >
> > "TFA_WIND" (for TFA wind sensor)
> >
> >
> >
> >
> >
> > Example:
> >
> > define Tempsensor TRX_WEATHER TX3_T
> >
> > define Tempsensor3 TRX_WEATHER THR128_3
> >
> > define Windsensor TRX_WEATHER WGR918_A
> >
> > define Regensensor TRX_WEATHER RGR918
> >
> >
> >
> > Set
> >
> > N/A
> >
> >
> >
> > Get
> >
> > N/A
>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Du hast eine PM dazu...

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com