Neue Modul TRX* für RFXCOM RFXtrx433 transceiver

[Guest]

Originally posted by: <email address deleted>

Hallo,

bei beiden Versuchen leider kein Erfolg.

1. Versuch mit noinit und ausklammern:

2012.03.21 22:31:59 5: Cmd: >define RFXTRXUSB TRX COM3 noinit<
2012.03.21 22:31:59 5: Loading ./FHEM/45_TRX.pm
2012.03.21 22:31:59 1: reload: Error:Modul 45_TRX deactivated:
 Global symbol "$init" requires explicit package name at ./FHEM/45_TRX.pm
line 249, <$fh> line 21.
Global symbol "$init" requires explicit package name at ./FHEM/45_TRX.pm
line 250, <$fh> line 21.

2012.03.21 22:31:59 5: Cmd: >define Tempsensor TRX_WEATHER TX3_T<
2012.03.21 22:31:59 5: Loading ./FHEM/46_TRX_WEATHER.pm
2012.03.21 22:31:59 3: No I/O device found for Tempsensor
2012.03.21 22:31:59 5: Triggering global (1 changes)


Ich schau nochmal ob ich das richtige ausgeklammert habe.


2. Versuch mit timeout 8

2012.03.21 22:38:58 5: Cmd: >define RFXTRXUSB TRX COM3@38400<
2012.03.21 22:38:58 5: Loading ./FHEM/45_TRX.pm
2012.03.21 22:38:58 3: Opening RFXTRXUSB device COM3
2012.03.21 22:38:58 3: Setting RFXTRXUSB baudrate to 38400
2012.03.21 22:38:58 3: RFXTRXUSB device opened
2012.03.21 22:38:58 5: SW:
             
2012.03.21 22:38:58 5: SW:
             
2012.03.21 22:38:58 1: TRX: Initialization Error: No character read
2012.03.21 22:38:59 1: Cannot init COM3, ignoring it
2012.03.21 22:38:59 5: Triggering global (1 changes)


ActivePerl habe ich auch nochmal neu installiert und das Packet SerialPort
über den Packetmanager installiert, leider ohne Erfolg


Am Mittwoch, 21. März 2012 15:05:37 UTC+1 schrieb Willi:
>
> Seltsam sind die Zeilen
> 2012.03.21 09:14:20 5: SW:
> 2012.03.21 09:14:20 5: SW:
>
> Dies habe ich so noch nicht gesehen.
>
> Evtl. verhält sich das DevIO unter Windows etwas anders.
>
> Probiert mal folgendes:
> -1- Setze
>
> define RFXTRXUSB TRX COM3 noinit
>
> Damit versucht das Modul keinen Initialisierungsstring an RFXtrx433 zu
> senden. Das ist normalerweise dafür vorgesehen, wenn man RFXtrx433
>
> Wenn das nicht hilft:
>
> -2- Änderen die Zeilen "DevIo_TimeoutRead($hash, 0.5);" sowie "$buf =
> DevIo_TimeoutRead($hash, 0.5);"
> auf einen höheren Timeout, z.B.
>
> DevIo_TimeoutRead($hash, 2);
> sowie
> $buf = DevIo_TimeoutRead($hash, 2);
>
> Evtl. dauert einfach die Rückmeldung länger.
>
> Welche Firmware-Version ist auf Deinem RFXtrx433? Die Version wird Dir von
> RFXmngr angezeigt.
>
> MfG Willi
>
>
>
>

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

[Guest]

Originally posted by: <email address deleted>

Update:

sieht jetzt besser aus!

2012.03.21 22:56:06 5: Cmd: >define RFXTRXUSB TRX COM3@38400 noinit<
2012.03.21 22:56:06 5: Loading ./FHEM/45_TRX.pm
2012.03.21 22:56:06 1: TRX: RFXTRXUSB no init is done
2012.03.21 22:56:06 3: Opening RFXTRXUSB device COM3
2012.03.21 22:56:06 3: Setting RFXTRXUSB baudrate to 38400
2012.03.21 22:56:06 3: RFXTRXUSB device opened
2012.03.21 22:56:06 1: TRX: defined with noinit. Do not send init string to
device.
2012.03.21 22:56:06 5: Triggering global (1 changes)

ich habe nur die zeilen für write und read ausgeklammert.

Die Temperaturdaten kommen jetzt an!

CODE
TX3_T
DEF
TX3_T
NAME
Tempsensor
NR
16
STATE
T: 25.6 BAT: ok
TIME
2012-03-21 23:02:56
TYPE
TRX_WEATHER

Danke für die Hilfe!!

Was ist der unterschied zwischen init und noinit? Habe ich dadurch
nachteile?

Am Mittwoch, 21. März 2012 22:43:13 UTC+1 schrieb Martin:
>
> Hallo,
>
> bei beiden Versuchen leider kein Erfolg.
>
> 1. Versuch mit noinit und ausklammern:
>
> 2012.03.21 22:31:59 5: Cmd: >define RFXTRXUSB TRX COM3 noinit<
> 2012.03.21 22:31:59 5: Loading ./FHEM/45_TRX.pm
> 2012.03.21 22:31:59 1: reload: Error:Modul 45_TRX deactivated:
>  Global symbol "$init" requires explicit package name at ./FHEM/45_TRX.pm
> line 249, <$fh> line 21.
> Global symbol "$init" requires explicit package name at ./FHEM/45_TRX.pm
> line 250, <$fh> line 21.
>
> 2012.03.21 22:31:59 5: Cmd: >define Tempsensor TRX_WEATHER TX3_T<
> 2012.03.21 22:31:59 5: Loading ./FHEM/46_TRX_WEATHER.pm
> 2012.03.21 22:31:59 3: No I/O device found for Tempsensor
> 2012.03.21 22:31:59 5: Triggering global (1 changes)
>
>
> Ich schau nochmal ob ich das richtige ausgeklammert habe.
>
>
> 2. Versuch mit timeout 8
>
> 2012.03.21 22:38:58 5: Cmd: >define RFXTRXUSB TRX COM3@38400<
> 2012.03.21 22:38:58 5: Loading ./FHEM/45_TRX.pm
> 2012.03.21 22:38:58 3: Opening RFXTRXUSB device COM3
> 2012.03.21 22:38:58 3: Setting RFXTRXUSB baudrate to 38400
> 2012.03.21 22:38:58 3: RFXTRXUSB device opened
> 2012.03.21 22:38:58 5: SW:
>              
> 2012.03.21 22:38:58 5: SW:
>              
> 2012.03.21 22:38:58 1: TRX: Initialization Error: No character read
> 2012.03.21 22:38:59 1: Cannot init COM3, ignoring it
> 2012.03.21 22:38:59 5: Triggering global (1 changes)
>
>
> ActivePerl habe ich auch nochmal neu installiert und das Packet SerialPort
> über den Packetmanager installiert, leider ohne Erfolg
>
>
> Am Mittwoch, 21. März 2012 15:05:37 UTC+1 schrieb Willi:
>>
>> Seltsam sind die Zeilen
>> 2012.03.21 09:14:20 5: SW:
>> 2012.03.21 09:14:20 5: SW:
>>
>> Dies habe ich so noch nicht gesehen.
>>
>> Evtl. verhält sich das DevIO unter Windows etwas anders.
>>
>> Probiert mal folgendes:
>> -1- Setze
>>
>> define RFXTRXUSB TRX COM3 noinit
>>
>> Damit versucht das Modul keinen Initialisierungsstring an RFXtrx433 zu
>> senden. Das ist normalerweise dafür vorgesehen, wenn man RFXtrx433
>>
>> Wenn das nicht hilft:
>>
>> -2- Änderen die Zeilen "DevIo_TimeoutRead($hash, 0.5);" sowie "$buf =
>> DevIo_TimeoutRead($hash, 0.5);"
>> auf einen höheren Timeout, z.B.
>>
>> DevIo_TimeoutRead($hash, 2);
>> sowie
>> $buf = DevIo_TimeoutRead($hash, 2);
>>
>> Evtl. dauert einfach die Rückmeldung länger.
>>
>> Welche Firmware-Version ist auf Deinem RFXtrx433? Die Version wird Dir
>> von RFXmngr angezeigt.
>>
>> MfG Willi
>>
>>
>>
>>

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

[Guest]

Originally posted by: <email address deleted>

Am Mittwoch, 21. März 2012 23:04:44 UTC+1 schrieb Martin:
>
> Danke für die Hilfe!!
>
> Kein Problem.
 

> Was ist der unterschied zwischen init und noinit? Habe ich dadurch
> nachteile?
>

noinit ist normalerweise für die Kopplung mehrerer FHEM-Server mittels
FHEM2FHEM gedacht oder wenn man Testdaten per TCP/IP verwenden will (per
netcat). Ich habe bei mir mehrere FHEM-Server (Produktion, Test für
Entwicklung sowie Programmentwicklung, Fritzbox an der der RFXtrx433
angeschlossen ist), die per FHEM2FHEM gekoppelt sind.

Der Unterschied ist nur, dass man sich bei init sicher sein kann, dass ein
RFXtrx433 angeschlossen ist.

Normalerweise solltge es auch ohne Einschränkungen mit noinit funktionieren.

Was mich wundert ist, dass Du angegeben hast, dass Du auf Oregon-Sensoren
wartest, aber der angegebene TX3_T ein LaCrosse-Temperatursensor ist. Ich
empfange bei mir auch einen, besitze aber keinen. Der ist vermutlich bei
einem der Nachbarhäuser (wo auch immer).

- Siehst Du jetzt in FHEM dieselben Sensoren wie in RFXmngr?
- Welche Firmware-Version setzt Du ein (siehe RFXmngr). Evtl. ist ja ein
Firmware-Update sinnvoll.
 

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

[Guest]

Originally posted by: <email address deleted>

Hallo,

Die Sensoren sind die gleichen die auch im rfxmanager angezeigt werden. Es
ist nur so das sie früher gekommen sind als die Oregon.

Aktuell habe ich 2x TX3P von La Crosse.

Es funktioniert alles super bis auf den Plot, da bekomme ich folgende
Fehlermeldung:

Argument "|temperature" isn't numeric in numeric gt (>) at ./FHEM/98_SVG.pm
line 210.
Argument "|temperature" isn't numeric in subtraction (-) at
./FHEM/98_SVG.pm line 450.
Argument "|temperature" isn't numeric in numeric gt (>) at ./FHEM/98_SVG.pm
line 210.
Argument "|temperature" isn't numeric in subtraction (-) at
./FHEM/98_SVG.pm line 450.

Aber ich weis nicht ob es was mit dem RFX zu tun hat oder mit dem Plot
Modul, da ich einige Icons im webfehm auch nicht sehen kann. hmm..

Übrigens nach einem updatefhem funktioniert es auch ohne die Datei in
45_TRX.pm editieren zu müssen, da ich es nochmal mit einer neuinstallation
versucht habe!!

Am Donnerstag, 22. März 2012 07:02:48 UTC+1 schrieb Willi:
>
> Am Mittwoch, 21. März 2012 23:04:44 UTC+1 schrieb Martin:
>>
>> Danke für die Hilfe!!
>>
>> Kein Problem.
>  
>
>> Was ist der unterschied zwischen init und noinit? Habe ich dadurch
>> nachteile?
>>
>
> noinit ist normalerweise für die Kopplung mehrerer FHEM-Server mittels
> FHEM2FHEM gedacht oder wenn man Testdaten per TCP/IP verwenden will (per
> netcat). Ich habe bei mir mehrere FHEM-Server (Produktion, Test für
> Entwicklung sowie Programmentwicklung, Fritzbox an der der RFXtrx433
> angeschlossen ist), die per FHEM2FHEM gekoppelt sind.
>
> Der Unterschied ist nur, dass man sich bei init sicher sein kann, dass ein
> RFXtrx433 angeschlossen ist.
>
> Normalerweise solltge es auch ohne Einschränkungen mit noinit
> funktionieren.
>
> Was mich wundert ist, dass Du angegeben hast, dass Du auf Oregon-Sensoren
> wartest, aber der angegebene TX3_T ein LaCrosse-Temperatursensor ist. Ich
> empfange bei mir auch einen, besitze aber keinen. Der ist vermutlich bei
> einem der Nachbarhäuser (wo auch immer).
>
> - Siehst Du jetzt in FHEM dieselben Sensoren wie in RFXmngr?
> - Welche Firmware-Version setzt Du ein (siehe RFXmngr). Evtl. ist ja ein
> Firmware-Update sinnvoll.
>  
>

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

[Guest]

Originally posted by: <email address deleted>

Am Donnerstag, 22. März 2012 11:56:23 UTC+1 schrieb Martin:
>
> Hallo,
>
> Die Sensoren sind die gleichen die auch im rfxmanager angezeigt werden. Es
> ist nur so das sie früher gekommen sind als die Oregon.
>
> Aktuell habe ich 2x TX3P von La Crosse.
>
> Es funktioniert alles super bis auf den Plot, da bekomme ich folgende
> Fehlermeldung:
>
> Argument "|temperature" isn't numeric in numeric gt (>) at
> ./FHEM/98_SVG.pm line 210.
> Argument "|temperature" isn't numeric in subtraction (-) at
> ./FHEM/98_SVG.pm line 450.
> Argument "|temperature" isn't numeric in numeric gt (>) at
> ./FHEM/98_SVG.pm line 210.
> Argument "|temperature" isn't numeric in subtraction (-) at
> ./FHEM/98_SVG.pm line 450.
>
>
>
Uups. Da war ein Fehler in FHEM/temp4.gplot
Bei der Zeile
          #FileLog 4:T\x3a:|temperature:0:
ist ein : zuviel.

Richtig ist
          #FileLog 4:T\x3a|temperature:0:

Du kannst das händisch in der Datei FHEM/temp4.gplot entsprechend ändern.

Habe ich ansonsten auch gerade im SVN geändert. Daher kannst Du auch bis
morgen früh warten und dann updatefhem erneut ausführen. Dann hast Du das
als Update.

Der gplot wird bei autocreate nur für die TX3-Sensoren verwendet, wenn man
einen RFXtrx433 hat. Deshalb ist es wohl noch niemandem aufgefallen.

Ich verstehe es so, dass Du derzeit mit noinit arbeitest. Richtig?
Kannst Du noch mal prüfen (per RFXmngr), welche Firmware-Version Du bei dem
RFXtrx433 hast?

Falls ich irgendwann mal Zeit habe, versuche ich FHEM mal unter Windows
aufzusetzen und schaue mir das Problem an, warum der init nicht
funktioniert. Sofern Du überhaupt bei Windows als FHEM-Server bleiben
willst.

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

[Guest]

Originally posted by: <email address deleted>

Am Donnerstag, 22. März 2012 16:18:33 UTC+1 schrieb Willi:
>
> Am Donnerstag, 22. März 2012 11:56:23 UTC+1 schrieb Martin:
>>
>> Hallo,
>>
>> Die Sensoren sind die gleichen die auch im rfxmanager angezeigt werden.
>> Es ist nur so das sie früher gekommen sind als die Oregon.
>>
>> Aktuell habe ich 2x TX3P von La Crosse.
>>
>> Es funktioniert alles super bis auf den Plot, da bekomme ich folgende
>> Fehlermeldung:
>>
>> Argument "|temperature" isn't numeric in numeric gt (>) at
>> ./FHEM/98_SVG.pm line 210.
>> Argument "|temperature" isn't numeric in subtraction (-) at
>> ./FHEM/98_SVG.pm line 450.
>> Argument "|temperature" isn't numeric in numeric gt (>) at
>> ./FHEM/98_SVG.pm line 210.
>> Argument "|temperature" isn't numeric in subtraction (-) at
>> ./FHEM/98_SVG.pm line 450.
>>
>>
>>
> Uups. Da war ein Fehler in FHEM/temp4.gplot
> Bei der Zeile
>           #FileLog 4:T\x3a:|temperature:0:
> ist ein : zuviel.
>
> Richtig ist
>           #FileLog 4:T\x3a|temperature:0:
>
> Du kannst das händisch in der Datei FHEM/temp4.gplot entsprechend ändern.
>
> Habe ich ansonsten auch gerade im SVN geändert. Daher kannst Du auch bis
> morgen früh warten und dann updatefhem erneut ausführen. Dann hast Du das
> als Update.
>
> Der gplot wird bei autocreate nur für die TX3-Sensoren verwendet, wenn man
> einen RFXtrx433 hat. Deshalb ist es wohl noch niemandem aufgefallen.
>
> Ich verstehe es so, dass Du derzeit mit noinit arbeitest. Richtig?
> Kannst Du noch mal prüfen (per RFXmngr), welche Firmware-Version Du bei
> dem RFXtrx433 hast?
>
> Falls ich irgendwann mal Zeit habe, versuche ich FHEM mal unter Windows
> aufzusetzen und schaue mir das Problem an, warum der init nicht
> funktioniert. Sofern Du überhaupt bei Windows als FHEM-Server bleiben
> willst.
>
>
Danke, ich werds testen wenn ich nach hause komme.

Sorry wegen der Firmware, hab das ganz vergessen. Ich bin jetzt nicht 100%
sicher aber ich glaube es war die:

FW release 433_28 15-3-2012

Ja ich verwende immernoch noinit und werde auch weiter bei Windows bleiben
da ich hier schon einiges am Laufen habe (Eventghost, USBUIRT, FS20 Sender,
XBMC, Dropbox, Winamp Visualisierung, Twonky Mediaserver, etc, pp) Ich kann
deswegen leider nicht auf Linux wechseln.

Solange es mit noinit funktioniert bleibe ich aber auch gern dabei!
Ansonsten wenn ich dir irgendwie helfen kann, sag mir bescheid.


 

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

[Guest]

Originally posted by: <email address deleted>

Hallo,

also es ist wirklich die Firmware wo ich unten geschrieben habe!

Ich hätte noch eine Frage, klappt das Empfangen auch von folgenden Sensoren:

TX 80-TH
TX 3TH

Das sind beide Sensoren von La Crosse mit Temperatur und Luftfeuchtigkeit
gleichzeitig.

Vorteil ist das sie wesentlich günstiger sind als die Oregon (15 anstatt 30
Euro).
Bei 4 Stück wären das 60 anstatt 120 Euro also nicht zu vernachlässigen.

Bei der Recherche bin ich nur auf folgendes gestoßen:

https://groups.google.com/forum/?fromgroups#!searchin/fhem-users/la$20crosse/fhem-users/-gMlMbNSHFk/HtwwXkLyBvcJ

Dh, selbst wenn die Daten ankommen, gäbe es Probleme wie dort beschrieben?




Am Donnerstag, 22. März 2012 18:09:45 UTC+1 schrieb Martin:
>
>
>
> Am Donnerstag, 22. März 2012 16:18:33 UTC+1 schrieb Willi:
>>
>> Am Donnerstag, 22. März 2012 11:56:23 UTC+1 schrieb Martin:
>>>
>>> Hallo,
>>>
>>> Die Sensoren sind die gleichen die auch im rfxmanager angezeigt werden.
>>> Es ist nur so das sie früher gekommen sind als die Oregon.
>>>
>>> Aktuell habe ich 2x TX3P von La Crosse.
>>>
>>> Es funktioniert alles super bis auf den Plot, da bekomme ich folgende
>>> Fehlermeldung:
>>>
>>> Argument "|temperature" isn't numeric in numeric gt (>) at
>>> ./FHEM/98_SVG.pm line 210.
>>> Argument "|temperature" isn't numeric in subtraction (-) at
>>> ./FHEM/98_SVG.pm line 450.
>>> Argument "|temperature" isn't numeric in numeric gt (>) at
>>> ./FHEM/98_SVG.pm line 210.
>>> Argument "|temperature" isn't numeric in subtraction (-) at
>>> ./FHEM/98_SVG.pm line 450.
>>>
>>>
>>>
>> Uups. Da war ein Fehler in FHEM/temp4.gplot
>> Bei der Zeile
>>           #FileLog 4:T\x3a:|temperature:0:
>> ist ein : zuviel.
>>
>> Richtig ist
>>           #FileLog 4:T\x3a|temperature:0:
>>
>> Du kannst das händisch in der Datei FHEM/temp4.gplot entsprechend ändern.
>>
>> Habe ich ansonsten auch gerade im SVN geändert. Daher kannst Du auch bis
>> morgen früh warten und dann updatefhem erneut ausführen. Dann hast Du das
>> als Update.
>>
>> Der gplot wird bei autocreate nur für die TX3-Sensoren verwendet, wenn
>> man einen RFXtrx433 hat. Deshalb ist es wohl noch niemandem aufgefallen.
>>
>> Ich verstehe es so, dass Du derzeit mit noinit arbeitest. Richtig?
>> Kannst Du noch mal prüfen (per RFXmngr), welche Firmware-Version Du bei
>> dem RFXtrx433 hast?
>>
>> Falls ich irgendwann mal Zeit habe, versuche ich FHEM mal unter Windows
>> aufzusetzen und schaue mir das Problem an, warum der init nicht
>> funktioniert. Sofern Du überhaupt bei Windows als FHEM-Server bleiben
>> willst.
>>
>>
> Danke, ich werds testen wenn ich nach hause komme.
>
> Sorry wegen der Firmware, hab das ganz vergessen. Ich bin jetzt nicht 100%
> sicher aber ich glaube es war die:
>
> FW release 433_28 15-3-2012
>
> Ja ich verwende immernoch noinit und werde auch weiter bei Windows bleiben
> da ich hier schon einiges am Laufen habe (Eventghost, USBUIRT, FS20 Sender,
> XBMC, Dropbox, Winamp Visualisierung, Twonky Mediaserver, etc, pp) Ich kann
> deswegen leider nicht auf Linux wechseln.
>
> Solange es mit noinit funktioniert bleibe ich aber auch gern dabei!
> Ansonsten wenn ich dir irgendwie helfen kann, sag mir bescheid.
>
>
>  
>

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

[Guest]

Originally posted by: <email address deleted>

Am Freitag, 23. März 2012 15:29:58 UTC+1 schrieb Martin:
>
> Ich hätte noch eine Frage, klappt das Empfangen auch von folgenden
> Sensoren:
>
> TX 80-TH
> TX 3TH
>
>
Ich habe leider keine der Sensoren. In der Dokumentation von RFXCOM steht,
dass von La Crosse TX3, TX4, TX17 empfangen werden können.
Es gibt auch einen speziellen Empfangstyp Humidity der Lacrosse-Sensoren.
Daher würde ich vermuten, dass es zumindest mit dem TX3TH geht.

Humidity für TX3 habe ich in meinem Treiber noch nicht implementiert,
könnte ich aber gerne hinzufügen.

Die Sensoren scheinen Temperatur und Humidity getrennt zu senden. Daher
wirst Du wohl zwei Sensoren in FHEM sehen. Einen für Temperatur und einen
für Luftfeuchtigkeit. Du kannst diese problemlos in dasselbe Filelog
schreiben und kannst dann die gleichen Grafiken wie bei einem einzelnen
Sensor anzeigen.

Ich habe gerade mal bei RFXCOM angefragt, ob die von Dir genannten Sensoren
unterstützt werden und wieviele gleichzeitig. Wenn ich Rückmeldung habe,
melde ich mich wieder.

Der TX3TH scheint keinen DIP-Switch zu haben, bei dem man eine ID
einstellen kann (siehe
http://www.lacrossetechnology.com.au/images/TX3TH/manual_TX3TH_en.pdf ).

Ich weiss allerdings nicht, ob die Sensoren doch eine ID senden, die beim
Einlegen der Batterie zufällig ausgewählt wird. Das ist bei den mir
bekannten Oregon-Sensoren der Fall. Um dies zu unterstützen, gibt es beim
TRX-Treiber das Attribut longids (siehe commandref.html). Damit kann man
auch bei gleichem Dip-Switch-Setting viele Sensoren gleichzeitig
unterscheiden und nutzen. Nachteil ist nur, dass sich die ID nach
Batteriewechsel ändert. Deshalb sollte longids nur verwendet werden, wenn
erforderlich (man also mehr Sensoren eines Typs hat als von der
entsprechenden Wetterstation unterstützt). Nutze ich beisepielsweise, weil
ich mehrere Oregon BTHR918N-Sensoren habe.

Eine Alternative könnten auch andere Oregon-Sensoren sein. Schau mal unter
http://de.oregonscientific.com/shop/browse.asp?cid=2&scid=11
Den 3-Kanalsensor (bedeutet, dass Du drei verschiedene IDs einstellen
kannst) THGN122N gibt es bereits für 17,90 EUR.
Persönlich interesant finde ich den solarbetriebenen Sensor THN132ES (auch
3 IDs). Da entfällt der Batteriewechsel wie auch bei den größeren
Oregon-Wetterstationen.
 

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

[Guest]

Originally posted by: <email address deleted>

Danke für die Info!

Ich verwende derzeit die longid option mit zwei La Crosse TX3, funktioniert
soweit ganz gut.
Dh. wenn ich einen Batterie wechsel machen muss, muss ich den Sensor wieder
umbenennen in den alten alias?
Oder heißt das ich muss alle Logs, einstellungen, Scripte, etc die auf den
Sensor programmiert sind auch wieder ändern?

Ich suche auf jedenfall einen Sensor mit Display für beide Werte.
Was mir aber bei dem La Crosse aufgefallen ist er Sendet nur 1x pro Minute
und die reichweite liegt nur bei 25m.

Die Oregon senden 2x pro Minute oder?

Martin


Am Freitag, 23. März 2012 18:55:29 UTC+1 schrieb Willi:
>
>
> Am Freitag, 23. März 2012 15:29:58 UTC+1 schrieb Martin:
>>
>> Ich hätte noch eine Frage, klappt das Empfangen auch von folgenden
>> Sensoren:
>>
>> TX 80-TH
>> TX 3TH
>>
>>
> Ich habe leider keine der Sensoren. In der Dokumentation von RFXCOM steht,
> dass von La Crosse TX3, TX4, TX17 empfangen werden können.
> Es gibt auch einen speziellen Empfangstyp Humidity der Lacrosse-Sensoren.
> Daher würde ich vermuten, dass es zumindest mit dem TX3TH geht.
>
> Humidity für TX3 habe ich in meinem Treiber noch nicht implementiert,
> könnte ich aber gerne hinzufügen.
>
> Die Sensoren scheinen Temperatur und Humidity getrennt zu senden. Daher
> wirst Du wohl zwei Sensoren in FHEM sehen. Einen für Temperatur und einen
> für Luftfeuchtigkeit. Du kannst diese problemlos in dasselbe Filelog
> schreiben und kannst dann die gleichen Grafiken wie bei einem einzelnen
> Sensor anzeigen.
>
> Ich habe gerade mal bei RFXCOM angefragt, ob die von Dir genannten
> Sensoren unterstützt werden und wieviele gleichzeitig. Wenn ich Rückmeldung
> habe, melde ich mich wieder.
>
> Der TX3TH scheint keinen DIP-Switch zu haben, bei dem man eine ID
> einstellen kann (siehe
> http://www.​lacrossetechnology.com.au/​images/TX3TH/manual_TX3TH_en.​pdf<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<http://de.oregonscientific.com/shop/browse.asp?cid=2&scid=11>
> Den 3-Kanalsensor (bedeutet, dass Du drei verschiedene IDs einstellen
> kannst) THGN122N gibt es bereits für 17,90 EUR.
> Persönlich interesant finde ich den solarbetriebenen Sensor THN132ES (auch
> 3 IDs). Da entfällt der Batteriewechsel wie auch bei den größeren
> Oregon-Wetterstationen.
>  
>

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

[Guest]

Originally posted by: <email address deleted>

Hallo Martin,

ich habe eine Rückmeldung von RFXCOM erhalten.

Man hat die unter http://www.rfxcom.com/oregon.htm angegebenen Sensoren
getestet. Über weitere kann man keine Aussagen treffen. Dies sind bei
LaCrosse: TX3, TX3P, TX4, TX17

Die genannten LaCrosse-Sensoren haben gemäß RFXCOM eine zufällige ID
zwischen 0 to 127. Man hat allerdings nicht getestet ist wie sich bzgl. des
Funkverkehrs sich die Sensoren bzgl. des Timings verhalten. Die
Oregon-Sensoren nutzen die Kanalnummer, um das Sendeinterval etwas
anzupassen, damit Kollisionen über einen längern Zeitraum vermieden werden.

Ob TX 80-TH und TX 3TH funktionieren ist unklar. Die Wahrscheinlichkeit,
dass diese funktionieren ist vermutlich hoch. Dies müsstest Du also wohl
probieren (evtl. Kaufen mit Rückgaberecht, wenn es nicht klappt?).

Weiterhin steht dort:
"
Tested Cresta sensors (only supported by the RFXtrx433)
TX-320
TS-34C
anemometer
UV sensor
Rain sensor
 
Tested La Crosse sensors (only supported by the RFXtrx433)
 
Tested TFA sensors (only supported by the RFXtrx433)
TS34C

Tested UPM / Esic sensors (only supported by the RFXtrx433)
WT440H
WT450
WT450H
"

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

[Guest]

Originally posted by: <email address deleted>

Am Freitag, 23. März 2012 23:35:20 UTC+1 schrieb Martin:
>
> Danke für die Info!
>
> Ich verwende derzeit die longid option mit zwei La Crosse TX3,
> funktioniert soweit ganz gut.
> Dh. wenn ich einen Batterie wechsel machen muss, muss ich den Sensor
> wieder umbenennen in den alten alias?
> Oder heißt das ich muss alle Logs, einstellungen, Scripte, etc die auf den
> Sensor programmiert sind auch wieder ändern?
>
>
Ich setze meine Oregon-Sensoren seit August 2010 mit meinem alten
RFXCOM-Receiver ein. Bisher habe ich bei meinen Sensoren (>10) noch nicht
sehr oft die Batterien gewechselt.  Die Batterien halten wesentlich über
ein Jahr. Genau habe ich mir das nicht gemerkt. Gefühlt ist der
Batteriewechsel sehr sehr selten.

Da die Oregon-Sensoren den Batteriezustand mitsenden, kann man sich auf den
Batteriewechsel auch schon ein paar Tage vorher geistig einstellen.........


 Ich mache es wie folgt:
-1- Batteriewechsel
-2- In fhem*.log nachsehen, welches neue Gerät per autocreate auftaucht.
Beispiel BTHR918N_f3
-3- FHEM  stoppen.
-4- Die Definitionen des neuen Devices löschen (sind einfach die letzten
Zeilen in fhem.cfg)
-5- Die ID des Devices(defines), bei dem der Batteriewechsel stattfand auf
die neue ID wechseln.
  Beispiel:
  - Vor Batteriewechsel:
     define Wohnzimmer TRX_WEATHER BTHR918N_e6
  abändern in
     define Wohnzimmer TRX_WEATHER BTHR918N_f3
-6- FHEM neu starten. Das wars.

Danach schreibt FHEM die Werte des Sensors in das gleiche Filelog wie
immer. Man hat also auch noch alle alten Werte und  muss auch keine Dateien
umbenennen.

Das kann man sicherlich auch ohne Stoppen von FHEM machen. Da dies so
selten auftritt, mache ich es wie oben beschrieben.

Das ist beim neuen RFXtrx433 aber nur erforderlich, wenn man mehr Sensoren
eines Typs einsetzt als es verschiedene Kanalnumer gibt. Also bei
Verwendung des Attributs longids.
Beim alten RFXCOM-Empfänger habe ich im Treiber immer longids verwendet.
Hier hat man keine Wahlmöglichkeit.

Welche Sensoren mit welchen kompatibel sind und wie viele Kanäle diese
haben, steht unter
http://www2.oregonscientific.com/service/sensors/sensorchart.pdf
.


> Die Oregon senden 2x pro Minute oder?
>
>
Ich habe mir mal kurz Logfiles angesehen. Die von mir eingesetzten
Oregon-Sensoren haben unterschiedliche Sendeintervalle:
- THGR228N, WTGR800_T, BTHR918N, alle 40-43 Sekunden.
- THR128 alle 16 Sekunden
-  WTGR800 Windsensor alle 15 Sekunden.
Ich habe nur kurz in die Logfiles reingeschaut.

Die meisten Sensoren scheinen ca. alle 40 Sekunden zu senden.

Steht aber normalerweise auch in der Bedienungsanleitung der jeweiligen
Oregon-Sensores. Google ist Dein Freund

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

[Guest]

Originally posted by: <email address deleted>

Okay, dann versuch ich mal die TX3TH.
Ich werde sie wohl in den nächsten 10 Tagen erhalten.

Brauchst du dann Daten von mir um sie in fhem einzubinden?


Am Samstag, 24. März 2012 10:22:47 UTC+1 schrieb Willi:
>
> Am Freitag, 23. März 2012 23:35:20 UTC+1 schrieb Martin:
>>
>> Danke für die Info!
>>
>> Ich verwende derzeit die longid option mit zwei La Crosse TX3,
>> funktioniert soweit ganz gut.
>> Dh. wenn ich einen Batterie wechsel machen muss, muss ich den Sensor
>> wieder umbenennen in den alten alias?
>> Oder heißt das ich muss alle Logs, einstellungen, Scripte, etc die auf
>> den Sensor programmiert sind auch wieder ändern?
>>
>>
> Ich setze meine Oregon-Sensoren seit August 2010 mit meinem alten
> RFXCOM-Receiver ein. Bisher habe ich bei meinen Sensoren (>10) noch nicht
> sehr oft die Batterien gewechselt.  Die Batterien halten wesentlich über
> ein Jahr. Genau habe ich mir das nicht gemerkt. Gefühlt ist der
> Batteriewechsel sehr sehr selten.
>
> Da die Oregon-Sensoren den Batteriezustand mitsenden, kann man sich auf
> den Batteriewechsel auch schon ein paar Tage vorher geistig
> einstellen.........
>
>  Ich mache es wie folgt:
> -1- Batteriewechsel
> -2- In fhem*.log nachsehen, welches neue Gerät per autocreate auftaucht.
> Beispiel BTHR918N_f3
> -3- FHEM  stoppen.
> -4- Die Definitionen des neuen Devices löschen (sind einfach die letzten
> Zeilen in fhem.cfg)
> -5- Die ID des Devices(defines), bei dem der Batteriewechsel stattfand auf
> die neue ID wechseln.
>   Beispiel:
>   - Vor Batteriewechsel:
>      define Wohnzimmer TRX_WEATHER BTHR918N_e6
>   abändern in
>      define Wohnzimmer TRX_WEATHER BTHR918N_f3
> -6- FHEM neu starten. Das wars.
>
> Danach schreibt FHEM die Werte des Sensors in das gleiche Filelog wie
> immer. Man hat also auch noch alle alten Werte und  muss auch keine Dateien
> umbenennen.
>
> Das kann man sicherlich auch ohne Stoppen von FHEM machen. Da dies so
> selten auftritt, mache ich es wie oben beschrieben.
>
> Das ist beim neuen RFXtrx433 aber nur erforderlich, wenn man mehr Sensoren
> eines Typs einsetzt als es verschiedene Kanalnumer gibt. Also bei
> Verwendung des Attributs longids.
> Beim alten RFXCOM-Empfänger habe ich im Treiber immer longids verwendet.
> Hier hat man keine Wahlmöglichkeit.
>
> Welche Sensoren mit welchen kompatibel sind und wie viele Kanäle diese
> haben, steht unter
> http://www2.​oregonscientific.com/service/​sensors/sensorchart.pdf<http://www2.oregonscientific.com/service/sensors/sensorchart.pdf>
> .
>
>
>> Die Oregon senden 2x pro Minute oder?
>>
>>
> Ich habe mir mal kurz Logfiles angesehen. Die von mir eingesetzten
> Oregon-Sensoren haben unterschiedliche Sendeintervalle:
> - THGR228N, WTGR800_T, BTHR918N, alle 40-43 Sekunden.
> - THR128 alle 16 Sekunden
> -  WTGR800 Windsensor alle 15 Sekunden.
> Ich habe nur kurz in die Logfiles reingeschaut.
>
> Die meisten Sensoren scheinen ca. alle 40 Sekunden zu senden.
>
> Steht aber normalerweise auch in der Bedienungsanleitung der jeweiligen
> Oregon-Sensores. Google ist Dein Freund
>
>

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

[Guest]

Originally posted by: <email address deleted>

Am Sonntag, 25. März 2012 14:57:14 UTC+2 schrieb Martin:
>
> Okay, dann versuch ich mal die TX3TH.
> Ich werde sie wohl in den nächsten 10 Tagen erhalten.
>
> Brauchst du dann Daten von mir um sie in fhem einzubinden?
>
>
>>
Nein. Ich muss nur noch eine Routine für einen Sensortyp anlegen, der nur
Humditity-Daten sendet (Die LaCrosse-Sensoren sehen ja für FHEM so als
wären es zwei Sensoren, einmal für Temperatur und einmal für Humidity).

Ich schau mal, wann ich nächste Woche dazu komme dies zu implementieren.
Ich stelle es dann ins SVN ein.

Wenn Du die Sensoren bekommen hast, sag mir dann Bescheid, ob es
funktioniert.

Wenn Du die Sensoren vor meiner Anpassung hast, kannst Du zumindest die
Temperaturdaten bereits empfangen, für Luftfeuchtigkeit-Daten bekommst Du
dann eine Fehlermeldung im Log (mit dem entsprechenden Hex-Wert), dass der
Sensortyp noch nicht realisiert ist. Auf Basis der Fehlermeldung
(Hex-String des Empfangs) können wir dann auch ohne weitere Implementierung
feststellen, ob RFXtrx433 den Sensor richtig empfängt.

Sag mir einfach Bescheid, wenn die Sensoren da sind.

MfG Willi

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

[Guest]

Originally posted by: <email address deleted>

Am Sonntag, 25. März 2012 16:05:40 UTC+2 schrieb Willi:
>
> Ich schau mal, wann ich nächste Woche dazu komme dies zu implementieren.
> Ich stelle es dann ins SVN ein.
>
>
Ging doch etwas schneller

Habe gerade den Hydro-Teil von TX3 hinzugefügt und ins SVN  eingecheckt.
Sollte also ab morgen über updatefhem zur Verfügung stehen.

Wie bereits mitgeteilt, ist das dann ein eigenes Devices für das aber auch
autocreate funktioniert und ein Graph dargestellt wird.
Wenn Du Temperatur und Humidity in einer Anzeige haben willst, musst Du
beides in dieselbe Filelog-Datei schreiben.

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

[Guest]

Originally posted by: <email address deleted>

Hallo, ich habe nun endlich die Sensoren bekommen.

Funktioniert sehr gut bis auf das Hygrometer. Das Problem ist das nur ein
von 4 Hygrometern angezeigt wird.
Warscheinlich weil der Name "TX3_H" lautet und nicht wie bei Temperatur
z.B. "TX3_T_07" also es fehlt der _XX teil.

Kriegst du das noch hin?

Aber danke soweit!

Am Montag, 26. März 2012 21:15:53 UTC+2 schrieb Willi:
>
> Am Sonntag, 25. März 2012 16:05:40 UTC+2 schrieb Willi:
>>
>> Ich schau mal, wann ich nächste Woche dazu komme dies zu implementieren.
>> Ich stelle es dann ins SVN ein.
>>
>>
> Ging doch etwas schneller
>
> Habe gerade den Hydro-Teil von TX3 hinzugefügt und ins SVN  eingecheckt.
> Sollte also ab morgen über updatefhem zur Verfügung stehen.
>
> Wie bereits mitgeteilt, ist das dann ein eigenes Devices für das aber auch
> autocreate funktioniert und ein Graph dargestellt wird.
> Wenn Du Temperatur und Humidity in einer Anzeige haben willst, musst Du
> beides in dieselbe Filelog-Datei schreiben.
>

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