TFA 30.3166 wird nicht erkannt

Begonnen von domi-ch, 20 August 2013, 21:14:40

Vorheriges Thema - Nächstes Thema

domi-ch

Guten Abend!

ich bin vor kurzem zur Welt von FHEM und RFXTRX gestossen. Für einige Monate hatte ich einen TellusNet im Einsatz, war eigentlich zufrienden, wollte aber ein bisschen mehr machen können, und habe nun auf RFXTRX und RPi gewechselt - oder bin dran zu wechseln.

Meine bestehenden Intertechno Aktoren und Sensoren funktioniern ganz gut mit dem RFXTRX & FHEM. Zudem hatte ich mit dem Tellus auch 3 Temp- & Feuchtigkeitssensoren im Einsatz (Model: TFA 30.3166). Leider werden diese von FHEM nicht erkannt, und auch direkt im RFX manager sehe ich die Geräte nicht (obwohl ich nicht genau weiss, welchen Modus ich da auswählen müsste).

Andere TFA Sensoren scheinen zu funktionieren (was man so liest), und eben auch mit dem TellusNet hatte ich keine Probleme.

Ich danke bereits im voraus, sollte jemand mit diesen Sensoren Erfahrung haben und/oder mir sonst helfen kann.

Vielen Dank!
Domi

Willi

Hallo,

was wird in fhem*.log bei Dir zur Initialisierung angezeigt?

Dass ist eine Zeile ähnlich wie diese
2013.08.17 22:46:26 1: TRX: Init status: '433.92MHz transceiver, firmware=67, protocols enabled: LaCrosse Hideki OREGON HOMEEASY AC ARC X10 '

Poste mal diese Zeile hier.


Gemäß http://www.rfxcom.com/Documents/RFXtrx%20User%20Guide.pdf (siehe page 3, Zeile 2) musst Du für TFA-Sensoren das Protokoll Hideki in RFXmngr für den RFxtrx433 freischalten.

In der Protokollaufzählung muss also wie hier gezeigt Hideki angezeigt werden.

Wenn Hideki nicht ausgewählt ist: Wähle in RFXmngr Hideki als Protokoll aus und speichere auch gleich die ausgewählten Protokolle ab, so dass diese Protokollauswahl auch in FHEM genutzt wird.

Wenn Du schon Hideki ausgewählt hattest, könnte es auch sein, dass der Sensor noch nicht unterstützt wird. Wende Dich in diesem Fall direkt an RFXCOM.

-- Willi
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

domi-ch

Zuerst Mal vielen Dank für die rasche Antwort, Willi. Und natürlich dafür, dass RFXTRX so gut in FHEM eingebettet ist, und ich so meine IT Befehle nicht nur senden, sondern auch empfangen kann (was ja bekanntlich erst die vielen interessanten Möglichkeiten ergibt).

Also, ich bin direkt in den RFXMNGR eingestiegen. Das Hideki Protokoll hatte ich, glaube ich, schon gestern ausprobiert, aber um auf Nummer sicher zu geben habe ich es nochmals, nur zusammen mit dem AC, eingestellt. Aber weiterhin ohne Erfolg.

Meine Sensoren haben, auf der Rückseite, noch einen "date code" 12/2012, was mir als Produktionsdatum erscheint, und daher diese doch recht neu sein könnten und evt nicht in der Firmware drin sind. Ich wende mich daher, wie empfohlen, direkt an RFXCOM.

Folgend noch der Status des RFXTRX im RFXMNGR


Get Status:0D 00 00 0A 02 00 00 00 00 00 00 00 00 00
------------------------------------------------
0D01000A02534300040401010000
Packettype        = Interface Message
subtype           = Interface Response
Sequence nbr      = 10
response on cmnd  = Get Status
Transceiver type  = 433.92MHz
Firmware version  = 67
Hardware version  = 1.1
Undec             off
X10               disabled
ARC               disabled
AC                enabled
HomeEasy EU       disabled
Meiantech         disabled
Oregon Scientific disabled
ATI               disabled
Visonic           disabled
Mertik            disabled
AD                disabled
Hideki            enabled
La Crosse         disabled
FS20              disabled
ProGuard          disabled
BlindsT0          disabled
BlindsT1          disabled
AE                disabled
RUBiCSON          disabled
FineOffset        disabled
Lighting4         disabled
RSL               disabled
RFU protocol 5    disabled
RFU protocol 6    disabled

domi-ch

Innerhalb von Minuten hatte ich, wenn auch eine negative, Antwort von Bert von RFXCOM: es gibt keine Pläne, den TFA 30.3166 zum RFXTRX hinzuzufügen. Aber trotzdem super Kundenservice!

Ich wollte diese Information ebenfalls ins FHEM Wiki übertragen, bin aber noch nicht angemeldet und kann daher nicht editieren.

An dieser Stelle eine Frage an die RFXTRX User hier: welche Temperatur & Feuchtigkeitssensoren habt ihr/empfiehlt ihr im Zusammenspiel mit dem RFXTRX (auf dessen Webseite gibt es ja einige zur Auswahl)?

Vielen Dank!
domi


Willi

Zitat von: domi-ch schrieb am Do, 22 August 2013 10:41Innerhalb von Minuten hatte ich, wenn auch eine negative, Antwort von Bert von RFXCOM: es gibt keine Pläne, den TFA 30.3166 zum RFXTRX hinzuzufügen. Aber trotzdem super Kundenservice!

Ich wollte diese Information ebenfalls ins FHEM Wiki übertragen, bin aber noch nicht angemeldet und kann daher nicht editieren.
Habe es gerade im WIKI eingetragen. Danke für das Feedback.

ZitatAn dieser Stelle eine Frage an die RFXTRX User hier: welche Temperatur & Feuchtigkeitssensoren habt ihr/empfiehlt ihr im Zusammenspiel mit dem RFXTRX (auf dessen Webseite gibt es ja einige zur Auswahl)?
Ich setze derzeit nur gebraucht gekaufte Oregon-Sensoren ein. Einerseits hatte ich die Wetterstation WMR100 gebraucht gekauft und habe ein großes Paket als "defekt" gekennzeichnete Sensoren gekauft, von denen aber die Hälfte dann doch mehr oder weniger lief. Teilweise ist die Reichweite nicht besonders, was daran liegen kann, dass diese doch HW-Probleme haben.

Es gibt hier allerdings einige User, die verschiedenste Sensoren einsetzen und sicherlich von Ihren Erfahrungen berichten können.
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

domi-ch

Ich habe den TFA 30.3126 günstig zu kaufen gesehen und soll auch von der RFXTRX Firmware unterstützt werden (laut http://www.rfxcom.com/oregon.htm). Auf der RFXtrx Fhem Wiki Seite ist er aber nicht gelistet.

Hat jemand mit diesem Sensor bereits Erfahrungen gesammelt?

Willi

Zitat von: domi-ch schrieb am So, 25 August 2013 20:55Ich habe den TFA 30.3126 günstig zu kaufen gesehen und soll auch von der RFXTRX Firmware unterstützt werden (laut http://www.rfxcom.com/oregon.htm). Auf der RFXtrx Fhem Wiki Seite ist er aber nicht gelistet.

Da habe ich eingetragen was mir bekannt war.

Unterstützt werden kann generell das was die RFXCOM-Firmware unterstützt. Beim einem Temp/Hum-Sensor, den die RFXCOM-Firmware unterstützt, sehe ich keinerlei Probleme diesen auch mit FHEM zu nutzen.

Grüße

Willi
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

domi-ch

Danke Willi, ich werde mein Glück mal mit diesen Sensoren versuchen  :)

Willi

Zitat von: domi-ch schrieb am Mo, 26 August 2013 22:15Danke Willi, ich werde mein Glück mal mit diesen Sensoren versuchen  :)
Dann freue ich mich über Dein Feedback wie die Qualität des Sensors ist (Reichweite, Genauigkeit, etc.).
Wie viel kostet der Sensor bei Deinem Angebot?
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

domi-ch

Zitat von: Willi schrieb am Di, 27 August 2013 11:41Dann freue ich mich über Dein Feedback wie die Qualität des Sensors ist (Reichweite, Genauigkeit, etc.).
Wie viel kostet der Sensor bei Deinem Angebot?

Feedback soll folgen. Bei "meinem" Intertechno Händler der Wahl kosten sie 13 Euro pro Stück: http://www.hans-hats.de/advanced_search_result.php?osCsid=07ad7caf51c670e55a1dd576f540d448&keywords=30.3126+&osCsid=07ad7caf51c670e55a1dd576f540d448&x=0&y=0

HarryT

For your info:

I also use these:
http://www.weerstationkopen.nl/wsp-433-3ch/product_info.php/products_id/1944

With google translate
http://translate.google.com/translate?sl=nl&tl=en&js=n&prev=_t&hl=nl&ie=UTF-8&u=http%3A%2F%2Fwww.weerstationkopen.nl%2Fwsp-433-3ch%2Fproduct_info.php%2Fproducts_id%2F1944

I didn't do extensive tests with them but I had no problems with there range.

I didn't see them somewhere outside the netherlands but would be surprised if they are only available in the netherlands.
FHEM 6.2 auf Raspberry Pi3  (1,2 Ghz)
RFXTRX433XL, ZWave, KFL200 and ConBeeIII
Raspberry Pi1 (0,7 Ghz) and Raspberry Pi4 for testing
German reading skills are good.

domlanz

So, nach längerer Abwesenheit habe ich es doch nocht geschaft, die TFA 30.3126 zubestellen und einzubinden. Sie wurden tadellos erkannt und scheinen gut zu funktionieren.

bugster_de

auch ich habe zweo von den TFA3126 nun im Einsatz und sie wurden tadellos erkannt und laufen einwandfrei.

Wieviele von den Dingern kann ich parallel einsetzen? Ich denke da so an 5-6 Geräte (für jeden Raum eines). Geht das oder ist be 3 Schluß wegen dem Kanalschalter?

Willi

Schau Dir mal in commandref bei TRX das Attribut longids an.

Wenn Du dieses setzt, kannst Du vermutlich wesentlich mehr als die per Kanalschalter vorgesehenen Geräte verwenden. Du hast dann nur das Problem, dass sich die ID nach einem Batteriewechsel ändert und Du die ID manuell in fhem.cfg ändern muss.
Probier es mal aus.

Grüße

Willi
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

bugster_de


bugster_de

si, ich hab jetzt gerade auf longids umgeschaltet. Mit den zwei Sensoren funktioniert das ohne Probleme. Ich habe jetzt noch einen Schwung weitere Sensoren bestellt. ich berichte dann sobald es soweit ist.

bugster_de

Hi,

wie versprochen hier meine Statusmeldung: ich habe jetzt 5 TFA 31.3126 im Einsatz und das geht mit den longid einwandfrei. Genauigkeit ist ca. 0,3 Grad Abweichung zwischen den Geräten. Also für den Preis wirklich zu empfehlen

drdownload

weiß jemand ob der TFA 30.3169 unterstützt wird?
CUL 868 Slow-RF (FS20 Aktoren, Sender, FHT8V), CUL 868 (WMBUS-Empfang), Jeelink (PCA301), WS3600 (WH3080 über USB-Basis), Bewässerung mit ESP-Easy und Proplanta, RFXTRX433 Home-Easy Empfang und Senden, Oregon TH, WS001 TH), Blackbean IR, Mopidy-Snapcast MR Audio, Kodi, Forum-LED-Controller,

habichthugo

#18
Zitat von: bugster_de am 17 November 2013, 10:46:07
Hi,

wie versprochen hier meine Statusmeldung: ich habe jetzt 5 TFA 31.3126 im Einsatz und das geht mit den longid einwandfrei. Genauigkeit ist ca. 0,3 Grad Abweichung zwischen den Geräten. Also für den Preis wirklich zu empfehlen
Du meintest den TFA 30.3126? Wäre ja der Hammer, wenn da mehr als drei gingen!?
p.s.: Wie oft sendet der Werte?
CUL (CC1101-USB-Lite module-V3) + 5*fht80b + 6*Mumbi-Funksteckdosen (=Elro AB440); HM-LAN + 11*HM-LC-Bl1PBU-FM Rollladenaktor + 1*HM-LC-Sw1PBU-FM Funklichtschalter + 2*HM-RC-12-W; Raspbian (Raspberry Pi Model B Rev 1 ECN0001 256MB)

mfeske

Zitat von: Willi am 08 November 2013, 19:17:28
Schau Dir mal in commandref bei TRX das Attribut longids an.

Wenn Du dieses setzt, kannst Du vermutlich wesentlich mehr als die per Kanalschalter vorgesehenen Geräte verwenden. Du hast dann nur das Problem, dass sich die ID nach einem Batteriewechsel ändert und Du die ID manuell in fhem.cfg ändern muss.
Probier es mal aus.

Hallo Willi,

ich bin durch Mario auf das Thema longid gestossen, da ich mehrere TFA Sensoren am CUL betreibe, aber ich werde aus der commandref leider nicht ganz schlau, was auch an meinen schlechten Englischkenntnissen liegen kann. Ich habe das hier geschilderte Problem, das die Sensoren sich bei der Anmeldung überlagern. Für den Batteriewechsel gibt es ja glücklicherweise set DEVICE replaceBatteryForSec 120 doch wie bekomme ich es jetzt hin, das die angemeldeten sich nicht mehr überlagern oder bei der Neuanmeldung überschreiben?

Gruß
Micha
Hardware:
1 x Raspberry Pi Mod. B 512 MB
eq-3 2 x MAX! eTRV Heizungssteller, 1 x MAX! Fensterkontakt, 1 x MAX! Cube - LAN Gateway (ausser Betrieb)
Intertechno 1x ITZ-500, 3x ITT-1500, 9x ITR-1500, 3 x ITDL-1000, 2 x ITL-500
1 x CC1101-USB-Lite 433MHz (CUL433)  V3 1 x CC1101-USB-Lite 868MHz (CUL868)

Markus M.

Zitat von: mfeske am 25 Januar 2015, 21:20:26
Für den Batteriewechsel gibt es ja glücklicherweise set DEVICE replaceBatteryForSec 120

Nicht für den RFXTRX433, oder?!
FHEM dev + HomeBridge + Lenovo Flex15 + HM-CFG-USB + RFXtrx433 + Fritz!Box 7590/7580/546E

HM Aktor/Sensor/Winmatic/Keymatic/Thermostat, HUE, Netatmo Weather/Security/Heating, Xiaomi AirPurifier/Vacuum, Withings Aura/BPM/Cardio/Go/Pulse/Thermo, VSX828, Harmony, Siro ERB15LE
https://paypal.me/mm0

bugster_de

Hallo Leute,

die Sensoren TFA30.3126 haben jetzt seit 2013 einwandfrei funktioniert. Jetzt gehen sie aber doch nicht mehr. Die haben alle auf einen Schlag vor ca. 2 Monaten ihren letzten Wert gesendet.  Da ich mich nicht mehr genau erinnere, was ich vor 2 Monaten gemacht habe, kann ich nur spekulieren:

- Wurde hier ein Update von FHEM gemacht?
- mit welcher RFXTRX433 Firmware Version sind die suported? Ich hatte vor geraumer Zeit mal ein FW Update gemacht

mfeske

Hallo bugster_de,

ich habe diese auch seit fünf Jahren unverändert im Einsatz und führe alle FHEM Updates durch. Eine Frage m Rande, die Batterien sind okay ?

Gruß
Micha
Hardware:
1 x Raspberry Pi Mod. B 512 MB
eq-3 2 x MAX! eTRV Heizungssteller, 1 x MAX! Fensterkontakt, 1 x MAX! Cube - LAN Gateway (ausser Betrieb)
Intertechno 1x ITZ-500, 3x ITT-1500, 9x ITR-1500, 3 x ITDL-1000, 2 x ITL-500
1 x CC1101-USB-Lite 433MHz (CUL433)  V3 1 x CC1101-USB-Lite 868MHz (CUL868)

bugster_de

Hi,

Batterien sind i.O. Ich habe gestern bei zwei Geräten diese mal prophylaktisch getauscht aber keine Änderung gesehen.

Es haben auch alle Sensoren ziemlich zeitgleich den Geist aufgegeben. Wenn ich in den Detail-View der Sensoren gehe, dann ist die letzte Statusmeldung (das Datum und die Zeit an den Readings) alle am gleichen Tag mit einem Zeitunterschied von max. 2 Minuten. Sprich die haben alle ihren Wert gesendet und dann war Feierabend.

Der CUL selbst funktioniert, da ich darüber z.B. auch Intertecno Dosen schalte. Und die gehen ohne Probleme.

KölnSolar

#24
ZitatCUL
???
wenn es dann doch ein rfxtrx ist, würde ich mal im rfxmgr testen.
Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

bugster_de

Hi,

habe ich auch schon gemacht. Da sehe ich keine Kommunikation. Aber Nachbars Temperatur Sender sendet ab und zu was, welches der RFXTRX Manager dann anzeigt.
Danke aber trotzdem für den Hinweis, denn ich merke erst jetzt, das das ganze dann ja nix mit FHEM zu tun hat. Wenn der RFXTRX schon nix sieht, wie soll es dann FHEM sehen. Manchmal sieht man nur viele Bäume aber den Wald nicht.

Ich hatte auch schon alle Protokolle im RFXTRX eingeschaltet, um zu sehen ob es daran liegt. War es aber auch nicht.

Kann ich die Firmware down-graden und mal ältere FW Versionen versuchen?

KölnSolar

Da lag ich ja richtig mit meiner Vermutung  8)
ZitatKann ich die Firmware down-graden und mal ältere FW Versionen versuchen?
Klar  ;)
Manchmal ist weniger mehr. Sprich, besser die Protokolle immer nur einzeln aktivieren, da sie sich tw. gegenseitig beeinflussen, der RFXTRX dann nicht eindeutig das Protokoll identifizieren kann.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

bugster_de

Ich bin so doof! Wenn man mal den zweiten Post hier durchliest kommt man drauf, dass das Hideki Protokoll enabled sein muß. Hatte ich wohl bei der FW Update Aktion ausgeschaltet   :-[  Ich habe jetzt die neuste FW drauf (1006a) und es geht wieder. Auch mein Imagintronix Bodenfeuchte Sensor läuft jetzt.