weiss jemand wie der Device Name bei einem Windows 7 Rechner aussehen
muss?
In linux /dev/ttyUSB0 aber wie sieht es bei windows aus?
CODE | TX3_T |
DEF | TX3_T |
NAME | Tempsensor |
NR | 16 |
STATE | T: 25.6 BAT: ok |
TIME | 2012-03-21 23:02:56 |
TYPE | TRX_WEATHER |
Danke für die Hilfe!!
Was ist der unterschied zwischen init und noinit? Habe ich dadurch nachteile?
Hallo,Die Sensoren sind die gleichen die auch im rfxmanager angezeigt werden. Es ist nur so das sie früher gekommen sind als die Oregon.Aktuell habe ich 2x TX3P von La Crosse.Es funktioniert alles super bis auf den Plot, da bekomme ich folgende Fehlermeldung:Argument "|temperature" isn't numeric in numeric gt (>) at ./FHEM/98_SVG.pm line 210.Argument "|temperature" isn't numeric in subtraction (-) at ./FHEM/98_SVG.pm line 450.Argument "|temperature" isn't numeric in numeric gt (>) at ./FHEM/98_SVG.pm line 210.Argument "|temperature" isn't numeric in subtraction (-) at ./FHEM/98_SVG.pm line 450.
Ich hätte noch eine Frage, klappt das Empfangen auch von folgenden Sensoren:TX 80-THTX 3TH
Danke für die Info!Ich verwende derzeit die longid option mit zwei La Crosse TX3, funktioniert soweit ganz gut.Dh. wenn ich einen Batterie wechsel machen muss, muss ich den Sensor wieder umbenennen in den alten alias?Oder heißt das ich muss alle Logs, einstellungen, Scripte, etc die auf den Sensor programmiert sind auch wieder ändern?
Die Oregon senden 2x pro Minute oder?
Okay, dann versuch ich mal die TX3TH.Ich werde sie wohl in den nächsten 10 Tagen erhalten.Brauchst du dann Daten von mir um sie in fhem einzubinden?
Ich schau mal, wann ich nächste Woche dazu komme dies zu implementieren. Ich stelle es dann ins SVN ein.
Hallo, ich habe nun endlich die Sensoren bekommen.Funktioniert sehr gut bis auf das Hygrometer. Das Problem ist das nur ein von 4 Hygrometern angezeigt wird.Warscheinlich weil der Name "TX3_H" lautet und nicht wie bei Temperatur z.B. "TX3_T_07" also es fehlt der _XX teil.Kriegst du das noch hin?
Commando zurück, es funktioniert immer nur eine longid, nicht bei beiden.In der Config habe ich:define RFXTRXUSB TRX COM3@38400 noinitattr RFXTRXUSB do_not_init 1attr RFXTRXUSB longids TX3_Hattr RFXTRXUSB longids TX3_Tattr RFXTRXUSB room Wohnzimmeraber das funktioniert entweder nur bei _H oder nur bei _T nicht aber bei beiden
Ah okay danke geht jetzt! sorry wegen den Anfängerfehlern
Ich hab trotzdem noch ne Frage, wie krieg ich es hin das temp und hygro in einem plot angezeigt werden?mit filelog kann ich ja den dateinamen angeben aber der weblink zeigt dann garnichts an. In dem file selbst wird zudem mit longid geschrieben:2012-04-12_19:26:19 TX3_T_07 temperature: 23.12012-04-12_19:26:19 TX3_T_07 battery: ok2012-04-12_19:26:19 TX3_T_07 T: 23.1 BAT: ok2012-04-12_19:26:19 TX3_H_07 humidity: 392012-04-12_19:26:19 TX3_H_07 battery: ok
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 <name> TRX <device> [noinit]
USB-connected:
<device> 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:
<device> 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 <name> TRX_SECURITY <type> <deviceid> <devicelog> [<deviceid>
<devicelog>]
<type>
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].))
<deviceid>
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.
<devicelog>
is the name of the Reading used to report. Suggested: "Window" or
"Door" for ds10a, "motion" for motion sensors, "smoke" for sd90.
<deviceid2>
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.
<devicelog2>
is optional for the name used for the Reading of <deviceid2>.
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 <name> TRX_LIGHT <type> <deviceid> <devicelog> [<deviceid>
<devicelog>]
<type>
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.)
<deviceid>
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").
<devicelog>
is the name of the Reading used to report. Suggested: "motion" for
motion sensors.
<deviceid2>
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.
<devicelog2>
is optional for the name used for the Reading of <deviceid2>.
Example:
define motion_sensor2 TRX_LIGHT MS14A A1 motion A2 light
define Steckdose TRX_LIGHT ARC G2 light
Set
set <name> <value>
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 <name> OREGON <deviceid>
<deviceid> 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
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...
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?