Neue Modul TRX* für RFXCOM RFXtrx433 transceiver

[Guest]

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

[Guest]

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

[Guest]

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

[Guest]

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

[Guest]

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<http://fhemwiki.de/wiki/Windows_-_FHEM_installierensieht>
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

[Guest]

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<http://fhemwiki.de/wiki/Windows_-_FHEM_installierensieht>
> 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

[Guest]

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<http://fhemwiki.de/wiki/Windows_-_FHEM_installierensieht>
> > 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

[Guest]

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

[Guest]

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

[Guest]

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

[Guest]

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

[Guest]

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

[Guest]

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

[Guest]

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

[Guest]

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