Problem mit THGR132N Sensoren im TRX-WEATHER Modul mit RFXtrx433

[netwalk]

Hallo zusammen,

ich habe seit vorgestern das Problem, das in der Nachbarschaft neue Sensoren aufgetaucht sind. Sie werden als THGR132N_xx_y auf meiner FB 7390 mit RFXtrx433 und aktiviertem Attribut "longid" angelegt. Setze ich das "ignore" Attribut, taucht der entsprechende Sensor auch nicht mehr auf. Nun wird aber einige Zeit später ein neuer Sensor mit anderer ID auf gleichem Kanal angelegt. Diesen habe ich auch auf "ignore" gesetzt. Das ganze hat sich etwa 8 mal am ersten Abend wiederholt. Meine Vermutung war, dass der Nachbar mehrmals die Batterien neu eingesetzt hat und dadurch eine neue ID erzeugt wurde.

Gestern stellte ich mit Verwunderung fest, dass etwa 30 (!) neue Sensoren in der Nacht angelegt wurden, Die Logfiles besagen, dass sie immer nur 10-40 Minuten aktiv waren, bevor ein neuer Sensor auftauchte und der alte keine Werte mehr lieferte.
Da das Neuanlegen die ganze Nacht über geschah, schließe ich einen ständigen Batteriewechsel aus.

Wie kann es sein, dass ein und der selbe Sensor offenbar mit anderer ID ständig neu angelegt wird, ohne einen Batteriewechsel?


netwalk

[Willi]

Wie kann es sein, dass ein und der selbe Sensor offenbar mit anderer ID ständig neu angelegt wird, ohne einen Batteriewechsel?

Wenn Du THGR132N mit longid verwendest, vermute ich, dass Du eine Menge dieser Sensoren (THGR132N, THC238/268,THN132,THWR288,THRN122,THN122,AW129/131) hast. Welche Sensoren hast Du genau?

Ich sehe mehrere Möglichkeiten, die zu dem Problem führen könnten:
-1- Einer Deiner Sensoren hat einen Defekt bzw. Wackelkontakt der Stromzufuhr, so dass er immer wieder neu startet. Oder die Batterie ist fast leer und verursacht so das Problem.
-2- In der Nachbarschaft gibt es einen defekten THGR132n oderwürde ich es ist kein THGR132N, sondern ein Sensor ist, der ein ähnliches Protokoll hat und fälschlicherweise von der RFXCOM-Firmware als THGR132N erkannt wird.

Wenn Du einen Sensor in der Nachbarschaft vermutest, weisst Du um welchen Sensor es sich handeln könnte? Oder war das der Verdacht, weil Dur Dir die neuen Sensoren nicht erklären konntest?

Wenn Du bisher keinen Sensor beim Nachbarn gesehen hast, würde ich vermuten, dass einer Deiner Sensoren Probleme macht.

Ich würde erst mal longids nicht mehr setzen, um zu sehen, welche ID (Dip-Switch) der Sensor hat, der das Problem verursacht.
Danach würde ich longid wieder setzen. Die per Dip-Switch als verdächtig identifizierten Sensoren dann testweise nach und nach der Batterie berauben und testen, ob dann das Problem noch auftaucht.

Ansonsten könntest Du Dich an RFXCOM wenden und dort fragen wie man am besten vorgeht.

Grüße

Willi

[netwalk]

Ich setze verschiedene Sensoren ein: THGR228N, THGR132N und RTGR328. Jeweils mehrere, daher die longid.

Batterien bei meinen Sensoren sind bereits getauscht, einen Wackler kann ich, denke ich, ausschließen, da sie ja bei mir mit einer einzigen longid brav ihre Daten abliefern, ohne Aussetzer. Außerdem weichen die Temperaturen deutlich von meinen ab. Ich habe meine fraglichen Sensoren in Kühl- und Gefriergeräten im Einsatz. Es können nur fremde, neue Sensoren sein.

Ich werde den RFXtrx433 mal am Manager betreiben und schauen, ob ich mehr Informationen erhalte.


netwalk

[oliv06]

@Willi : I may have a related problem.
I have longid defined for THGR228N :

Code Auswählen Erweitern

attr TRX longids THGR228N
define temp_hum_SDB_bas TRX_WEATHER THGR228N_d9_1

Until today it was working properly but I upgraded FHEM (which is now $Id: 46_TRX_WEATHER.pm 3781 2013-08-24 18:37:40Z wherzig $) and it recreated all my THGR228N differently (it seems there is no more the channel in the identifier) so I have now (in addition) :

Code Auswählen Erweitern

define THGR228N_d9 TRX_WEATHER THGR228N_d9
Please let me know if it is intended or it is a bug so a have the appropriate response. In the meanwhile I removed the new ones and changed the definition of the old ones in fhem.cfg in order to get a continuity in logs

[Willi]

@Willi : I may have a related problem.

I have looked into this. Your problem does not relate to the RF problem of netwalk. It is something different. Your problem is caused by a problem of using longids for temphum devices.

I have longid defined for THGR228N :

Code Auswählen Erweitern

attr TRX longids THGR228N
define temp_hum_SDB_bas TRX_WEATHER THGR228N_d9_1

Until today it was working properly but I upgraded FHEM (which is now $Id: 46_TRX_WEATHER.pm 3781 2013-08-24 18:37:40Z wherzig $) and it recreated all my THGR228N differently (it seems there is no more the channel in the identifier) so I have now (in addition) :

Code Auswählen Erweitern

define THGR228N_d9 TRX_WEATHER THGR228N_d9
Please let me know if it is intended or it is a bug so a have the appropriate response.

I did an error handling several temphum devices (this includes THGR228N) when setting longids with the version beginning at 2013-08-09 of 46_TRX_WEATHER.pm (correction for TS34C ids). I have corrected this just some minutes ago and submitted it into SVN.

In the meanwhile I removed the new ones and changed the definition of the old ones in fhem.cfg in order to get a continuity in logs

Please
- get the new version of file 46_TRX_WEATHER.pm from SVN, http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/46_TRX_WEATHER.pm?format=raw
- change your definition back and
- do a "reload 46_TRX_WEATHER.pm" or restart of FHEM.

Please give feedback if it works.

-- Willi

[oliv06]

Thanks, it works as a charm