[gelöst] CUL_TCM97001: keinen weiteren Temp-Sensor GT-WT-01/Prologue anlernbar

yersinia · 10 August 2019, 16:57:50

Hallo zusammen,

nach einem Batteriewechsel kann ich den vierten (von vier) GT-WT-01 (model: Prologue) nicht anlernen. Normalerweise ging dies immer nach ein paar Tage warten ohne Batterie, aber mittlerweile ist eine Woche vorbei und das Modul vergibt immer wieder eine bereits bestehende ID eines anderen GT-WT-01. longids = 1 ist gesetzt beim CUL. Der Temperatursensor funktioniert und sendet auch. FHEM registriert beide Sensoren auch im Parallelbetrieb, alelrdings als ein Sensor...

Der alte GT-WT-01 vor dem Batteriewechsel:

Code Auswählen

Internals:
   CFGFN      
   CODE       CUL_TCM97001_153
   DEF        CUL_TCM97001_153
   FUUID      5d4ad60c-f33f-3151-4b28-3b5d0df28fa2faf9
   NAME       Prologue_153
   NR         927
   STATE      Defined
   TYPE       CUL_TCM97001
   lastH      0
   lastT      0
   .attreocr:
     .*
   .attrminint:
     .*:300
   READINGS:
Attributes:
   event-min-interval .*:300
   event-on-change-reading .*
   model      Prologue

Der GT-WT-01 welcher immer wieder übersendet wird:

Code Auswählen

Internals:
   .lastTimechannel 1565185522.25823
   .lastTimehumidity 1565448701.38512
   .lastTimemode 1565185559.26389
   .lastTimestate 1565448533.3898
   .lastTimetemperature 1565448533.3898
   CODE       CUL_TCM97001_145
   DEF        CUL_TCM97001_145
   FUUID      5c443cf9-f33f-3151-7265-5b3f249d5801e663
   LASTInputDev nanoCUL_433_1
   MSGCNT     4836
   NAME       Prologue_145
   NR         165
   RSSI       -75
   STATE      2019-08-10 16:51:41 T: 24.7 H: 24
   TYPE       CUL_TCM97001
   lastH      0
   lastT      1565448701
   nanoCUL_433_1_MSGCNT 4836
   nanoCUL_433_1_RAWMSG s91720F7188FE;  512: 9120
   nanoCUL_433_1_TIME 2019-08-10 16:51:41
   .attraggr:
   .attreocr:
     .*
   .attrminint:
     .*:300
   Helper:
     DBLOG:
       humidity:
         logdb:
           TIME       1565448365.38705
           VALUE      24
       temperature:
         logdb:
           TIME       1565448533.39843
           VALUE      24.7
   READINGS:
     2019-08-07 13:18:29   T:              25.2 H: 24
     2019-05-05 09:11:57   battery         ok
     2019-08-07 15:45:22   channel         2
     2019-08-10 16:51:41   humidity        24
     2019-08-07 15:45:59   mode            normal
     2019-08-10 16:51:41   state           T: 24.7 H: 24
     2019-08-10 16:51:41   temperature     24.7
Attributes:
   event-min-interval .*:300
   event-on-change-reading .*
   model      Prologue
   showtime   0

Die ids der anderen Sensoren sind TCM21...._146 und W044_152 (mit model Prologue funktionieren diese auch einwandfrei).

Empfangsdevice ist ein 433er Selbstbau-nanoCUL mit aculfw:

Code Auswählen

Internals:
   CMDS       ABCeFfGiKLlMNRTtUVWXx
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS:FS20V: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT::OREGON::Hideki::SD_WS07:
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0@38400 0000
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0@38400
   FD         11
   FHTID      0000
   FUUID      5c443cee-f33f-3151-e168-c4667b4184539660
   NAME       nanoCUL_433_1
   NR         36
   PARTIAL    
   RAWMSG     s92380FE358E6;  544: 9072
   RSSI       -86
   STATE      2019-08-10 16:47:49 Initialized
   TIME       1565442630
   TYPE       CUL
   VERSION    V 1.26.03 a-culfw Build: 300 (2018-04-15_20-15-39) nanoCUL433 (F-Band: 433MHz)
   initString X21
   nanoCUL_433_1_MSGCNT 13592
   nanoCUL_433_1_TIME 2019-08-10 16:47:49
   .attraggr:
   .attreocr:
     .*
   .attrminint:
   .clientArray:
     IT
     CUL_TCM97001
   MatchList:
     0:FS20V    ^81..(04|0c)..0101a001......00[89a-f]...
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04......a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     C:Hideki   ^P12#75[A-F0-9]{17,30}
     C:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     C:SD_WS07  ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2019-08-07 13:18:44   Initialized     
     2018-03-05 17:04:02   ccconf          freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB
     2019-08-07 13:19:17   cmds             A B C e F f G i K L l M N R T t U V W X x
     2019-07-04 21:21:15   raw             isDD1F010DDD00
     2019-08-10 16:47:49   state           Initialized
     2018-08-16 20:14:46   uptime          0 00:13:58
     2019-01-29 15:57:07   version         V 1.26.03 a-culfw Build: 300 (2018-04-15_20-15-39) nanoCUL433 (F-Band: 433MHz)
Attributes:
   event-on-change-reading .*
   icon       cul_cul
   longids    1
   model      nanoCUL
   verbose    2

Version vom Modul 14_CUL_TCM97001.pm:

Code Auswählen

14_CUL_TCM97001.pm 19762 2019-07-02 19:21:52Z bjoernh
Letztes FHEM-Update ist zwei Tage alt. autocreate ist aktiviert.

Was kann ich noch tun um die wieder vernünftig ans Laufen zu bekommen?
Ein Batteriewechsel des einen Sensors steht demnächst auch an...:/

Danke vorab.

yersinia · 23 August 2019, 14:33:23

So, nach einigen Tagen und rumprobieren habe ich es dann doch mal geschafft den anderen GT-WT-01 anzulernen.

Mal schauen ob das Drama mit den nun anderen Sensoren auch bald wieder ansteht....

Ralf9 · 22 Oktober 2019, 18:23:07

Das Problem beim GT-WT-01 und beim Prologue ist, daß die Nachricht immer mit 9 beginnt und die ID ist die 2. und 3. Hexziffer.
Beim CUL_TCM97001 Modul werden aber die ersten beiden Hexziffern für die ID verwendet, dies zu ändern wäre recht kompliziert und aufwändig.

Bei dieser Nachricht
s91720F7188FE
wird Hex 91 (dez 145) als ID verwendet, die ID, die sich bei jedem Batteriewechsel ändert ist aber Hex 17.
Wenn sich bei zwei GT-WT-01 die IDs nur in der low Hexziffer unterscheiden haben beim CUL_TCM97001 Modul beide die selbe ID (z.B Hex 17 und 18 ergibt die selbe CUL_TCM97001 Hex ID 91.

Es gibt momentan nur die Möglichkeit die Batterie so oft zu wechseln bis sich auch die zweite Hexziffer (high Hexziffer der ID) der Nachricht ändert.

Gruß Ralf

yersinia · 23 Oktober 2019, 09:37:03

Danke Ralf für die detaillierte Antwort.

Zitat von: Ralf9 am 22 Oktober 2019, 18:23:07
Beim CUL_TCM97001 Modul werden aber die ersten beiden Hexziffern für die ID verwendet, dies zu ändern wäre recht kompliziert und aufwändig.

Was würde es für ein Aufwand bedeuten, wenn man dies irgendwie umbauen könnte? Ich meine, ich finde es schon nervig, da der Batteriewechsel ~ einmal im Jahr ansteht.
Könnte man möglicherweise die ID auf die 2., 3. und 4. Hexziffer erweitern?
Gibt es eine Wunsch-/ToDo-Liste?

Ralf9 · 01 November 2019, 12:50:00

ZitatWas würde es für ein Aufwand bedeuten, wenn man dies irgendwie umbauen könnte?

Ich habe eine Idee wie man es machen könnte, könnte aber noch etwas dauern.
Eine Möglichkeit wäre für Prologue eine optionale neue DEF, z.B. bei s91720F7188FE die DEF CUL_TCM97001_P_23

Ich habe hier eine Wunsch-/ToDo-Liste angefangen:
https://forum.fhem.de/index.php/topic,101425.msg948723.html#msg948723

Gruß Ralf

Ralf9 · 28 November 2019, 00:18:19

ZitatIch habe eine Idee wie man es machen könnte, könnte aber noch etwas dauern.
Eine Möglichkeit wäre für Prologue eine optionale neue DEF, z.B. bei s91720F7188FE die DEF CUL_TCM97001_P_23

Ich habe das mal ins CUL_TCM97001 Modul eingebaut
https://github.com/Ralf9/14_CUL_TCM97001/commit/6d64699d61049b49951085361ebbf3b6bfab80fa
Dazu diese Datei ins FHEM Verzeichnis kopieren und dann fhem neu starten
https://raw.githubusercontent.com/Ralf9/14_CUL_TCM97001/dev/fhem/FHEM/14_CUL_TCM97001.pm

Es gibt ein neues Internal AlternativeDEFcode in dem der alternative devicecode (DEF) steht.
Der alternative devicecode wird nicht automatisch verwendet, die DEF muss bei Bedarf von Hand geändert werden.

z.B. bei s91720F7188FE ist der alternative devicecode (DEF) "CUL_TCM97001_9_23". Die 23 ist der Dezimalwert von der 2. und 3. Hexziffer (17)

Gruß Ralf

yersinia · 28 November 2019, 17:18:24

Cool, Danke. Ich habe es gerade getestet und es läuft erstmal unverändert und ohne erkennbare Fehler(meldungen) weiter. Anbei ein List:

Code Auswählen

Internals:
   .lastTimechannel 1574957519.5986
   .lastTimehumidity 1574957519.5986
   .lastTimestate 1574957519.5986
   .lastTimetemperature 1574957519.5986
   AlternativeDEFcode CUL_TCM97001_153
   CHANGED    
   CODE       CUL_TCM97001_153
   DEF        CUL_TCM97001_153
   FUUID      5dadd19d-f33f-3151-ab86-0183eadb51d84545
   LASTInputDev nanoCUL_433_1
   MSGCNT     4
   NAME       Prologue_153
   NR         282
   RSSI       -81
   STATE      2019-11-28 17:14:47 T: 9.2 H: 70
   TYPE       CUL_TCM97001
   lastH      0
   lastT      1574957687
   nanoCUL_433_1_MSGCNT 4
   nanoCUL_433_1_RAWMSG s99F205C468F2;  512: 9104
   nanoCUL_433_1_TIME 2019-11-28 17:14:47
   .attraggr:
   .attreocr:
     .*
   .attrminint:
     .*:300
   Helper:
     DBLOG:
       humidity:
         logdb:
           TIME       1574957519.6023
           VALUE      70
       temperature:
         logdb:
           TIME       1574957519.6023
           VALUE      9.2
   READINGS:
     2019-11-28 17:10:07   T:              9.2 H: 69
     2019-11-24 09:15:25   battery         ok
     2019-11-24 09:15:25   batteryState    ok
     2019-11-28 17:11:59   channel         3
     2019-11-28 17:14:47   humidity        70
     2019-10-21 17:42:17   mode            normal
     2019-11-28 17:14:47   state           T: 9.2 H: 70
     2019-11-28 17:14:47   temperature     9.2
Attributes:
   event-min-interval .*:300
   event-on-change-reading .*
   model      Prologue
   stateFormat {ReadingsTimestamp($name,'state','')." ".ReadingsVal($name,'state','')}

Die Frage, die sich mir gerade stellt, ist wie sich das mit einem neuen Sensor bzw Batteriewechsel verhält. Das Device wird mWn via des NAME referenziert und nicht anhand des DEF. Kann ich ohne weiteres dann ein neues Device anlernen?
Möglicherweise finde ich am WE etwas Zeit einen Sensor mit niedriger Batterie neu anzulernen. Das Modul funktioniert auf jedenfall erstmal unauffällig bei mir.

Danke für die Mühe. Cool!

Nachtrag
die Alternative DEF funktioniert auch:

Code Auswählen

Internals:
   .lastTimechannel 1574957445.63916
   .lastTimehumidity 1574958138.06222
   .lastTimestate 1574958138.06222
   .lastTimetemperature 1574958138.06222
   AlternativeDEFcode CUL_TCM97001_146
   CODE       CUL_TCM97001_9_35
   DEF        CUL_TCM97001_9_35
   FUUID      5c443cff-f33f-3151-a63a-4fd97130e27a9782
   LASTInputDev nanoCUL_433_1
   MSGCNT     14
   NAME       TCM21...._146
   NR         226
   RSSI       -77.5
   STATE      2019-11-28 17:22:18 T: 9.8 H: 93
   TYPE       CUL_TCM97001
   lastH      0
   lastT      1574958138
   nanoCUL_433_1_MSGCNT 14
   nanoCUL_433_1_RAWMSG s92380625D8F9;  544: 9072
   nanoCUL_433_1_TIME 2019-11-28 17:22:18
   .attraggr:
   .attreocr:
     .*
   .attrminint:
     .*:300
   Helper:
     DBLOG:
       humidity:
         logdb:
           TIME       1574957445.64169
           VALUE      93
       temperature:
         logdb:
           TIME       1574957445.64169
           VALUE      9.8
   READINGS:
     2019-11-28 17:09:48   T:              9.8 H: 93
     2019-07-27 17:11:34   battery         low
     2019-07-27 17:11:34   batteryState    low
     2019-11-28 17:10:45   channel         1
     2019-11-28 17:22:18   humidity        93
     2019-07-03 17:28:08   mode            normal
     2019-11-28 17:22:18   state           T: 9.8 H: 93
     2019-11-28 17:22:18   temperature     9.8
Attributes:
   event-min-interval .*:300
   event-on-change-reading .*
   model      Prologue

Ein Punkt habe ich noch: kannst du verhindern dass ein Reading wie

Code Auswählen

2019-11-28 17:10:07 T: 9.2 H: 69
angelegt wird? Das führt zu Warnings in FHEM.

Ralf9 · 28 November 2019, 19:54:34

ZitatAlternativeDEFcode CUL_TCM97001_153
CODE CUL_TCM97001_153
DEF CUL_TCM97001_153

Beim AlternativeDEFcode passt irgendwas noch nicht ganz er müsste sein "CUL_TCM97001_9_159"
Der AlternativeDEFcode wird nur aktualisiert, wenn was empfangen wird.

Wenn Du beim Prologue_153 den verbose auf 4 setzt, siehst Du welcher devicecode beim Empfang verwendet wird.

Code Auswählen

2019.11.28 19:07:36.085 4 : sduinoD: CUL_TCM97001 Parse Name: Prologue_153 , devicecode: CUL_TCM97001_153 , Model defined: Prologue

Nach Änderung der DEF in CUL_TCM97001_9_159 sieht es dann so aus:

Code Auswählen

2019.11.28 19:26:59.749 4 : sduinoD: CUL_TCM97001 Parse Name: Prologue_153 , devicecode: CUL_TCM97001_9_159 , Model defined: Prologue

Eine Änderung wieder zurück zum normalen DEF "CUL_TCM97001_153" funktioniert nur, wenn danach ein fhem restart gemacht wird.

ZitatDas Device wird mWn via des NAME referenziert

Das Device wird via des devicecode (DEF) referenziert.

Wenn Du ein neues device anlernst, wird der normale devicecode verwendet, Du musst dann von Hand das DEF ändern.
Dies so zu machen, daß automatisch der alternative devicecode verwendet wird, ist mir zu aufwändig, da würde ich Hilfe benötigen. Es gibt da einiges zu beachten.

ZitatEin Punkt habe ich noch: kannst du verhindern dass ein Reading wie
2019-11-28 17:10:07 T: 9.2 H: 69

Dazu müsste ich dies bei mir reproduzieren können, so ein reading tritt bei mir nicht auf.

Gruß Ralf

yersinia · 30 November 2019, 15:29:41

Zitat von: Ralf9 am 28 November 2019, 19:54:34
Beim AlternativeDEFcode passt irgendwas noch nicht ganz er müsste sein "CUL_TCM97001_9_159"
Der AlternativeDEFcode wird nur aktualisiert, wenn was empfangen wird.

Ich dachte erst, das würde daran liegen das ich bei diesem Device schonmal zwischen alternivem und ursprünglichen DEF gewechselt hatte. Aber nach Neuempfang wird der DEFCode nicht aktualisiert;

Code Auswählen

Internals:
   .lastTimebattery 1575109617.17841
   .lastTimebatteryState 1575109617.17841
   .lastTimechannel 1574957519.5986
   .lastTimehumidity 1575123729.46864
   .lastTimestate 1575123729.46864
   .lastTimetemperature 1575123673.31743
   AlternativeDEFcode CUL_TCM97001_153
   CHANGED    
   CODE       CUL_TCM97001_153
   DEF        CUL_TCM97001_153
   FUUID      5dadd19d-f33f-3151-ab86-0183eadb51d84545
   LASTInputDev nanoCUL_433_1
   MSGCNT     2901
   NAME       Prologue_153
   NR         282
   RSSI       -87.5
   STATE      2019-11-30 15:23:05 T: 3.3 H: 67
   TYPE       CUL_TCM97001
   lastH      0
   lastT      1575123785
   nanoCUL_433_1_MSGCNT 2901
   nanoCUL_433_1_RAWMSG s99F2021438E5;  512: 9072
   nanoCUL_433_1_TIME 2019-11-30 15:23:05
   .attraggr:
   .attreocr:
     .*
   .attrminint:
     .*:300
   Helper:
     DBLOG:
       humidity:
         logdb:
           TIME       1575123393.32035
           VALUE      67
       temperature:
         logdb:
           TIME       1575123337.32215
           VALUE      3.3
   READINGS:
     2019-11-28 17:10:07   T:              9.2 H: 69
     2019-11-30 11:26:57   battery         ok
     2019-11-30 11:26:57   batteryState    ok
     2019-11-28 17:11:59   channel         3
     2019-11-30 15:23:05   humidity        67
     2019-10-21 17:42:17   mode            normal
     2019-11-30 15:23:05   state           T: 3.3 H: 67
     2019-11-30 15:23:05   temperature     3.3
Attributes:
   event-min-interval .*:300
   event-on-change-reading .*
   model      Prologue

Aber ich denke, dass das damit zusammen hängt:

Zitat von: Ralf9 am 28 November 2019, 19:54:34
Eine Änderung wieder zurück zum normalen DEF "CUL_TCM97001_153" funktioniert nur, wenn danach ein fhem restart gemacht wird.
Das Device wird via des devicecode (DEF) referenziert.

Einen Restart gab es seit der Übernahme der alterniven .pm nicht.

Zitat von: Ralf9 am 28 November 2019, 19:54:34
Dazu müsste ich dies bei mir reproduzieren können, so ein reading tritt bei mir nicht auf.

Ich hatte die schonmal aus dem statefile rausgelöscht (als ich den FHEM RasPi von Jessy auf Strech umgezogen habe); kurz danach waren diese wieder da; aber mir scheint, diese Readings werden nach dem ersten Empfang nach einem Neustart geschrieben. Hier ein anderes Device mit dem gleichen Reading:

Code Auswählen

Internals:
   .lastTimechannel 1574957449.11299
   .lastTimehumidity 1575123824.98369
   .lastTimestate 1575123824.98369
   .lastTimetemperature 1575123824.98369
   AlternativeDEFcode CUL_TCM97001_9_71
   CHANGED    
   CODE       CUL_TCM97001_148
   DEF        CUL_TCM97001_148
   FUUID      5d518caf-f33f-3151-a62c-8f13d660701e9edc
   LASTInputDev nanoCUL_433_1
   MSGCNT     2979
   NAME       Prologue_148
   NR         275
   RSSI       -78.5
   STATE      2019-11-30 15:28:24 T: 14.0 H: 55
   TYPE       CUL_TCM97001
   lastH      0
   lastT      1575124104
   nanoCUL_433_1_MSGCNT 2979
   nanoCUL_433_1_RAWMSG s947A08C378F7;  512: 9104
   nanoCUL_433_1_TIME 2019-11-30 15:28:24
   .attraggr:
   .attreocr:
     .*
   .attrminint:
     .*:300
   Helper:
     DBLOG:
       humidity:
         logdb:
           TIME       1575123824.98769
           VALUE      55
       temperature:
         logdb:
           TIME       1575123824.98769
           VALUE      14.0
   READINGS:
     2019-11-28 17:09:53   T:              15.2 H: 66
     2019-11-13 15:16:49   battery         low
     2019-11-13 15:16:49   batteryState    low
     2019-11-28 17:10:49   channel         3
     2019-11-30 15:28:24   humidity        55
     2019-10-07 18:12:28   mode            normal
     2019-11-30 15:28:24   state           T: 14.0 H: 55
     2019-11-30 15:28:24   temperature     14.0
Attributes:
   event-min-interval .*:300
   event-on-change-reading .*
   model      Prologue

Ralf9 · 30 November 2019, 19:47:25

ZitatIch hatte die schonmal aus dem statefile rausgelöscht (als ich den FHEM RasPi von Jessy auf Strech umgezogen habe); kurz danach waren diese wieder da; aber mir scheint, diese Readings werden nach dem ersten Empfang nach einem Neustart geschrieben.

Solange dies nur bei Dir auftritt, wird es schwierig den Fehler zu finden.

Gruß Ralf

yersinia · 02 Dezember 2019, 12:29:13

Ok, ich schau mal, ob es sich reproduzieren lässt und melde mich dann wieder hier.
Andererseits, außer einem Warning beim FHEM-Start, stört es nicht.

Edit sagt, dass ich das schonmal hier gepostet hatte: https://forum.fhem.de/index.php/topic,87844.0.html
Von daher ist das dort schon abgedeckt.