Originally posted by: <email address deleted>
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
Originally posted by: <email address deleted>
weiss jemand wie der Device Name bei einem Windows 7 Rechner aussehen
muss?
In linux /dev/ttyUSB0 aber wie sieht es bei windows aus?
On 25 Feb., 16:21, Willi wrote:
> Hallo,
>
> nachdem mein alterRFXCOM-Receiver in die Jahre gekommen ist und ich
> jetzt auch senden wollte (Meine ELRO-Funksteckdosen schalten), habe
> ich
> mir denRFXCOMRFXtrx433 (433 Mhz) Transceiver besorgt und
> entsprechende FHEM-Module geschrieben. Zu dem Gerät siehehttp://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 theRFXCOMRFXtrx433 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. Seehttp://www.rfxcom.com/oregon.htmfor 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 aRFXCOMRFXtrx433 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. Seehttp://www.rfxcom.com/oregon.htmfor 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
Originally posted by: <email address deleted>
Am Samstag, 17. März 2012 16:39:07 UTC+1 schrieb Martin:
>
> weiss jemand wie der Device Name bei einem Windows 7 Rechner aussehen
> muss?
>
> In linux /dev/ttyUSB0 aber wie sieht es bei windows aus?
>
>
Ich habe noch nie FHEM unter Windows laufen lassen. Ich habe es unter
Ubuntu (Notebook, Testsystem), debian (Sheevaplug) und Fritzbox 7390 laufen.
Unter http://fhemwiki.de/wiki/Windows_-_FHEM_installieren sieht man jedoch
folgende Konfiguration bei CUL unter Windows:
define CUL CUL com14@9600 1234
Analog dazu müßte es bei TRXtrx433 folgendes heissen:
define RFXTRX TRX com14@38400
(TRXtrx433 läuft normalerweise unter 38400 Baud).
Wobei Du natürlich vorher herausfinden musst, welches COM-Device RFXtrx433
unter Deiner Windows-Konfiguration ist.
Am einfachsten nimmst Du dazu RFXmngr. Damit kannst Du damit RFXtrx433
gleich auf Funktion testen und auch konfigurieren (z.B. nicht gewünschte
Protokolle abschalten). RFXmngr zeigt Dir die verfügbaren Ports an. Probier
die dann durch bis es funktioniert (bei mir bisher immer der letzte
angebotene Port). (Download http://www.rfxcom.com/documents/RFXmngr.zip)
Empfehlenswert ist evtl. noch die neueste Firmware auf RFXtrx433 zu
flashen. Dazu bekommst Du die Firmware
unter http://www.rfxcom.com/documents/RFXtrx433_firmware.zip und das
notwendige Flash-Programm
unter http://www.rfxcom.com/documents/RFXflash.zip .
Ich bin mal gespannt wie mein Modul mit RFXtrx433 unter Windows bei FHEM
läuft. Sollte eigentlich funktionieren, da ich für den Zugriff über
USB DevIo.pm verwende, was ja auch für CUL verwendet wird.
MfG Willi
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Danke für die Hilfe!
mit
define rfxcomusb RFXCOM COM3
scheint es zu funktionieren, zumindest bekomme ich keine Fehlermeldung
mehr!
Testen kann ich es leider erst wenn ich meine Oregon Sensoren bekommen
habe (Vielleicht nächste Woche)
Ich gebe dann nochmal bescheid.
Mit FHEM habe ich noch gar keine Erfahrung aber unter Windows sieht
es, bis auf folgende Fehlermeldung die ich seit Anfang an habe gut
aus:
Use of uninitialized value in concatenation (.) or string at C:
\fhem-5.2-fb7270\fhem\fhem.pl line 1436, <$fh> line 2.
Use of uninitialized value in concatenation (.) or string at C:
\fhem-5.2-fb7270\fhem\fhem.pl line 1436, <$fh> line 2.
Use of uninitialized value in concatenation (.) or string at C:
\fhem-5.2-fb7270\fhem\fhem.pl line 1436, <$fh> line 2.
Use of uninitialized value in concatenation (.) or string at C:
\fhem-5.2-fb7270\fhem\fhem.pl line 1436, <$fh> line 2.
jemand ne Idee was das sein könnte?
On 17 Mrz., 19:06, Willi wrote:
> Am Samstag, 17. März 2012 16:39:07 UTC+1 schrieb Martin:
>
> > weiss jemand wie der Device Name bei einem Windows 7 Rechner aussehen
> > muss?
>
> > In linux /dev/ttyUSB0 aber wie sieht es bei windows aus?
>
> Ich habe noch nie FHEM unter Windows laufen lassen. Ich habe es unter
> Ubuntu (Notebook, Testsystem), debian (Sheevaplug) und Fritzbox 7390 laufen.
>
> Unterhttp://fhemwiki.de/wiki/Windows_-_FHEM_installierensieht man jedoch
> folgende Konfiguration bei CUL unter Windows:
>
> define CUL CUL com14@9600 1234
>
> Analog dazu müßte es bei TRXtrx433 folgendes heissen:
>
> define RFXTRX TRX com14@38400
>
> (TRXtrx433 läuft normalerweise unter 38400 Baud).
>
> Wobei Du natürlich vorher herausfinden musst, welches COM-Device RFXtrx433
> unter Deiner Windows-Konfiguration ist.
>
> Am einfachsten nimmst Du dazu RFXmngr. Damit kannst Du damit RFXtrx433
> gleich auf Funktion testen und auch konfigurieren (z.B. nicht gewünschte
> Protokolle abschalten). RFXmngr zeigt Dir die verfügbaren Ports an. Probier
> die dann durch bis es funktioniert (bei mir bisher immer der letzte
> angebotene Port). (Downloadhttp://www.rfxcom.com/documents/RFXmngr.zip)
>
> Empfehlenswert ist evtl. noch die neueste Firmware auf RFXtrx433 zu
> flashen. Dazu bekommst Du die Firmware
> unterhttp://www.rfxcom.com/documents/RFXtrx433_firmware.zipund das
> notwendige Flash-Programm
> unterhttp://www.rfxcom.com/documents/RFXflash.zip.
>
> Ich bin mal gespannt wie mein Modul mit RFXtrx433 unter Windows bei FHEM
> läuft. Sollte eigentlich funktionieren, da ich für den Zugriff über
> USB DevIo.pm verwende, was ja auch für CUL verwendet wird.
>
> MfG Willi
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
In Deinem Pfad ist \fhem-5.2-fb7270. Du hast vermutlich die FHEM-Version
für Fritzbox 7270 installiert (fhem-5.2-fb7270.zip statt fhem-5.2.tar.gz)
verwendet.
Ich bin mir nicht sicher, ob diese Version bzgl. der Pfade etc. unter
Windows läuft. Evtl. kann ja einer der Windows-User etwas dazu sagen, ob
das überhaupt funktionieren kann.
Besser ist wohl gemäß der Anleitung unter
http://fhemwiki.de/wiki/Windows_-_FHEM_installieren
vorzugehen. Danach am besten mittels "updatefhem" updaten.
Die von Dir installierte Version 5.2 unterstützt ohne Update nicht den
RFXtrx.
Die von Dir definierte Zeile
" define rfxcomusb RFXCOM COM3 "
funktioniert auch nur mit dem alten RFXCOM-Receiver, aber nicht mit
RFXtrx433.
Was für ein Gerät hast Du genau gekauft?
MfG Willi
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo,
danke für die Hilfe!
Ich bin nach der u.g. Anleitung vorgegangen, hatte nur die falsche
Fhem Version benutzt!
Ich habe es nochmal neu Installiert aber auch dann hatte ich die
Fehlermeldung, erst nach dem "updatefhem" Befehl ging es!
Jetzt habe ich keine Fehlermeldungen mehr!
Ich hab die neue RFXtrx433 aber wie gesagt, noch keinen Sender kann
also noch nicht sagen ob es funktioniert!
Martin
On 18 Mrz., 00:04, Willi wrote:
> In Deinem Pfad ist \fhem-5.2-fb7270. Du hast vermutlich die FHEM-Version
> für Fritzbox 7270 installiert (fhem-5.2-fb7270.zip statt fhem-5.2.tar.gz)
> verwendet.
>
> Ich bin mir nicht sicher, ob diese Version bzgl. der Pfade etc. unter
> Windows läuft. Evtl. kann ja einer der Windows-User etwas dazu sagen, ob
> das überhaupt funktionieren kann.
>
> Besser ist wohl gemäß der Anleitung unterhttp://fhemwiki.de/wiki/Windows_-_FHEM_installieren
> vorzugehen. Danach am besten mittels "updatefhem" updaten.
>
> Die von Dir installierte Version 5.2 unterstützt ohne Update nicht den
> RFXtrx.
>
> Die von Dir definierte Zeile
> " define rfxcomusb RFXCOM COM3 "
> funktioniert auch nur mit dem alten RFXCOM-Receiver, aber nicht mit
> RFXtrx433.
>
> Was für ein Gerät hast Du genau gekauft?
>
> MfG Willi
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Nachdem ich endlich einen Sensor habe und die Config neu gemacht habe:
define RFXTRXUSB TRX COM3
define Tempsensor TRX_WEATHER TX3_T
bekomme ich folgende Fehlermeldung:
C:\Users\htpc\Dropbox\htpc\fhem>perl fhem.pl fhem.cfg
Missing REQUIRED setting for STOP at ./FHEM/DevIo.pm line 212
Missing REQUIRED setting for PARITY at ./FHEM/DevIo.pm line 212
Missing REQUIRED setting for DATA at ./FHEM/DevIo.pm line 212
Missing REQUIRED setting for BAUD at ./FHEM/DevIo.pm line 212
write_settings failed, closing port at ./FHEM/DevIo.pm line 212
Use of uninitialized value in subroutine entry at C:/Perl/site/lib/
Win32API/C
Port.pm line 217.
Use of uninitialized value in subroutine entry at C:/Perl/site/lib/
Win32API/C
Port.pm line 247.
Use of uninitialized value in subroutine entry at C:/Perl/site/lib/
Win32API/C
Port.pm line 235.
Second Write attempted before First is done at ./FHEM/DevIo.pm line 88
Use of uninitialized value $written in numeric ne (!=) at C:/Perl/site/
lib/Wi
/SerialPort.pm line 1580.
Use of uninitialized value in subroutine entry at C:/Perl/site/lib/
Win32API/C
Port.pm line 247.
Im log file:
2012.03.21 01:07:06 5: Loading ./FHEM/45_TRX.pm
2012.03.21 01:07:06 3: Opening RFXTRXUSB device COM3
2012.03.21 01:07:06 3: RFXTRXUSB device opened
2012.03.21 01:07:06 5: SW:
2012.03.21 01:07:06 5: SW:
2012.03.21 01:07:06 1: TRX: Initialization Error: No character read
2012.03.21 01:07:06 1: Cannot init COM3, ignoring it
2012.03.21 01:07:06 5: Triggering global (1 changes)
Status im fhem:
TRX
RFXTRXUSB
opened
TRX_WEATHER
Tempsensor
???
Ne Idee was nicht stimmen kann?
On Mar 18, 1:10 pm, Martin wrote:
> Hallo,
>
> danke für die Hilfe!
> Ich bin nach der u.g. Anleitung vorgegangen, hatte nur die falsche
> Fhem Version benutzt!
>
> Ich habe es nochmal neu Installiert aber auch dann hatte ich die
> Fehlermeldung, erst nach dem "updatefhem" Befehl ging es!
> Jetzt habe ich keine Fehlermeldungen mehr!
>
> Ich hab die neue RFXtrx433 aber wie gesagt, noch keinen Sender kann
> also noch nicht sagen ob es funktioniert!
>
> Martin
>
> On 18 Mrz., 00:04, Willi wrote:
>
>
>
>
>
>
>
> > In Deinem Pfad ist \fhem-5.2-fb7270. Du hast vermutlich die FHEM-Version
> > für Fritzbox 7270 installiert (fhem-5.2-fb7270.zip statt fhem-5.2.tar.gz)
> > verwendet.
>
> > Ich bin mir nicht sicher, ob diese Version bzgl. der Pfade etc. unter
> > Windows läuft. Evtl. kann ja einer der Windows-User etwas dazu sagen, ob
> > das überhaupt funktionieren kann.
>
> > Besser ist wohl gemäß der Anleitung unterhttp://fhemwiki.de/wiki/Windows_-_FHEM_installieren
> > vorzugehen. Danach am besten mittels "updatefhem" updaten.
>
> > Die von Dir installierte Version 5.2 unterstützt ohne Update nicht den
> > RFXtrx.
>
> > Die von Dir definierte Zeile
> > " define rfxcomusb RFXCOM COM3 "
> > funktioniert auch nur mit dem alten RFXCOM-Receiver, aber nicht mit
> > RFXtrx433.
>
> > Was für ein Gerät hast Du genau gekauft?
>
> > MfG Willi
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Die Meldungen sagen m. E. aus, dass die Schnittstelle COM3 nicht richtig
initialisiert werden konnte.
Ich hatte es so verstanden, dass vorher die Initialisierung funktioniert
hatte. Oder doch nicht?
Wenn die Initialisierung des RFXtrx433 richtig funktioniert, sollte beim
Start in fhem.log folgendes stehen (natürlich mit anderem
Device/Interface-Namen, bei mir ist der Devicename TRX_0 und das
Interface /dev/ttyUSB0):
2012.03.02 10:16:10 3: Opening TRX_0 device /dev/ttyUSB0
2012.03.02 10:16:11 3: Setting TRX_0 baudrate to 38400
2012.03.02 10:16:11 3: TRX_0 device opened
2012.03.02 10:16:12 1: TRX: Init OK
Wichtig ist die Meldung "Init OK". Die besagt, dass der entsprechende
Init-String zum RFXtrx433 geschickt wurde und die richtige Rückmeldung kam.
Wenn Diese Meldung nicht kommt, konnte das Modul nicht mit RFXtrx433
kommunzieren.
Ich vermute, dass bei Dir RFXtrx433 nicht an COM3 ist, sondern an einer
anderen Schnittstelle. COM3 ist bei Windows normalerweise auch einer
interne Schnittstelle und kein externes USB-Interface.
Nimm das von mir angegebene Hilfsprogramm RFXmngr und teste auf welcher
Schnittstelle RFXtrx433 ist. RFXmngr zeigt Dir die möglichen Schnittstellen
an, die Du dann probieren kannst. RFXmngr zeigt Dir auch gleich an, was
RFXtrx433 empfängt. Du solltest die Meldungen Deines Oregon-Sensors sehen.
Alternativ geh in den Windows-Gerätemanager und sieht nach welchem COM-Port
das Device zugeordnet ist.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo,
also vorher hatte ich den alten rfxcom in der config:
define rfxcomusb RFXCOM COM3
Da ich aber den neuen habe habe ich es auf
define RFXTRXUSB TRX COM3
geändert.
Laut RFXmngr ist es tatsächhlich COM3, ich befürchte das irgendetwas
bei der installation von Perl bzw diesem komischen Win32 Serial Port
Modul schief gegangen ist.
Bei dem Befehl:
"perl Makefile.PL TESTPORT=COM3"
...
Checking if your kit is complete...
Looks good
Have \perl\site\lib
Want \perl\lib
Your perl and your Config.pm seem to have different ideas about the
architecture they are running on.
Perl thinks: [lib]
Config says: [MSWin32-x86-multi-thread]
This may or may not cause problems. Please check your installation of
perl
if you have problems building this extension.
Writing Makefile for Win32::SerialPort
Dann:
:\Perl\lib\Win32-SerialPort-0.22>perl nomake_test
t/test1.t .. ok
t/test2.t .. ok
t/test3.t .. ok
t/test4.t .. ok
t/test5.t .. ok
t/test6.t .. 1/? Could not set databits on TestPort at t/test6.t line
306
t/test6.t .. ok
t/test7.t .. ok
All tests successful.
Files=7, Tests=1808, 10 wallclock secs ( 0.84 usr + 0.14 sys = 0.98
CPU)
Result: PASS
On 21 Mrz., 06:33, Willi wrote:
> Die Meldungen sagen m. E. aus, dass die Schnittstelle COM3 nicht richtig
> initialisiert werden konnte.
>
> Ich hatte es so verstanden, dass vorher die Initialisierung funktioniert
> hatte. Oder doch nicht?
>
> Wenn die Initialisierung des RFXtrx433 richtig funktioniert, sollte beim
> Start in fhem.log folgendes stehen (natürlich mit anderem
> Device/Interface-Namen, bei mir ist der Devicename TRX_0 und das
> Interface /dev/ttyUSB0):
>
> 2012.03.02 10:16:10 3: Opening TRX_0 device /dev/ttyUSB0
> 2012.03.02 10:16:11 3: Setting TRX_0 baudrate to 38400
> 2012.03.02 10:16:11 3: TRX_0 device opened
> 2012.03.02 10:16:12 1: TRX: Init OK
>
> Wichtig ist die Meldung "Init OK". Die besagt, dass der entsprechende
> Init-String zum RFXtrx433 geschickt wurde und die richtige Rückmeldung kam.
> Wenn Diese Meldung nicht kommt, konnte das Modul nicht mit RFXtrx433
> kommunzieren.
>
> Ich vermute, dass bei Dir RFXtrx433 nicht an COM3 ist, sondern an einer
> anderen Schnittstelle. COM3 ist bei Windows normalerweise auch einer
> interne Schnittstelle und kein externes USB-Interface.
>
> Nimm das von mir angegebene Hilfsprogramm RFXmngr und teste auf welcher
> Schnittstelle RFXtrx433 ist. RFXmngr zeigt Dir die möglichen Schnittstellen
> an, die Du dann probieren kannst. RFXmngr zeigt Dir auch gleich an, was
> RFXtrx433 empfängt. Du solltest die Meldungen Deines Oregon-Sensors sehen.
>
> Alternativ geh in den Windows-Gerätemanager und sieht nach welchem COM-Port
> das Device zugeordnet ist.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
fhemlog sag hierzu:
2012.03.21 09:14:20 5: Cmd: >define RFXTRXUSB TRX COM3@9600<
2012.03.21 09:14:20 5: Loading ./FHEM/45_TRX.pm
2012.03.21 09:14:20 3: Opening RFXTRXUSB device COM3
2012.03.21 09:14:20 3: Setting RFXTRXUSB baudrate to 9600
2012.03.21 09:14:20 3: RFXTRXUSB device opened
2012.03.21 09:14:20 5: SW:
2012.03.21 09:14:20 5: SW:
2012.03.21 09:14:20 1: TRX: Initialization Error: No character read
2012.03.21 09:14:20 1: Cannot init COM3, ignoring it
On 21 Mrz., 08:58, Martin wrote:
> Hallo,
>
> also vorher hatte ich den alten rfxcom in der config:
>
> define rfxcomusb RFXCOM COM3
>
> Da ich aber den neuen habe habe ich es auf
>
> define RFXTRXUSB TRX COM3
>
> geändert.
>
> Laut RFXmngr ist es tatsächhlich COM3, ich befürchte das irgendetwas
> bei der installation von Perl bzw diesem komischen Win32 Serial Port
> Modul schief gegangen ist.
>
> Bei dem Befehl:
>
> "perl Makefile.PL TESTPORT=COM3"
>
> ...
> Checking if your kit is complete...
> Looks good
> Have \perl\site\lib
> Want \perl\lib
> Your perl and your Config.pm seem to have different ideas about the
> architecture they are running on.
> Perl thinks: [lib]
> Config says: [MSWin32-x86-multi-thread]
> This may or may not cause problems. Please check your installation of
> perl
> if you have problems building this extension.
> Writing Makefile for Win32::SerialPort
>
> Dann:
>
> :\Perl\lib\Win32-SerialPort-0.22>perl nomake_test
> t/test1.t .. ok
> t/test2.t .. ok
> t/test3.t .. ok
> t/test4.t .. ok
> t/test5.t .. ok
> t/test6.t .. 1/? Could not set databits on TestPort at t/test6.t line
> 306
> t/test6.t .. ok
> t/test7.t .. ok
> All tests successful.
> Files=7, Tests=1808, 10 wallclock secs ( 0.84 usr + 0.14 sys = 0.98
> CPU)
> Result: PASS
>
> On 21 Mrz., 06:33, Willi wrote:
>
>
>
>
>
>
>
> > Die Meldungen sagen m. E. aus, dass die Schnittstelle COM3 nicht richtig
> > initialisiert werden konnte.
>
> > Ich hatte es so verstanden, dass vorher die Initialisierung funktioniert
> > hatte. Oder doch nicht?
>
> > Wenn die Initialisierung des RFXtrx433 richtig funktioniert, sollte beim
> > Start in fhem.log folgendes stehen (natürlich mit anderem
> > Device/Interface-Namen, bei mir ist der Devicename TRX_0 und das
> > Interface /dev/ttyUSB0):
>
> > 2012.03.02 10:16:10 3: Opening TRX_0 device /dev/ttyUSB0
> > 2012.03.02 10:16:11 3: Setting TRX_0 baudrate to 38400
> > 2012.03.02 10:16:11 3: TRX_0 device opened
> > 2012.03.02 10:16:12 1: TRX: Init OK
>
> > Wichtig ist die Meldung "Init OK". Die besagt, dass der entsprechende
> > Init-String zum RFXtrx433 geschickt wurde und die richtige Rückmeldung kam.
> > Wenn Diese Meldung nicht kommt, konnte das Modul nicht mit RFXtrx433
> > kommunzieren.
>
> > Ich vermute, dass bei Dir RFXtrx433 nicht an COM3 ist, sondern an einer
> > anderen Schnittstelle. COM3 ist bei Windows normalerweise auch einer
> > interne Schnittstelle und kein externes USB-Interface.
>
> > Nimm das von mir angegebene Hilfsprogramm RFXmngr und teste auf welcher
> > Schnittstelle RFXtrx433 ist. RFXmngr zeigt Dir die möglichen Schnittstellen
> > an, die Du dann probieren kannst. RFXmngr zeigt Dir auch gleich an, was
> > RFXtrx433 empfängt. Du solltest die Meldungen Deines Oregon-Sensors sehen.
>
> > Alternativ geh in den Windows-Gerätemanager und sieht nach welchem COM-Port
> > das Device zugeordnet ist.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Ich habe jetzt noch die Baudrate mitangegeben, damit sind die
Fehlermeldungen beim start von fhem weg, jedoch immernoch kein init.
fhemlog sag hierzu:
2012.03.21 09:14:20 5: Cmd: >define RFXTRXUSB TRX COM3@38400<
2012.03.21 09:14:20 5: Loading ./FHEM/45_TRX.pm
2012.03.21 09:14:20 3: Opening RFXTRXUSB device COM3
2012.03.21 09:14:20 3: Setting RFXTRXUSB baudrate to 38400
2012.03.21 09:14:20 3: RFXTRXUSB device opened
2012.03.21 09:14:20 5: SW:
2012.03.21 09:14:20 5: SW:
2012.03.21 09:14:20 1: TRX: Initialization Error: No character read
2012.03.21 09:14:20 1: Cannot init COM3, ignoring it
Kann es sein das man den Rest wie Datenbits, Parität, Stoppbits noch
angeben muss?
Laut rfxmanager sind die Einstellungen: 38400-8-N-1
On 21 Mrz., 08:58, Martin wrote:
> Hallo,
>
> also vorher hatte ich den alten rfxcom in der config:
>
> define rfxcomusb RFXCOM COM3
>
> Da ich aber den neuen habe habe ich es auf
>
> define RFXTRXUSB TRX COM3
>
> geändert.
>
> Laut RFXmngr ist es tatsächhlich COM3, ich befürchte das irgendetwas
> bei der installation von Perl bzw diesem komischen Win32 Serial Port
> Modul schief gegangen ist.
>
> Bei dem Befehl:
>
> "perl Makefile.PL TESTPORT=COM3"
>
> ...
> Checking if your kit is complete...
> Looks good
> Have \perl\site\lib
> Want \perl\lib
> Your perl and your Config.pm seem to have different ideas about the
> architecture they are running on.
> Perl thinks: [lib]
> Config says: [MSWin32-x86-multi-thread]
> This may or may not cause problems. Please check your installation of
> perl
> if you have problems building this extension.
> Writing Makefile for Win32::SerialPort
>
> Dann:
>
> :\Perl\lib\Win32-SerialPort-0.22>perl nomake_test
> t/test1.t .. ok
> t/test2.t .. ok
> t/test3.t .. ok
> t/test4.t .. ok
> t/test5.t .. ok
> t/test6.t .. 1/? Could not set databits on TestPort at t/test6.t line
> 306
> t/test6.t .. ok
> t/test7.t .. ok
> All tests successful.
> Files=7, Tests=1808, 10 wallclock secs ( 0.84 usr + 0.14 sys = 0.98
> CPU)
> Result: PASS
>
> On 21 Mrz., 06:33, Willi wrote:
>
>
>
>
>
>
>
> > Die Meldungen sagen m. E. aus, dass die Schnittstelle COM3 nicht richtig
> > initialisiert werden konnte.
>
> > Ich hatte es so verstanden, dass vorher die Initialisierung funktioniert
> > hatte. Oder doch nicht?
>
> > Wenn die Initialisierung des RFXtrx433 richtig funktioniert, sollte beim
> > Start in fhem.log folgendes stehen (natürlich mit anderem
> > Device/Interface-Namen, bei mir ist der Devicename TRX_0 und das
> > Interface /dev/ttyUSB0):
>
> > 2012.03.02 10:16:10 3: Opening TRX_0 device /dev/ttyUSB0
> > 2012.03.02 10:16:11 3: Setting TRX_0 baudrate to 38400
> > 2012.03.02 10:16:11 3: TRX_0 device opened
> > 2012.03.02 10:16:12 1: TRX: Init OK
>
> > Wichtig ist die Meldung "Init OK". Die besagt, dass der entsprechende
> > Init-String zum RFXtrx433 geschickt wurde und die richtige Rückmeldung kam.
> > Wenn Diese Meldung nicht kommt, konnte das Modul nicht mit RFXtrx433
> > kommunzieren.
>
> > Ich vermute, dass bei Dir RFXtrx433 nicht an COM3 ist, sondern an einer
> > anderen Schnittstelle. COM3 ist bei Windows normalerweise auch einer
> > interne Schnittstelle und kein externes USB-Interface.
>
> > Nimm das von mir angegebene Hilfsprogramm RFXmngr und teste auf welcher
> > Schnittstelle RFXtrx433 ist. RFXmngr zeigt Dir die möglichen Schnittstellen
> > an, die Du dann probieren kannst. RFXmngr zeigt Dir auch gleich an, was
> > RFXtrx433 empfängt. Du solltest die Meldungen Deines Oregon-Sensors sehen.
>
> > Alternativ geh in den Windows-Gerätemanager und sieht nach welchem COM-Port
> > das Device zugeordnet ist.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Der Fehler kommt von folgendem Code in der 45_TRX.pm file:
sub
TRX_DoInit($)
{
my $hash = shift;
my $name = $hash->{NAME};
my $err;
my $msg = undef;
my $buf;
my $char = undef ;
# Reset
my $init = pack('H*', "0D00000000000000000000000000");
DevIo_SimpleWrite($hash, $init, 0);
DevIo_TimeoutRead($hash, 0.5);
TRX_Clear($hash);
if(defined($attr{$name}) && defined($attr{$name}{"do_not_init"})) {
Log 1, "TRX: defined with noinit. Do not send init string to
device.";
$hash->{STATE} = "Initialized" if(!$hash->{STATE});
# Reset the counter
delete($hash->{XMIT_TIME});
delete($hash->{NR_CMD_LAST_H});
return undef;
}
#
# Get Status
$init = pack('H*', "0D00000102000000000000000000");
DevIo_SimpleWrite($hash, $init, 0);
$buf = DevIo_TimeoutRead($hash, 0.5);
if (! $buf) {
Log 1, "TRX: Initialization Error: No character read";
return "TRX: Initialization Error $name: no char read";
} elsif ($buf !~ m/^\x0d\x01\x00.........../) {
my $hexline = unpack('H*', $buf);
Log 1, "TRX: Initialization Error hexline='$hexline'";
return "TRX: Initialization Error %name expected char=0x2c, but char=
$char received.";
} else {
Log 1, "TRX: Init OK";
$hash->{STATE} = "Initialized" if(!$hash->{STATE});
}
#
# Reset the counter
delete($hash->{XMIT_TIME});
delete($hash->{NR_CMD_LAST_H});
return undef;
}
On Mar 21, 9:40 am, Martin wrote:
> Ich habe jetzt noch die Baudrate mitangegeben, damit sind die
> Fehlermeldungen beim start von fhem weg, jedoch immernoch kein init.
>
> fhemlog sag hierzu:
>
> 2012.03.21 09:14:20 5: Cmd: >define RFXTRXUSB TRX COM3@38400<
> 2012.03.21 09:14:20 5: Loading ./FHEM/45_TRX.pm
> 2012.03.21 09:14:20 3: Opening RFXTRXUSB device COM3
> 2012.03.21 09:14:20 3: Setting RFXTRXUSB baudrate to 38400
> 2012.03.21 09:14:20 3: RFXTRXUSB device opened
> 2012.03.21 09:14:20 5: SW:
> 2012.03.21 09:14:20 5: SW:
> 2012.03.21 09:14:20 1: TRX: Initialization Error: No character read
> 2012.03.21 09:14:20 1: Cannot init COM3, ignoring it
>
> Kann es sein das man den Rest wie Datenbits, Parität, Stoppbits noch
> angeben muss?
>
> Laut rfxmanager sind die Einstellungen: 38400-8-N-1
>
> On 21 Mrz., 08:58, Martin wrote:
>
>
>
>
>
>
>
> > Hallo,
>
> > also vorher hatte ich den alten rfxcom in der config:
>
> > define rfxcomusb RFXCOM COM3
>
> > Da ich aber den neuen habe habe ich es auf
>
> > define RFXTRXUSB TRX COM3
>
> > geändert.
>
> > Laut RFXmngr ist es tatsächhlich COM3, ich befürchte das irgendetwas
> > bei der installation von Perl bzw diesem komischen Win32 Serial Port
> > Modul schief gegangen ist.
>
> > Bei dem Befehl:
>
> > "perl Makefile.PL TESTPORT=COM3"
>
> > ...
> > Checking if your kit is complete...
> > Looks good
> > Have \perl\site\lib
> > Want \perl\lib
> > Your perl and your Config.pm seem to have different ideas about the
> > architecture they are running on.
> > Perl thinks: [lib]
> > Config says: [MSWin32-x86-multi-thread]
> > This may or may not cause problems. Please check your installation of
> > perl
> > if you have problems building this extension.
> > Writing Makefile for Win32::SerialPort
>
> > Dann:
>
> > :\Perl\lib\Win32-SerialPort-0.22>perl nomake_test
> > t/test1.t .. ok
> > t/test2.t .. ok
> > t/test3.t .. ok
> > t/test4.t .. ok
> > t/test5.t .. ok
> > t/test6.t .. 1/? Could not set databits on TestPort at t/test6.t line
> > 306
> > t/test6.t .. ok
> > t/test7.t .. ok
> > All tests successful.
> > Files=7, Tests=1808, 10 wallclock secs ( 0.84 usr + 0.14 sys = 0.98
> > CPU)
> > Result: PASS
>
> > On 21 Mrz., 06:33, Willi wrote:
>
> > > Die Meldungen sagen m. E. aus, dass die Schnittstelle COM3 nicht richtig
> > > initialisiert werden konnte.
>
> > > Ich hatte es so verstanden, dass vorher die Initialisierung funktioniert
> > > hatte. Oder doch nicht?
>
> > > Wenn die Initialisierung des RFXtrx433 richtig funktioniert, sollte beim
> > > Start in fhem.log folgendes stehen (natürlich mit anderem
> > > Device/Interface-Namen, bei mir ist der Devicename TRX_0 und das
> > > Interface /dev/ttyUSB0):
>
> > > 2012.03.02 10:16:10 3: Opening TRX_0 device /dev/ttyUSB0
> > > 2012.03.02 10:16:11 3: Setting TRX_0 baudrate to 38400
> > > 2012.03.02 10:16:11 3: TRX_0 device opened
> > > 2012.03.02 10:16:12 1: TRX: Init OK
>
> > > Wichtig ist die Meldung "Init OK". Die besagt, dass der entsprechende
> > > Init-String zum RFXtrx433 geschickt wurde und die richtige Rückmeldung kam.
> > > Wenn Diese Meldung nicht kommt, konnte das Modul nicht mit RFXtrx433
> > > kommunzieren.
>
> > > Ich vermute, dass bei Dir RFXtrx433 nicht an COM3 ist, sondern an einer
> > > anderen Schnittstelle. COM3 ist bei Windows normalerweise auch einer
> > > interne Schnittstelle und kein externes USB-Interface.
>
> > > Nimm das von mir angegebene Hilfsprogramm RFXmngr und teste auf welcher
> > > Schnittstelle RFXtrx433 ist. RFXmngr zeigt Dir die möglichen Schnittstellen
> > > an, die Du dann probieren kannst. RFXmngr zeigt Dir auch gleich an, was
> > > RFXtrx433 empfängt. Du solltest die Meldungen Deines Oregon-Sensors sehen.
>
> > > Alternativ geh in den Windows-Gerätemanager und sieht nach welchem COM-Port
> > > das Device zugeordnet ist.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Seltsam sind die Zeilen
2012.03.21 09:14:20 5: SW:
2012.03.21 09:14:20 5: SW:
Dies habe ich so noch nicht gesehen.
Evtl. verhält sich das DevIO unter Windows etwas anders.
Probiert mal folgendes:
-1- Setze
define RFXTRXUSB TRX COM3 noinit
Damit versucht das Modul keinen Initialisierungsstring an RFXtrx433 zu
senden. Das ist normalerweise dafür vorgesehen, wenn man RFXtrx433
Wenn das nicht hilft:
-2- Änderen die Zeilen "DevIo_TimeoutRead($hash, 0.5);" sowie "$buf =
DevIo_TimeoutRead($hash, 0.5);"
auf einen höheren Timeout, z.B.
DevIo_TimeoutRead($hash, 2);
sowie
$buf = DevIo_TimeoutRead($hash, 2);
Evtl. dauert einfach die Rückmeldung länger.
Welche Firmware-Version ist auf Deinem RFXtrx433? Die Version wird Dir von
RFXmngr angezeigt.
MfG Willi
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Ich sehe gerade, dass auch bei noninit fälschlicherweise die Zeilen
"
# Reset
my $init = pack('H*', "0D00000000000000000000000000");
DevIo_SimpleWrite($hash, $init, 0);
DevIo_TimeoutRead($hash, 0.5);
TRX_Clear($hash);
"
ausgeführt werden.
Kommentiere die bei dem nonit-Test am besten aus (per #-Zeichen).
Ich werde das Modul im SVN abändern, dass die Abfrage auf noinit früher
erfolgt.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Danke, ich probiere es aus sobald ich nach Hause komme, wird aber spät.
Evtl vielleicht auch erst Morgen früh.
Gebe dir aber dann gleich bescheid!
Am Mittwoch, 21. März 2012 15:05:37 UTC+1 schrieb Willi:
>
> Seltsam sind die Zeilen
> 2012.03.21 09:14:20 5: SW:
> 2012.03.21 09:14:20 5: SW:
>
> Dies habe ich so noch nicht gesehen.
>
> Evtl. verhält sich das DevIO unter Windows etwas anders.
>
> Probiert mal folgendes:
> -1- Setze
>
> define RFXTRXUSB TRX COM3 noinit
>
> Damit versucht das Modul keinen Initialisierungsstring an RFXtrx433 zu
> senden. Das ist normalerweise dafür vorgesehen, wenn man RFXtrx433
>
> Wenn das nicht hilft:
>
> -2- Änderen die Zeilen "DevIo_TimeoutRead($hash, 0.5);" sowie "$buf =
> DevIo_TimeoutRead($hash, 0.5);"
> auf einen höheren Timeout, z.B.
>
> DevIo_TimeoutRead($hash, 2);
> sowie
> $buf = DevIo_TimeoutRead($hash, 2);
>
> Evtl. dauert einfach die Rückmeldung länger.
>
> Welche Firmware-Version ist auf Deinem RFXtrx433? Die Version wird Dir von
> RFXmngr angezeigt.
>
> MfG Willi
>
>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo,
bei beiden Versuchen leider kein Erfolg.
1. Versuch mit noinit und ausklammern:
2012.03.21 22:31:59 5: Cmd: >define RFXTRXUSB TRX COM3 noinit<
2012.03.21 22:31:59 5: Loading ./FHEM/45_TRX.pm
2012.03.21 22:31:59 1: reload: Error:Modul 45_TRX deactivated:
Global symbol "$init" requires explicit package name at ./FHEM/45_TRX.pm
line 249, <$fh> line 21.
Global symbol "$init" requires explicit package name at ./FHEM/45_TRX.pm
line 250, <$fh> line 21.
2012.03.21 22:31:59 5: Cmd: >define Tempsensor TRX_WEATHER TX3_T<
2012.03.21 22:31:59 5: Loading ./FHEM/46_TRX_WEATHER.pm
2012.03.21 22:31:59 3: No I/O device found for Tempsensor
2012.03.21 22:31:59 5: Triggering global (1 changes)
Ich schau nochmal ob ich das richtige ausgeklammert habe.
2. Versuch mit timeout 8
2012.03.21 22:38:58 5: Cmd: >define RFXTRXUSB TRX COM3@38400<
2012.03.21 22:38:58 5: Loading ./FHEM/45_TRX.pm
2012.03.21 22:38:58 3: Opening RFXTRXUSB device COM3
2012.03.21 22:38:58 3: Setting RFXTRXUSB baudrate to 38400
2012.03.21 22:38:58 3: RFXTRXUSB device opened
2012.03.21 22:38:58 5: SW:
2012.03.21 22:38:58 5: SW:
2012.03.21 22:38:58 1: TRX: Initialization Error: No character read
2012.03.21 22:38:59 1: Cannot init COM3, ignoring it
2012.03.21 22:38:59 5: Triggering global (1 changes)
ActivePerl habe ich auch nochmal neu installiert und das Packet SerialPort
über den Packetmanager installiert, leider ohne Erfolg :(
Am Mittwoch, 21. März 2012 15:05:37 UTC+1 schrieb Willi:
>
> Seltsam sind die Zeilen
> 2012.03.21 09:14:20 5: SW:
> 2012.03.21 09:14:20 5: SW:
>
> Dies habe ich so noch nicht gesehen.
>
> Evtl. verhält sich das DevIO unter Windows etwas anders.
>
> Probiert mal folgendes:
> -1- Setze
>
> define RFXTRXUSB TRX COM3 noinit
>
> Damit versucht das Modul keinen Initialisierungsstring an RFXtrx433 zu
> senden. Das ist normalerweise dafür vorgesehen, wenn man RFXtrx433
>
> Wenn das nicht hilft:
>
> -2- Änderen die Zeilen "DevIo_TimeoutRead($hash, 0.5);" sowie "$buf =
> DevIo_TimeoutRead($hash, 0.5);"
> auf einen höheren Timeout, z.B.
>
> DevIo_TimeoutRead($hash, 2);
> sowie
> $buf = DevIo_TimeoutRead($hash, 2);
>
> Evtl. dauert einfach die Rückmeldung länger.
>
> Welche Firmware-Version ist auf Deinem RFXtrx433? Die Version wird Dir von
> RFXmngr angezeigt.
>
> MfG Willi
>
>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Update:
sieht jetzt besser aus!
2012.03.21 22:56:06 5: Cmd: >define RFXTRXUSB TRX COM3@38400 noinit<
2012.03.21 22:56:06 5: Loading ./FHEM/45_TRX.pm
2012.03.21 22:56:06 1: TRX: RFXTRXUSB no init is done
2012.03.21 22:56:06 3: Opening RFXTRXUSB device COM3
2012.03.21 22:56:06 3: Setting RFXTRXUSB baudrate to 38400
2012.03.21 22:56:06 3: RFXTRXUSB device opened
2012.03.21 22:56:06 1: TRX: defined with noinit. Do not send init string to
device.
2012.03.21 22:56:06 5: Triggering global (1 changes)
ich habe nur die zeilen für write und read ausgeklammert.
Die Temperaturdaten kommen jetzt an!
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?
Am Mittwoch, 21. März 2012 22:43:13 UTC+1 schrieb Martin:
>
> Hallo,
>
> bei beiden Versuchen leider kein Erfolg.
>
> 1. Versuch mit noinit und ausklammern:
>
> 2012.03.21 22:31:59 5: Cmd: >define RFXTRXUSB TRX COM3 noinit<
> 2012.03.21 22:31:59 5: Loading ./FHEM/45_TRX.pm
> 2012.03.21 22:31:59 1: reload: Error:Modul 45_TRX deactivated:
> Global symbol "$init" requires explicit package name at ./FHEM/45_TRX.pm
> line 249, <$fh> line 21.
> Global symbol "$init" requires explicit package name at ./FHEM/45_TRX.pm
> line 250, <$fh> line 21.
>
> 2012.03.21 22:31:59 5: Cmd: >define Tempsensor TRX_WEATHER TX3_T<
> 2012.03.21 22:31:59 5: Loading ./FHEM/46_TRX_WEATHER.pm
> 2012.03.21 22:31:59 3: No I/O device found for Tempsensor
> 2012.03.21 22:31:59 5: Triggering global (1 changes)
>
>
> Ich schau nochmal ob ich das richtige ausgeklammert habe.
>
>
> 2. Versuch mit timeout 8
>
> 2012.03.21 22:38:58 5: Cmd: >define RFXTRXUSB TRX COM3@38400<
> 2012.03.21 22:38:58 5: Loading ./FHEM/45_TRX.pm
> 2012.03.21 22:38:58 3: Opening RFXTRXUSB device COM3
> 2012.03.21 22:38:58 3: Setting RFXTRXUSB baudrate to 38400
> 2012.03.21 22:38:58 3: RFXTRXUSB device opened
> 2012.03.21 22:38:58 5: SW:
>
> 2012.03.21 22:38:58 5: SW:
>
> 2012.03.21 22:38:58 1: TRX: Initialization Error: No character read
> 2012.03.21 22:38:59 1: Cannot init COM3, ignoring it
> 2012.03.21 22:38:59 5: Triggering global (1 changes)
>
>
> ActivePerl habe ich auch nochmal neu installiert und das Packet SerialPort
> über den Packetmanager installiert, leider ohne Erfolg :(
>
>
> Am Mittwoch, 21. März 2012 15:05:37 UTC+1 schrieb Willi:
>>
>> Seltsam sind die Zeilen
>> 2012.03.21 09:14:20 5: SW:
>> 2012.03.21 09:14:20 5: SW:
>>
>> Dies habe ich so noch nicht gesehen.
>>
>> Evtl. verhält sich das DevIO unter Windows etwas anders.
>>
>> Probiert mal folgendes:
>> -1- Setze
>>
>> define RFXTRXUSB TRX COM3 noinit
>>
>> Damit versucht das Modul keinen Initialisierungsstring an RFXtrx433 zu
>> senden. Das ist normalerweise dafür vorgesehen, wenn man RFXtrx433
>>
>> Wenn das nicht hilft:
>>
>> -2- Änderen die Zeilen "DevIo_TimeoutRead($hash, 0.5);" sowie "$buf =
>> DevIo_TimeoutRead($hash, 0.5);"
>> auf einen höheren Timeout, z.B.
>>
>> DevIo_TimeoutRead($hash, 2);
>> sowie
>> $buf = DevIo_TimeoutRead($hash, 2);
>>
>> Evtl. dauert einfach die Rückmeldung länger.
>>
>> Welche Firmware-Version ist auf Deinem RFXtrx433? Die Version wird Dir
>> von RFXmngr angezeigt.
>>
>> MfG Willi
>>
>>
>>
>>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Mittwoch, 21. März 2012 23:04:44 UTC+1 schrieb Martin:
>
> Danke für die Hilfe!!
>
> Kein Problem.
> Was ist der unterschied zwischen init und noinit? Habe ich dadurch
> nachteile?
>
noinit ist normalerweise für die Kopplung mehrerer FHEM-Server mittels
FHEM2FHEM gedacht oder wenn man Testdaten per TCP/IP verwenden will (per
netcat). Ich habe bei mir mehrere FHEM-Server (Produktion, Test für
Entwicklung sowie Programmentwicklung, Fritzbox an der der RFXtrx433
angeschlossen ist), die per FHEM2FHEM gekoppelt sind.
Der Unterschied ist nur, dass man sich bei init sicher sein kann, dass ein
RFXtrx433 angeschlossen ist.
Normalerweise solltge es auch ohne Einschränkungen mit noinit funktionieren.
Was mich wundert ist, dass Du angegeben hast, dass Du auf Oregon-Sensoren
wartest, aber der angegebene TX3_T ein LaCrosse-Temperatursensor ist. Ich
empfange bei mir auch einen, besitze aber keinen. Der ist vermutlich bei
einem der Nachbarhäuser (wo auch immer).
- Siehst Du jetzt in FHEM dieselben Sensoren wie in RFXmngr?
- Welche Firmware-Version setzt Du ein (siehe RFXmngr). Evtl. ist ja ein
Firmware-Update sinnvoll.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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.
Aber ich weis nicht ob es was mit dem RFX zu tun hat oder mit dem Plot
Modul, da ich einige Icons im webfehm auch nicht sehen kann. hmm..
Übrigens nach einem updatefhem funktioniert es auch ohne die Datei in
45_TRX.pm editieren zu müssen, da ich es nochmal mit einer neuinstallation
versucht habe!!
Am Donnerstag, 22. März 2012 07:02:48 UTC+1 schrieb Willi:
>
> Am Mittwoch, 21. März 2012 23:04:44 UTC+1 schrieb Martin:
>>
>> Danke für die Hilfe!!
>>
>> Kein Problem.
>
>
>> Was ist der unterschied zwischen init und noinit? Habe ich dadurch
>> nachteile?
>>
>
> noinit ist normalerweise für die Kopplung mehrerer FHEM-Server mittels
> FHEM2FHEM gedacht oder wenn man Testdaten per TCP/IP verwenden will (per
> netcat). Ich habe bei mir mehrere FHEM-Server (Produktion, Test für
> Entwicklung sowie Programmentwicklung, Fritzbox an der der RFXtrx433
> angeschlossen ist), die per FHEM2FHEM gekoppelt sind.
>
> Der Unterschied ist nur, dass man sich bei init sicher sein kann, dass ein
> RFXtrx433 angeschlossen ist.
>
> Normalerweise solltge es auch ohne Einschränkungen mit noinit
> funktionieren.
>
> Was mich wundert ist, dass Du angegeben hast, dass Du auf Oregon-Sensoren
> wartest, aber der angegebene TX3_T ein LaCrosse-Temperatursensor ist. Ich
> empfange bei mir auch einen, besitze aber keinen. Der ist vermutlich bei
> einem der Nachbarhäuser (wo auch immer).
>
> - Siehst Du jetzt in FHEM dieselben Sensoren wie in RFXmngr?
> - Welche Firmware-Version setzt Du ein (siehe RFXmngr). Evtl. ist ja ein
> Firmware-Update sinnvoll.
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Donnerstag, 22. März 2012 11:56:23 UTC+1 schrieb Martin:
>
> 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.
>
>
>
Uups. Da war ein Fehler in FHEM/temp4.gplot
Bei der Zeile
#FileLog 4:T\x3a:|temperature:0:
ist ein : zuviel.
Richtig ist
#FileLog 4:T\x3a|temperature:0:
Du kannst das händisch in der Datei FHEM/temp4.gplot entsprechend ändern.
Habe ich ansonsten auch gerade im SVN geändert. Daher kannst Du auch bis
morgen früh warten und dann updatefhem erneut ausführen. Dann hast Du das
als Update.
Der gplot wird bei autocreate nur für die TX3-Sensoren verwendet, wenn man
einen RFXtrx433 hat. Deshalb ist es wohl noch niemandem aufgefallen.
Ich verstehe es so, dass Du derzeit mit noinit arbeitest. Richtig?
Kannst Du noch mal prüfen (per RFXmngr), welche Firmware-Version Du bei dem
RFXtrx433 hast?
Falls ich irgendwann mal Zeit habe, versuche ich FHEM mal unter Windows
aufzusetzen und schaue mir das Problem an, warum der init nicht
funktioniert. Sofern Du überhaupt bei Windows als FHEM-Server bleiben
willst.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Donnerstag, 22. März 2012 16:18:33 UTC+1 schrieb Willi:
>
> Am Donnerstag, 22. März 2012 11:56:23 UTC+1 schrieb Martin:
>>
>> 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.
>>
>>
>>
> Uups. Da war ein Fehler in FHEM/temp4.gplot
> Bei der Zeile
> #FileLog 4:T\x3a:|temperature:0:
> ist ein : zuviel.
>
> Richtig ist
> #FileLog 4:T\x3a|temperature:0:
>
> Du kannst das händisch in der Datei FHEM/temp4.gplot entsprechend ändern.
>
> Habe ich ansonsten auch gerade im SVN geändert. Daher kannst Du auch bis
> morgen früh warten und dann updatefhem erneut ausführen. Dann hast Du das
> als Update.
>
> Der gplot wird bei autocreate nur für die TX3-Sensoren verwendet, wenn man
> einen RFXtrx433 hat. Deshalb ist es wohl noch niemandem aufgefallen.
>
> Ich verstehe es so, dass Du derzeit mit noinit arbeitest. Richtig?
> Kannst Du noch mal prüfen (per RFXmngr), welche Firmware-Version Du bei
> dem RFXtrx433 hast?
>
> Falls ich irgendwann mal Zeit habe, versuche ich FHEM mal unter Windows
> aufzusetzen und schaue mir das Problem an, warum der init nicht
> funktioniert. Sofern Du überhaupt bei Windows als FHEM-Server bleiben
> willst.
>
>
Danke, ich werds testen wenn ich nach hause komme.
Sorry wegen der Firmware, hab das ganz vergessen. Ich bin jetzt nicht 100%
sicher aber ich glaube es war die:
FW release 433_28 15-3-2012
Ja ich verwende immernoch noinit und werde auch weiter bei Windows bleiben
da ich hier schon einiges am Laufen habe (Eventghost, USBUIRT, FS20 Sender,
XBMC, Dropbox, Winamp Visualisierung, Twonky Mediaserver, etc, pp) Ich kann
deswegen leider nicht auf Linux wechseln.
Solange es mit noinit funktioniert bleibe ich aber auch gern dabei!
Ansonsten wenn ich dir irgendwie helfen kann, sag mir bescheid.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo,
also es ist wirklich die Firmware wo ich unten geschrieben habe!
Ich hätte noch eine Frage, klappt das Empfangen auch von folgenden Sensoren:
TX 80-TH
TX 3TH
Das sind beide Sensoren von La Crosse mit Temperatur und Luftfeuchtigkeit
gleichzeitig.
Vorteil ist das sie wesentlich günstiger sind als die Oregon (15 anstatt 30
Euro).
Bei 4 Stück wären das 60 anstatt 120 Euro also nicht zu vernachlässigen.
Bei der Recherche bin ich nur auf folgendes gestoßen:
https://groups.google.com/forum/?fromgroups#!searchin/fhem-users/la$20crosse/fhem-users/-gMlMbNSHFk/HtwwXkLyBvcJ
Dh, selbst wenn die Daten ankommen, gäbe es Probleme wie dort beschrieben?
Am Donnerstag, 22. März 2012 18:09:45 UTC+1 schrieb Martin:
>
>
>
> Am Donnerstag, 22. März 2012 16:18:33 UTC+1 schrieb Willi:
>>
>> Am Donnerstag, 22. März 2012 11:56:23 UTC+1 schrieb Martin:
>>>
>>> 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.
>>>
>>>
>>>
>> Uups. Da war ein Fehler in FHEM/temp4.gplot
>> Bei der Zeile
>> #FileLog 4:T\x3a:|temperature:0:
>> ist ein : zuviel.
>>
>> Richtig ist
>> #FileLog 4:T\x3a|temperature:0:
>>
>> Du kannst das händisch in der Datei FHEM/temp4.gplot entsprechend ändern.
>>
>> Habe ich ansonsten auch gerade im SVN geändert. Daher kannst Du auch bis
>> morgen früh warten und dann updatefhem erneut ausführen. Dann hast Du das
>> als Update.
>>
>> Der gplot wird bei autocreate nur für die TX3-Sensoren verwendet, wenn
>> man einen RFXtrx433 hat. Deshalb ist es wohl noch niemandem aufgefallen.
>>
>> Ich verstehe es so, dass Du derzeit mit noinit arbeitest. Richtig?
>> Kannst Du noch mal prüfen (per RFXmngr), welche Firmware-Version Du bei
>> dem RFXtrx433 hast?
>>
>> Falls ich irgendwann mal Zeit habe, versuche ich FHEM mal unter Windows
>> aufzusetzen und schaue mir das Problem an, warum der init nicht
>> funktioniert. Sofern Du überhaupt bei Windows als FHEM-Server bleiben
>> willst.
>>
>>
> Danke, ich werds testen wenn ich nach hause komme.
>
> Sorry wegen der Firmware, hab das ganz vergessen. Ich bin jetzt nicht 100%
> sicher aber ich glaube es war die:
>
> FW release 433_28 15-3-2012
>
> Ja ich verwende immernoch noinit und werde auch weiter bei Windows bleiben
> da ich hier schon einiges am Laufen habe (Eventghost, USBUIRT, FS20 Sender,
> XBMC, Dropbox, Winamp Visualisierung, Twonky Mediaserver, etc, pp) Ich kann
> deswegen leider nicht auf Linux wechseln.
>
> Solange es mit noinit funktioniert bleibe ich aber auch gern dabei!
> Ansonsten wenn ich dir irgendwie helfen kann, sag mir bescheid.
>
>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Freitag, 23. März 2012 15:29:58 UTC+1 schrieb Martin:
>
> Ich hätte noch eine Frage, klappt das Empfangen auch von folgenden
> Sensoren:
>
> TX 80-TH
> TX 3TH
>
>
Ich habe leider keine der Sensoren. In der Dokumentation von RFXCOM steht,
dass von La Crosse TX3, TX4, TX17 empfangen werden können.
Es gibt auch einen speziellen Empfangstyp Humidity der Lacrosse-Sensoren.
Daher würde ich vermuten, dass es zumindest mit dem TX3TH geht.
Humidity für TX3 habe ich in meinem Treiber noch nicht implementiert,
könnte ich aber gerne hinzufügen.
Die Sensoren scheinen Temperatur und Humidity getrennt zu senden. Daher
wirst Du wohl zwei Sensoren in FHEM sehen. Einen für Temperatur und einen
für Luftfeuchtigkeit. Du kannst diese problemlos in dasselbe Filelog
schreiben und kannst dann die gleichen Grafiken wie bei einem einzelnen
Sensor anzeigen.
Ich habe gerade mal bei RFXCOM angefragt, ob die von Dir genannten Sensoren
unterstützt werden und wieviele gleichzeitig. Wenn ich Rückmeldung habe,
melde ich mich wieder.
Der TX3TH scheint keinen DIP-Switch zu haben, bei dem man eine ID
einstellen kann (siehe
http://www.lacrossetechnology.com.au/images/TX3TH/manual_TX3TH_en.pdf ).
Ich weiss allerdings nicht, ob die Sensoren doch eine ID senden, die beim
Einlegen der Batterie zufällig ausgewählt wird. Das ist bei den mir
bekannten Oregon-Sensoren der Fall. Um dies zu unterstützen, gibt es beim
TRX-Treiber das Attribut longids (siehe commandref.html). Damit kann man
auch bei gleichem Dip-Switch-Setting viele Sensoren gleichzeitig
unterscheiden und nutzen. Nachteil ist nur, dass sich die ID nach
Batteriewechsel ändert. Deshalb sollte longids nur verwendet werden, wenn
erforderlich (man also mehr Sensoren eines Typs hat als von der
entsprechenden Wetterstation unterstützt). Nutze ich beisepielsweise, weil
ich mehrere Oregon BTHR918N-Sensoren habe.
Eine Alternative könnten auch andere Oregon-Sensoren sein. Schau mal unter
http://de.oregonscientific.com/shop/browse.asp?cid=2&scid=11
Den 3-Kanalsensor (bedeutet, dass Du drei verschiedene IDs einstellen
kannst) THGN122N gibt es bereits für 17,90 EUR.
Persönlich interesant finde ich den solarbetriebenen Sensor THN132ES (auch
3 IDs). Da entfällt der Batteriewechsel wie auch bei den größeren
Oregon-Wetterstationen.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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?
Ich suche auf jedenfall einen Sensor mit Display für beide Werte.
Was mir aber bei dem La Crosse aufgefallen ist er Sendet nur 1x pro Minute
und die reichweite liegt nur bei 25m.
Die Oregon senden 2x pro Minute oder?
Martin
Am Freitag, 23. März 2012 18:55:29 UTC+1 schrieb Willi:
>
>
> Am Freitag, 23. März 2012 15:29:58 UTC+1 schrieb Martin:
>>
>> Ich hätte noch eine Frage, klappt das Empfangen auch von folgenden
>> Sensoren:
>>
>> TX 80-TH
>> TX 3TH
>>
>>
> Ich habe leider keine der Sensoren. In der Dokumentation von RFXCOM steht,
> dass von La Crosse TX3, TX4, TX17 empfangen werden können.
> Es gibt auch einen speziellen Empfangstyp Humidity der Lacrosse-Sensoren.
> Daher würde ich vermuten, dass es zumindest mit dem TX3TH geht.
>
> Humidity für TX3 habe ich in meinem Treiber noch nicht implementiert,
> könnte ich aber gerne hinzufügen.
>
> Die Sensoren scheinen Temperatur und Humidity getrennt zu senden. Daher
> wirst Du wohl zwei Sensoren in FHEM sehen. Einen für Temperatur und einen
> für Luftfeuchtigkeit. Du kannst diese problemlos in dasselbe Filelog
> schreiben und kannst dann die gleichen Grafiken wie bei einem einzelnen
> Sensor anzeigen.
>
> Ich habe gerade mal bei RFXCOM angefragt, ob die von Dir genannten
> Sensoren unterstützt werden und wieviele gleichzeitig. Wenn ich Rückmeldung
> habe, melde ich mich wieder.
>
> Der TX3TH scheint keinen DIP-Switch zu haben, bei dem man eine ID
> einstellen kann (siehe
> http://www.lacrossetechnology.com.au/images/TX3TH/manual_TX3TH_en.pdf
> ).
>
> Ich weiss allerdings nicht, ob die Sensoren doch eine ID senden, die beim
> Einlegen der Batterie zufällig ausgewählt wird. Das ist bei den mir
> bekannten Oregon-Sensoren der Fall. Um dies zu unterstützen, gibt es beim
> TRX-Treiber das Attribut longids (siehe commandref.html). Damit kann man
> auch bei gleichem Dip-Switch-Setting viele Sensoren gleichzeitig
> unterscheiden und nutzen. Nachteil ist nur, dass sich die ID nach
> Batteriewechsel ändert. Deshalb sollte longids nur verwendet werden, wenn
> erforderlich (man also mehr Sensoren eines Typs hat als von der
> entsprechenden Wetterstation unterstützt). Nutze ich beisepielsweise, weil
> ich mehrere Oregon BTHR918N-Sensoren habe.
>
> Eine Alternative könnten auch andere Oregon-Sensoren sein. Schau mal unter
> http://de.oregonscientific.com/shop/browse.asp?cid=2&scid=11
> Den 3-Kanalsensor (bedeutet, dass Du drei verschiedene IDs einstellen
> kannst) THGN122N gibt es bereits für 17,90 EUR.
> Persönlich interesant finde ich den solarbetriebenen Sensor THN132ES (auch
> 3 IDs). Da entfällt der Batteriewechsel wie auch bei den größeren
> Oregon-Wetterstationen.
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo Martin,
ich habe eine Rückmeldung von RFXCOM erhalten.
Man hat die unter http://www.rfxcom.com/oregon.htm angegebenen Sensoren
getestet. Über weitere kann man keine Aussagen treffen. Dies sind bei
LaCrosse: TX3, TX3P, TX4, TX17
Die genannten LaCrosse-Sensoren haben gemäß RFXCOM eine zufällige ID
zwischen 0 to 127. Man hat allerdings nicht getestet ist wie sich bzgl. des
Funkverkehrs sich die Sensoren bzgl. des Timings verhalten. Die
Oregon-Sensoren nutzen die Kanalnummer, um das Sendeinterval etwas
anzupassen, damit Kollisionen über einen längern Zeitraum vermieden werden.
Ob TX 80-TH und TX 3TH funktionieren ist unklar. Die Wahrscheinlichkeit,
dass diese funktionieren ist vermutlich hoch. Dies müsstest Du also wohl
probieren (evtl. Kaufen mit Rückgaberecht, wenn es nicht klappt?).
Weiterhin steht dort:
"
Tested Cresta sensors (only supported by the RFXtrx433)
TX-320
TS-34C
anemometer
UV sensor
Rain sensor
Tested La Crosse sensors (only supported by the RFXtrx433)
Tested TFA sensors (only supported by the RFXtrx433)
TS34C
Tested UPM / Esic sensors (only supported by the RFXtrx433)
WT440H
WT450
WT450H
"
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Freitag, 23. März 2012 23:35:20 UTC+1 schrieb Martin:
>
> 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?
>
>
Ich setze meine Oregon-Sensoren seit August 2010 mit meinem alten
RFXCOM-Receiver ein. Bisher habe ich bei meinen Sensoren (>10) noch nicht
sehr oft die Batterien gewechselt. Die Batterien halten wesentlich über
ein Jahr. Genau habe ich mir das nicht gemerkt. Gefühlt ist der
Batteriewechsel sehr sehr selten.
Da die Oregon-Sensoren den Batteriezustand mitsenden, kann man sich auf den
Batteriewechsel auch schon ein paar Tage vorher geistig einstellen.........
;-)
Ich mache es wie folgt:
-1- Batteriewechsel
-2- In fhem*.log nachsehen, welches neue Gerät per autocreate auftaucht.
Beispiel BTHR918N_f3
-3- FHEM stoppen.
-4- Die Definitionen des neuen Devices löschen (sind einfach die letzten
Zeilen in fhem.cfg)
-5- Die ID des Devices(defines), bei dem der Batteriewechsel stattfand auf
die neue ID wechseln.
Beispiel:
- Vor Batteriewechsel:
define Wohnzimmer TRX_WEATHER BTHR918N_e6
abändern in
define Wohnzimmer TRX_WEATHER BTHR918N_f3
-6- FHEM neu starten. Das wars.
Danach schreibt FHEM die Werte des Sensors in das gleiche Filelog wie
immer. Man hat also auch noch alle alten Werte und muss auch keine Dateien
umbenennen.
Das kann man sicherlich auch ohne Stoppen von FHEM machen. Da dies so
selten auftritt, mache ich es wie oben beschrieben.
Das ist beim neuen RFXtrx433 aber nur erforderlich, wenn man mehr Sensoren
eines Typs einsetzt als es verschiedene Kanalnumer gibt. Also bei
Verwendung des Attributs longids.
Beim alten RFXCOM-Empfänger habe ich im Treiber immer longids verwendet.
Hier hat man keine Wahlmöglichkeit.
Welche Sensoren mit welchen kompatibel sind und wie viele Kanäle diese
haben, steht unter
http://www2.oregonscientific.com/service/sensors/sensorchart.pdf
.
> Die Oregon senden 2x pro Minute oder?
>
>
Ich habe mir mal kurz Logfiles angesehen. Die von mir eingesetzten
Oregon-Sensoren haben unterschiedliche Sendeintervalle:
- THGR228N, WTGR800_T, BTHR918N, alle 40-43 Sekunden.
- THR128 alle 16 Sekunden
- WTGR800 Windsensor alle 15 Sekunden.
Ich habe nur kurz in die Logfiles reingeschaut.
Die meisten Sensoren scheinen ca. alle 40 Sekunden zu senden.
Steht aber normalerweise auch in der Bedienungsanleitung der jeweiligen
Oregon-Sensores. Google ist Dein Freund ;-)
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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?
Am Samstag, 24. März 2012 10:22:47 UTC+1 schrieb Willi:
>
> Am Freitag, 23. März 2012 23:35:20 UTC+1 schrieb Martin:
>>
>> 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?
>>
>>
> Ich setze meine Oregon-Sensoren seit August 2010 mit meinem alten
> RFXCOM-Receiver ein. Bisher habe ich bei meinen Sensoren (>10) noch nicht
> sehr oft die Batterien gewechselt. Die Batterien halten wesentlich über
> ein Jahr. Genau habe ich mir das nicht gemerkt. Gefühlt ist der
> Batteriewechsel sehr sehr selten.
>
> Da die Oregon-Sensoren den Batteriezustand mitsenden, kann man sich auf
> den Batteriewechsel auch schon ein paar Tage vorher geistig
> einstellen......... ;-)
>
> Ich mache es wie folgt:
> -1- Batteriewechsel
> -2- In fhem*.log nachsehen, welches neue Gerät per autocreate auftaucht.
> Beispiel BTHR918N_f3
> -3- FHEM stoppen.
> -4- Die Definitionen des neuen Devices löschen (sind einfach die letzten
> Zeilen in fhem.cfg)
> -5- Die ID des Devices(defines), bei dem der Batteriewechsel stattfand auf
> die neue ID wechseln.
> Beispiel:
> - Vor Batteriewechsel:
> define Wohnzimmer TRX_WEATHER BTHR918N_e6
> abändern in
> define Wohnzimmer TRX_WEATHER BTHR918N_f3
> -6- FHEM neu starten. Das wars.
>
> Danach schreibt FHEM die Werte des Sensors in das gleiche Filelog wie
> immer. Man hat also auch noch alle alten Werte und muss auch keine Dateien
> umbenennen.
>
> Das kann man sicherlich auch ohne Stoppen von FHEM machen. Da dies so
> selten auftritt, mache ich es wie oben beschrieben.
>
> Das ist beim neuen RFXtrx433 aber nur erforderlich, wenn man mehr Sensoren
> eines Typs einsetzt als es verschiedene Kanalnumer gibt. Also bei
> Verwendung des Attributs longids.
> Beim alten RFXCOM-Empfänger habe ich im Treiber immer longids verwendet.
> Hier hat man keine Wahlmöglichkeit.
>
> Welche Sensoren mit welchen kompatibel sind und wie viele Kanäle diese
> haben, steht unter
> http://www2.oregonscientific.com/service/sensors/sensorchart.pdf
> .
>
>
>> Die Oregon senden 2x pro Minute oder?
>>
>>
> Ich habe mir mal kurz Logfiles angesehen. Die von mir eingesetzten
> Oregon-Sensoren haben unterschiedliche Sendeintervalle:
> - THGR228N, WTGR800_T, BTHR918N, alle 40-43 Sekunden.
> - THR128 alle 16 Sekunden
> - WTGR800 Windsensor alle 15 Sekunden.
> Ich habe nur kurz in die Logfiles reingeschaut.
>
> Die meisten Sensoren scheinen ca. alle 40 Sekunden zu senden.
>
> Steht aber normalerweise auch in der Bedienungsanleitung der jeweiligen
> Oregon-Sensores. Google ist Dein Freund ;-)
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Sonntag, 25. März 2012 14:57:14 UTC+2 schrieb Martin:
>
> 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?
>
>
>>
Nein. Ich muss nur noch eine Routine für einen Sensortyp anlegen, der nur
Humditity-Daten sendet (Die LaCrosse-Sensoren sehen ja für FHEM so als
wären es zwei Sensoren, einmal für Temperatur und einmal für Humidity).
Ich schau mal, wann ich nächste Woche dazu komme dies zu implementieren.
Ich stelle es dann ins SVN ein.
Wenn Du die Sensoren bekommen hast, sag mir dann Bescheid, ob es
funktioniert.
Wenn Du die Sensoren vor meiner Anpassung hast, kannst Du zumindest die
Temperaturdaten bereits empfangen, für Luftfeuchtigkeit-Daten bekommst Du
dann eine Fehlermeldung im Log (mit dem entsprechenden Hex-Wert), dass der
Sensortyp noch nicht realisiert ist. Auf Basis der Fehlermeldung
(Hex-String des Empfangs) können wir dann auch ohne weitere Implementierung
feststellen, ob RFXtrx433 den Sensor richtig empfängt.
Sag mir einfach Bescheid, wenn die Sensoren da sind.
MfG Willi
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Sonntag, 25. März 2012 16:05:40 UTC+2 schrieb Willi:
>
> Ich schau mal, wann ich nächste Woche dazu komme dies zu implementieren.
> Ich stelle es dann ins SVN ein.
>
>
Ging doch etwas schneller ;-)
Habe gerade den Hydro-Teil von TX3 hinzugefügt und ins SVN eingecheckt.
Sollte also ab morgen über updatefhem zur Verfügung stehen.
Wie bereits mitgeteilt, ist das dann ein eigenes Devices für das aber auch
autocreate funktioniert und ein Graph dargestellt wird.
Wenn Du Temperatur und Humidity in einer Anzeige haben willst, musst Du
beides in dieselbe Filelog-Datei schreiben.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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?
Aber danke soweit!
Am Montag, 26. März 2012 21:15:53 UTC+2 schrieb Willi:
>
> Am Sonntag, 25. März 2012 16:05:40 UTC+2 schrieb Willi:
>>
>> Ich schau mal, wann ich nächste Woche dazu komme dies zu implementieren.
>> Ich stelle es dann ins SVN ein.
>>
>>
> Ging doch etwas schneller ;-)
>
> Habe gerade den Hydro-Teil von TX3 hinzugefügt und ins SVN eingecheckt.
> Sollte also ab morgen über updatefhem zur Verfügung stehen.
>
> Wie bereits mitgeteilt, ist das dann ein eigenes Devices für das aber auch
> autocreate funktioniert und ein Graph dargestellt wird.
> Wenn Du Temperatur und Humidity in einer Anzeige haben willst, musst Du
> beides in dieselbe Filelog-Datei schreiben.
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Donnerstag, 12. April 2012 17:51:24 UTC+2 schrieb Martin:
>
> 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?
>
Hmm. Ich habe gerade den Code geprüft. Ist eigentlich bzgl. IDs gleich der
Routine für TX3_T.
Hast Du TX3_H bei longids eingetragen?
MfG Willi
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Danke das wars, ich hatte die longid nicht gesetzt, sorry!
Am Donnerstag, 12. April 2012 18:16:20 UTC+2 schrieb Willi:
>
>
>
> Am Donnerstag, 12. April 2012 17:51:24 UTC+2 schrieb Martin:
>>
>> 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?
>>
>
> Hmm. Ich habe gerade den Code geprüft. Ist eigentlich bzgl. IDs gleich der
> Routine für TX3_T.
>
> Hast Du TX3_H bei longids eingetragen?
>
> MfG Willi
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Commando zurück, es funktioniert immer nur eine longid, nicht bei beiden.
In der Config habe ich:
define RFXTRXUSB TRX COM3@38400 noinit
attr RFXTRXUSB do_not_init 1
attr RFXTRXUSB longids TX3_H
attr RFXTRXUSB longids TX3_T
attr RFXTRXUSB room Wohnzimmer
aber das funktioniert entweder nur bei _H oder nur bei _T nicht aber bei
beiden
Am Donnerstag, 12. April 2012 18:47:14 UTC+2 schrieb Martin:
>
> Danke das wars, ich hatte die longid nicht gesetzt, sorry!
>
> Am Donnerstag, 12. April 2012 18:16:20 UTC+2 schrieb Willi:
>>
>>
>>
>> Am Donnerstag, 12. April 2012 17:51:24 UTC+2 schrieb Martin:
>>>
>>> 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?
>>>
>>
>> Hmm. Ich habe gerade den Code geprüft. Ist eigentlich bzgl. IDs gleich
>> der Routine für TX3_T.
>>
>> Hast Du TX3_H bei longids eingetragen?
>>
>> MfG Willi
>>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Donnerstag, 12. April 2012 19:00:16 UTC+2 schrieb Martin:
>
> Commando zurück, es funktioniert immer nur eine longid, nicht bei beiden.
> In der Config habe ich:
>
> define RFXTRXUSB TRX COM3@38400 noinit
> attr RFXTRXUSB do_not_init 1
> attr RFXTRXUSB longids TX3_H
> attr RFXTRXUSB longids TX3_T
> attr RFXTRXUSB room Wohnzimmer
>
> aber das funktioniert entweder nur bei _H oder nur bei _T nicht aber bei
> beiden
>
>
Es gibt immer nur ein Attribut mit gleichem Namen bei FHEM.
Du kannst aber mehrere bei loingids über Comma separiert angeben.
Probier mal
attr RFXTRXUSB longids TX3_T,TX3_H
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Ah okay danke geht jetzt! sorry wegen den Anfängerfehlern
Am Donnerstag, 12. April 2012 19:06:13 UTC+2 schrieb Willi:
>
> Am Donnerstag, 12. April 2012 19:00:16 UTC+2 schrieb Martin:
>>
>> Commando zurück, es funktioniert immer nur eine longid, nicht bei beiden.
>> In der Config habe ich:
>>
>> define RFXTRXUSB TRX COM3@38400 noinit
>> attr RFXTRXUSB do_not_init 1
>> attr RFXTRXUSB longids TX3_H
>> attr RFXTRXUSB longids TX3_T
>> attr RFXTRXUSB room Wohnzimmer
>>
>> aber das funktioniert entweder nur bei _H oder nur bei _T nicht aber bei
>> beiden
>>
>>
> Es gibt immer nur ein Attribut mit gleichem Namen bei FHEM.
> Du kannst aber mehrere bei loingids über Comma separiert angeben.
>
> Probier mal
>
> attr RFXTRXUSB longids TX3_T,TX3_H
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Donnerstag, 12. April 2012 19:15:21 UTC+2 schrieb Martin:
>
> Ah okay danke geht jetzt! sorry wegen den Anfängerfehlern
>
Kein Problem. Zeigt mir nur, dass meine Dokumentation in commandref
verbesserungswürdig ist. Ich werde ein weiteres Beispiel aufnehmen.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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.1
2012-04-12_19:26:19 TX3_T_07 battery: ok
2012-04-12_19:26:19 TX3_T_07 T: 23.1 BAT: ok
2012-04-12_19:26:19 TX3_H_07 humidity: 39
2012-04-12_19:26:19 TX3_H_07 battery: ok
2012-04-12_19:26:19 TX3_H_07 H: 39 BAT: ok
2012-04-12_19:27:18 TX3_T_07 temperature: 23.1
2012-04-12_19:27:18 TX3_T_07 battery: ok
2012-04-12_19:27:18 TX3_T_07 T: 23.1 BAT: ok
2012-04-12_19:27:18 TX3_H_07 humidity: 39
2012-04-12_19:27:18 TX3_H_07 battery: ok
2012-04-12_19:27:18 TX3_H_07 H: 39 BAT: ok
2012-04-12_19:28:17 TX3_T_07 temperature: 23.1
btw du kannst mir auch unter hippieschuh at gmail.com mailen, will hier
nicht alles zuspammen^^
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Donnerstag, 12. April 2012 20:02:36 UTC+2 schrieb Martin:
>
> 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.1
> 2012-04-12_19:26:19 TX3_T_07 battery: ok
> 2012-04-12_19:26:19 TX3_T_07 T: 23.1 BAT: ok
> 2012-04-12_19:26:19 TX3_H_07 humidity: 39
> 2012-04-12_19:26:19 TX3_H_07 battery: ok
>
>
Das ist eigentlich schon (fast) richtig. Wie die Namen der Spalte 2
aussehen (TX3_T_07, TX3_H_07) ist für den Plot eigentlich egal. Es fehlt
nur noch der entsprechende weblink mit dem Plot temp4hum4.
Ich würde an Deiner Stelle aber erst mal die überflüssigen Einträge T: und
H: herausnehmen und nur temperature, humidity und battery beider Devices
(TX3_T_xx und TX3_H_xx) ins Filelog schreiben. Das wäre folgender Filelog
(bei Annahme der ID 63 für das entsprechende Gerät):
define FileLog_TX3_63 FileLog /var/log/fhem/TX3_63-%Y.log
TX3_(T|H)_63.*(temperature|humidity|battery).*
attr FileLog_TX3_63 logtype temp4hum4:Temp/Hum,text
attr FileLog_TX3_63 room Test-Plots
Danach kommt nur noch ein weblink, der auf das Filelog verweist und
temp4hum4 als Gplot nutzt:
define weblink_TX3_63 weblink fileplot FileLog_TX3_63:temp4hum4:CURRENT
attr weblink_TX3_63 label "TX3_63 Min $data{min1}, Max $data{max1}, Last
$data{currval1}"
attr weblink_TX3_63 room Test-Plots
Das war es dann (hoffentlich) schon.
Leider klappt das nicht automatisch, da sich die LaCrosse TX3 leider die
Daten für Temperatur und Luftfeuchtigkeit getrennt melden. Das machen die
ELV-Geräte wie S300th oder die Oregon-Sensoren besser.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo Willi,
dieses Modul nutze ich seit einiger Zeit erfolgreich mit Home Easy
komponenten. Danke schon mal dafür!
Da ich noch einige alte Philips Funksteckdosen (SBC SB370) für 433,92 MHz
habe und die Fernbedienung über den unterstützten Chip PT2262 verfügt habe
ich Kontakt mit Bert Weijenberg von RFXCOM aufgenommen um diese mit dem
RFXtrx433 nutzen zu können.
Dieser hat mit hohem Einsatz (bis spät in die Nacht) dafür gesorgt, das es
bei mir jetzt mit noch nicht öffentlichen Versionen der Firmware (47) und
des RFXmngr (Auswahl Philips unter Lightning 1) FUNKtioniert. Leider nur
senden aber immerhin.
Jetzt wäre es natürlich schön wenn man das auch in fhem mit deinem Modul
nutzen könnte.
Daher meine Frage: Ist das möglich und was wird dafür benötigt?
Gruß, Tom
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
Originally posted by: <email address deleted>
Hallo Tom!
> Dieser hat mit hohem Einsatz (bis spät in die Nacht) dafür gesorgt, das es
Ja, so kenne ich die Leute von RFXCOM.....
> bei mir jetzt mit noch nicht öffentlichen Versionen der Firmware (47) und
> des RFXmngr (Auswahl Philips unter Lightning 1) FUNKtioniert. Leider nur
> senden aber immerhin.
> Jetzt wäre es natürlich schön wenn man das auch in fhem mit deinem Modul
> nutzen könnte.
> Daher meine Frage: Ist das möglich und was wird dafür benötigt?
Sofern Du noch etwas warten kannst, wird RFXCOM die Firmware und
RFXmngr sicherlich in den nächsten Tagen bereitstellen (derzeit ist
nur Firmware 46 veröffentlicht) und ich kann dies anhand der SDK-Doku
implementieren.
Hilfreich ist aber auf jeden Fall, wenn Du mir angibst, welche
Hexwerte RFXmngr an RFXtrx433 schickt, wenn Du die Philips
Funksteckdosen nutzt. Dazu ist die Ausgabe von RFXmngr und die
Kommentierung von Dir, was Du damit gemacht hast, hilfreich.
Schick mir am besten dazu eine PM. Die Liste interessiert dies
vermutlich kaum.
Die eigentlichen Änderungen an meinen FHEM-Treibern kann ich dann
gerne vornehmen. Ich würde Dir dann jeweils eine Testversion von
46_TRX_LIGHT.pm zum Test bereitstellen, bevor ich dann die getestete
Version ins SVN für die offizielle Verteilung packe.
MfG Willi
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo Willi,
sorry das ich das jetzt erst gelesen habe (Schuld ist das gute Wetter).
Erlich gesagt hab ich keine Ahnung wie ich dir eine PM senden kann - bin
noch ziemlich neu bei den Gruppen. Evtl. ist es das einfachste du sendest
mir per PM deine email-Adresse und ich sende Dir die Firmware und den
RFXmngr zu.
Ich habe bisher die Hauscodes A bis E jeweils Unitcode 1 bis 8 und Group
(alles an/aus) getested und es läuft, ich gehe davon aus das die restlichen
Haus- und Unitcodes ebenfalls arbeiten. Die HEX-Codes könntest Du mit den
o.g. Dateien selbst rausfinden ohne ständiges hin-und-her-mailen. Wie
gesagt empfangen von Fernbedienungssignalen geht (noch) nicht.
Gruß, Tom
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
> Erlich gesagt hab ich keine Ahnung wie ich dir eine PM senden kann - bin
Einfach im Google-Groups-Webinterface auf "Antwort an Autor"
klicken ;-)
Oder auf "Profil anzeigen" klicken, dass wird nach weiterer
Bestätigung die E-Mailadresse angezeigt.
> Ich habe bisher die Hauscodes A bis E jeweils Unitcode 1 bis 8 und Group
> (alles an/aus) getested und es läuft, ich gehe davon aus das die restlichen
> Haus- und Unitcodes ebenfalls arbeiten. Die HEX-Codes könntest Du mit den
> o.g. Dateien selbst rausfinden ohne ständiges hin-und-her-mailen. Wie
> gesagt empfangen von Fernbedienungssignalen geht (noch) nicht.
Es wäre hilfreich, wenn Du ein bis zwei Beispiele der Hex-Codierung
aus RFXmngr senden könntest, die Du später auch verwenden willst. Dann
kann ich das zum gegenchecken nutzen. Das würde die Tests
beschleunigen, da ich dann gleich vergleichen kann ohne auf Deine
Testergebnisse zu warten.
Hintergrund: Ich nutze normalerweise kein Windows (nutze sowohl auf
Client und Server nur Linux), habe meinen RFXtrx433 fest an meinen
FHEM-Server angeschlossen/ausgerichtet und kann daher ohne weiteren
Aufwand RFXmngr nicht ausprobieren.
MfG Willi
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
On 25 Jul., 09:04, Breaker wrote:
> Dieser hat mit hohem Einsatz (bis spät in die Nacht) dafür gesorgt, das es
> bei mir jetzt mit noch nicht öffentlichen Versionen der Firmware (47) und
> des RFXmngr (Auswahl Philips unter Lightning 1) FUNKtioniert. Leider nur
> senden aber immerhin.
> Jetzt wäre es natürlich schön wenn man das auch in fhem mit deinem Modul
> nutzen könnte.
> Daher meine Frage: Ist das möglich und was wird dafür benötigt?
Nach erfolgreichen Tests habe ich das geänderte Modul 46_TRX_LIGHT.pm
sowie angepasste commandref.html (neuer PHILIPS_SBC) ins SVN
eingecheckt.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
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
Originally posted by: <email address deleted>
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
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
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
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
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
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
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
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
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
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
Originally posted by: <email address deleted>
Du hast eine PM dazu...
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com