Neue Modul TRX* für RFXCOM RFXtrx433 transceiver

[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 <name> TRX <device> [noinit]

USB-connected:
<device> specifies the USB port to communicate with the RFXtrx433
receiver. Normally on Linux the device will be named /dev/ttyUSBx,
where x is a number. For example /dev/ttyUSB0.

Example:
define RFXTRXUSB TRX /dev/ttyUSB0

Network-connected devices:
<device> specifies the host:port of the device. E.g. 192.168.1.5:10001
noninit is optional and issues that the RFXtrx433 device should not be
initialized. This is useful if you share a RFXtrx433 device via LAN.
It is also useful for testing to simulate a RFXtrx433 receiver via
netcat.

Example:
define RFXTRXTCP TRX 192.168.1.5:10001
define RFXTRXTCP2 TRX 192.168.1.121:10001 noinit

Attributes
dummy

longids
Comma separates list of device-types for TRX_WEATHER that should be
handles using long ids. This additional ID is a one byte hex string
and is generated by the Oregon sensor when is it powered on. The value
seems to be randomly generated. This has the advantage that you may
use more than one Oregon sensor of the same type even if it has no
switch to set a sensor id. For example the author uses two BTHR918N
sensors at the same time. All have different deviceids. The drawback
is that the deviceid changes after changing batteries.
Example:
attr RFXTRXUSB longids BTHR918N


TRX_SECURITY

The TRX_SECURITY module interprets X10, KD101 and Visonic security
sensors received by a RFXCOM RFXtrx433 RF receiver. You need to define
an RFXtrx433 receiver first. See TRX.

Define
define <name> TRX_SECURITY <type> <deviceid> <devicelog> [<deviceid>
<devicelog>]

<type>
specifies one of the following security devices:
DS10A (X10 security ds10a Door/Window Sensor or compatible devices.
This device type reports the status of the switch [Open/Closed],
status of the delay switch [min|max]], and battery status [ok|low].)
MS10A (X10 security ms10a motion sensor. This device type reports the
status of motion sensor [normal|alert] and battery status [ok|low].))
SD90 (Marmitek sd90 smoke detector. This device type reports the
status of the smoke detector [normal|alert] and battery status [ok|
low].)
KR18 (X10 security remote control. Report the Reading "Security" with
values [Arm|Disarm], "ButtonA" and "ButtonB" with values [on|off] )
KD101 (KD101 smoke sensor. Report the Reading "smoke" with values
[normal|alert])
VISONIC_WINDOW (VISONIC security Door/Window Sensor or compatible
devices. This device type reports the status of the switch [Open/
Closed] and battery status [ok|low].)
VISONIC_MOTION (VISONIC security motion sensor. This device type
reports the status of motion sensor [normal|alert] and battery status
[ok|low].))

<deviceid>
specifies the first device id of the device. X10 security (DS10A,
MS10A) and SD90 have a a 16 bit device id which has to be written as a
hex-string (example "5a54"). All other devices have a 24 bit device
id.

<devicelog>
is the name of the Reading used to report. Suggested: "Window" or
"Door" for ds10a, "motion" for motion sensors, "smoke" for sd90.

<deviceid2>
is optional and specifies the second device id of the device if it
exists. For example sd90 smoke sensors can be configured to report two
device ids.

<devicelog2>
is optional for the name used for the Reading of <deviceid2>.

Example:
define livingroom_window TRX_SECURITY ds10a 72cd Window
define motion_sensor1 TRX_SECURITY ms10a 55c6 motion
define smoke_sensor1 TRX_SECURITY sd90 54d3 Smoke 54d3 Smoketest

Set
N/A

Get
N/A

TRX_LIGHT

The TRX_LIGHT module receives and sends X10, ARC, ELRO AB400D,
Waveman, Chacon EMW200 and IMPULS lighting messages by a RFXtrx433 RF
transceiver. ARC is a protocol used by devices from HomeEasy,
KlikAanKlikUit, ByeByeStandBy, Intertechno, ELRO, AB600, Duewi,
DomiaLite and COCO with address code wheels.
You need to define an RFXtrx433 transceiver receiver first. See TRX.

Define
define <name> TRX_LIGHT <type> <deviceid> <devicelog> [<deviceid>
<devicelog>]

<type>
specifies the type of the device:
X10 lighting devices:
MS14A (X10 motion sensor. Reports [normal|alert] on the first deviceid
(motion sensor) and [on|off] for the second deviceid (light sensor))
X10 (All other x10 devices. Report [on|off] on both deviceids.)
ARC (ARC devices. ARC is a protocol used by devices from HomeEasy,
KlikAanKlikUit, ByeByeStandBy, Intertechno, ELRO, AB600, Duewi,
DomiaLite and COCO with address code wheels. Report [on|off] on both
deviceids.)
AB400D (ELRO AB400D devices. Report [on|off] on both deviceids.)
WAVEMAN (Waveman devices. Report [on|off] on both deviceids.)
EMW200 (Chacon EMW200 devices. Report [on|off] on both deviceids.)
IMPULS (IMPULS devices. Report [on|off] on both deviceids.)

<deviceid>
specifies the first device id of the device. A lighting device has a
house code A..P followed by a unitcode 1..16 (example "B1").

<devicelog>
is the name of the Reading used to report. Suggested: "motion" for
motion sensors.

<deviceid2>
is optional and specifies the second device id of the device if it
exists. For example ms14a motion sensors report motion status on the
first deviceid and the status of the light sensor on the second
deviceid.

<devicelog2>
is optional for the name used for the Reading of <deviceid2>.

Example:
define motion_sensor2 TRX_LIGHT MS14A A1 motion A2 light
define Steckdose TRX_LIGHT ARC G2 light

Set
set <name> <value>

where value is one of:
off
on
dim # only for X10
bright # only for X10
all_off # only for X10, ARC, EMW200
all_on # only for X10, ARC, EMW200
chime # only for ARC

Example:
set Steckdose on

Get
N/A

TRX_WEATHER

The TRX_WEATHER module interprets weather sensor messages received by
a RTXtrx receiver. See http://www.rfxcom.com/oregon.htm for a list of
Oregon Scientific weather sensors that could be received by the
RFXtrx433 tranmitter. You need to define a RFXtrx433 receiver first.
See See TRX.

Define
define <name> OREGON <deviceid>

<deviceid> is the device identifier of the Oregon sensor. It consists
of the sensors name and (only if the attribute longids is set of the
RFXtrx433) an a one byte hex string (00-ff) that identifies the
sensor. If an sensor uses an switch to set an additional is then this
is also added. The define statement with the deviceid is generated
automatically by autocreate. The following sensor names are used:
"THR128" (for THR128/138, THC138),
"THGR132N" (for THC238/268,THN132,THWR288,THRN122,THN122,AW129/131),
"THWR800",
"RTHN318",
"TX3_T" (for LaCrosse TX3, TX4, TX17),
"THGR228N" (for THGN122/123, THGN132, THGR122/228/238/268),
"THGR810",
"RTGR328",
"THGR328",
"WTGR800_T" (for temperature of WTGR800),
"THGR918" (for THGR918, THGRN228, THGN500),
"TFATS34C" (for TFA TS34C),
"BTHR918",
"BTHR918N (for BTHR918N, BTHR968),
"RGR918" (for RGR126/682/918),
"PCR800",
"TFA_RAIN" (for TFA rain sensor),
"WTGR800_A" (for wind sensor of WTGR800),
"WGR800_A" (for wind sensor of WGR800),
"WGR918_A" (for wind sensor of STR918 and WGR918),
"TFA_WIND" (for TFA wind sensor)


Example:
define Tempsensor TRX_WEATHER TX3_T
define Tempsensor3 TRX_WEATHER THR128_3
define Windsensor TRX_WEATHER WGR918_A
define Regensensor TRX_WEATHER RGR918

Set
N/A

Get
N/A

[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?




On 25 Feb., 16:21, Willi <willi.her...@googlemail.com> 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

> 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

> sensors received by aRFXCOMRFXtrx433 RF receiver. You need to define

> a RTXtrx receiver. Seehttp://www.rfxcom.com/oregon.htmfor a list of

[Willi]

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

[Martin]

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 <willi.her...@googlemail.com> 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)

[Willi]

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

[Martin]

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 <willi.her...@googlemail.com> 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>

[Martin]

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?

[Willi]

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.

[Martin]

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

[Martin]

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

[Martin]

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;

[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

[Willi]

 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.

[Martin]

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!

[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:

[Martin]

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?

[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.

 

[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.

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!!

[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.

[Martin]

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.

 

[Martin]

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?

[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.

 

[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 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

[Willi]

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

"

[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 ;-)

[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?

[Willi]

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

[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. 

[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?

Aber danke soweit!

[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

[Martin]

Danke das wars, ich hatte die longid nicht gesetzt, sorry!

[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

[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

[Martin]

Ah okay danke geht jetzt! sorry wegen den Anfängerfehlern

[Willi]

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. 

[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

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^^

[Willi]

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.

[Breaker]

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 <name> TRX <device> [noinit]

USB-connected:
<device> specifies the USB port to communicate with the RFXtrx433
receiver. Normally on Linux the device will be named /dev/ttyUSBx,
where x is a number. For example /dev/ttyUSB0.

Example:
define RFXTRXUSB TRX /dev/ttyUSB0

Network-connected devices:
<device> specifies the host:port of the device. E.g. 192.168.1.5:10001
noninit is optional and issues that the RFXtrx433 device should not be
initialized. This is useful if you share a RFXtrx433 device via LAN.
It is also useful for testing to simulate a RFXtrx433 receiver via
netcat.

Example:
define RFXTRXTCP TRX 192.168.1.5:10001
define RFXTRXTCP2 TRX 192.168.1.121:10001 noinit

Attributes
dummy

longids
Comma separates list of device-types for TRX_WEATHER that should be
handles using long ids. This additional ID is a one byte hex string
and is generated by the Oregon sensor when is it powered on. The value
seems to be randomly generated. This has the advantage that you may
use more than one Oregon sensor of the same type even if it has no
switch to set a sensor id. For example the author uses two BTHR918N
sensors at the same time. All have different deviceids. The drawback
is that the deviceid changes after changing batteries.
Example:
attr RFXTRXUSB longids BTHR918N


TRX_SECURITY

The TRX_SECURITY module interprets X10, KD101 and Visonic security
sensors received by a RFXCOM RFXtrx433 RF receiver. You need to define
an RFXtrx433 receiver first. See TRX.

Define
define <name> TRX_SECURITY <type> <deviceid> <devicelog> [<deviceid>
<devicelog>]

<type>
specifies one of the following security devices:
DS10A (X10 security ds10a Door/Window Sensor or compatible devices.
This device type reports the status of the switch [Open/Closed],
status of the delay switch [min|max]], and battery status [ok|low].)
MS10A (X10 security ms10a motion sensor. This device type reports the
status of motion sensor [normal|alert] and battery status [ok|low].))
SD90 (Marmitek sd90 smoke detector. This device type reports the
status of the smoke detector [normal|alert] and battery status [ok|
low].)
KR18 (X10 security remote control. Report the Reading "Security" with
values [Arm|Disarm], "ButtonA" and "ButtonB" with values [on|off] )
KD101 (KD101 smoke sensor. Report the Reading "smoke" with values
[normal|alert])
VISONIC_WINDOW (VISONIC security Door/Window Sensor or compatible
devices. This device type reports the status of the switch [Open/
Closed] and battery status [ok|low].)
VISONIC_MOTION (VISONIC security motion sensor. This device type
reports the status of motion sensor [normal|alert] and battery status
[ok|low].))

<deviceid>
specifies the first device id of the device. X10 security (DS10A,
MS10A) and SD90 have a a 16 bit device id which has to be written as a
hex-string (example "5a54"). All other devices have a 24 bit device
id.

<devicelog>
is the name of the Reading used to report. Suggested: "Window" or
"Door" for ds10a, "motion" for motion sensors, "smoke" for sd90.

<deviceid2>
is optional and specifies the second device id of the device if it
exists. For example sd90 smoke sensors can be configured to report two
device ids.

<devicelog2>
is optional for the name used for the Reading of <deviceid2>.

Example:
define livingroom_window TRX_SECURITY ds10a 72cd Window
define motion_sensor1 TRX_SECURITY ms10a 55c6 motion
define smoke_sensor1 TRX_SECURITY sd90 54d3 Smoke 54d3 Smoketest

Set
N/A

Get
N/A

TRX_LIGHT

The TRX_LIGHT module receives and sends X10, ARC, ELRO AB400D,
Waveman, Chacon EMW200 and IMPULS lighting messages by a RFXtrx433 RF
transceiver. ARC is a protocol used by devices from HomeEasy,
KlikAanKlikUit, ByeByeStandBy, Intertechno, ELRO, AB600, Duewi,
DomiaLite and COCO with address code wheels.
You need to define an RFXtrx433 transceiver receiver first. See TRX.

Define
define <name> TRX_LIGHT <type> <deviceid> <devicelog> [<deviceid>
<devicelog>]

<type>
specifies the type of the device:
X10 lighting devices:
MS14A (X10 motion sensor. Reports [normal|alert] on the first deviceid
(motion sensor) and [on|off] for the second deviceid (light sensor))
X10 (All other x10 devices. Report [on|off] on both deviceids.)
ARC (ARC devices. ARC is a protocol used by devices from HomeEasy,
KlikAanKlikUit, ByeByeStandBy, Intertechno, ELRO, AB600, Duewi,
DomiaLite and COCO with address code wheels. Report [on|off] on both
deviceids.)
AB400D (ELRO AB400D devices. Report [on|off] on both deviceids.)
WAVEMAN (Waveman devices. Report [on|off] on both deviceids.)
EMW200 (Chacon EMW200 devices. Report [on|off] on both deviceids.)
IMPULS (IMPULS devices. Report [on|off] on both deviceids.)

<deviceid>
specifies the first device id of the device. A lighting device has a
house code A..P followed by a unitcode 1..16 (example "B1").

<devicelog>
is the name of the Reading used to report. Suggested: "motion" for
motion sensors.

<deviceid2>
is optional and specifies the second device id of the device if it
exists. For example ms14a motion sensors report motion status on the
first deviceid and the status of the light sensor on the second
deviceid.

<devicelog2>
is optional for the name used for the Reading of <deviceid2>.

Example:
define motion_sensor2 TRX_LIGHT MS14A A1 motion A2 light
define Steckdose TRX_LIGHT ARC G2 light

Set
set <name> <value>

where value is one of:
    off
    on
    dim                # only for X10
    bright             # only for X10
    all_off            # only for X10, ARC, EMW200
    all_on             # only for X10, ARC, EMW200
    chime              # only for ARC

Example:
set Steckdose on

Get
N/A

TRX_WEATHER

The TRX_WEATHER module interprets weather sensor messages received by
a RTXtrx receiver. See http://www.rfxcom.com/oregon.htm for a list of
Oregon Scientific weather sensors that could be received by the
RFXtrx433 tranmitter. You need to define a RFXtrx433 receiver first.
See See TRX.

Define
define <name> OREGON <deviceid>

<deviceid> is the device identifier of the Oregon sensor. It consists
of the sensors name and (only if the attribute longids is set of the
RFXtrx433) an a one byte hex string (00-ff) that identifies the
sensor. If an sensor uses an switch to set an additional is then this
is also added. The define statement with the deviceid is generated
automatically by autocreate. The following sensor names are used:
"THR128" (for THR128/138, THC138),
"THGR132N" (for THC238/268,THN132,THWR288,THRN122,THN122,AW129/131),
"THWR800",
"RTHN318",
"TX3_T" (for LaCrosse TX3, TX4, TX17),
"THGR228N" (for THGN122/123, THGN132, THGR122/228/238/268),
"THGR810",
"RTGR328",
"THGR328",
"WTGR800_T" (for temperature of WTGR800),
"THGR918" (for THGR918, THGRN228, THGN500),
"TFATS34C" (for TFA TS34C),
"BTHR918",
"BTHR918N (for BTHR918N, BTHR968),
"RGR918" (for RGR126/682/918),
"PCR800",
"TFA_RAIN" (for TFA rain sensor),
"WTGR800_A" (for wind sensor of WTGR800),
"WGR800_A" (for wind sensor of WGR800),
"WGR918_A" (for wind sensor of STR918 and WGR918),
"TFA_WIND" (for TFA wind sensor)


Example:
define Tempsensor TRX_WEATHER TX3_T
define Tempsensor3 TRX_WEATHER THR128_3
define Windsensor TRX_WEATHER WGR918_A
define Regensensor TRX_WEATHER RGR918

Set
N/A

Get
N/A

[Willi]

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

[Breaker]

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

[Willi]

> 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

[Willi]

On 25 Jul., 09:04, Breaker <upads...@gmail.com> 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 <type> PHILIPS_SBC) ins SVN
eingecheckt.

[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

[Willi]

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

[Sini]

Hallo Willi,

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

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


Grüße...


Sini

[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

[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:

[Sini]

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

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

Und danke dafür...

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


Grüße...

Sini

[Sini]

Hallo WiKu,

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

Also ich hab folgende Sensoren:

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

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

Ich würde die jederzeit wieder kaufen...


Grüße...


Sini

[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

[Sini]

Vielen Dank für die Info...

Grüße...

Sini

[Willi]

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

MfG Willi

[Marc]

Hi Willi,
wäre es ein grosser Aufwand für die IT noch den on-till Befehl zu realisieren?
VG,
Marc

[Willi]

Du hast eine PM dazu...