Zweites und mehr MAX!-HTs lassen sich nicht anlernen

piet · 29 Dezember 2019, 19:25:28

Hallo zusammen,

ich habe folgenden Aufbau:
- RaspberryPi 4B mit Raspbian
- nanoCUL 868MHz (https://www.ebay.de/itm/nanoCUL-USB-Stick-868-Mhz-CC1101-SMA-Antenne-CUL-868-CCU2-FHEM-iobroker/293160685566?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649)
- 6x MAX!-Heizungsthermostat (BC-RT-TRX-CyG-3)

Ich habe entsprechend der FHEM Anleitung https://wiki.fhem.de/wiki/Raspberry_Pi#Installation_.2F_Setup Raspbian, den nanoCUL und FHEM aufgesetzt.
Dann das erste MAX!-HT geschnappt, an der Heizung montiert und folgende Schritte durchgeführt:

"reS" wird im Display angezeigt, dann "InS", drücken der Boost-Taste für Start für Adaptionsfahrt -> Temperatur wird auf Display angezeigt
In FHEM: set cm pairmode 500
Batterien in HT, dabei drei Tasten für Reset drücken
Boost-Taste gedrückt halten bis 30-Sekunden-Countdown

Das ganze hat bei dem ersten Thermostat vor 2 Wochen geklappt, nun funktioniert es nicht mehr.Ich habe 5 Thermostate nach und nach ausprobiert, doch sehe ich im Logfile keinerlei Kommunikation.
Ich habe das System schon einmal mit Raspbian und FHEM neu aufgesetzt und das eine Thermostat wurde sofort wieder erkannt, alle weiteren wurden dennoch nicht erkannt.
Hat jemand eine Idee welche Einstellungen ich nochmal checken könnte?
Vielen Dank im Vorhinein und guten Rutsch!

Konfiguration:

Der nanoCUL (CUL_0) hat folgende Konfiguration:

Code Auswählen


Internals:
   CMDS       ABbCeFGhiKkLlMmNRTtUuVWXxYZ
   CUL_0_MSGCNT 3
   CUL_0_TIME 2019-12-29 18:04:17
   Clients    :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        /dev/ttyACM0@9600 1034
   DeviceName /dev/ttyACM0@9600
   FD         7
   FHTID      1034
   FUUID      5e08bc24-f33f-d778-4926-928d66f463abd20f
   NAME       CUL_0
   NR         14
   NR_CMD_LAST_H 4
   PARTIAL    
   RAWMSG     Z0F0004601440760000000019242800C120
   RSSI       -58
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.67 CUL868
   initString X21
Zr
Za123456
Zw111111
   MatchList:
     1:CUL_MAX  ^Z........................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2019-12-29 17:47:55   cmds             A B b C e F G h i K k L l M m N R T t U u V W X x Y Z
     2019-12-29 17:56:19   credit10ms      794
     2019-12-29 18:04:17   state           Initialized
   XMIT_TIME:
     1577638075.67283
     1577638075.97333
     1577638573.61209
     1577638579.62192
Attributes:
   rfmode     MAX
   verbose    5

Das CUL_MAX (cm) hat folgende Konfiguration:
Internals:

Code Auswählen


   CUL_0_MSGCNT 3
   CUL_0_RAWMSG Z0F0004601440760000000019242800C1
   CUL_0_RSSI -58
   CUL_0_TIME 2019-12-29 18:04:17
   DEF        123456
   FUUID      5e08beef-f33f-d778-5c31-6db21bcaa3c60f39
   IODev      CUL_0
   LASTInputDev CUL_0
   MSGCNT     3
   NAME       cm
   NR         15
   STATE      Defined
   TYPE       CUL_MAX
   addr       123456
   cnt        0
   pairmode   0
   retryCount 0
   READINGS:
     2019-12-29 17:32:18   packetsLost     3
   sendQueue:
Attributes:
   IODev      CUL_0
   verbose    5

Wenn ich eine Temperaturänderung (erfolgreich) an das bereits gepairte HT schicke spuckt mir das Log folgendes aus:

Code Auswählen


2019.12.29 23:12:13 4: WEB_192.168.2.108_54034 GET /fhem?room=MAX; BUFLEN:0
2019.12.29 23:12:13 4: WEB: /fhem?room=MAX / RL:1733 / text/html; charset=UTF-8 / Content-Encoding: gzip
 / Cache-Control: no-cache, no-store, must-revalidate

2019.12.29 23:12:13 4: WEB_192.168.2.108_54034 GET /fhem?XHR=1&inform=type=status;filter=room=MAX;since=1577657532;fmt=JSON&fw_id=65×tamp=1577657535654; BUFLEN:0
2019.12.29 23:12:19 4: Connection accepted from WEB_192.168.2.108_54041
2019.12.29 23:12:19 4: WEB_192.168.2.108_54041 POST /fhem?cmd=set%20MAX_144076%20desiredTemperature%2019.5&XHR=1&fwcsrf=csrf_229040138773841&fw_id=65; BUFLEN:0
2019.12.29 23:12:19 5: Cmd: >set MAX_144076 desiredTemperature 19.5<
2019.12.29 23:12:19 5: CUL_MAX_Send: enqueuing 0b0700401234561440760067
2019.12.29 23:12:19 5: CUL_MAX_SendQueueHandler: 1 items in queue
2019.12.29 23:12:19 5: SW: X
2019.12.29 23:12:19 5: CUL/RAW (ReadAnswer): 21  900

2019.12.29 23:12:19 5: Starting notify loop for CUL_0, 1 event(s), first is credit10ms: 900
2019.12.29 23:12:19 5: createNotifyHash
2019.12.29 23:12:19 5: End notify loop for CUL_0
2019.12.29 23:12:19 5: needPreamble: 1, necessaryCredit: 110, credit10ms: 900
2019.12.29 23:12:19 5: CUL_0 sending Zs0b0700401234561440760067
2019.12.29 23:12:19 5: SW: Zs0b0700401234561440760067
2019.12.29 23:12:19 5: Starting notify loop for MAX_144076, 1 event(s), first is desiredTemperature 19.5
2019.12.29 23:12:19 5: End notify loop for MAX_144076
2019.12.29 23:12:19 4: WEB: /fhem?cmd=set%20MAX_144076%20desiredTemperature%2019.5&XHR=1&fwcsrf=csrf_229040138773841&fw_id=65 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
 / Cache-Control: no-cache, no-store, must-revalidate

2019.12.29 23:12:19 5: CUL_MAX_SendQueueHandler: 1 items in queue
2019.12.29 23:12:20 5: CUL_MAX_SendQueueHandler: 1 items in queue
2019.12.29 23:12:20 5: CUL_MAX_SendQueueHandler: 1 items in queue
2019.12.29 23:12:21 4: Connection closed for WEB_192.168.2.108_54034: EOF
2019.12.29 23:12:21 4: WEB_192.168.2.108_54041 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2019-12.log; BUFLEN:0

Das Log vom Pairing eines neuen HTs kippt aus meiner Sicht keinerlei Info für Kommunikation zwischen dem HT und dem CUL, ich sehe nur dass der pairmode aktiviert wurde:

Code Auswählen


2019.12.29 22:57:36 3: WEB: port 8083 opened
2019.12.29 22:57:36 2: eventTypes: loaded 29 events from ./log/eventTypes.txt
2019.12.29 22:57:36 3: Opening CUL_0 device /dev/ttyACM0
2019.12.29 22:57:36 3: Setting CUL_0 serial parameters to 9600,8,N,1
2019.12.29 22:57:36 3: CUL_0: Possible commands: ABbCeFGhiKkLlMmNRTtUuVWXxYZ
2019.12.29 22:57:36 3: CUL_0 device opened
2019.12.29 22:57:36 2: Switched CUL_0 rfmode to MAX
2019.12.29 22:57:36 3: CUL_MAX_Check: Detected firmware version 167 of the CUL-compatible IODev
2019.12.29 22:57:37 1: Including ./log/fhem.save
2019.12.29 22:57:37 1: usb create starting
2019.12.29 22:57:37 3: Probing ZWDongle device /dev/serial1
2019.12.29 22:57:37 3: Probing CUL device /dev/ttyAMA0
2019.12.29 22:57:37 3: Probing TCM_ESP3 device /dev/ttyAMA0
2019.12.29 22:57:37 3: Probing ZWDongle device /dev/ttyAMA0
2019.12.29 22:57:37 3: Probing SIGNALDuino device /dev/ttyAMA0
2019.12.29 22:57:37 3: Probing MYSENSORS device /dev/ttyAMA0
2019.12.29 22:57:38 3: Probing ArduCounter device /dev/ttyAMA0
2019.12.29 22:57:38 3: Probing ElsnerWS device /dev/ttyAMA0
2019.12.29 22:57:39 3: Probing FRM device /dev/ttyAMA0
2019.12.29 22:57:44 1: usb create end
2019.12.29 22:57:44 0: Featurelevel: 5.9
2019.12.29 22:57:44 0: Server started with 10 defined entities (fhem.pl:20827/2019-12-25 perl:5.028001 os:linux user:fhem pid:7644)
2019.12.29 23:04:12 5: Starting notify loop for global, 1 event(s), first is ATTR global verbose 5
2019.12.29 23:04:12 5: createNotifyHash
2019.12.29 23:04:12 5: End notify loop for global
2019.12.29 23:04:12 4: WEB: /fhem?cmd.attrglobal%3Dattr%20global%20verbose%205&XHR=1&fwcsrf=csrf_229040138773841&fw_id=54 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
 / Cache-Control: no-cache, no-store, must-revalidate

2019.12.29 23:04:12 4: Connection closed for WEB_192.168.2.108_53505: EOF
2019.12.29 23:04:12 4: WEB_192.168.2.108_53514 GET /fhem?detail=global&fw_id=54; BUFLEN:0
2019.12.29 23:04:12 4: WEB: /fhem?detail=global&fw_id=54 / RL:3769 / text/html; charset=UTF-8 / Content-Encoding: gzip
 / Cache-Control: no-cache, no-store, must-revalidate

2019.12.29 23:04:12 4: WEB_192.168.2.108_53514 GET /fhem?cmd=%7BAttrVal(%22global%22%2C%22room%22%2C%22%22)%7D&XHR=1&fwcsrf=csrf_229040138773841; BUFLEN:0
2019.12.29 23:04:12 5: Cmd: >{AttrVal("global","room","")}<
2019.12.29 23:04:12 4: WEB: /fhem?cmd=%7BAttrVal(%22global%22%2C%22room%22%2C%22%22)%7D&XHR=1&fwcsrf=csrf_229040138773841 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
 / Cache-Control: no-cache, no-store, must-revalidate

2019.12.29 23:04:37 4: Connection accepted from WEB_192.168.2.108_53546
2019.12.29 23:04:37 4: WEB_192.168.2.108_53546 POST /fhem&fw_id=56&fwcsrf=csrf_229040138773841&cmd=set+cm+pairmode; BUFLEN:0
2019.12.29 23:04:37 5: Cmd: >set cm pairmode<
2019.12.29 23:04:37 5: Starting notify loop for cm, 1 event(s), first is pairmode
2019.12.29 23:04:37 5: createNotifyHash
2019.12.29 23:04:37 5: End notify loop for cm
2019.12.29 23:04:37 4: WEB_192.168.2.108_53546 GET /fhem?fw_id=56; BUFLEN:0
2019.12.29 23:04:37 4: WEB: /fhem?fw_id=56 / RL:1472 / text/html; charset=UTF-8 / Content-Encoding: gzip
 / Cache-Control: no-cache, no-store, must-revalidate

2019.12.29 23:04:38 4: WEB_192.168.2.108_53546 GET /fhem?XHR=1&inform=type=status;filter=;since=1577657076;fmt=JSON&fw_id=56×tamp=1577657080566; BUFLEN:0
2019.12.29 23:04:39 4: Connection closed for WEB_192.168.2.108_53546: EOF
2019.12.29 23:04:39 4: Connection accepted from WEB_192.168.2.108_53552
2019.12.29 23:04:39 4: WEB_192.168.2.108_53552 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2019-12.log; BUFLEN:0
2019.12.29 23:04:39 4: WEB_192.168.2.108_53552 GET /fhem/FileLog_logWrapper?XHR=1&inform=type=status;filter=;since=1577657078;fmt=JSON&fw_id=58×tamp=1577657082379; BUFLEN:0
2019.12.29 23:05:28 4: Connection closed for WEB_192.168.2.108_53552: EOF
2019.12.29 23:05:28 4: Connection accepted from WEB_192.168.2.108_53601
2019.12.29 23:05:28 4: WEB_192.168.2.108_53601 GET /fhem?cmd=style%20eventMonitor; BUFLEN:0
2019.12.29 23:05:28 4: WEB: /fhem?cmd=style%20eventMonitor / RL:1476 / text/html; charset=UTF-8 / Content-Encoding: gzip
 / Cache-Control: no-cache, no-store, must-revalidate

2019.12.29 23:05:28 4: WEB_192.168.2.108_53601 GET /fhem?XHR=1&inform=type=status;filter=;since=1577657127;fmt=JSON&fw_id=59×tamp=1577657130738; BUFLEN:0
2019.12.29 23:05:29 4: Connection closed for WEB_192.168.2.108_53601: EOF
2019.12.29 23:05:29 4: Connection accepted from WEB_192.168.2.108_53604
2019.12.29 23:05:29 4: WEB_192.168.2.108_53604 GET /fhem?XHR=1&inform=type=raw;withLog=0;filter=.*×tamp=1577657131661&fwcsrf=csrf_229040138773841; BUFLEN:0
2019.12.29 23:05:30 4: Connection closed for WEB_192.168.2.108_53604: EOF
2019.12.29 23:05:30 4: Connection accepted from WEB_192.168.2.108_53606
2019.12.29 23:05:30 4: WEB_192.168.2.108_53606 GET /fhem?XHR=1&inform=type=raw;withLog=1;filter=.*×tamp=1577657132852&fwcsrf=csrf_229040138773841; BUFLEN:0
2019.12.29 23:05:31 4: Connection accepted from WEB_192.168.2.108_53608
2019.12.29 23:05:31 4: WEB_192.168.2.108_53608 GET /fhem/pgm2/images/ui-icons_222222_256x240.png; BUFLEN:0
2019.12.29 23:05:48 4: Connection closed for WEB_192.168.2.108_53606: EOF
2019.12.29 23:05:48 4: WEB_192.168.2.108_53608 GET /fhem?XHR=1&inform=type=raw;withLog=1;filter=MAX.*×tamp=1577657151313&fwcsrf=csrf_229040138773841; BUFLEN:0
2019.12.29 23:05:57 4: Connection closed for WEB_192.168.2.108_53608: EOF
2019.12.29 23:05:57 4: Connection accepted from WEB_192.168.2.108_53636
2019.12.29 23:05:57 4: WEB_192.168.2.108_53636 GET /fhem?XHR=1&inform=type=raw;withLog=1;filter=.*×tamp=1577657160105&fwcsrf=csrf_229040138773841; BUFLEN:0
2019.12.29 23:06:02 4: Connection closed for WEB_192.168.2.108_53636: EOF
2019.12.29 23:06:02 4: Connection accepted from WEB_192.168.2.108_53641
2019.12.29 23:06:02 4: WEB_192.168.2.108_53641 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2019-12.log; BUFLEN:0

Wzut · 29 Dezember 2019, 19:53:27

1. pairmode 500 macht keinen Sinn , das aktuelle Modul will irgend einen Wert , setzt den pairmode aber danach immer auf 60 Sekunden !
das kann also schon mal knapp werden wenn man durchs Haus rennen muss.

2.da du schon den CUL und das CUL_MAX Device auf verbose 5 stehen hast , warum enthälst du uns das Log vor ?
Da steht bestimmt drin warum es nicht klappt

piet · 29 Dezember 2019, 23:17:37

Zitat1. pairmode 500 macht keinen Sinn , das aktuelle Modul will irgend einen Wert , setzt den pairmode aber danach immer auf 60 Sekunden !
das kann also schon mal knapp werden wenn man durchs Haus rennen muss.

Hab in Verzweifelung meines Tuns immer mal wieder verschiedenes ausprobiert, unter anderem auch ohne Zeitangabe.
Im Wissen um meine eigene Sportlichkeit habe ich erstmal versucht den zweiten Heizkörper im gleichen Raum zu pairen, im gleichen Raum befinden sich auch das bereits gepairte HT und der Pi, Distanz sollte also kein Problem sein.

Zitat2.da du schon den CUL und das CUL_MAX Device auf verbose 5 stehen hast , warum enthälst du uns das Log vor ?
Da steht bestimmt drin warum es nicht klappt

Ich hab's in meinem initialen Text jetzt das Log für eine erfolgreiche Temperaturänderung des bereits gepairten HTs und das Log beim Pairing-Versuch des zweiten HTs ergänzt.
Wirklich schlau daraus geworden bin ich bisher leider nicht, das funktionierende Gerät scheint mir i.O. in der Kommunikation und bei dem fehlgeschlagenen Pairing sehe ich keine hilfreiche Kommunikation.

Wzut · 30 Dezember 2019, 07:28:08

Sorry , aber deine Logs sind (fast) unbrauchbar. Bitte sorge dafür das global attr verbose nicht höher als 3 ist und auch am WEB Device nicht mehr als 3.
Selbst dein erster Log zeigt schon zu wenig Infos, man sieht zwar das ein Telegramm raus sollte ->

Code Auswählen

2019.12.29 23:12:19 5: CUL_MAX_SendQueueHandler: 1 items in queue
aber von der Rückantwort fehlt jede Spur.
Im zweiten Log sind jede Menge Eiinträge von deiner PC Bedienung aber von MAX und CUL steht da gar nichts.

piet · 30 Dezember 2019, 18:30:29

Zuerstmal: Danke für deine Geduld mit mir, Wzut!

Habe nun für global und web attr verbose auf 3 gesetzt. Leider wird im FHEM Logfile gar nichts angezeigt, wenn ich den Pairmode und Pairing-Modus am HT2 starte.
Im Event Monitor sehe ich folgendes: (18:19:18 HT1 Temperatur umgestellt, 18:19:59 Pairmode einschalten, 3 Sekunden später Pairing-Modus am HT)

Code Auswählen

2019.12.30 18:19:18 5 : CUL_MAX_Send: enqueuing 0b0c00401234561440760069
2019.12.30 18:19:18 5 : CUL_MAX_SendQueueHandler: 1 items in queue
2019.12.30 18:19:18 5 : SW: X
2019.12.30 18:19:18 5 : needPreamble: 1, necessaryCredit: 110, credit10ms: 900
2019.12.30 18:19:18 5 : CUL_0 sending Zs0b0c00401234561440760069
2019.12.30 18:19:18 5 : SW: Zs0b0c00401234561440760069
2019.12.30 18:19:18 5 : CUL/RAW (ReadAnswer): 21 900 </div>2019-12-30 18:19:18 CUL CUL_0 credit10ms: 900
2019-12-30 18:19:18 MAX MAX_144076 desiredTemperature 20.5
2019.12.30 18:19:19 5 : CUL_MAX_SendQueueHandler: 1 items in queue
2019.12.30 18:19:19 5 : CUL_MAX_SendQueueHandler: 1 items in queue
2019.12.30 18:19:19 4 : CUL_Parse: CUL_0 Z0E0C020214407612345600011934290F -66.5
2019.12.30 18:19:19 5 : CUL_0: dispatch Z0E0C02021440761234560001193429
2019.12.30 18:19:19 5 : CUL_MAX_Parse: len 14, msgcnt 0C, msgflag 02, msgTypeRaw Ack, src 144076, dst 123456, groupid 0, payload 01193429
2019.12.30 18:19:19 5 : CUL_MAX_Parse: rssi: -66.5
2019.12.30 18:19:19 5 : cm: dispatch MAX,1,Ack,144076,01193429
2019.12.30 18:19:19 5 : MAX_Parse MAX,1,Ack,144076,01193429
2019.12.30 18:19:19 5 : MAX_Parse MAX,1,ThermostatState,144076,193429
2019.12.30 18:19:19 5 : battery 0, rferror 0, panel 0, langateway 1, dstsetting 1, mode 1, valveposition 52 %, desiredTemperature 20.5, until , curTemp 
2019.12.30 18:19:19 5 : Got matching ack
2019.12.30 18:19:19 5 : CUL/RAW: /Z0E0C020214407612345600011934290F </div>2019-12-30 18:19:19 MAX MAX_144076 mode: manual
2019-12-30 18:19:19 MAX MAX_144076 battery: ok
2019-12-30 18:19:19 MAX MAX_144076 batteryState: ok
2019-12-30 18:19:19 MAX MAX_144076 panel: unlocked
2019-12-30 18:19:19 MAX MAX_144076 rferror: 0
2019-12-30 18:19:19 MAX MAX_144076 desiredTemperature: 20.5
2019-12-30 18:19:19 MAX MAX_144076 valveposition: 52
2019-12-30 18:19:19 MAX MAX_144076 20.5 °C
2019-12-30 18:19:19 MAX MAX_144076 RSSI: -66.5
2019.12.30 18:19:20 5 : CUL_MAX_SendQueueHandler: 1 items in queue
2019-12-30 18:19:59 CUL_MAX cm pairmode 60

1) Wieso sehe ich das Anschalten des Pairmode nicht im FHEM Logfile?
2) Für mich sieht es so aus als würde keines meiner 5 weiteren Thermostate mit dem CUL kommunizieren, gibt's eine Möglichkeit die Kommunikationsfähigkeit zu testen? Ich nehme an nur mit einem Max!Cube?

Wzut · 30 Dezember 2019, 19:37:10

also das wirklich komisch das dein Log an der Stelle aufhört , zumindest die RAW Nachricht des CUL sollte doch auftauchen wenn das Gerät irgendetwas von sich gibt:
Bei einem würde ich sagen ist halt defekt , aber bei fünf

Dein CUL scheint ja auch ok zu sein, sonst ginge das eine ja auch nicht.
Das einzige was ich da noch sehe ist das da ständig 1 Packet in der Queue ist das nicht zugestellt wird, aber darum kann man sich noch später kümmern wen der Rest läuft.
Was du noch versuchen kannst ( ansonst gehen mir auch die Ideen aus )
a. lass CUL und CUL_MAX auf verbode 5 stehen
b. stelle sicher das autocreate aktiv ist
c. mach den Eventmonitor auf und setze oben auch den Haken FHEM log
c. nimm bei einem HT die Batterien raus, warte eine Minute,
d. setze den pairmode am cm
e. Batterien wiede reinlegen , schickt es Pair Ping ?
Wenn nein , mach noch die Ada Fahrt und sobald er fertig ist wieder pairing
Ist der nicht im Eventmonitor/Log sichtbar, d.h. dein CUL schweigt noch immer, wiederhole a -d , aber beim Wiedereinlegen der Batterien halte nochmal die drei Tasten bis rES im Display erscheint.

zu deiner Frage 2 : IMHO würde dir ein MAX Cube nichts nützen, wenn der CUL schon nichts sieht und der sieht mehr als ein Cube mit org Firmware ....

piet · 30 Dezember 2019, 20:23:45

Also wenn ich das bereits funktionierende HT resete kommt das folgende im Event Monitor, das ist wahrscheinlich auch was du erwartest hast.
Bei allen weiteren fünf Thermostaten kommt nichts

Möglicherweise doch einfach defekt .. ich habe noch 3 weitere HTs die ich am Freitag mal ausprobieren werde .. im Zweifel bestelle ich mal ein Neues um das mal gegenzuchecken.

Code Auswählen


2019-12-30 20:16:02 CUL_MAX cm pairmode
2019.12.30 20:17:11 4 : CUL_Parse: CUL_0 Z17000400144076123456001001A04D4551313335303934322A -53
2019.12.30 20:17:11 5 : CUL_0: dispatch Z17000400144076123456001001A04D455131333530393432
2019.12.30 20:17:11 5 : CUL_MAX_Parse: len 23, msgcnt 00, msgflag 04, msgTypeRaw PairPing, src 144076, dst 123456, groupid 0, payload 1001A04D455131333530393432
2019.12.30 20:17:11 5 : CUL_MAX_Parse: rssi: -53
2019.12.30 20:17:11 5 : CUL_MAX_Parse: Got PairPing (dst 123456, pairmode 0), firmware 16, type 1, testresult 160, serial MEQ1350942
2019.12.30 20:17:11 3 : CUL_MAX_Parse: Re-Pairing device 144076 of type HeatingThermostat with serial MEQ1350942
2019.12.30 20:17:11 5 : cm: dispatch MAX,1,define,144076,HeatingThermostat,MEQ1350942,0
2019.12.30 20:17:11 5 : MAX_Parse MAX,1,define,144076,HeatingThermostat,MEQ1350942,0
2019.12.30 20:17:11 5 : CUL_MAX_Send: enqueuing 0b1100011234561440760000
2019.12.30 20:17:11 5 : CUL_MAX_SendQueueHandler: 1 items in queue
2019.12.30 20:17:11 5 : SW: X
2019.12.30 20:17:11 5 : needPreamble: 1, necessaryCredit: 110, credit10ms: 398
2019.12.30 20:17:11 5 : CUL_0 sending Zs0b1100011234561440760000
2019.12.30 20:17:11 5 : SW: Zs0b1100011234561440760000
2019.12.30 20:17:11 5 : CUL/RAW: /Z17000400144076123456001001A04D4551313335303934322A </div>2019-12-30 20:17:11 MAX MAX_144076 groupid: 0
2019-12-30 20:17:11 MAX MAX_144076 20.0 °C
2019-12-30 20:17:11 MAX MAX_144076 RSSI: -53
2019-12-30 20:17:11 MAX MAX_144076 firmware: 1.0
2019-12-30 20:17:11 MAX MAX_144076 testresult: 160
2019.12.30 20:17:11 5 : CUL/RAW (ReadAnswer): 21 398 </div>2019-12-30 20:17:11 CUL CUL_0 credit10ms: 398
2019.12.30 20:17:11 5 : CUL_MAX_SendQueueHandler: 1 items in queue
2019.12.30 20:17:12 5 : CUL_MAX_SendQueueHandler: 1 items in queue
2019.12.30 20:17:12 4 : CUL_Parse: CUL_0 Z0E110202144076123456000119002828 -54
2019.12.30 20:17:12 5 : CUL_0: dispatch Z0E1102021440761234560001190028
2019.12.30 20:17:12 5 : CUL_MAX_Parse: len 14, msgcnt 11, msgflag 02, msgTypeRaw Ack, src 144076, dst 123456, groupid 0, payload 01190028
2019.12.30 20:17:12 5 : CUL_MAX_Parse: rssi: -54
2019.12.30 20:17:12 5 : cm: dispatch MAX,1,Ack,144076,01190028
2019.12.30 20:17:12 5 : MAX_Parse MAX,1,Ack,144076,01190028
2019.12.30 20:17:12 5 : MAX_Parse MAX,1,ThermostatState,144076,190028
2019.12.30 20:17:12 5 : battery 0, rferror 0, panel 0, langateway 1, dstsetting 1, mode 1, valveposition 0 %, desiredTemperature 20, until , curTemp 
2019.12.30 20:17:12 5 : Got matching ack
2019.12.30 20:17:12 5 : CUL/RAW: /Z0E110202144076123456000119002828 </div>2019-12-30 20:17:12 MAX MAX_144076 mode: manual
2019-12-30 20:17:12 MAX MAX_144076 battery: ok
2019-12-30 20:17:12 MAX MAX_144076 batteryState: ok
2019-12-30 20:17:12 MAX MAX_144076 panel: unlocked
2019-12-30 20:17:12 MAX MAX_144076 rferror: 0
2019-12-30 20:17:12 MAX MAX_144076 desiredTemperature: 20.0
2019-12-30 20:17:12 MAX MAX_144076 valveposition: 0
2019-12-30 20:17:12 MAX MAX_144076 20.0 °C
2019-12-30 20:17:12 MAX MAX_144076 RSSI: -54
2019.12.30 20:17:12 5 : CUL_MAX_SendQueueHandler: 1 items in queue

Wzut · 31 Dezember 2019, 09:04:02

Zitat von: piet am 30 Dezember 2019, 20:23:45
Also wenn ich das bereits funktionierende HT resete kommt das folgende im Event Monitor, das ist wahrscheinlich auch was du erwartest hast.
Code Auswählen Erweitern
2019.12.30 20:17:11 5 : CUL_MAX_Parse: Got PairPing (dst 123456, pairmode 0), firmware 16, type 1, testresult 160, serial MEQ1350942

Das war kein Reset sondern entweder Bat raus / rein oder boost länger gedrückt. Sieht man am dst 123456, aber ja so soll das eigentlich im Log aussehen.
pairmode 0 kommt da deine eine Minute seit dem setzen bereits um war -> 20:16:02 vs 20:17:11

piet · 09 Januar 2020, 20:19:28

Auflösung des Rätsels: Ich habe 4 neue MAX! Heizungsthermostate bei ELV bestellt die sich alle einwandfrei pairen lassen.
Entsprechend waren die gebrauchten Thermostate die ich vorher getestet hatte wohl tatsächlich alle durch ..

@Wzut: Vielen Dank für deine Unterstützung!!