FHEM Forum

Hallo,
ich bin Neueinsteiger und möchte hier um Hilfe für mein Problem seit zwei Tagen bitten.

Bei mir läuft Fhem auf der Fritzbox Version 6.01 und einem CUL V3.0.
Ich habe einen Taster und mehree Switches sowie 6   HM-CC-RT-DN im Einsatz.

Zuerst habe ich mit einem HM-CC-RT-DN angefangen und nach Super -Erfolg 5 weitere gekauft. Diese funktionierten bis vor ca. 2 bis drei Tagen auch ohne Probleme auf der oben beschriebenen Hardware und Software.

Jetzt habe ich den Stand erreicht, dass ein neu gepairter Thermostat kein verstellen der desired-Temp zulässt. Das System erhält alle Daten nach dem Aufwachen, desired-temp wird aber nicht übernommen.
Auf die Anfrage getConfig sagt der Status nun seit ca.17 Minuten: CMDs_pending

Bitte seit mir nicht böse, aber ich bringe diesen Umstand mit dem letztgemachten Update in Verbindung.

Kann mir jemand von den Experten helfen.

Viele Grüße
Wolfgang

Hallo Wolfgang,

wenn es mit dem letzten Update zusammen hängt sollte ein getConfig auch mit anderen RTs nicht mehr erfolgreich sein. Wie ist hier der Stand?

Ich gehe davon aus, dass du demnach auf dem aktuellen Stand bist.

kannst du einmal ein log der messages schicken - mit
attr global verbose 1
attr global mseclog 1
attr <cul> verbose 4
Gruss Martin

Hallo Martin,
nett, dass du dich meldest.
In der Tat bin ich auf dem neuesten Stand für Fhem und Fritzbox.

Ja, alle RT´s zeigen das gleiche Verhalten.

Ich habe alles versucht: neu gepeert, nur ein RT-Betrieb, mögliche Störquellen ausgeschaltet, CUL mit Fritzbox an anderer Stelle positioniert.

Hier nun die verschiedenen Informationen:

CFGFN /usr/share/fhem/FHEM/Arbeitszimmer.cfg CUL_MSGCNT 3 CUL_RAWMSG A0FB7861021F2D50000000AA8D90F1D1828 CUL_RSSI -54 CUL_TIME 2013-12-31 08:59:35 DEF  21F2D5 IODev CUL LASTInputDev CUL MSGCNT 3 NAME AZ_Heizungsventil NR 290 STATE CMDs_pending TYPE CUL_HM channel_01 AZ_Heizungsventil_Weather channel_02 AZ_Heizungsventil_Climate channel_03 AZ_Heizungsventil_WindowRec channel_04 AZ_Heizungsventil_Clima channel_05 AZ_Heizungsventil_ClimaTeam channel_06 AZ_Heizungsventil_remote lastMsg No:B7 - t:10 s:21F2D5 d:000000 0AA8D90F1D18 protCmdPend 13 CMDs pending protLastRcv 2013-12-31 08:59:35 protResnd 3 last_at:2013-12-31 08:59:39 protSnd 3 last_at:2013-12-31 08:59:35 protState CMDs_pending rssi_at_CUL avg:-54.16 min:-54.5 max:-54 lst:-54 cnt:3  Readings Activity alive 2013-12-31 08:53:58 actuator 29 % 2013-12-31 08:59:35 battery ok 2013-12-31 08:59:35 batteryLevel 3 V 2013-12-31 08:59:35 desired-temp 21 2013-12-31 08:59:35 measured-temp 21.7 2013-12-31 08:59:35 state CMDs_pending 2013-12-31 08:59:39

Aus der Logdatei:

2013-12-31_08:53:24 AZ_Heizungsventil Activity: alive 2013-12-31_08:53:58 AZ_Heizungsventil Activity: alive 2013-12-31_08:54:46 AZ_Heizungsventil battery: ok 2013-12-31_08:54:46 AZ_Heizungsventil batteryLevel: 3 V 2013-12-31_08:54:46 AZ_Heizungsventil measured-temp: 21.2 2013-12-31_08:54:46 AZ_Heizungsventil desired-temp: 21 2013-12-31_08:54:46 AZ_Heizungsventil actuator: 42 % 2013-12-31_08:57:18 AZ_Heizungsventil battery: ok 2013-12-31_08:57:18 AZ_Heizungsventil batteryLevel: 3 V 2013-12-31_08:57:18 AZ_Heizungsventil measured-temp: 21.4 2013-12-31_08:57:18 AZ_Heizungsventil desired-temp: 21 2013-12-31_08:57:18 AZ_Heizungsventil actuator: 42 % 2013-12-31_08:59:35 AZ_Heizungsventil battery: ok 2013-12-31_08:59:35 AZ_Heizungsventil batteryLevel: 3 V 2013-12-31_08:59:35 AZ_Heizungsventil measured-temp: 21.7 2013-12-31_08:59:35 AZ_Heizungsventil desired-temp: 21 2013-12-31_08:59:35 AZ_Heizungsventil actuator: 29 % 2013-12-31_09:01:38 AZ_Heizungsventil battery: ok 2013-12-31_09:01:38 AZ_Heizungsventil batteryLevel: 3 V 2013-12-31_09:01:38 AZ_Heizungsventil measured-temp: 21.9 2013-12-31_09:01:38 AZ_Heizungsventil desired-temp: 21 2013-12-31_09:01:38 AZ_Heizungsventil actuator: 29 % 2013-12-31_09:01:41 AZ_Heizungsventil ResndFail 2013-12-31_09:01:41 AZ_Heizungsventil MISSING ACK

Aus dem LogFile (ich habe nach Einstellung der attr einen Neustart durchgeführt):

2013.12.31 08:53:39.631 0: Server shutdown 2013.12.31 08:53:43.232 1: Including /etc/fhem.cfg 2013.12.31 08:53:46.513 1: Including /usr/share/fhem/FHEM/Automatik.cfg 2013.12.31 08:53:46.866 1: Including /usr/share/fhem/FHEM/Garten.cfg 2013.12.31 08:53:48.991 1: Including /usr/share/fhem/FHEM/kleines_Zimmer.cfg 2013.12.31 08:53:49.396 1: Including /usr/share/fhem/FHEM/Arbeitszimmer.cfg 2013.12.31 08:53:49.876 1: Including /usr/share/fhem/FHEM/Plots.cfg 2013.12.31 08:53:50.372 1: Including /usr/share/fhem/FHEM/Enigma2.cfg 2013.12.31 08:53:51.193 1: Including /usr/share/fhem/FHEM/Gaestezimmer.cfg 2013.12.31 08:53:51.971 1: Including /usr/share/fhem/FHEM/Bad_Erdgeschoss.cfg 2013.12.31 08:53:52.227 1: Including /usr/share/fhem/FHEM/Bad_Untergeschoss.cfg 2013.12.31 08:53:52.564 1: Including /usr/share/fhem/FHEM/Anwesenheit.cfg 2013.12.31 08:53:52.574 1: Including /usr/share/fhem/FHEM/Wetter_yahoo.cfg 2013.12.31 08:53:53.055 1: Including /var/log/fhem/fhem.save 2013.12.31 08:53:53.823 1: usb create starting 2013.12.31 08:53:53.976 1: usb create end 2013.12.31 08:53:53.981 0: Server started with 177 defined entities (version $Id: fhem.pl 4501 2013-12-29 17:59:52Z rudolfkoenig $, os linux, user unknown, pid 2654) 2013.12.31 08:54:33.190 2: CUL_HM set AZ_Heizungsventil getConfig 2013.12.31 08:54:49.548 4: CUL_HM_Resend: AZ_Heizungsventil nr 2 2013.12.31 08:57:22.679 4: CUL_HM_Resend: AZ_Heizungsventil nr 3 2013.12.31 08:59:39.871 4: CUL_HM_Resend: AZ_Heizungsventil nr 4

Hoffentlich habe ich die richtigen Informationen für dich

Gruß Wolfgang

Hallo Wolfgang,

wenn du ein
list AZ_Heizungsventil
in die Kommandozeile eingibst kannst du formatiert kopieren

die Logs des verhaltens - auf message-ebene musst du loggen gemäss
http://forum.fhem.de/index.php/topic,16563.msg107848.html#msg107848

Nach dem einstellen des verbose levels sollten auch messages im Logfile stehen

Gruss Martin

Hallo Martin,
tut mir Leid, dass es so lange dauert.
Ich bin in den Vorbereitungen für heute Abend.
Berliner backen, Raum schmücken  etc.

Nun noch einmal:
Internals:
   CFGFN      /usr/share/fhem/FHEM/Arbeitszimmer.cfg
   CUL_MSGCNT 7
   CUL_RAWMSG A0F06861021F2D50000000A80D40F001825
   CUL_RSSI   -55.5
   CUL_TIME   2013-12-31 12:18:49
   DEF        21F2D5
   IODev      CUL
   LASTInputDev CUL
   MSGCNT     7
   NAME       AZ_Heizungsventil
   NR         291
   STATE      MISSING ACK
   TYPE       CUL_HM
   channel_01 AZ_Heizungsventil_Weather
   channel_02 AZ_Heizungsventil_Climate
   channel_03 AZ_Heizungsventil_WindowRec
   channel_04 AZ_Heizungsventil_Clima
   channel_05 AZ_Heizungsventil_ClimaTeam
   channel_06 AZ_Heizungsventil_remote
   lastMsg    No:06 - t:10 s:21F2D5 d:000000 0A80D40F0018
   protCmdDel 54
   protLastRcv 2013-12-31 12:18:49
   protResnd  3 last_at:2013-12-31 12:08:44
   protResndFail 1 last_at:2013-12-31 12:11:37
   protSnd    4 last_at:2013-12-31 12:11:34
   protState  CMDs_done_Errors:1
   rssi_at_CUL avg:-55.71 min:-56.5 max:-55 lst:-55.5 cnt:7
   Readings:
     2013-12-31 12:03:13   Activity        alive
     2013-12-31 12:18:49   actuator        0 %
     2013-12-31 12:18:49   battery         ok
     2013-12-31 12:18:49   batteryLevel    3 V
     2013-12-31 12:18:49   desired-temp    16
     2013-12-31 12:18:49   measured-temp   21.2
     2013-12-31 12:11:37   state           MISSING ACK
   Helper:
     mId        0095
     rxType     140
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf   
       qReqStat   
     Role:
       dev        1
     Rssi:
       At_cul:
         avg        -55.7142857142857
         cnt        7
         lst        -55.5
         max        -55
         min        -56.5
Attributes:
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_full
   firmware   1.0
   group      AZ_Heizungsventil
   model      HM-CC-RT-DN
   peerIDs   
   room       y_aktor
   serialNr   KEQ0652122
   subType    thermostat
   verbose    4
   webCmd     getConfig:burstXmit

Viele Grüße
Wolfgang

evtl hilft auch mein log. ich habe seit dem post am 28.12 in http://forum.fhem.de/index.php/topic,14738.735.html nun wieder das Problem MISSING_ACK und das ich die temp nicht setzen kann.
am 28.12 war mein sys aktuell -> misisng ack -> neu gemacht, fhem neu -> schon probleme beim pairen, aber dann doch erfolgreich -> nun nach kurzer zeit erfolgreichen laufens (wieder ziemlich genau 1,5-2 tage) missing  MISSING_ACK, CMDsPending, Änderungen am Ventil werden aber in fhem übernommen / angezeigt

list buero.heizung

Zitat

Internals:
   CUL_0_MSGCNT 46
   CUL_0_RAWMSG A0F8B86102222750000000A90AE0F50C059
   CUL_0_RSSI -29.5
   CUL_0_TIME 2013-12-31 12:27:10
   DEF        222275
   IODev      CUL_0
   LASTInputDev CUL_0
   MSGCNT     46
   NAME       Buero.Heizung
   NR         47
   STATE      MISSING ACK
   TYPE       CUL_HM
   channel_01 Buero.Heizung_Weather
   channel_02 Buero.Heizung_Climate
   channel_03 Buero.Heizung_WindowRec
   channel_04 Buero.Heizung_Clima
   channel_05 Buero.Heizung_ClimaTeam
   channel_06 Buero.Heizung_remote
   lastMsg    No:8B - t:10 s:222275 d:000000 0A90AE0F50C0
   protCmdDel 32
   protLastRcv 2013-12-31 12:27:10
   protResnd  6 last_at:2013-12-31 12:25:00
   protResndFail 2 last_at:2013-12-31 12:27:12
   protSnd    8 last_at:2013-12-31 12:27:10
   protState  CMDs_done_Errors:1
   rssi_at_CUL_0 avg:-29.84 min:-30.5 max:-28 lst:-29.5 cnt:46
   Readings:
     2013-12-31 10:33:51   Activity        alive
     2013-12-30 12:17:20   CommandAccepted yes
     2013-12-29 19:19:13   PairedTo        0xF11034
     2013-12-29 19:19:13   R-backOnTime    10 s
     2013-12-31 12:00:10   R-btnLock       unlock
     2013-12-31 12:00:10   R-burstRx       set_on
     2013-12-31 12:00:10   R-cyclicInfoMsg on
     2013-12-31 12:00:10   R-cyclicInfoMsgDis 0
     2013-12-31 12:00:10   R-globalBtnLock off
     2013-12-31 12:00:10   R-localResDis   off
     2013-12-29 19:19:13   R-lowBatLimitRT 2.1 V
     2013-12-31 12:00:10   R-modusBtnLock  off
     2013-12-31 12:00:10   R-pairCentral   0xF11034
     2013-12-29 19:19:13   RegL_00:        01:00 02:01 09:01 0A:F1 0B:10 0C:34 0E:0A 0F:00  11:00 12:15 16:00 18:00 19:00 1A:00 00:00
     2013-12-31 12:27:10   actuator        80 %
     2013-12-31 12:27:10   battery         ok
     2013-12-31 12:27:10   batteryLevel    3 V
     2013-12-31 12:27:10   desired-temp    18
     2013-12-31 12:27:10   measured-temp   17.4
     2013-12-31 12:27:12   state           MISSING ACK
     2013-12-30 18:05:04   time-request    -
   Helper:
     mId        0095
     rxType     140
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf   
       qReqStat   
     Role:
       dev        1
     Rssi:
       At_cul_0:
         avg        -29.8478260869565
         cnt        46
         lst        -29.5
         max        -28
         min        -30.5
     Shadowreg:
       RegL_00:   01:01 02:01 09:01 0A:F1 0B:10 0C:34 0E:0A 0F:00  11:00 12:15 16:00 18:00 19:00 1A:00 00:00
Attributes:
   IODev      CUL_0
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_full
   firmware   1.0
   model      HM-CC-RT-DN
   peerIDs   
   room       Buero
   serialNr   KEQ0514304
   subType    thermostat
   webCmd     getConfig:burstXmit

Hallo Chris,

ja, muss auch noch vorbereiten....

dein CUL (oder CUNO) empfängt in sehr kleinen Schritten... (oder stottert?)

Ich sehe einen Sendeversuche um12:00:19.964 - Aber das ist eine Katastrophe. was sollte da gesendet werden?
Hast hattest du etwas zu senden? Das war keine message.
Gruss Martin

2013.12.31 12:00:19.964 4: CUL_send:  CUL_0is 00 00 0F00 0FF0 

da sendet er zur IT1500 steckdose ein AUS.

der CUL ist ein COC. was heisst er stottert? Fehlverhalten? Ich habe ja hier http://forum.fhem.de/index.php/topic,18106.0.html schon eimal befragt weil sich der COC für mich als frischling komisch verhält.

IT1500? Was ist das? HM?
Wenn nicht  - eine CUL kann HM nur exclisiv. Kann dass das Problem sein?

das sind Intertechno-Funksteckdosen. die laufen auf 433 MHz und sind nicht hm. in diversen beiträgen habe ich gelesen das der COC damit keine probleme haben soll kurz auf 433 zu gehen und den befehl zu senden.

HM devics brauchen ein eigenes IO device. Es gibt keines, das einen Mischbetrieb mit HM kann.
habe ich etwas übersehen oder hast du gemischt?

OK. könnte der grund sein. habe nun nochmal ein frisches system erstellt und nur den RT eingebunden. evtl hilft es (pi neu installiert, fhem frisch installiert).

kannst du dir bitte nochmal das log ansehen? ich habe wieder das problem gehabt das pairing am RT 2x einzuleiten und habe wieder erst beim 2. mal das AC bekommen.

danke & gruß
chris

Hi Chris,

was eigentliche pairen hat sofort funktioniert. Auch das Lesen der ersten registerlisten und peers.
Zu diesem Zeitpunkt konntest du schon in den Registern sehen, dass das pairing funktioniert hat.

Erst bei der sehr langen registerliste von Channel 04 ist ein Problem aufgetreten.
Channel 04 und 05 wurden nicht korrekt gelesen - muss ich einmal suchen...

channel 06 ist nach dem aufwachen dann korrekt gelesen worden - auch die Uhrzeit wurde übertragen.

Gruss Martin

Hallo Martin, hallo Chris,
gesundes neues Jahr wünsche ich euch.
Wollte mich noch einmal melden. Mein Problem besteht immernoch.
Martin gibt es die Möglichkeit Fhem auf den Stand vom vor den 28.12.2013 rückzudaten?

Gruß
Wolfgang

@Wolfgang,

du solltest mit jedem Update ein entsprechendes File dazu angelegt bekommen. Ansonsten kannst su aus SVN die Files dieses Datums - also die zu diesem Zeitpunkt gültige Version zusammenstellen

Gruss Martin

Hallo Martin,

Danke für die schnelle Information

Gruß
Wolfgang

Hallo Martin,
großes Kompliment an dich und das gesamte Team.
Ein glücklicher Mensch schreibt dieses. Es funktioniert wieder alles.
Musste zwar alle RT´s neu peeren, aber was soll´s
Ich habe es mitbekommen, dass du (ihr) wohl viel Zeit verbracht habt.

FB ist 6.01
Fhem letztes update

Vielen Dank und viele Grüße
Wolfgang

Hallo Wollebe oder Martinp876,

ich habe ein ähnliches Problem.
Irgendwie fehlt mir der letzte Schritt, wie das Problem gelöst wurde?
Könnt ihr Infos dazu geben?

Gruß,
Martin
P.S: LogFile:
2014.01.31 10:04:21.194 4: CUL_send:  CUL_0As 0A 85 8002 F11034 21F454 00
2014.01.31 10:04:21.436 4: CUL_Parse: CUL_0 A 1A 85 A010 21F454 F11034 03012A22093D18030016073000640F050034 -48
2014.01.31 10:04:21.446 4: CUL_send:  CUL_0As 0A 85 8002 F11034 21F454 00
2014.01.31 10:04:21.694 4: CUL_Parse: CUL_0 A 1A 85 A010 21F454 F11034 03012A22093D18030016073000640F050034 -48
2014.01.31 10:04:21.704 4: CUL_send:  CUL_0As 0A 85 8002 F11034 21F454 00
2014.01.31 10:04:24.548 4: CUL_Parse: CUL_0 A 0F E9 8610 21BC53 000000 0AB0F08F161808 -70
2014.01.31 10:04:24.651 4: CUL_send:  CUL_0As 09 86 A112 F11034 21BC53
2014.01.31 10:04:24.812 4: CUL_Parse: CUL_0 A 0A 86 8002 21BC53 F11034 0007 -70.5
2014.01.31 10:04:24.914 4: CUL_send:  CUL_0As 10 87 A001 F11034 21BC53 00040000000007
2014.01.31 10:04:25.090 4: CUL_Parse: CUL_0 A 1A 87 A010 21BC53 F11034 03012A22093D18030016073000640F050008 -70
2014.01.31 10:04:25.119 4: CUL_send:  CUL_0As 0A 87 8002 F11034 21BC53 00
2014.01.31 10:04:25.349 4: CUL_Parse: CUL_0 A 1A 87 A010 21BC53 F11034 03012A22093D18030016073000640F050008 -70
2014.01.31 10:04:25.609 4: CUL_Parse: CUL_0 A 1A 87 A010 21BC53 F11034 03012A22093D18030016073000640F050008 -70
2014.01.31 10:04:25.618 4: CUL_send:  CUL_0As 0A 87 8002 F11034 21BC53 00
2014.01.31 10:04:40.304 4: CUL_send:  CUL_0As 09 88 B112 F11034 21BC53
2014.01.31 10:06:20.104 4: CUL_Parse: CUL_0 A 0F 60 8610 22E1B9 000000 0A9CCE0F10290B -68.5
2014.01.31 10:06:20.207 4: CUL_send:  CUL_0As 09 89 A112 F11034 22E1B9
2014.01.31 10:06:20.365 4: CUL_Parse: CUL_0 A 0A 89 8002 22E1B9 F11034 000D -67.5
2014.01.31 10:06:20.467 4: CUL_send:  CUL_0As 10 8A A001 F11034 22E1B9 00040000000007
2014.01.31 10:06:20.642 4: CUL_Parse: CUL_0 A 1A 8A A010 22E1B9 F11034 03012A22093D18030016073000640F050007 -70.5
2014.01.31 10:06:20.662 4: CUL_send:  CUL_0As 0A 8A 8002 F11034 22E1B9 00
2014.01.31 10:06:20.899 4: CUL_Parse: CUL_0 A 1A 8A A010 22E1B9 F11034 03012A22093D18030016073000640F050012 -65
2014.01.31 10:06:20.908 4: CUL_send:  CUL_0As 0A 8A 8002 F11034 22E1B9 00
2014.01.31 10:06:21.157 4: CUL_Parse: CUL_0 A 1A 8A A010 22E1B9 F11034 03012A22093D18030016073000640F050013 -64.5
2014.01.31 10:06:21.166 4: CUL_send:  CUL_0As 0A 8A 8002 F11034 22E1B9 00
2014.01.31 10:06:30.628 4: CUL_Parse: CUL_0 A 0F 72 8610 21F454 000000 0A98C60E072C2D -51.5
2014.01.31 10:06:30.731 4: CUL_send:  CUL_0As 09 8B A112 F11034 21F454
2014.01.31 10:06:30.891 4: CUL_Parse: CUL_0 A 0A 8B 8002 21F454 F11034 0030 -50
2014.01.31 10:06:30.993 4: CUL_send:  CUL_0As 10 8C A001 F11034 21F454 00040000000007
2014.01.31 10:06:31.167 4: CUL_Parse: CUL_0 A 1A 8C A010 21F454 F11034 03012A22093D18030016073000640F050035 -47.5
2014.01.31 10:06:31.183 4: CUL_send:  CUL_0As 0A 8C 8002 F11034 21F454 00
2014.01.31 10:06:31.425 4: CUL_Parse: CUL_0 A 1A 8C A010 21F454 F11034 03012A22093D18030016073000640F050035 -47.5
2014.01.31 10:06:31.434 4: CUL_send:  CUL_0As 0A 8C 8002 F11034 21F454 00
2014.01.31 10:06:31.683 4: CUL_Parse: CUL_0 A 1A 8C A010 21F454 F11034 03012A22093D18030016073000640F050034 -48
2014.01.31 10:06:31.692 4: CUL_send:  CUL_0As 0A 8C 8002 F11034 21F454 00
2014.01.31 10:06:36.252 4: CUL_Parse: CUL_0 A 0F D8 8610 22E0FA 000000 0A9CCE0F0E2B16 -63
2014.01.31 10:07:26.046 4: CUL_Parse: CUL_0 A 0F EA 8610 21BC53 000000 0AB0F08F161807 -70.5
2014.01.31 10:07:26.149 4: CUL_send:  CUL_0As 09 8D B112 F11034 21BC53
2014.01.31 10:07:26.167 4: CUL_send:  CUL_0As 09 8E A112 F11034 21BC53
und noch ein list:
Internals:
   CUL_0_MSGCNT 4447
   CUL_0_RAWMSG A1A94A01021BC53F1103403012A22093D18030016073000640F050007
   CUL_0_RSSI -70.5
   CUL_0_TIME 2014-01-31 10:10:14
   DEF        21BC53
   IODev      CUL_0
   LASTInputDev CUL_0
   MSGCNT     4447
   NAME       CUL_HM_HM_CC_RT_DN_21BC53
   NR         535
   STATE      CMDs_pending
   TYPE       CUL_HM
   channel_01 CUL_HM_HM_CC_RT_DN_21BC53_Weather
   channel_02 CUL_HM_HM_CC_RT_DN_21BC53_Climate
   channel_03 CUL_HM_HM_CC_RT_DN_21BC53_WindowRec
   channel_04 CUL_HM_HM_CC_RT_DN_21BC53_Clima
   channel_05 CUL_HM_HM_CC_RT_DN_21BC53_ClimaTeam
   channel_06 CUL_HM_HM_CC_RT_DN_21BC53_remote
   lastMsg    No:94 - t:10 s:21BC53 d:F11034 03012A22093D18030016073000640F0500
   protCmdPend 21 CMDs pending
   protCondBurst off
   protLastRcv 2014-01-31 10:10:14
   protResnd  949 last_at:2014-01-31 10:10:15
   protSnd    4390 last_at:2014-01-31 10:10:14
   protState  CMDs_pending
   rssi_at_CUL_0 avg:-69.74 min:-79.5 max:-66.5 lst:-70.5 cnt:4447
   Readings:
     2014-01-29 17:53:53   Activity        alive
     2014-01-31 10:10:13   CommandAccepted yes
     2014-01-27 22:53:15   PairedTo        0xF11034
     2014-01-27 22:53:15   R-backOnTime    10 s
     2014-01-31 10:04:40   R-btnLock       unlock
     2014-01-31 10:04:40   R-burstRx       set_on
     2014-01-31 10:04:40   R-cyclicInfoMsg on
     2014-01-31 10:04:40   R-cyclicInfoMsgDis 0
     2014-01-31 10:04:40   R-globalBtnLock off
     2014-01-31 10:04:40   R-localResDis   off
     2014-01-27 22:53:15   R-lowBatLimitRT 2.1 V
     2014-01-31 10:04:40   R-modusBtnLock  off
     2014-01-31 10:04:40   R-pairCentral   0xF11034
     2014-01-27 22:53:15   RegL_00:        01:00 02:01 09:01 0A:F1 0B:10 0C:34 0E:0A 0F:00  11:00 12:15 16:00 18:00 19:00 1A:00 00:00
     2014-01-31 10:10:13   actuator        22 %
     2014-01-31 10:10:13   battery         ok
     2014-01-31 10:10:13   batteryLevel    3 V
     2014-01-31 10:10:13   desired-temp    22
     2014-01-31 10:10:13   measured-temp   24.0
     2014-01-27 20:43:55   powerOn         -
     2014-01-27 20:43:55   recentStateType info
     2014-01-31 10:10:15   state           CMDs_pending
     2014-01-30 16:59:53   time-request    -
     Regl_07::
       VAL       
   cmdStack:
     ++A001F1103421BC5300040000000007
     ++A001F1103421BC530503
     ++A001F1103421BC5305040000000001
     ++A001F1103421BC530603
     ++A001F1103421BC5306040000000001
     ++A011F1103421BC5386042B
     ++A001F1103421BC5300050000000000
     ++A001F1103421BC5300080101
     ++A001F1103421BC530006
     ++A001F1103421BC5300040000000000
     ++A001F1103421BC530103
     ++A001F1103421BC5301040000000001
     ++A001F1103421BC530203
     ++A001F1103421BC5302040000000001
     ++A001F1103421BC530303
     ++A001F1103421BC5303040000000001
     ++A001F1103421BC5304040000000001
     ++A001F1103421BC5300040000000007
     ++A001F1103421BC530503
     ++A001F1103421BC5305040000000001
     ++A001F1103421BC530603
     ++A001F1103421BC5306040000000001
   Helper:
     cSnd       01F1103421BC5300040000000007
     mId        0095
     rxType     140
     Io:
       nextSend   1391159414.46629
     Prt:
       awake      0
       bErr       0
       sProc      2
       wakeup     0
       wuReSent   2
     Q:
       qReqConf   
       qReqStat   
     Role:
       dev        1
     Rpt:
       IO         CUL_0
       flg        A
       ts         1391159414.37235
       ack:
         HASH(0x16122b0)
         948002F1103421BC5300
     Rssi:
       At_cul_0:
         avg        -69.745783674387
         cnt        4447
         lst        -70.5
         max        -66.5
         min        -79.5
     Shregw:
       07         04
     Shadowreg:
       RegL_00:   01:01 02:01 09:01 0A:F1 0B:10 0C:34 0E:0A 0F:00  11:00 12:15 16:00 18:00 19:00 1A:00 00:00
       RegL_07:   
Attributes:
   IODev      CUL_0
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   burstAccess 1_auto
   expert     2_full
   firmware   1.0
   model      HM-CC-RT-DN
   peerIDs   
   room       CUL_HM
   serialNr   KEQ0576965
   subType    thermostat
   webCmd     :burstXmit
und ein List von Channel 4
Internals:
   CUL_0_MSGCNT 954
   CUL_0_RAWMSG A0FEB861021BC530000000AB0F08F161808
   CUL_0_RSSI -70
   CUL_0_TIME 2014-01-31 10:10:13
   DEF        21BC5304
   LASTInputDev CUL_0
   MSGCNT     954
   NAME       CUL_HM_HM_CC_RT_DN_21BC53_Clima
   NR         540
   STATE      T: 24.0 desired: 22 valve: 22 %
   TYPE       CUL_HM
   chanNo     04
   device     CUL_HM_HM_CC_RT_DN_21BC53
   Readings:
     2014-01-26 13:45:07   H               0
     2014-01-29 18:00:27   R-sign          off
     2014-01-31 10:10:13   RegL_07:         01:2A 02:22 03:09 04:3D 05:18 06:03 07:00 08:16 09:07 0A:30 0B:00 0C:64 0D:0F 0E:05 0F:00
     2014-01-26 13:57:03   T               0
     2014-01-31 10:10:13   ValvePosition   22 %
     2014-01-31 10:10:13   desired-temp    22
     2014-01-31 10:10:13   measured-temp   24.0
     2014-01-31 10:10:13   mode            auto
     2014-01-31 10:10:13   motorErr        communicationERR
     2014-01-31 10:10:13   state           T: 24.0 desired: 22 valve: 22 %
   Helper:
     getCfgListNo
     Prt:
       wakeup     1
     Role:
       chn        1
     Shregr:
       07         00
     Shadowreg:
Attributes:
   model      HM-CC-RT-DN
   peerIDs   

Hallo Martin,

das ist ein getConfig, das schief geht?
Sieht aus, als ob der RT die ACKs nicht versteht - evtl kommen die zu früh. (Gerade war es anderen Devices zu spät...)

Du konntest einmal im HMLAN die Bremse wieder einbauen, dann ein getConfig loggen

00_HMLAN etwa Zeile 689

    my $tn = gettimeofday();
   
    if($typ ne "02" &&
       $modules{CUL_HM}{defptr}{$dst} &&
       $modules{CUL_HM}{defptr}{$dst}{helper}{io} &&
       $modules{CUL_HM}{defptr}{$dst}{helper}{io}{nextSend}
       ){
      my $DevDelay = $modules{CUL_HM}{defptr}{$dst}{helper}{io}{nextSend} - $tn;

ersetzen (eine Zeile löschen) mit
    my $tn = gettimeofday();
   
    if($modules{CUL_HM}{defptr}{$dst} &&
       $modules{CUL_HM}{defptr}{$dst}{helper}{io} &&
       $modules{CUL_HM}{defptr}{$dst}{helper}{io}{nextSend}
       ){
      my $DevDelay = $modules{CUL_HM}{defptr}{$dst}{helper}{io}{nextSend} - $tn;

einfach ein reload 00_HMLAN und dann ein getConfig
ggf müssen wir einen verküzten Delay einbauen.

Du hast eine CUL, keine CUNO über LAN - oder? Die geht eh nicht, schlechtes Timing
Gruss Martn

Zitat von: martinp876 am 31 Januar 2014, 10:39:04

Du hast eine CUL, keine CUNO über LAN - oder? Die geht eh nicht, schlechtes Timing
Gruss Martn

Ich habe einen CUL, den Cuno nutze ich für SlowRF

Deinen Vorschlag probiere ich aus. Vielen, Vielen Dank, war schon ziemlich frustriert, da seit Tagen/2 Wochen alle meine restlichen Versuche fehlgeschlagen sind.
Gruß,
Martin

sorry, wo habe ich meinen Kopf. Du hast CUL - also

00_CUL line 687

  if($id &&
     $mTy ne "02" &&
     $modules{CUL_HM}{defptr}{$id} &&
     $modules{CUL_HM}{defptr}{$id}{helper}{io} &&
     $modules{CUL_HM}{defptr}{$id}{helper}{io}{nextSend}) {
    my $dDly = $modules{CUL_HM}{defptr}{$id}{helper}{io}{nextSend} - $now;

  if($id &&
     $modules{CUL_HM}{defptr}{$id} &&
     $modules{CUL_HM}{defptr}{$id}{helper}{io} &&
     $modules{CUL_HM}{defptr}{$id}{helper}{io}{nextSend}) {
    my $dDly = $modules{CUL_HM}{defptr}{$id}{helper}{io}{nextSend} - $now;


Gruss Martin

Zitat von: martinp876 am 31 Januar 2014, 11:41:26
sorry, wo habe ich meinen Kopf. Du hast CUL - also

00_CUL line 687


Gruss Martin

Hallo Martin,

oh deswegen funktioniert es nicht  ;D

dann mache ich es wieder rückgängig

Dankeschön,
Martin

Hallo Martin,

das hat mein Problem wahrschenlich behoben. Vielen Vielen lieben Dank für deine Hilfe  :D

Ich beobachte und hoffe, daß es jetzt geht :-)

Martin
P.S: Muß ich dies jetzt bei jedem Update wieder ändern?

ich habe jetzt ein Problem: Einige devs wollen sofort ein ACK, der RT erst spätern. Ich kenne den Unterscheider noch nicht.

wenndu es einmal austesten könntest, wie lange man warten darf?
  if($id &&
     $modules{CUL_HM}{defptr}{$id} &&
     $modules{CUL_HM}{defptr}{$id}{helper}{io} &&
     $modules{CUL_HM}{defptr}{$id}{helper}{io}{nextSend}) {
    my $dDly = $modules{CUL_HM}{defptr}{$id}{helper}{io}{nextSend} - $now;
    $dDly -= 0.08 if ($mTy eq "02");
    if ($dDly > 0.01){# wait less then 10 ms will not work
      $dDly = 0.1 if($dDly > 0.1);
      Log3 $hash->{NAME}, 5, "CUL $id dly:".int($dDly*1000)."ms";
      select(undef, undef, undef, $dDly);
    }
  }


die 0.08, die abgezogen werden sollten möglicht klein sein.
0.00 wäre der ursprüngliche Zustand, funktoniert also nicht.
0.10 ist der max-wert (kein warten) - funktioniert bei remotes nicht.
also könnte man werte um die 0.03 bis 0.07 probieren, je größer um so besser. Ich werde einmal mit den remotes testen, in die gegenrichtung.

p.s. code neu!

hallo Martin,

ich habe in Zeile 687      (habe einen CUL)
$mTy ne "02" &&

entfernt und schon geht es wieder !


sieht also so aus !

if($id &&
     $modules{CUL_HM}{defptr}{$id} &&
     $modules{CUL_HM}{defptr}{$id}{helper}{io} &&
     $modules{CUL_HM}{defptr}{$id}{helper}{io}{nextSend}) {
    my $dDly = $modules{CUL_HM}{defptr}{$id}{helper}{io}{nextSend} - $now;
    if ($dDly > 0.01){# wait less then 10 ms will not work
      $dDly = 0.1 if($dDly > 0.1);
      Log3 $hash->{NAME}, 5, "CUL $id dly:".int($dDly*1000)."ms";
      select(undef, undef, undef, $dDly);
    }

Hi Karl,

kannst du auch den oben beschriebenen Test machen?
So können wir es nicht lassen - die Zeile war schlieslich nitwendig

Zitat von: martinp876 am 31 Januar 2014, 13:49:58
ich habe jetzt ein Problem: Einige devs wollen sofort ein ACK, der RT erst spätern. Ich kenne den Unterscheider noch nicht.

wenndu es einmal austesten könntest, wie lange man warten darf?

Code Auswählen Erweitern

  if($id &&
     $modules{CUL_HM}{defptr}{$id} &&
     $modules{CUL_HM}{defptr}{$id}{helper}{io} &&
     $modules{CUL_HM}{defptr}{$id}{helper}{io}{nextSend}) {
    my $dDly = $modules{CUL_HM}{defptr}{$id}{helper}{io}{nextSend} - $now;
    $dDly -= 0.08 if ($mTy eq "02");
    if ($dDly > 0.01){# wait less then 10 ms will not work
      $dDly = 0.1 if($dDly > 0.1);
      Log3 $hash->{NAME}, 5, "CUL $id dly:".int($dDly*1000)."ms";
      select(undef, undef, undef, $dDly);
    }
  }


die 0.08, die abgezogen werden sollten möglicht klein sein.
0.00 wäre der ursprüngliche Zustand, funktoniert also nicht.
0.10 ist der max-wert (kein warten) - funktioniert bei remotes nicht.
also könnte man werte um die 0.03 bis 0.07 probieren, je größer um so besser. Ich werde einmal mit den remotes testen, in die gegenrichtung.

p.s. code neu!

Hallo Martin,
mir ist nicht so ganz klar wie der Test aussieht (kann nicht programmieren :-()
Die obigen Zeilen einfügen und dann? getConfig auslösen? Wird irgendein LOG geschrieben?
Gruß,
Martin

noch ein Hinweis meinerseits

$dDly -= 0.08 if ($mTy eq "02");

fehlt in meiner 00_CUL.pm   

(s.o.)


klaus

$dDly -= 0.08 if ($mTy eq "02");

Ich habe jetzt mit dieser Zeile etwas rumgespielt:
Bei Werten 0.03 -0.05 funktioniert ein getconfig, bei Werten größer 0.05 hat es nicht funktioniert.
Ich habe es mit 2 Thermostaten und mit mehrmaligen Test probiert. Bei 0.05 wird es langsam unsicher.

Ich hoffe es war nicht kompletter Quatsch und hilft euch?!?

Gruß,
Martin

Hi,
@klaus
klar - das wäre auch eine neue Zeile zur Korrektur

@martin & klaus
damit der teste infacher wird im Anhang eine Datei - man kann das ackDelay  einstellen mit
attr <CUL> ackDly 0.8

Der wert ist hier "positiv" - will sagen
Probleme hattet ihr bei "0.0"
Funitioniert hat es bei "0.1" (100ms)
Aufgabe  ist, auszumessen wann es 'noch' geht.  Stufen sind 0.01 0.02,... 0.09.

Kriterium ist, dass die Kommandos (getConfig oder ähnlich) abgearbeitet werden ohne protokoll-fehler. Hierzu kann man HMInfo
set hm protoEvents short

oder
set hm protoEvents -f <name> short

Gruss Martin

p.s. sehe gerade die Antwort - ja, die Werte hören sich sinnvoll an

Zitat von: martinp876 am 31 Januar 2014, 15:48:49
Hi,
@klaus
klar - das wäre auch eine neue Zeile zur Korrektur

@martin & klaus
damit der teste infacher wird im Anhang eine Datei - man kann das ackDelay  einstellen mit
attr <CUL> ackDly 0.8

Der wert ist hier "positiv" - will sagen
Probleme hattet ihr bei "0.0"
Funitioniert hat es bei "0.1" (100ms)
Aufgabe  ist, auszumessen wann es 'noch' geht.  Stufen sind 0.01 0.02,... 0.09.

Kriterium ist, dass die Kommandos (getConfig oder ähnlich) abgearbeitet werden ohne protokoll-fehler. Hierzu kann man HMInfo
set hm protoEvents short

oder
set hm protoEvents -f <name> short

Gruss Martin

p.s. sehe gerade die Antwort - ja, die Werte hören sich sinnvoll an

Soll wir diese Version von 00_CUL.PM noch testen? Wird dies dann auch die Lösung sein, daß man ein Attribut setzt?
Martin

klaus könnte es noch einmal bestätigen - wäre schön.

das attribut wird nicht die offizielle Lösung. Ich hoffe, dass es mit 50ms für alle läuft... Einstellen könnte man es ggf sowieso nicht am IO device - man müsste es Geräteindividuell machen.

Gruss Martin

Zitat von: martinp876 am 31 Januar 2014, 16:22:35
klaus könnte es noch einmal bestätigen - wäre schön.

das attribut wird nicht die offizielle Lösung. Ich hoffe, dass es mit 50ms für alle läuft... Einstellen könnte man es ggf sowieso nicht am IO device - man müsste es Geräteindividuell machen.

Gruss Martin

dann werde ich es jetzt auf jeden Fall bei mir auch auf 50ms einstellen (aktuell habe ich 40ms) und mit allen RT testen. Bei 50ms hatte ich einmal Probleme. Mal sehen.
Martin
Edit: Leider haben 50ms doch nicht funktioniert, habe jetzt wieder auf 40ms eingestellt

Seit Neuestem habe ich auch wieder unregelmäßig MISSING ACK bei der Kommunikation zwischen HM-CFG-USB und RT.

Hi,

die normale Kommunikation zwischen HMLAN und RT - insbesondere die ACKs - werden vom HMUSB selbst "gemacht". Da hat sich also nichts geändert.
So du aber virtuelle Aktoren nutzt kommt eine Änderung ins Spiel.
Im Anhang ein 00_HMLAN das bei ack 50ms wartet - das hatte bei CUL Erfolge gezeigt.
Falls du logs der missing ack ziehen kannst  und/oder die Datei ausprobieren willst ...

Gruss Martin

Virtuelle Aktoren hab ich nicht *grusel*  8)

Die Probleme können auch einfach aus den aktuellen Bastelarbeiten bezüglich Updates, Parallelbetrieb CCU2+fhem etc kommen. Im Moment ist wieder Ruhe eingekehrt und alles läuft wie geplant.

Hallo Martin,

Sorry konnte leider noch nicht testen , mußte heute nachmittag kurzfristig weg.

Ist ein weiterer Test jetzt noch notwendig?

Klaus

Zitat von: kvo1 am 31 Januar 2014, 22:18:25
Hallo Martin,

Sorry konnte leider noch nicht testen , mußte heute nachmittag kurzfristig weg.

Ist ein weiterer Test jetzt noch notwendig?

Klaus

Hallo Klaus,
sowie ich es verstanden habe ja, da er es gerne verifiziert haben möchte.

Bei mir läuft aktuell stabil 40ms, aber nicht 50ms
Martin

ZitatVirtuelle Aktoren hab ich nicht *grusel*  8)

die haben auch nur begrenzt sinn - gebe ich zu. Manchmal aber durchaus. m.E. sehr hilfreich sind sie
- SD als team lead (würde ich nie anders machen). Ist einfach sauber und löst eigentlich nur die Verlegenheit auf, aus der HM den pseudo-Team-Lead realisiert hat.
- virtueller TC zum Steuern eines VD
- virtueller HM-Temp-Fühler z.B. zum steuern eines RT - ermöglicht das Nutzen beliebiger nicht-HM Fühler

Die beiden letzteren sind aus timing Gründen nicht zu umgehen.

ZitatDie Probleme können auch einfach aus den aktuellen Bastelarbeiten bezüglich Updates, Parallelbetrieb CCU2+fhem etc kommen. Im Moment ist wieder Ruhe eingekehrt und alles läuft wie geplant.

ACKs sind bei HMLAN/USB selten ein Problen, da das IO diese selbst sendet, bis auf ein paar Ausnahmen. Virtuelle Aktoren sind eine der grossen Gruppen hier.
Bei einer CUL sieht es anders aus - hier werden alle ACK "manuel" gesendet. Jetzt gab es Probleme wenn das ACk 100ms verzögert war - einmal war es zu spät, einmal zu früh, je nach Device. Daher plane ich jetzt die 50ms und hoffe, es passt für alle. Den Code für die CUL werde ich demnächst an Rudi abgeben. Falls einer vorher testen will, gerne.

@Martin
ok - verstanden - 60ms min delay (100-40). Du hast im code geändert - oder mit dem Attribut?
Ich werden es noch einmal abhängen lassen - hoffe auf mehr tester. was alles ist bei dir im Aufbau? Nur RTs?

Gruss Martin

Hallo Martin,
sorry ich habe deine Meldung gerade eben erst gesehen, da ich bei Schwiegereltern bin und nicht so häufig reinschaue.
Ich habe es direkt im Code geändert:
$dDly -= 0.04 if ($mTy eq "02");
d.h. heißt dann wohl 60ms delay :-)

Ich habe momentan 4 HM RT an einem CUL hängen und keine weiteren Homematic Module (das wird sich aber demnächst sicherlich noch ändern, evtl. Fensterkontakt, Schalter?). Kommendes WE werde ich wohl einen S300TH Temperatursensor mit einem RT peeren (wenn ich es hinbekomme).

@All: es scheinen ja momentan viele diese Probleme zu haben und wären potentielle Tester. Warum wird es nicht getestet?

Gruß und danke,
Martin

Zitat von: DosiRocker am 03 Februar 2014, 10:48:46
@All: es scheinen ja momentan viele diese Probleme zu haben und wären potentielle Tester. Warum wird es nicht getestet?

Ich teste das auch, da ich auch immer wieder Missing ACK habe (und ich mir dann im Moment nur mit FHEM-Neustart helfen kann); betroffen sind Schalt-/Dimmaktoren.
Ich kann aber noch nichts sagen, da die Missing ACK immer erst nach etwa einem Tag auftreten und ich nicht weiß, warum. Insofern probiere ich nur mit verschiedenen Timings, aber bisher kann ich nicht sagen, dass es was bringt...  :-\

Zitat von: martinp876 am 31 Januar 2014, 20:27:28
Falls du logs der missing ack ziehen kannst  und/oder die Datei ausprobieren willst ...

Ich habe die hier mal probiert, leider ohne Erfolg. Mal gehen die Temperaturen durch, dann wieder nicht:
nternals:
   DEF        235C66
   HMLAN1_MSGCNT 7
   HMLAN1_RAWMSG E235C66,0000,04E396C3,FF,FFB6,5F8610235C660000000A84B7100018
   HMLAN1_RSSI -74
   HMLAN1_TIME 2014-02-03 18:52:18
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     7
   NAME       HK7
   NR         345
   STATE      MISSING ACK
   TYPE       CUL_HM
   channel_01 HK7_Weather
   channel_02 HK7_Climate
   channel_03 HK7_WindowRec
   channel_04 HK7_ClimRT_tr
   channel_05 HK7_ClimaTeam
   channel_06 HK7_remote
   lastMsg    No:5F - t:10 s:235C66 d:000000 0A84B7100018
   protCmdDel 8
   protLastRcv 2014-02-03 18:52:18
   protResnd  3 last_at:2014-02-03 18:44:54
   protResndFail 1 last_at:2014-02-03 18:47:36
   protSnd    4 last_at:2014-02-03 18:47:34
   protState  CMDs_done_Errors:1
   rssi_at_HMLAN1 avg:-74.42 min:-76 max:-73 lst:-74 cnt:7
   Readings:
     2014-02-03 18:37:21   Activity        alive
     2014-02-02 22:58:48   CommandAccepted yes
     2014-01-03 12:58:54   PairedTo        0x121212
     2014-01-03 12:58:54   R-backOnTime    10 s
     2014-01-03 12:58:54   R-btnLock       unlock
     2014-01-03 12:58:54   R-burstRx       off
     2014-01-03 12:58:54   R-cyclicInfoMsg on
     2014-01-03 12:58:54   R-cyclicInfoMsgDis 0
     2014-01-03 12:58:54   R-globalBtnLock off
     2014-01-03 12:58:54   R-localResDis   off
     2014-01-03 12:58:54   R-lowBatLimitRT 2.1 V
     2014-01-03 12:58:54   R-modusBtnLock  off
     2014-01-03 12:58:54   R-pairCentral   0x121212
     2014-01-03 12:58:54   RegL_00:        01:00 02:01 09:01 0A:12 0B:12 0C:12 0E:0A 0F:00  11:00 12:15 16:00 18:00 19:00 1A:00 00:00
     2014-02-02 22:53:45   RegL_07:        0
     2014-02-03 18:52:18   actuator        0 %
     2014-02-03 18:52:18   battery         ok
     2014-02-03 18:52:18   batteryLevel    3.1 V
     2014-02-03 18:52:18   desired-temp    16.5
     2014-02-03 18:52:18   measured-temp   18.3
     2014-01-07 15:53:24   noReceiver      src:235C66 A010 0500000000000700
     2014-02-03 18:47:36   state           MISSING ACK
     2014-02-01 22:24:53   time-request    -
   Helper:
     mId        0095
     rxType     140
     Io:
       nextSend   1391449938.5409
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf   
       qReqStat   
     Role:
       dev        1
     Rssi:
       At_hmlan1:
         avg        -74.4285714285714
         cnt        7
         lst        -74
         max        -73
         min        -76
     Shregw:
       07         04
Attributes:
   IODev      HMLAN1
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_full
   firmware   1.0
   model      HM-CC-RT-DN
   peerIDs   
   room       EG_Werkstatt
   serialNr   KEQ0575544
   subType    thermostat
   webCmd     getConfig:burstXmit

ok - eins nach dem anderen.

ACKs bei HMLAN/USB werden in erster Linie von diesem gesendet - FHEM hat hier also kein Timing problem. Die Änderunge betrifft erst einmal nur CUL Nutzern.

Wer jetzt noch ein Problem hat (HMLAN/USB) bitte Beschreiben und roh-messages mitsenden. Das mit der CUL ist erledigt - bis Probleme auftreten WENN die Änderung eingearbeitet ist.

Gruss Martin

Ah, o.k., dass nur für den CUL war habe ich nicht verstanden.

Ich setzte in der Weboberfläche die Temperatur auf einen anderen Wert. Wird auch übernommen und es erscheint CMDs_pending.

Ein list HK2 bringt:



Internals:
   DEF        21DC2E
   HMLAN1_MSGCNT 28
   HMLAN1_RAWMSG E21DC2E,0000,0036A108,FF,FFB6,8A861021DC2E0000000A9CDA0F0014
   HMLAN1_RSSI -74
   HMLAN1_TIME 2014-02-03 20:27:42
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     28
   NAME       HK2
   NR         110
   STATE      CMDs_pending
   TYPE       CUL_HM
   channel_01 HK2_Weather
   channel_02 HK2_Climate
   channel_03 HK2_WindowRec
   channel_04 HK2_ClimRT_tr
   channel_05 HK2_ClimaTeam
   channel_06 HK2_remote
   lastMsg    No:8A - t:10 s:21DC2E d:000000 0A9CDA0F0014
   protCmdPend 1 CMDs_pending
   protState  CMDs_pending
   rssi_at_HMLAN1 avg:-72.6 min:-80 max:-70 lst:-74 cnt:28
   Readings:
     2014-02-03 19:22:44   Activity        alive
     2014-02-03 19:29:50   CommandAccepted yes
     2014-02-03 18:55:28   PairedTo        0x121212
     2014-01-06 18:27:51   R-backOnTime    10 s
     2014-02-03 18:55:28   R-btnLock       unlock
     2014-02-03 18:55:28   R-burstRx       on
     2014-02-03 18:55:28   R-cyclicInfoMsg on
     2014-02-03 18:55:28   R-cyclicInfoMsgDis 0
     2014-02-03 18:55:28   R-globalBtnLock off
     2014-02-03 18:55:28   R-localResDis   off
     2014-01-06 18:27:51   R-lowBatLimitRT 2.1 V
     2014-02-03 18:55:28   R-modusBtnLock  off
     2014-02-03 18:55:28   R-pairCentral   0x121212
     2014-02-03 18:55:28   RegL_00:        01:01 02:01 09:01 0A:12 0B:12 0C:12 0E:0A 0F:00  11:00 12:15 16:00 18:00 19:00 1A:00 00:00
     2014-02-03 18:58:22   RegL_07:        0
     2014-02-03 20:27:42   actuator        0 %
     2014-02-03 20:27:42   battery         ok
     2014-02-03 20:27:42   batteryLevel    3 V
     2014-02-03 20:27:42   desired-temp    19.5
     2014-02-03 20:27:42   measured-temp   21.8
     2014-01-06 18:25:14   noReceiver      src:21DC2E A001 0106
     2014-01-06 18:22:46   powerOn         -
     2014-01-06 18:22:46   recentStateType info
     2014-02-03 20:28:47   state           CMDs_pending
     2014-02-03 06:23:09   time-request    -
   cmdStack:
     ++A01112121221DC2E860428
   Helper:
     cSnd       0112121221DC2E01040000000001
     mId        0095
     rxType     140
     Io:
       nextSend   1391455662.3547
     Prt:
       awake      0
       bErr       0
       sProc      2
       wakeup     1
     Q:
       qReqConf   
       qReqStat   
     Role:
       dev        1
     Rssi:
       At_hmlan1:
         avg        -72.6071428571429
         cnt        28
         lst        -74
         max        -70
         min        -80
     Shregw:
       07         04
Attributes:
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_full
   firmware   1.0
   model      HM-CC-RT-DN
   peerIDs   
   room       DG_Bad
   serialNr   KEQ0573297
   subType    thermostat
   webCmd     getConfig:burstXmit

Save config
DG_Bad
DG_Flur
DG_Schlafzimmer
DG_Toilette
EG_Bibliothek
EG_Buero
EG_Flur
EG_Waschkueche
EG_Werkstatt
KG_Gaszaehler
OG_Wohnzimmer
Unsorted
Ventile
icoEverything Everything
Logfile
Commandref
Remote doc
Edit files
Select style
Event monitor

Im Log von HK2 steht nur:
014-02-03_20:30:24 HK2 battery: ok
2014-02-03_20:30:24 HK2 batteryLevel: 3 V
2014-02-03_20:30:24 HK2 measured-temp: 21.7
2014-02-03_20:30:24 HK2 desired-temp: 21.5
2014-02-03_20:30:24 HK2 actuator: 0 %
2014-02-03_20:32:53 HK2 battery: ok
2014-02-03_20:32:53 HK2 batteryLevel: 3 V
2014-02-03_20:32:53 HK2 measured-temp: 21.7
2014-02-03_20:32:53 HK2 desired-temp: 21.5
2014-02-03_20:32:53 HK2 actuator: 41 %

bzw.
2014-02-03_20:30:24 HK2_ClimRT_tr T: 21.7 desired: 21.5 valve: 0 %
2014-02-03_20:32:53 HK2_ClimRT_tr T: 21.7 desired: 21.5 valve: 41 %

Das HMLAN sagt:
Internals:
   DEF        10.1.1.62:1000
   DeviceName 10.1.1.62:1000
   FD         4
   HMLAN1_MSGCNT 371
   HMLAN1_TIME 2014-02-03 20:36:13
   HM_CMDNR   95
   NAME       HMLAN1
   NR         25
   NTFY_ORDER 50-HMLAN1
   PARTIAL   
   RAWMSG     E235C66,0000,003E702C,FF,FFBB,888610235C660000000A84AD100018
   RSSI       -69
   STATE      opened
   TYPE       HMLAN
   XmitOpen   1
   assignedIDs 234FB1,221F0F,21D6F0,20853C,15D167,234FA4,221F50,21DC2E,207BAB,235C66
   assignedIDsCnt 10
   assignedIDsReport 9
   firmware   0.961
   msgKeepAlive dlyMax:0.15 bufferMin:4
   msgLoadEst 1hour:2% 10min steps: 0/0/0/0/0/1
   msgParseDly min:1 max:3934 last:6 cnt:329
   owner      121212
   serialNr   KEQ0852586
   uptime     000 01:08:11.948
   Readings:
     2014-02-03 19:28:06   Xmit-Events     ok:1
     2014-02-03 19:28:06   cond            ok
     2014-02-03 19:27:22   prot_ERROR-Overload last
     2014-02-03 19:22:39   prot_Warning-HighLoad last
     2014-02-03 19:28:06   prot_disconnected last
     2014-02-03 19:28:06   prot_init       last
     2014-02-03 19:28:06   prot_ok         last
     2014-01-25 08:22:26   prot_timeout    last
   Assids:
     15D167     1
     207BAB     1
     20853C     1
     21D6F0     1
     21DC2E     1
     221F0F     1
     221F50     1
     234FA4     1
     234FB1     1
     235C66     1
   Helper:
     assId      0
     000001:
       flg        0
       msg       
       to         1391452088.69308
     121212:
       flg        0
     21dc2e:
       chn        01
       flg        0
       msg       
       name       HK2
       newChn     +21DC2E,00,01,
       to         1391456108.26293
     Assids:
     Dly:
       cnt        329
       lst        6
       max        3934
       min        1
     K:
       BufMin     4
       DlyMax     0.15
       Next       1391456182.64797
       Start      1391456157.64797
     Log:
       all        0
       sys        0
       ids:
         ARRAY(0x7f8754150b98)
     Q:
       HMcndN     0
       answerPend 0
       hmLanQlen  1
       keepAliveRec 1
       keepAliveRpt 0
       apIDs:
       Cap:
         0          0
         1          0
         2          12
         3          9
         4          18
         5          6
         last       3
         sum        45
     Ref:
       drft       -0.000159083678014636
       hmtL       4075636
       kTs        0
       offL       1391452082014
       sysL       1391456157650
Attributes:
   hmId       121212
   hmLanQlen  1_min


Nach einiger Zeit geht dann der Thermostat auf Missing ACK
Internals:
   DEF        21DC2E
   HMLAN1_MSGCNT 32
   HMLAN1_RAWMSG E21DC2E,0000,0040329D,FF,FFB6,8E861021DC2E0000000AACDA0F2914
   HMLAN1_RSSI -74
   HMLAN1_TIME 2014-02-03 20:38:09
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     32
   NAME       HK2
   NR         110
   STATE      MISSING ACK
   TYPE       CUL_HM
   channel_01 HK2_Weather
   channel_02 HK2_Climate
   channel_03 HK2_WindowRec
   channel_04 HK2_ClimRT_tr
   channel_05 HK2_ClimaTeam
   channel_06 HK2_remote
   lastMsg    No:8E - t:10 s:21DC2E d:000000 0AACDA0F2914
   protCmdDel 2
   protLastRcv 2014-02-03 20:38:09
   protResnd  3 last_at:2014-02-03 20:35:09
   protResndFail 1 last_at:2014-02-03 20:38:11
   protSnd    4 last_at:2014-02-03 20:38:09
   protState  CMDs_done_Errors:1
   rssi_at_HMLAN1 avg:-72.84 min:-80 max:-70 lst:-74 cnt:32
   Readings:
     2014-02-03 19:22:44   Activity        alive
     2014-02-03 19:29:50   CommandAccepted yes
     2014-02-03 18:55:28   PairedTo        0x121212
     2014-01-06 18:27:51   R-backOnTime    10 s
     2014-02-03 18:55:28   R-btnLock       unlock
     2014-02-03 18:55:28   R-burstRx       on
     2014-02-03 18:55:28   R-cyclicInfoMsg on
     2014-02-03 18:55:28   R-cyclicInfoMsgDis 0
     2014-02-03 18:55:28   R-globalBtnLock off
     2014-02-03 18:55:28   R-localResDis   off
     2014-01-06 18:27:51   R-lowBatLimitRT 2.1 V
     2014-02-03 18:55:28   R-modusBtnLock  off
     2014-02-03 18:55:28   R-pairCentral   0x121212
     2014-02-03 18:55:28   RegL_00:        01:01 02:01 09:01 0A:12 0B:12 0C:12 0E:0A 0F:00  11:00 12:15 16:00 18:00 19:00 1A:00 00:00
     2014-02-03 18:58:22   RegL_07:        0
     2014-02-03 20:38:09   actuator        41 %
     2014-02-03 20:38:09   battery         ok
     2014-02-03 20:38:09   batteryLevel    3 V
     2014-02-03 20:38:09   desired-temp    21.5
     2014-02-03 20:38:09   measured-temp   21.8
     2014-01-06 18:25:14   noReceiver      src:21DC2E A001 0106
     2014-01-06 18:22:46   powerOn         -
     2014-01-06 18:22:46   recentStateType info
     2014-02-03 20:38:11   state           MISSING ACK
     2014-02-03 06:23:09   time-request    -
   Helper:
     cSnd       0112121221DC2E01040000000001
     mId        0095
     rxType     140
     Io:
       nextSend   1391456289.35788
     Prt:
       awake      0
       bErr       0
       sProc      0
       wakeup     1
       Rspwait:
     Q:
       qReqConf   
       qReqStat   
     Role:
       dev        1
     Rssi:
       At_hmlan1:
         avg        -72.84375
         cnt        32
         lst        -74
         max        -70
         min        -80
     Shregw:
       07         04
Attributes:
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_full
   firmware   1.0
   model      HM-CC-RT-DN
   peerIDs   
   room       DG_Bad
   serialNr   KEQ0573297
   subType    thermostat
   webCmd     getConfig:burstXmit

Und das steht im Log vom HMLAN

2014.02.03 20:57:09.876 5: HMLAN_Parse: HMLAN1 R:E221F0F   stat:0000 t:00519AC9 d:FF r:FFC7     m:F6 8610 221F0F 000000 0A88D80F0018
2014.02.03 20:57:09.876 5: HMLAN1 dispatch A0FF68610221F0F0000000A88D80F0018::-57:HMLAN1
2014.02.03 20:57:09.929 5: HMLAN_Parse: HMLAN1 R:RF95368EC stat:0001 t:00519B03 d:FF r:FFB6     m:37 8002 21DC2E 121212 00
2014.02.03 20:57:09.929 5: HMLAN1 dispatch A0A37800221DC2E12121200::-74:HMLAN1
2014.02.03 20:57:10.158 5: HMLAN_Send:  HMLAN1 S:+21DC2E,00,01,
2014.02.03 20:57:10.158 5: HMLAN_Send:  HMLAN1 S:SF9536AED stat:  00 t:00000000 d:01 r:F9536AED m:38 A001 121212 21DC2E 04040000000001
2014.02.03 20:57:10.331 5: HMLAN_Parse: HMLAN1 R:RF9536AED stat:0001 t:00519C95 d:FF r:FFB6     m:38 8010 21DC2E 121212 0208000000
2014.02.03 20:57:10.331 5: HMLAN1 dispatch A0E38801021DC2E1212120208000000::-74:HMLAN1
2014.02.03 20:57:10.566 5: HMLAN_Send:  HMLAN1 S:+21DC2E,00,01,
2014.02.03 20:57:10.566 5: HMLAN_Send:  HMLAN1 S:SF9536C7F stat:  00 t:00000000 d:01 r:F9536C7F m:39 A001 121212 21DC2E 00040000000007
2014.02.03 20:57:10.744 5: HMLAN_Parse: HMLAN1 R:E21DC2E   stat:0000 t:00519E2D d:FF r:FFB6     m:39 A010 21DC2E 121212 03012A22093D18030016073000640F0500
2014.02.03 20:57:10.745 5: HMLAN1 dispatch A1A39A01021DC2E12121203012A22093D18030016073000640F0500::-74:HMLAN1
2014.02.03 20:57:10.856 5: HMLAN_Parse: HMLAN1 R:RF9536C7F stat:0001 t:00519E32 d:FF r:FFB6     m:39 A010 21DC2E 121212 03012A22093D18030016073000640F0500
2014.02.03 20:57:10.856 5: HMLAN1 dispatch A1A39A01021DC2E12121203012A22093D18030016073000640F0500::-74:HMLAN1
2014.02.03 20:57:11.001 5: HMLAN_Parse: HMLAN1 R:E21DC2E   stat:0000 t:00519F2E d:FF r:FFB6     m:3A A010 21DC2E 121212 03100000098E4C6058904CFC5520452045
2014.02.03 20:57:11.002 5: HMLAN1 dispatch A1A3AA01021DC2E12121203100000098E4C6058904CFC5520452045::-74:HMLAN1
2014.02.03 20:57:11.258 5: HMLAN_Parse: HMLAN1 R:E21DC2E   stat:0000 t:0051A02F d:FF r:FFB6     m:3B A010 21DC2E 121212 031F204520452045204520452045204520
2014.02.03 20:57:11.259 5: HMLAN1 dispatch A1A3BA01021DC2E121212031F204520452045204520452045204520::-74:HMLAN1
2014.02.03 20:57:11.515 5: HMLAN_Parse: HMLAN1 R:E21DC2E   stat:0000 t:0051A130 d:FF r:FFB6     m:3C A010 21DC2E 121212 032E4C6058904CFC552045204520452045
2014.02.03 20:57:11.515 5: HMLAN1 dispatch A1A3CA01021DC2E121212032E4C6058904CFC552045204520452045::-74:HMLAN1
2014.02.03 20:57:11.773 5: HMLAN_Parse: HMLAN1 R:E21DC2E   stat:0000 t:0051A232 d:FF r:FFB6     m:3D A010 21DC2E 121212 033D20452045204520452045204848586C
2014.02.03 20:57:11.773 5: HMLAN1 dispatch A1A3DA01021DC2E121212033D20452045204520452045204848586C::-74:HMLAN1
2014.02.03 20:57:12.030 5: HMLAN_Parse: HMLAN1 R:E21DC2E   stat:0000 t:0051A333 d:FF r:FFB6     m:3E A010 21DC2E 121212 034C50F657144520452045204520452045
2014.02.03 20:57:12.030 5: HMLAN1 dispatch A1A3EA01021DC2E121212034C50F657144520452045204520452045::-74:HMLAN1
2014.02.03 20:57:12.287 5: HMLAN_Parse: HMLAN1 R:E21DC2E   stat:0000 t:0051A434 d:FF r:FFB6     m:3F A010 21DC2E 121212 035B204520452045204848586C50F65714
2014.02.03 20:57:12.287 5: HMLAN1 dispatch A1A3FA01021DC2E121212035B204520452045204848586C50F65714::-74:HMLAN1
2014.02.03 20:57:12.544 5: HMLAN_Parse: HMLAN1 R:E21DC2E   stat:0000 t:0051A535 d:FF r:FFB6     m:40 A010 21DC2E 121212 036A452045204520452045204520452045
2014.02.03 20:57:12.544 5: HMLAN1 dispatch A1A40A01021DC2E121212036A452045204520452045204520452045::-74:HMLAN1
2014.02.03 20:57:12.801 5: HMLAN_Parse: HMLAN1 R:E21DC2E   stat:0000 t:0051A636 d:FF r:FFB5     m:41 A010 21DC2E 121212 03792045204848586C50F6571445204520
2014.02.03 20:57:12.801 5: HMLAN1 dispatch A1A41A01021DC2E12121203792045204848586C50F6571445204520::-75:HMLAN1
2014.02.03 20:57:13.058 5: HMLAN_Parse: HMLAN1 R:E21DC2E   stat:0000 t:0051A737 d:FF r:FFB5     m:41 A010 21DC2E 121212 03792045204848586C50F6571445204520
2014.02.03 20:57:13.058 5: HMLAN1 dispatch A1A41A01021DC2E12121203792045204848586C50F6571445204520::-75:HMLAN1
2014.02.03 20:57:13.315 5: HMLAN_Parse: HMLAN1 R:E21DC2E   stat:0000 t:0051A838 d:FF r:FFB6     m:42 A010 21DC2E 121212 0388452045204520452045204520452048
2014.02.03 20:57:13.315 5: HMLAN1 dispatch A1A42A01021DC2E1212120388452045204520452045204520452048::-74:HMLAN1
2014.02.03 20:57:13.572 5: HMLAN_Parse: HMLAN1 R:E21DC2E   stat:0000 t:0051A939 d:FF r:FFB5     m:43 A010 21DC2E 121212 039748586C50F657144520452045204520
2014.02.03 20:57:13.572 5: HMLAN1 dispatch A1A43A01021DC2E121212039748586C50F657144520452045204520::-75:HMLAN1
2014.02.03 20:57:13.829 5: HMLAN_Parse: HMLAN1 R:E21DC2E   stat:0000 t:0051AA3A d:FF r:FFB5     m:44 A010 21DC2E 121212 03A6452045204520452045204848586C50
2014.02.03 20:57:13.829 5: HMLAN1 dispatch A1A44A01021DC2E12121203A6452045204520452045204848586C50::-75:HMLAN1
2014.02.03 20:57:14.086 5: HMLAN_Parse: HMLAN1 R:E21DC2E   stat:0000 t:0051AB3B d:FF r:FFB5     m:45 A010 21DC2E 121212 03B5F65714452045204520452045204520
2014.02.03 20:57:14.086 5: HMLAN1 dispatch A1A45A01021DC2E12121203B5F65714452045204520452045204520::-75:HMLAN1
2014.02.03 20:57:14.341 5: HMLAN_Parse: HMLAN1 R:E21DC2E   stat:0000 t:0051AC3A d:FF r:FFB6     m:46 A010 21DC2E 121212 03C44520452045200F1E1E0F1E1E
2014.02.03 20:57:14.341 5: HMLAN1 dispatch A1746A01021DC2E12121203C44520452045200F1E1E0F1E1E::-74:HMLAN1
2014.02.03 20:57:14.586 5: HMLAN_Parse: HMLAN1 R:E21DC2E   stat:0000 t:0051AD30 d:FF r:FFB6     m:47 8010 21DC2E 121212 0300
2014.02.03 20:57:14.586 5: HMLAN1 dispatch A0B47801021DC2E1212120300::-74:HMLAN1
2014.02.03 20:57:18.055 5: HMLAN_Send:  HMLAN1 I:K
2014.02.03 20:57:18.058 5: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0852586 d:23A75A O:121212 t:0051BAC6 IDcnt:000A
2014.02.03 20:57:18.243 5: HMLAN_Parse: HMLAN1 R:E221F49   stat:0000 t:0051BB77 d:FF r:FFC9     m:42 8610 221F49 000000 0A80A40F0023
2014.02.03 20:57:18.243 5: HMLAN1 dispatch A0F428610221F490000000A80A40F0023::-55:HMLAN1
2014.02.03 20:57:18.244 2: CUL_HM set HK6_ClimaTeam getConfig
2014.02.03 20:57:18.461 5: HMLAN_Send:  HMLAN1 S:SF9538B68 stat:  00 t:00000000 d:01 r:F9538B68 m:3A A112 121212 221F49
2014.02.03 20:57:19.064 5: HMLAN_Parse: HMLAN1 R:RF9538B68 stat:0008 t:00000000 d:FF r:7FFF     m:3A A112 121212 221F49
2014.02.03 20:57:19.065 5: HMLAN_Parse: HMLAN1 no ACK from 221F49
2014.02.03 20:57:25.492 5: HMLAN_Parse: HMLAN1 R:E234FB1   stat:0000 t:0051D7CB d:FF r:FFC0     m:92 8610 234FB1 000000 0A789810011B
2014.02.03 20:57:25.492 5: HMLAN1 dispatch A0F928610234FB10000000A789810011B::-64:HMLAN1
2014.02.03 20:57:25.493 2: CUL_HM set HK9_ClimaTeam getConfig
2014.02.03 20:57:25.724 5: HMLAN_Send:  HMLAN1 S:SF953A7B8 stat:  00 t:00000000 d:01 r:F953A7B8 m:3B A112 121212 234FB1
2014.02.03 20:57:26.326 5: HMLAN_Parse: HMLAN1 R:RF953A7B8 stat:0008 t:00000000 d:FF r:7FFF     m:3B A112 121212 234FB1
2014.02.03 20:57:26.327 5: HMLAN_Parse: HMLAN1 no ACK from 234FB1
2014.02.03 20:57:43.193 5: HMLAN_Send:  HMLAN1 I:K
2014.02.03 20:57:43.196 5: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0852586 d:23A75A O:121212 t:00521CFC IDcnt:000A
2014.02.03 20:58:04.917 5: HMLAN_Parse: HMLAN1 R:E2324A7   stat:0000 t:005271D0 d:FF r:FFCE     m:00 A410 2324A7 121212 06000030
2014.02.03 20:58:04.918 5: HMLAN1 dispatch A0D00A4102324A712121206000030::-50:HMLAN1
2014.02.03 20:58:04.919 5: HMLAN_Send:  HMLAN1 I:+2324A7,00,00,
2014.02.03 20:58:05.106 5: HMLAN_Send:  HMLAN1 S:SF95441BA stat:  00 t:00000000 d:01 r:F95441BA m:00 8002 121212 2324A7 00
2014.02.03 20:58:05.128 5: HMLAN_Parse: HMLAN1 R:RF95441BA stat:0002 t:00000000 d:FF r:7FFF     m:00 8002 121212 2324A7 00
2014.02.03 20:58:05.187 5: HMLAN_Parse: HMLAN1 R:E2324A7   stat:0000 t:005272E0 d:FF r:FFCE     m:01 A410 2324A7 121212 06000030
2014.02.03 20:58:05.187 5: HMLAN1 dispatch A0D01A4102324A712121206000030::-50:HMLAN1
2014.02.03 20:58:07.330 5: HMLAN_Parse: HMLAN1 R:E2324A7   stat:0000 t:00527B40 d:FF r:FFCD     m:02 A03F 2324A7 121212
2014.02.03 20:58:07.330 5: HMLAN1 dispatch A0902A03F2324A7121212::-51:HMLAN1
2014.02.03 20:58:07.573 5: HMLAN_Send:  HMLAN1 S:+2324A7,00,01,
2014.02.03 20:58:07.573 5: HMLAN_Send:  HMLAN1 S:SF9544B26 stat:  00 t:00000000 d:01 r:F9544B26 m:3C 803F 121212 2324A7 02041A82A33F
2014.02.03 20:58:07.575 5: HMLAN_Parse: HMLAN1 R:E2324A7   stat:0000 t:00527B40 d:FF r:FFCD     m:02 A03F 2324A7 121212
2014.02.03 20:58:07.575 5: HMLAN1 dispatch A0902A03F2324A7121212::-51:HMLAN1
2014.02.03 20:58:07.575 5: HMLAN_Send:  HMLAN1 S:SF9544C1A stat:  00 t:00000000 d:01 r:F9544C1A m:3D 803F 121212 2324A7 02041A82A33F
2014.02.03 20:58:07.967 5: HMLAN_Parse: HMLAN1 R:RF9544B26 stat:0002 t:00000000 d:FF r:7FFF     m:3C 803F 121212 2324A7 02041A82A33F
2014.02.03 20:58:07.991 5: HMLAN_Parse: HMLAN1 R:RF9544C1A stat:0002 t:00000000 d:FF r:7FFF     m:3D 803F 121212 2324A7 02041A82A33F
2014.02.03 20:58:08.325 5: HMLAN_Send:  HMLAN1 I:K
2014.02.03 20:58:08.328 5: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0852586 d:23A75A O:121212 t:00527F2C IDcnt:000B
2014.02.03 20:58:11.015 5: HMLAN_Parse: HMLAN1 R:E21DC2E   stat:0000 t:005289A6 d:FF r:FFB8     m:96 8610 21DC2E 000000 0A98E70E0014
2014.02.03 20:58:11.015 5: HMLAN1 dispatch A0F96861021DC2E0000000A98E70E0014::-72:HMLAN1
2014.02.03 20:58:11.017 2: CUL_HM set HK2_ClimaTeam getConfig
2014.02.03 20:58:11.246 5: HMLAN_Send:  HMLAN1 S:SF954598C stat:  00 t:00000000 d:01 r:F954598C m:3E A112 121212 21DC2E
2014.02.03 20:58:11.848 5: HMLAN_Parse: HMLAN1 R:RF954598C stat:0008 t:00000000 d:FF r:7FFF     m:3E A112 121212 21DC2E
2014.02.03 20:58:11.849 5: HMLAN_Parse: HMLAN1 no ACK from 21DC2E
2014.02.03 20:58:33.468 5: HMLAN_Send:  HMLAN1 I:K
2014.02.03 20:58:33.471 5: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0852586 d:23A75A O:121212 t:0052E167 IDcnt:000B
2014.02.03 20:58:58.601 5: HMLAN_Send:  HMLAN1 I:K
2014.02.03 20:58:58.604 5: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0852586 d:23A75A O:121212 t:00534398 IDcnt:000B
2014.02.03 20:59:11.297 5: HMLAN_Parse: HMLAN1 R:E206AE6   stat:0000 t:00537527 d:FF r:FFAD     m:3F 8670 206AE6 000000 00D12C
2014.02.03 20:59:11.298 5: HMLAN1 dispatch A0C3F8670206AE600000000D12C::-83:HMLAN1
2014.02.03 20:59:21.471 5: HMLAN_Parse: HMLAN1 R:E235C66   stat:0000 t:00539CE8 d:FF r:FFBC     m:91 8610 235C66 000000 0A84A9100318
2014.02.03 20:59:21.471 5: HMLAN1 dispatch A0F918610235C660000000A84A9100318::-68:HMLAN1
2014.02.03 20:59:21.472 2: CUL_HM set HK7_remote getConfig
2014.02.03 20:59:21.699 5: HMLAN_Send:  HMLAN1 S:SF9556CC4 stat:  00 t:00000000 d:01 r:F9556CC4 m:3F A112 121212 235C66
2014.02.03 20:59:22.302 5: HMLAN_Parse: HMLAN1 R:RF9556CC4 stat:0008 t:00000000 d:FF r:7FFF     m:3F A112 121212 235C66
2014.02.03 20:59:22.303 5: HMLAN_Parse: HMLAN1 no ACK from 235C66
2014.02.03 20:59:23.739 5: HMLAN_Send:  HMLAN1 I:K
2014.02.03 20:59:23.742 5: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0852586 d:23A75A O:121212 t:0053A5CD IDcnt:000B
2014.02.03 20:59:28.415 5: HMLAN_Parse: HMLAN1 R:E234FA4   stat:0000 t:0053B809 d:FF r:FFB8     m:A8 8610 234FA4 000000 0A80A40F0018
2014.02.03 20:59:28.415 5: HMLAN1 dispatch A0FA88610234FA40000000A80A40F0018::-72:HMLAN1
2014.02.03 20:59:28.416 2: CUL_HM set HK8_ClimaTeam getConfig
2014.02.03 20:59:28.649 5: HMLAN_Send:  HMLAN1 S:SF95587E3 stat:  00 t:00000000 d:01 r:F95587E3 m:40 A112 121212 234FA4
2014.02.03 20:59:29.251 5: HMLAN_Parse: HMLAN1 R:RF95587E3 stat:0008 t:00000000 d:FF r:7FFF     m:40 A112 121212 234FA4
2014.02.03 20:59:29.252 5: HMLAN_Parse: HMLAN1 no ACK from 234FA4
2014.02.03 20:59:32.382 5: HMLAN_Parse: HMLAN1 R:E221F0F   stat:0000 t:0053C789 d:FF r:FFC6     m:F7 8610 221F0F 000000 0A88D70F0018
2014.02.03 20:59:32.382 5: HMLAN1 dispatch A0FF78610221F0F0000000A88D70F0018::-58:HMLAN1
2014.02.03 20:59:39.811 5: HMLAN_Parse: HMLAN1 R:E223380   stat:0000 t:0053E48C d:FF r:FFBD     m:67 8610 223380 000000 0A80A50F001F
2014.02.03 20:59:39.812 5: HMLAN1 dispatch A0F6786102233800000000A80A50F001F::-67:HMLAN1
2014.02.03 20:59:48.879 5: HMLAN_Send:  HMLAN1 I:K
2014.02.03 20:59:48.882 5: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0852586 d:23A75A O:121212 t:00540805 IDcnt:000B
2014.02.03 20:59:59.747 5: HMLAN_Parse: HMLAN1 R:E221F50   stat:0000 t:00543272 d:FF r:FFCC     m:31 8610 221F50 000000 0A88D70F0018
2014.02.03 20:59:59.748 5: HMLAN1 dispatch A0F318610221F500000000A88D70F0018::-52:HMLAN1
2014.02.03 21:00:02.244 5: HMLAN_Parse: HMLAN1 R:E221F49   stat:0000 t:00543C31 d:FF r:FFCB     m:43 8610 221F49 000000 0A80A40F0023
2014.02.03 21:00:02.244 5: HMLAN1 dispatch A0F438610221F490000000A80A40F0023::-53:HMLAN1
2014.02.03 21:00:02.246 2: CUL_HM set HK6_remote getConfig
2014.02.03 21:00:02.467 5: HMLAN_Send:  HMLAN1 S:SF9560C09 stat:  00 t:00000000 d:01 r:F9560C09 m:41 A112 121212 221F49
2014.02.03 21:00:03.070 5: HMLAN_Parse: HMLAN1 R:RF9560C09 stat:0008 t:00000000 d:FF r:7FFF     m:41 A112 121212 221F49
2014.02.03 21:00:03.071 5: HMLAN_Parse: HMLAN1 no ACK from 221F49
2014.02.03 21:00:14.017 5: HMLAN_Send:  HMLAN1 I:K
2014.02.03 21:00:14.020 5: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0852586 d:23A75A O:121212 t:00546A3B IDcnt:000B
2014.02.03 21:00:24.048 5: HMLAN_Parse: HMLAN1 R:E2324A7   stat:0000 t:00549162 d:FF r:FFCF     m:02 8610 2324A7 000000 0A90DB0E0018030E18030E22
2014.02.03 21:00:24.048 5: HMLAN1 dispatch A150286102324A70000000A90DB0E0018030E18030E22::-49:HMLAN1
2014.02.03 21:00:24.051 2: CUL_HM set HK1 getConfig
2014.02.03 21:00:24.274 5: HMLAN_Send:  HMLAN1 S:SF9566136 stat:  00 t:00000000 d:01 r:F9566136 m:42 A112 121212 2324A7
2014.02.03 21:00:24.877 5: HMLAN_Parse: HMLAN1 R:RF9566136 stat:0008 t:00000000 d:FF r:7FFF     m:42 A112 121212 2324A7
2014.02.03 21:00:24.878 5: HMLAN_Parse: HMLAN1 no ACK from 2324A7
2014.02.03 21:00:26.742 5: HMLAN_Parse: HMLAN1 R:E234FB1   stat:0000 t:00549BEA d:FF r:FFC3     m:93 8610 234FB1 000000 0A789810011B
2014.02.03 21:00:26.743 5: HMLAN1 dispatch A0F938610234FB10000000A789810011B::-61:HMLAN1
2014.02.03 21:00:26.744 2: CUL_HM set HK9_remote getConfig
2014.02.03 21:00:26.982 5: HMLAN_Send:  HMLAN1 S:SF9566BBB stat:  00 t:00000000 d:01 r:F9566BBB m:43 A112 121212 234FB1
2014.02.03 21:00:27.586 5: HMLAN_Parse: HMLAN1 R:RF9566BBB stat:0008 t:00000000 d:FF r:7FFF     m:43 A112 121212 234FB1
2014.02.03 21:00:27.586 5: HMLAN_Parse: HMLAN1 no ACK from 234FB1
2014.02.03 21:00:39.151 5: HMLAN_Send:  HMLAN1 I:K
2014.02.03 21:00:39.154 5: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0852586 d:23A75A O:121212 t:0054CC6E IDcnt:000B
2014.02.03 21:01:04.294 5: HMLAN_Send:  HMLAN1 I:K
2014.02.03 21:01:04.297 5: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0852586 d:23A75A O:121212 t:00552EA8 IDcnt:000B
2014.02.03 21:01:12.266 5: HMLAN_Parse: HMLAN1 R:E21DC2E   stat:0000 t:00554DC4 d:FF r:FFB6     m:97 8610 21DC2E 000000 0A98E70E0014
2014.02.03 21:01:12.266 5: HMLAN1 dispatch A0F97861021DC2E0000000A98E70E0014::-74:HMLAN1
2014.02.03 21:01:12.267 2: CUL_HM set HK2_remote getConfig
2014.02.03 21:01:12.489 5: HMLAN_Send:  HMLAN1 S:SF9571D8E stat:  00 t:00000000 d:01 r:F9571D8E m:44 A112 121212 21DC2E
2014.02.03 21:01:13.091 5: HMLAN_Parse: HMLAN1 R:RF9571D8E stat:0008 t:00000000 d:FF r:7FFF     m:44 A112 121212 21DC2E
2014.02.03 21:01:13.092 5: HMLAN_Parse: HMLAN1 no ACK from 21DC2E
2014.02.03 21:01:29.416 5: HMLAN_Parse: HMLAN1 R:E234FA4   stat:0000 t:005590C5 d:FF r:FFBB     m:A9 8610 234FA4 000000 0A80A40F0018
2014.02.03 21:01:29.417 5: HMLAN1 dispatch A0FA98610234FA40000000A80A40F0018::-69:HMLAN1
2014.02.03 21:01:29.418 2: CUL_HM set HK8_remote getConfig
2014.02.03 21:01:29.627 5: HMLAN_Send:  HMLAN1 S:SF957608D stat:  00 t:00000000 d:01 r:F957608D m:45 A112 121212 234FA4
2014.02.03 21:01:29.629 5: HMLAN_Send:  HMLAN1 I:K
2014.02.03 21:01:29.649 5: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0852586 d:23A75A O:121212 t:005591B4 IDcnt:000B
2014.02.03 21:01:30.230 5: HMLAN_Parse: HMLAN1 R:RF957608D stat:0008 t:00000000 d:FF r:7FFF     m:45 A112 121212 234FA4
2014.02.03 21:01:30.230 5: HMLAN_Parse: HMLAN1 no ACK from 234FA4
2014.02.03 21:01:36.552 5: HMLAN_Parse: HMLAN1 R:E206AE6   stat:0000 t:0055ACA4 d:FF r:FFAF     m:40 8670 206AE6 000000 00D12C
2014.02.03 21:01:36.553 5: HMLAN1 dispatch A0C408670206AE600000000D12C::-81:HMLAN1
2014.02.03 21:01:40.626 5: HMLAN_Parse: HMLAN1 R:E221F0F   stat:0000 t:0055BC90 d:FF r:FFC7     m:F8 8610 221F0F 000000 0A88D70F0018
2014.02.03 21:01:40.626 5: HMLAN1 dispatch A0FF88610221F0F0000000A88D70F0018::-57:HMLAN1
2014.02.03 21:01:54.774 5: HMLAN_Send:  HMLAN1 I:K
2014.02.03 21:01:54.777 5: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0852586 d:23A75A O:121212 t:0055F3DF IDcnt:000B
2014.02.03 21:02:08.972 5: HMLAN_Parse: HMLAN1 R:E235C66   stat:0000 t:00562B4E d:FF r:FFBA     m:92 8610 235C66 000000 0A84A8100418
2014.02.03 21:02:08.972 5: HMLAN1 dispatch A0F928610235C660000000A84A8100418::-70:HMLAN1
2014.02.03 21:02:09.176 5: HMLAN_Send:  HMLAN1 S:SF957FB10 stat:  00 t:00000000 d:01 r:F957FB10 m:46 A112 121212 235C66
2014.02.03 21:02:09.779 5: HMLAN_Parse: HMLAN1 R:RF957FB10 stat:0008 t:00000000 d:FF r:7FFF     m:46 A112 121212 235C66
2014.02.03 21:02:09.780 5: HMLAN_Parse: HMLAN1 no ACK from 235C66
2014.02.03 21:02:19.912 5: HMLAN_Send:  HMLAN1 I:K
2014.02.03 21:02:19.915 5: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0852586 d:23A75A O:121212 t:00565615 IDcnt:000B
2014.02.03 21:02:25.561 5: HMLAN_Parse: HMLAN1 R:E223380   stat:0000 t:00566C1C d:FF r:FFBC     m:68 8610 223380 000000 0A80A50F001F
2014.02.03 21:02:25.561 5: HMLAN1 dispatch A0F6886102233800000000A80A50F001F::-68:HMLAN1
2014.02.03 21:02:26.292 5: HMLAN_Parse: HMLAN1 R:E2324A7   stat:0000 t:00566EFA d:FF r:FFD5     m:03 8610 2324A7 000000 0A90DC0F0018
2014.02.03 21:02:26.293 5: HMLAN1 dispatch A0F0386102324A70000000A90DC0F0018::-43:HMLAN1
2014.02.03 21:02:26.530 5: HMLAN_Send:  HMLAN1 S:SF9583EB8 stat:  00 t:00000000 d:01 r:F9583EB8 m:47 A112 121212 2324A7
2014.02.03 21:02:27.133 5: HMLAN_Parse: HMLAN1 R:RF9583EB8 stat:0008 t:00000000 d:FF r:7FFF     m:47 A112 121212 2324A7
2014.02.03 21:02:27.133 5: HMLAN_Parse: HMLAN1 no ACK from 2324A7
2014.02.03 21:02:31.746 5: HMLAN_Parse: HMLAN1 R:E221F49   stat:0000 t:00568446 d:FF r:FFC8     m:44 8610 221F49 000000 0A80A40F0023
2014.02.03 21:02:31.746 5: HMLAN1 dispatch A0F448610221F490000000A80A40F0023::-56:HMLAN1
2014.02.03 21:02:31.973 5: HMLAN_Send:  HMLAN1 S:SF9585406 stat:  00 t:00000000 d:01 r:F9585406 m:48 A112 121212 221F49
2014.02.03 21:02:32.577 5: HMLAN_Parse: HMLAN1 R:RF9585406 stat:0008 t:00000000 d:FF r:7FFF     m:48 A112 121212 221F49
2014.02.03 21:02:32.577 5: HMLAN_Parse: HMLAN1 no ACK from 221F49
2014.02.03 21:02:42.250 5: HMLAN_Parse: HMLAN1 R:E221F50   stat:0000 t:0056AD52 d:FF r:FFCA     m:32 8610 221F50 000000 0A88D60F0018
2014.02.03 21:02:42.250 5: HMLAN1 dispatch A0F328610221F500000000A88D60F0018::-54:HMLAN1
2014.02.03 21:02:45.059 5: HMLAN_Send:  HMLAN1 I:K
2014.02.03 21:02:45.062 5: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0852586 d:23A75A O:121212 t:0056B854 IDcnt:000B
2014.02.03 21:03:10.202 5: HMLAN_Send:  HMLAN1 I:K
2014.02.03 21:03:10.206 5: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0852586 d:23A75A O:121212 t:00571A8F IDcnt:000B
2014.02.03 21:03:13.495 5: HMLAN_Parse: HMLAN1 R:E234FB1   stat:0000 t:00572764 d:FF r:FFC2     m:94 8610 234FB1 000000 0A789810011B
2014.02.03 21:03:13.496 5: HMLAN1 dispatch A0F948610234FB10000000A789810011B::-62:HMLAN1
2014.02.03 21:03:13.735 5: HMLAN_Send:  HMLAN1 S:SF958F71B stat:  00 t:00000000 d:01 r:F958F71B m:49 A112 121212 234FB1
2014.02.03 21:03:14.339 5: HMLAN_Parse: HMLAN1 R:RF958F71B stat:0008 t:00000000 d:FF r:7FFF     m:49 A112 121212 234FB1
2014.02.03 21:03:14.339 5: HMLAN_Parse: HMLAN1 no ACK from 234FB1
2014.02.03 21:03:35.310 5: HMLAN_Send:  HMLAN1 I:K
2014.02.03 21:03:35.313 5: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0852586 d:23A75A O:121212 t:00577CA7 IDcnt:000B
2014.02.03 21:03:47.307 5: HMLAN_Parse: HMLAN1 R:E206AE6   stat:0000 t:0057AB7A d:FF r:FFAD     m:41 8670 206AE6 000000 00D22C
2014.02.03 21:03:47.307 5: HMLAN1 dispatch A0C418670206AE600000000D22C::-83:HMLAN1
2014.02.03 21:03:59.266 5: HMLAN_Parse: HMLAN1 R:E21DC2E   stat:0000 t:0057DA35 d:FF r:FFB6     m:98 8610 21DC2E 000000 0A98E80E0014
2014.02.03 21:03:59.266 5: HMLAN1 dispatch A0F98861021DC2E0000000A98E80E0014::-74:HMLAN1
2014.02.03 21:03:59.464 5: HMLAN_Send:  HMLAN1 S:SF959A9E6 stat:  00 t:00000000 d:01 r:F959A9E6 m:4A A112 121212 21DC2E
2014.02.03 21:04:00.067 5: HMLAN_Parse: HMLAN1 R:RF959A9E6 stat:0008 t:00000000 d:FF r:7FFF     m:4A A112 121212 21DC2E
2014.02.03 21:04:00.067 5: HMLAN_Parse: HMLAN1 no ACK from 21DC2E
2014.02.03 21:04:00.458 5: HMLAN_Send:  HMLAN1 I:K
2014.02.03 21:04:00.461 5: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0852586 d:23A75A O:121212 t:0057DEE7 IDcnt:000B
2014.02.03 21:04:19.919 5: HMLAN_Parse: HMLAN1 R:E234FA4   stat:0000 t:00582AE5 d:FF r:FFBA     m:AA 8610 234FA4 000000 0A80A30F0918
2014.02.03 21:04:19.919 5: HMLAN1 dispatch A0FAA8610234FA40000000A80A30F0918::-70:HMLAN1
2014.02.03 21:04:20.151 5: HMLAN_Send:  HMLAN1 S:SF959FA93 stat:  00 t:00000000 d:01 r:F959FA93 m:4B A112 121212 234FA4
2014.02.03 21:04:20.754 5: HMLAN_Parse: HMLAN1 R:RF959FA93 stat:0008 t:00000000 d:FF r:7FFF     m:4B A112 121212 234FA4
2014.02.03 21:04:20.755 5: HMLAN_Parse: HMLAN1 no ACK from 234FA4
2014.02.03 21:04:25.597 5: HMLAN_Send:  HMLAN1 I:K
2014.02.03 21:04:25.600 5: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0852586 d:23A75A O:121212 t:0058411D IDcnt:000B
2014.02.03 21:04:38.373 5: HMLAN_Parse: HMLAN1 R:E221F0F   stat:0000 t:005872FE d:FF r:FFC8     m:F9 8610 221F0F 000000 0A88D60F0018
2014.02.03 21:04:38.373 5: HMLAN1 dispatch A0FF98610221F0F0000000A88D60F0018::-56:HMLAN1
2014.02.03 21:04:41.972 5: HMLAN_Parse: HMLAN1 R:E235C66   stat:0000 t:0058810D d:FF r:FFBA     m:93 8610 235C66 000000 0A84A8100618
2014.02.03 21:04:41.972 5: HMLAN1 dispatch A0F938610235C660000000A84A8100618::-70:HMLAN1
2014.02.03 21:04:42.190 5: HMLAN_Send:  HMLAN1 S:SF95A50B8 stat:  00 t:00000000 d:01 r:F95A50B8 m:4C A112 121212 235C66
2014.02.03 21:04:42.793 5: HMLAN_Parse: HMLAN1 R:RF95A50B8 stat:0008 t:00000000 d:FF r:7FFF     m:4C A112 121212 235C66
2014.02.03 21:04:42.793 5: HMLAN_Parse: HMLAN1 no ACK from 235C66
2014.02.03 21:04:46.996 5: HMLAN_Parse: HMLAN1 R:E221F49   stat:0000 t:005894AC d:FF r:FFC8     m:45 8610 221F49 000000 0A80A40F0023
2014.02.03 21:04:46.996 5: HMLAN1 dispatch A0F458610221F490000000A80A40F0023::-56:HMLAN1
2014.02.03 21:04:47.239 5: HMLAN_Send:  HMLAN1 S:SF95A6458 stat:  00 t:00000000 d:01 r:F95A6458 m:4D A112 121212 221F49
2014.02.03 21:04:47.842 5: HMLAN_Parse: HMLAN1 R:RF95A6458 stat:0008 t:00000000 d:FF r:7FFF     m:4D A112 121212 221F49
2014.02.03 21:04:47.843 5: HMLAN_Parse: HMLAN1 no ACK from 221F49
2014.02.03 21:04:50.744 5: HMLAN_Send:  HMLAN1 I:K
2014.02.03 21:04:50.747 5: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0852586 d:23A75A O:121212 t:0058A35C IDcnt:000B
2014.02.03 21:04:56.811 5: HMLAN_Parse: HMLAN1 R:E223380   stat:0000 t:0058BB05 d:FF r:FFBC     m:69 8610 223380 000000 0A80A50F001F
2014.02.03 21:04:56.812 5: HMLAN1 dispatch A0F6986102233800000000A80A50F001F::-68:HMLAN1



Reicht das zum Debugging? Ich habe keine Ahnung, wie ich da noch mehr mitloggen soll ... :-[

Herr 3x

Hallo Martin, Hallo RosiDocker,

ich habe mal die Zeile

$dDly -= 0.1 + AttrVal($hash->{NAME},"ackDly",0.08) if ($mTy eq "02");

in die 00_CUL.pm eingebaut und getestet ...... aber auch bei

$dDly -= 0.1 + AttrVal($hash->{NAME},"ackDly",0.03) if ($mTy eq "02");

gibt es immer noch Probleme !

Wie genau interpretiert man das Ganze ?

@ Rosidocker wie sieht das bei Dir aus ?

Gruß
Klaus

Zitat von: kvo1 am 04 Februar 2014, 01:00:07
Hallo Martin, Hallo RosiDocker,

ich habe mal die Zeile

$dDly -= 0.1 + AttrVal($hash->{NAME},"ackDly",0.08) if ($mTy eq "02");

in die 00_CUL.pm eingebaut und getestet ...... aber auch bei

$dDly -= 0.1 + AttrVal($hash->{NAME},"ackDly",0.03) if ($mTy eq "02");

gibt es immer noch Probleme !

Wie genau interpretiert man das Ganze ?

@ Rosidocker wie sieht das bei Dir aus ?

Gruß
Klaus

Hallo Klaus,
ich hoffe du meintest mich :-) (RosiDocker -> DosiRocker)

Ich habe mich strikt nach Martins Anweisung aus Antwort 23 in diesem Thread gehalten und dann die Zeile
$dDly -= 0.08 if ($mTy eq "02");.
die 0.08 durch 0.04 ersetzt.
Dies läuft bei mir seit dem so.

oder du wartest bis die Änderungen in der 00_CUL.PM eingecheckt wurden, dies sollte nach Aussage von Martin demnächst passieren.

Gruß,
Martin

Hi,

Rudi hat es eingecheckt - heute => entweder heute aus SVN oder morgen im Update

danach verfolgen wir wieder, was übrig ist ;)

Gruss Martin

@DosiRocker
>>>ich hoffe du meintest mich :-) (RosiDocker -> DosiRocker)
ja sooooorrrry , der typische Buchstabendreher ?

@Martin
Danke , dann warte ich mal mit  weiteren Tests.!

klaus

Moin,

ich glaube, der RT hat ein grundsätzliches Problem mit Burst-Übertragungen. Ich habe gestern anhand einer kursierenden Anleitung einen RaspPi in eine CCU2 verwandelt und als Zentrale zusammen mit einem HM-CFG-USB (per hmland) verwendet.

Ergebnis: auch damit funktioniet das Pairing erst nach mehreren Versuchen, egal, ob der RT im selben Raum oder etwa 4m entfernt ist (RSSI jeweils <=70). Und auch im CCU2 hält sich besändig die Meldung "Gerkätekommunkation gesört" sowie "Konfigurationsdaten stehen zur Übertragung an". Eine Temperaturliste konnte ich mit der CCU2 nur übertragen, wenn ich am schon gepairten RT durch Aktivierung des Pairing-Modus die Übertragung angestoßen habe. Nach einigen Versuchen war die Liste dann endlich übertragen. Die Übertragung von der CCU2 an den RT wird dagegen immer mit einer Fehlermeldung ("Übertragung konnte nicht erfolgreich abgeschlossen werden") quittiert.

Die Logs des fhem zeigen keine Fehlermeldungen, solange man keinen Burst-Modus benutzt. Sobald aber " Burst=1" gesetzt ist, kommen die Messages nicht mehr durch bzw. werden vom RT (jedenfalls von meinem) nicht richtig verstanden.

Ich bekomme heute noch ein bißchen "Spielkram" (u.a. weitere RTs und einen 1-Kanal-Empfänger), wenn ich die habe, werde ich mal weiter testen.

Hat jemand eine Konfig, in der ein RT wirklich ohne Fehlermeldungen funktioniert? CCU1, CCU2, CUL oder was auch immer?

Sebi

Hi Sebi,

kannst du einmal mitloggen, wenn du den RT anlernst - incl roh-messages?

was meinst du mit Konfig, in der der RT funktioniert? Hast du ein Problem mit Anlernen oder mit Betrieb?
Im Übrigen - beachte die Änderung im 00_CUL von heute (morgen im update, heute in SVN)

Gruss Martin

Hallo Martin,

ja, ich werde - spätestens am Wochenende - mal ausführlich loggen und vor allem mal mit anderen Geräten testen.

Mit Konfig, die funktioniert, meine ich einen Aufbau, bei dem es nicht ständig Fehlermeldungen hagelt. Bisher habe ich getestet:

- HM-CFG-USB direkt am PC bzw. per hmland als HM-CFG-LAN mit der Homematic-Software unter Windows
-> Anlernen funktioniert prompt, Auslesen funktioniert auch, ebenso Übertragen der Sollwerte. Übertragen des Temperaturprofils klappt nur mühsahm, die Software zeigt immer eine Fehlermeldung an, in den Statusmeldungen sehe ich "Gerätekommunkation ist gestört" bzw. "Gerätekommunikation war gestört" sowie "Es stehen Konfigurationsdaten zur Übertragung an". Diese Meldungen bekomme ich nicht weg, egal, was ich anstelle.

- RaspPi als CCU2 konfiguriert mit HM-CFG-USB per hmland als Netzwerk-Device
-> wie oben. Es funktioniert "ein bißchen", aber ständig werden Fehlermeldungen ausgegeben. Temperaturprofil z.B. wird nur beim Aktivieren des Pairing-Mode einmalig übertragen, sonst nicht.

- fhem und HM-CFG-USB per hmland
-> Anlernen funktioniert nach 5-6 Versuchen, Werte vom RT werden übernommen, Temperaturlisten schreiben geht gar nicht, ständig CMDs pending

Dabei macht es keinen Unterschied, wie weit der RT vom Sender entfernt ist, die RSSI-Daten sprechen für mich dafür, dass die Funkstrecke in Ordnung ist. Auch der Umstand, dass ich ein Firmware-Update per OTA überspielen konnte, heißt für mich, dass die reine Übertragung nicht allzu fehleranfällig ist.

Bei fhem alleine könnte es sein, dass etwaige Protokoll-Spezialitäten nicht sauber umgesetzt sind. Aber genau das dürfte beim Einsatz "originaler" HM-Komponenten eben nicht auftreten. Also entweder ist eins (oder mehrere) meiner Geräte defekt, oder der RT hat ein grundsätzliches Problem. Und deshalb die Frage, ob irgendwer den RT völlig problemlos und ohne Fehlermeldungen mit welcher Hard- und Software einsetzt.

Ciao,
Sebi

hi sebi,

ah HW config...

Zitatdirekt am PC ... unter Windows

kann ich keine Aussage machen. Zum Kommunikation brauchst du präzises Timing - ob windows da geeignet ist habe ich nie getestet. Ich nutze in wesentlichen eine FB

ZitatRaspPi als CCU2 konfiguriert mit HM-CFG-USB

sollte von der Performance her reichen.

Bin auf die Logs gespannt - insbesondere da es HM-IOs sind, die liefern zusätzliches Timing.
Sende dann auch die Auswertung den HMUSB - also die Delays.
Evtl auch einmal apptime ansehen... falls es jemand anders (task oder prozess) ist
Gruss Martin

Zitat von: sebixvi am 04 Februar 2014, 17:58:13

Bei fhem alleine könnte es sein, dass etwaige Protokoll-Spezialitäten nicht sauber umgesetzt sind. Aber genau das dürfte beim Einsatz "originaler" HM-Komponenten eben nicht auftreten. Also entweder ist eins (oder mehrere) meiner Geräte defekt, oder der RT hat ein grundsätzliches Problem. Und deshalb die Frage, ob irgendwer den RT völlig problemlos und ohne Fehlermeldungen mit welcher Hard- und Software einsetzt.

Bis vor kurzem lief hier alles recht problemlos mit HMLAN und 7390. Anlernen von den RT war kein Problem.
Jetzt mit HMLAN und OS X bekomme ich keine Temperaturen mehr gesetzt. Bei keinem von 9 RT.
Beim HMLAN habe ich mal ein Softwareupdate gemacht, ohne erfolg.
Ich probiere am Wochenende nochmal den Weg zurück auf die FB. Wenn es dann geht liegt es am Server.

Herr 3x

Hallo Martin,
ich habe die 00_CUL.pm per fhem-Update eingespielt und grob getestet.
Bisher habe ich mit meinen 5 RT´s keine Probleme, werde das aber weiter
beobachten !

Danke & Gruß
Klaus

Hallo,

ich kämpfe auch mit dem Fehler des dauernden pending und processing.

Habe jetzt in der aktuellen 00_CUL.pm (Upfate von heute) folgenden Eintrag geändert:

# $dDly -= 0.04 if ($mTy eq "02");
(Befehl mit# deaktiviert)

Diese Zeile war in der Version der 00_CUL.pm vom 29.01.14 (meine Backup vom Update)
nicht vorhanden.

Jetzt habe ich zumindest kein dauerndes pending und processing mehr

Ob diese Änderung von Dauer ist muss ich erst abwarten.
Heute Abend kann ich dann sehen ob das Antennen Symbol an den HM-CC-RT-DN wieder den normalen Zustand erreicht.

...vielleicht etwas anachronistisch (da ja schon neue Version da), aber hier noch die Bestätigung , dass mit der Version von Post #29 und der Einstellung für ackDly = 0.05 meine Missing ACK-Probleme bei den Schaltaktoren/-dimmer HM-LC-Sw1PBU-FM und HM-LC-Dim1TPBU-FM offenbar beseitigt sind. Jedenfalls habe ich seit über 2 Tagen keine mehr (normalerweise waren spätestens nach 1 Tag welche da).

[CUL an Raspberry PI]

Hallo Leute,

die Zeile
# $dDly -= 0.04 if ($mTy eq "02");
ist ein Problem, war zu befürchten.
Kurzer Hintergrund: wir haben Fälle, da ein ACK softrt gesendet werden muss - und Fälle, in denen das ACK nicht vor 60ms nach der message gesendet werden muss.
Da ich keine Unterlagen habe, wann genau welche Verzögerung notwendig ist müssen wir die Daten sammeln. In einer alten Version hatten wir einen 100ms delay - nach ein paar Problemen und erfolgreichem test ist der auf 0 gesetzt worden, was dann bei anderen zu Problemen führte. Ausgemessen wurde, dass ein Delay von 60ms reichte....

Jetzt also eine Datenerhebung. Bitte posten, wer Probleme hatte.
- mit welcher Version ging es, mit welcher nicht?
- Welches Device?
- mit HMLAN/USB oder CUL (hier eigentlich nur CUL/CUNO,...)
- virtueller Peer oder Aktion mit FHEM/Zentrale
- ggf logs

Ich werden versuchen zu ergründen, wann welcher delay angesagt ist

Gruss Martin

Hallo,

hier ein paar Logs. Ich habe einen neuen Thermostat angelernt, das hat ca. 10 Versuche benötigt (5 bis zum "AC", dann nochmal etwa 5 bis set_ bei R_pairCentral verschwunden war und ich readings hatte).

Der ebenfalls inzwischen angelernte HM-LC-Sw1-BA_PCB funktioniert übrigens einwandfrei. Zwar gibt es hier kurzzeitig mal "Missing ACK", aber das verschwindet innerhalb von 1-2s gleich wieder. Schalten tut er problemlos, das Anlernen hat auch auf Anhieb geklappt.

list hm-cc-rt-dn:



Internals:
   CFGFN     
   DEF        22E536
   IODev      hmusb
   LASTInputDev hmusb
   MSGCNT     26
   NAME       thermostat_wz
   NR         185
   STATE      CMDs_pending
   TYPE       CUL_HM
   channel_01 CUL_HM_HM_CC_RT_DN_22E536_Weather
   channel_02 CUL_HM_HM_CC_RT_DN_22E536_Climate
   channel_03 CUL_HM_HM_CC_RT_DN_22E536_WindowRec
   channel_04 CUL_HM_HM_CC_RT_DN_22E536_Clima
   channel_05 CUL_HM_HM_CC_RT_DN_22E536_ClimaTeam
   channel_06 CUL_HM_HM_CC_RT_DN_22E536_remote
   hmusb_MSGCNT 26
   hmusb_RAWMSG E22E536,0000,0066F0F9,FF,FFE1,1E861022E5360000000A88E4100018
   hmusb_RSSI -31
   hmusb_TIME 2014-02-06 00:24:43
   lastMsg    No:1E - t:10 s:22E536 d:000000 0A88E4100018
   protCmdPend 6 CMDs pending
   protLastRcv 2014-02-06 00:24:42
   protResnd  8 last_at:2014-02-06 00:24:44
   protSnd    25 last_at:2014-02-06 00:24:43
   protState  CMDs_pending
   rssi_at_hmusb avg:-37.34 min:-45 max:-30 lst:-31 cnt:26
   Readings:
     2014-02-05 23:56:48   Activity        alive
     2014-02-06 00:14:10   CommandAccepted yes
     2014-02-05 23:56:49   PairedTo        0x424242
     2014-02-05 23:56:49   R-backOnTime    10 s
     2014-02-05 23:56:49   R-btnLock       unlock
     2014-02-05 23:56:49   R-burstRx       off
     2014-02-05 23:56:49   R-cyclicInfoMsg on
     2014-02-05 23:56:49   R-cyclicInfoMsgDis 0
     2014-02-05 23:56:49   R-globalBtnLock off
     2014-02-05 23:56:49   R-localResDis   off
     2014-02-05 23:56:49   R-lowBatLimitRT 2.1 V
     2014-02-05 23:56:49   R-modusBtnLock  off
     2014-02-05 23:56:49   R-pairCentral   0x424242
     2014-02-05 23:56:49   RegL_00:          01:00 02:01 09:01 0A:42 0B:42 0C:42 0E:0A 0F:00  11:00 12:15 16:00 18:00 19:00 1A:00 00:00
     2014-02-06 00:14:41   RegL_07:       
     2014-02-06 00:24:43   actuator        0 %
     2014-02-06 00:24:43   battery         ok
     2014-02-06 00:24:43   batteryLevel    3.1 V
     2014-02-06 00:24:43   desired-temp    17
     2014-02-06 00:24:43   measured-temp   22.8
     2014-02-06 00:24:44   state           CMDs_pending
   cmdStack:
     ++A00142424222E53600040000000007
     ++A00142424222E5360503
     ++A00142424222E53605040000000001
     ++A00142424222E5360603
     ++A00142424222E53606040000000001
     ++A01142424222E536860414
   Helper:
     cSnd       0142424222E53600040000000007
     mId        0095
     rxType     140
     Io:
       nextSend   1391642683.03501
     Prt:
       bErr       0
       sProc      2
       wuReSent   3
     Q:
       qReqConf   
       qReqStat   
     Role:
       dev        1
     Rssi:
       At_hmusb:
         avg        -37.3461538461539
         cnt        26
         lst        -31
         max        -30
         min        -45
     Shregw:
       07         04
     Shadowreg:
Attributes:
   IODev      hmusb
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_full
   firmware   1.1
   model      HM-CC-RT-DN
   peerIDs   
   room       CUL_HM
   serialNr   KEQ0733977
   subType    thermostat
   webCmd     :burstXmit

list hmusb:

Internals:
   DEF        192.168.0.20:1000
   DeviceName 192.168.0.20:1000
   FD         10
   HM_CMDNR   35
   NAME       hmusb
   NR         20
   NTFY_ORDER 50-hmusb
   PARTIAL   
   RAWMSG     E22E536,0000,00690D0A,FF,FFE1,1F861022E5360000000A88E4100018
   RSSI       -31
   STATE      opened
   TYPE       HMLAN
   XmitOpen   1
   assignedIDs 22BBF5,2392DE,22E536
   assignedIDsCnt 3
   assignedIDsReport 3
   firmware   0.967
   hmusb_MSGCNT 53
   hmusb_TIME 2014-02-06 00:27:01
   msgKeepAlive dlyMax:0.03 bufferMin:4
   msgLoadEst 1hour:2% 10min steps: 0/0/0/2/0/0
   owner      424242
   serialNr   IEQ0435240
   uptime     000 01:54:48.779
   Readings:
     2014-02-05 23:06:40   Xmit-Events     ok:1
     2014-02-05 23:06:40   cond            ok
     2014-02-04 00:26:14   prot_ERROR-Overload last
     2014-02-03 02:10:52   prot_Warning-HighLoad last
     2014-02-05 23:06:37   prot_disconnected last
     2014-02-05 23:06:37   prot_init       last
     2014-02-05 22:12:00   prot_keepAlive  last
     2014-02-05 23:06:40   prot_ok         last
     2014-02-02 11:53:18   prot_timeout    last
   Assids:
     22BBF5     1
     22E536     1
     2392DE     1
   Helper:
     assId      0
     000001:
       flg        0
     22bbf5:
       chn        00
       flg        0
       msg       
       name       thermostat_az
       newChn     +22BBF5,00,01,
       to         1391641157.7493
     22e536:
       chn        00
       flg        0
       msg       
       name       CUL_HM_HM_CC_RT_DN_22E536
       newChn     +22E536,00,01,
       to         1391642823.20761
     2392de:
       chn        02
       flg        0
       msg       
       name       CUL_HM_HM_LC_SW1_BA_PCB_2392DE
       newChn     +2392DE,00,01,
       to         1391639093.15944
     424242:
       flg        0
     Assids:
     K:
       BufMin     4
       DlyMax     0.03
       Next       1391642850.30569
       Start      1391642825.30569
     Log:
       all        1
       sys        1
       ids:
         all
         sys
     Q:
       HMcndN     0
       answerPend 0
       hmLanQlen  1
       keepAliveRec 1
       keepAliveRpt 0
       apIDs:
       Cap:
         0          0
         1          7
         2          6
         3          0
         4          0
         5          35
         last       2
         sum        48
     Ref:
       hmtL       6888779
       kTs        0
Attributes:
   addvaltrigger 1
   hmId       424242
   hmLanQlen  1_min
   hmProtocolEvents 1_dump
   logIDs     sys,all
   verbose    5
   wdTimer    25

list global:

Internals:
   DEF        <no definition>
   LASTInputDev hmusb
   MSGCNT     4
   NAME       global
   NR         1
   STATE      <no definition>
   TYPE       Global
   currentlogfile ./log/fhem-2014-02.log
   hmusb_MSGCNT 4
   hmusb_RAWMSG R04403F43,0001,00490995,FF,FFD6,13A01022E536424242020100020109010A420B420C420E0A0F00
   hmusb_RSSI -42
   hmusb_TIME 2014-02-05 23:52:03
   logfile    ./log/fhem-%Y-%m.log
Attributes:
   autoload_undefined_devices 1
   configfile fhem.cfg
   logfile    ./log/fhem-%Y-%m.log
   modpath    .
   motd       SecurityCheck:

WEB,WEBphone,WEBtablet has no basicAuth attribute.
telnetPort has no password/globalpassword attribute.
Running with root privileges.
Restart fhem for a new check if the problem is fixed,
or set the global attribute motd to none to supress this message.

   mseclog    1
   statefile  ./log/fhem.save
   updateInBackground 1
   userattr   devStateIcon devStateStyle icon sortby webCmd
   verbose    1
   version    $Id: fhem.pl 4769 2014-01-29 08:14:58Z rudolfkoenig $

So,

der Logs zweiter Teil. Jetzt habe ich es das erste Mal geschafft, mit fhem eine Temperaturliste an einen RT zu übertragen. Ich habe den Burst-Mode eingeschaltet (laut Wiki burstRX auf on und burstAcces 1_auto). Nach einigen Minuten hat er dann tatsächlich die Liste übernommen. Dazwischen gibt es viele noACKS. Ich verstehe auch nicht, warum die Readings alle auf set_ stehen?!

Insgesamt antwortet der RT häufig mit "nö", wenn fhem ihm Befehle schicken möchte. Aber warum?

Internals:
   DEF        22BBF5
   IODev      hmusb
   LASTInputDev hmusb
   MSGCNT     39
   NAME       thermostat_az
   NR         31
   STATE      CMDs_pending
   TYPE       CUL_HM
   channel_01 CUL_HM_HM_CC_RT_DN_22BBF5_Weather
   channel_02 CUL_HM_HM_CC_RT_DN_22BBF5_Climate
   channel_03 CUL_HM_HM_CC_RT_DN_22BBF5_WindowRec
   channel_04 solltemp_az
   channel_05 CUL_HM_HM_CC_RT_DN_22BBF5_ClimaTeam
   channel_06 CUL_HM_HM_CC_RT_DN_22BBF5_remote
   hmusb_MSGCNT 39
   hmusb_RAWMSG R04871910,0001,008FE42C,FF,FFE0,3C800222BBF542424200
   hmusb_RSSI -32
   hmusb_TIME 2014-02-06 01:09:26
   lastMsg    No:3C - t:02 s:22BBF5 d:424242 00
   protCmdDel 27
   protCmdPend 12 CMDs pending
   protCondBurst off
   protLastRcv 2014-02-06 01:09:26
   protResnd  6 last_at:2014-02-06 01:06:23
   protResndFail 1 last_at:2014-02-05 23:25:31
   protSnd    21 last_at:2014-02-06 01:09:26
   protState  CMDs_pending
   rssi_at_hmusb avg:-40.25 min:-59 max:-30 lst:-32 cnt:39
   rssi_hmusb avg:-45 min:-45 max:-45 lst:-45 cnt:1
   Readings:
     2014-02-06 00:54:09   Activity        alive
     2014-02-06 01:09:26   CommandAccepted yes
     2014-02-03 19:54:03   PairedTo        0x424242
     2014-02-04 00:49:29   R-backOnTime    set_10 s
     2014-02-04 00:49:29   R-btnLock       set_unlock
     2014-02-06 00:55:05   R-burstRx       set_on
     2014-02-04 00:49:29   R-cyclicInfoMsg set_on
     2014-02-04 00:49:29   R-cyclicInfoMsgDis set_0
     2014-02-04 00:49:29   R-globalBtnLock set_off
     2014-02-04 00:49:29   R-localResDis   set_off
     2014-02-04 00:49:29   R-lowBatLimitRT set_2.1 V
     2014-02-04 00:49:29   R-modusBtnLock  set_off
     2014-02-04 00:49:29   R-pairCentral   set_0x424242
     2014-02-05 23:59:15   RegL_07:        CA:11 CB:20 CC:24
     2014-02-06 01:09:25   actuator        0 %
     2014-02-06 01:09:25   battery         ok
     2014-02-06 01:09:25   batteryLevel    3 V
     2014-02-06 01:09:25   desired-temp    9
     2014-02-06 01:09:25   measured-temp   23.3
     2014-02-06 01:09:31   state           CMDs_pending
     Regl_00::
       VAL       
   cmdStack:
     ++A00142424222BBF500040000000000
     ++A00142424222BBF50103
     ++A00142424222BBF501040000000001
     ++A00142424222BBF50203
     ++A00142424222BBF502040000000001
     ++A00142424222BBF50303
     ++A00142424222BBF503040000000001
     ++A00142424222BBF504040000000001
     ++A00142424222BBF500040000000007
     ++A00142424222BBF50503
     ++A00142424222BBF505040000000001
     ++A00142424222BBF50603
     ++A00142424222BBF506040000000001
   Helper:
     cSnd       0142424222BBF500040000000000
     mId        0095
     rxType     140
     Io:
       nextSend   1391645366.62889
     Prt:
       awake      0
       bErr       0
       sProc      2
       sleeping   1
       wakeup     1
     Q:
       qReqConf   
       qReqStat   
     Role:
       dev        1
     Rssi:
       At_hmusb:
         avg        -40.2564102564102
         cnt        39
         lst        -32
         max        -30
         min        -59
       Hmusb:
         avg        -45
         cnt        1
         lst        -45
         max        -45
         min        -45
     Shregw:
       07         04
     Shadowreg:
       RegL_00:   0 01:01
       RegL_07:   
Attributes:
   IODev      hmusb
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   burstAccess 1_auto
   expert     2_full
   firmware   1.2
   model      HM-CC-RT-DN
   peerIDs   
   room       arbeitszimmer
   serialNr   KEQ0727575
   subType    thermostat
   webCmd     :burstXmit

Moin,

hier mein Beitrag zur "Datenerhebung" ;-)

• 1x     Raspberry mit CUL und FHEM (letztes Update gemacht am 05.02.14 morgens)
• 10x   HM-CC-RT-DN FW V1.2
• davon 6 RT in einer Structure
• Alle RT sowie Structure werden über Heating_Control zeitgesteuert vom FHEM betrieben.

Mit dieser Codezeile:       $dDly -= 0.04 if ($mTy eq "02");
hatte ich folgenden Effekt:

• RT hatten blinkende Antenne
• Readings im Device unter FHEM teilweise unvollständig
• motorERR:     communicationERR
• dauerndes wechseln zwischen CMDs_Processing und CMDs-pending (klar war ja communicationERR)

Nach dem deaktivieren der Codezeile:     # $dDly -= 0.04 if ($mTy eq "02");   

• Haben die RT keine blinkende Antenne mehr
• Die Readings in den Devices sind wieder vollständig
• motorERR: OK

hi sebixvi,

schau ich einmal durch - aber kannst du hmProtocolEvents abschalten? Das kostet mit unter performance - rate ich davon ab

Gruss Martin

Hallo Martin,

ja, werde ich auf jeden Fall versuchen. Ich habe erstmal alles, was mir nach logging klang, eingeschaltet ;-)

Inzwischen kann ich mit dem einen Thermostaten "reden" (zumindest ab und zu, ich werde mich noch bemühen, hier eine Regelmäßigkeit herauszufinden). Könnte es sein, dass die noACKs auf ein nicht vollständig erfolgreiches Pairing zurückzuführen sind? Oder antworten die Thermostate auf "Befehle" nicht autorisierter Partner schon gar nicht?

Aufgefallen ist mir, dass nach erfolgtem Pairing (AC im Display und PairedTo=0x424242) ein weiterer Druck auf die Boost-Taste keinen Funkverkehr mehr ausgelöst hat - oder zumindest der HM-CFG-USB hierauf nicht reagiert hat, es liefen keine Meldungen durch.

Ciao,
Sebi

Hallo,
nach meinem Urlaub habe ich vor einem update ein getConfig gestartet (auf allen 4 RTs) und nach kurzer Zeit kam CMDs done.
Danach ein FHEM update gestartet  und ein shutdown restart und dann sofort wieder getConfig und wieder kam nach kurzer Zeit CMDs done.
Also scheint bei mir alles wieder auch mit der offiziellen Version von 00_CUL.pm gut zu sein.

Meine Ausstattung (auf HM Seite):
4*HM-CC-RT-DN (FW 1.0 und 1.1)
Raspberry Pi mit aktueller FHEM
CUL V 1.57 CUL868

Falls du noch Log Infos brauchst bitte melden

Gruß,
Martin

@Martin,
danke, reicht

@Sebi,
pairing ist entweder ok oder nicht - halb fertig kann es nicht sein. Was halb fertig sein könnte ist die Abfrage der Register nach dem pairing - das sollte automatich passieren.

Aus boost reagiert er nur noch, wenn du etwas länger drückst - aber da sollte schon noch eine Message kommen (config message). Da passieren gelegentlich auch noch aktionen...

Gruss Martin

Hallo zusammen,

Ich glaube ich habe ein ähnliches (das gleiche?) Problem - in jedem Fall kann ich auch zur Datensammlung beitragen :-)
Vielleicht bin ich mit meinem Problem hier auch nicht vollkommen falsch.

habe seit Anfang der Woche einen HM-CFG-USB an meiner FritzBox 7390 hängen (neuestes FHEM von fhem.de, FritzOS 6.01). Dazu 3 HM-CC-RT-DN, mit denen ich für den Anfang gerne 3 Heizkörper steuern will. Nach 3 Abenden/Nächten (*gähn*) habe ich es geschafft die Firmware des USB Sticks und der Thermostate auf die jeweils aktuelleste Firmware zu aktualisieren, den USB-Stick mit FHEM sprechen zu lassen (hmlan-Emulation) und die HM-CC-RT-DN zu pairen - glaube ich wenigstens. "update check" sagte gerade eben auch "nothing to do..."

Bin total neu in der Materie und noch etwas erschlagen - kann gut sein dass ich nicht alle nötigen infos liefere - aber ich werde auf Anfrage nach bestem können nachliefern was nötig ist.

Das Problem: In FHEM sehe ich die aktuelle Temperatur und empfange auch Änderungen die ich am Thermostat mache. Ich kann aber keine Temperaturen in FHEM setzen. Da steht dann (aktuell seit gestern Nacht) "State CMDs_pending" und nichts rührt sich. Hier liest man einiges, dass andere dieses problem mit ähnlichen/gleichen Konstellationen seit kürzerer Zeit ebenfalls haben.
Gibt es vlt einen Stand von FHEM auf den ich zurück kann um zu sehen, dass das ganze prinzipiell funktioniert? Ich brauche mal ein Erfolgserlebnis und würde das auch gerne erleben, solange ich noch mein Rückgaberecht habe.

Zum Pairing: Mir wird die korrekte D-serialNr angezeigt, und bei PairedTo steht 0x424242.
Readings:
Activity unknown 2014-02-07 20:49:47
CommandAccepted yes 2014-02-07 00:36:33
D-firmware 1.2 2014-02-07 00:26:31
D-serialNr KEQ0729487 2014-02-07 00:26:31
PairedTo 0x424242 2014-02-07 00:26:33
R-backOnTime 10 s 2014-02-07 00:26:33
R-btnLock unlock 2014-02-07 00:26:33
R-burstRx on 2014-02-07 00:26:33
R-cyclicInfoMsg on 2014-02-07 00:26:33
R-cyclicInfoMsgDis 0 2014-02-07 00:26:33
R-globalBtnLock off 2014-02-07 00:26:33
R-localResDis off 2014-02-07 00:26:33
R-lowBatLimitRT 2.1 V 2014-02-07 00:26:33
R-modusBtnLock off 2014-02-07 00:26:33
R-pairCentral 0x424242 2014-02-07 00:26:33
RegL_00: 01:01 02:01 09:01 0A:42 0B:42 0C:42 0E:0A 0F:00 11:00 12:15 16:00 18:00 19:00 1A:00 00:00 2014-02-07 00:26:33
RegL_07: 0 2014-02-07 00:39:19
actuator 0 % 2014-02-07 00:38:34
battery ok 2014-02-07 00:38:34
batteryLevel 3.1 V 2014-02-07 00:38:34
desired-temp 17 2014-02-07 00:38:34
measured-temp 22.1 2014-02-07 00:38:34
state CMDs_pending 2014-02-07 20:57:22

Im Event Monitor taucht immer wieder das auf:
2014-02-07 21:13:23 HMLAN hmusb cond: timeout
2014-02-07 21:13:23 HMLAN hmusb Xmit-Events: timeout:1
2014-02-07 21:13:23 HMLAN hmusb prot_timeout: last
2014-02-07 21:13:23 HMLAN hmusb DISCONNECTED
2014-02-07 21:13:23 HMLAN hmusb cond: disconnected
2014-02-07 21:13:23 HMLAN hmusb Xmit-Events: disconnected:1
2014-02-07 21:13:23 HMLAN hmusb prot_disconnected: last
2014-02-07 21:13:23 HMLAN hmusb cond: init
2014-02-07 21:13:23 HMLAN hmusb Xmit-Events: init:1
2014-02-07 21:13:23 HMLAN hmusb prot_init: last
2014-02-07 21:13:23 HMLAN hmusb CONNECTED
Ist das normal?

Bei den Logs blicke ich noch überhaupt nicht durch. Da scheint es ja einige zu geben - welche wofür sind, habe ich noch nicht kapiert.  :-[
Hilft davon schon was weiter? Oder ganz anderes Problem? Lieber eigener Thread?

Danke fürs lesen!
Lieben Gruß
Jonas

Hallo Jonas,

ich kenne das Gefühl ... das wird aber besser :-)

Probier mal folgendes, das hat bei mir definitiv geholfen, seit läuft alles gut:

Habe jetzt in der aktuellen 00_CUL.pm folgenden Eintrag geändert:

# $dDly -= 0.04 if ($mTy eq "02");                                    (Befehl mit# deaktiviert)

Best Grüße und viel Erfolg

Uwe

Hallo Uwe,

Danke für die Antwort!

Ich habe die Zeile per telnet mit vi auskommentiert und fhem mittels "shutdown restart" neugestartet - danach noch die FB komplett. Leider keine Änderung. Es steht immer noch die selbe Anzahl an CMDs pending...

Der Pfad
/var/media/ftp/fhem/FHEM/00_CUL.pm
Zeile #691
sollte stimmen oder? Die Änderung ist dort definitiv vorgenommen.

Gute Nacht  ;)

Hallo Jonas

du hast HMUSB => 00_CUL interessiert dich nicht. 00_HMLAN ist dein IOdev. Das funktioniert etwas anders.

Die Kommandos für einen RT werden per default beim Aufwachen des RT (alle 2,5min) übertragen. Der RT stellt dann den Wert ein, sendet dann aber noch einmal den alten Wert an FHEM. Erst beim nächsten aufwachen (jetzt also schon 5 min später) - wird FHEM informiert - und der neue Wert ist sichtbar.

Das Übertragen kann man beschleunigen durch Nutzung von Burst. Angezeigt wird der Wert aber auch hier erst beim nächsten Aufwachen nach setzen. Abfragen kann man den Sollwert nicht, man muss warten.

Ist dies dein Problem?

Gruss Martin

Hallo Martin,

Danke für die Antwort!

Zitat von: martinp876 am 08 Februar 2014, 08:25:11
du hast HMUSB => 00_CUL interessiert dich nicht. 00_HMLAN ist dein IOdev. Das funktioniert etwas anders.

Klingt logisch :-)

Zitat von: martinp876 am 08 Februar 2014, 08:25:11
Die Kommandos für einen RT werden per default beim Aufwachen des RT (alle 2,5min) übertragen. Der RT stellt dann den Wert ein, sendet dann aber noch einmal den alten Wert an FHEM. Erst beim nächsten aufwachen (jetzt also schon 5 min später) - wird FHEM informiert - und der neue Wert ist sichtbar.

Wenn ich das richtig verstehe sollte also nach ~10min der korrekte Wert wieder in fhem ankommen - bei mir ist er nach 24h noch der alte, bzw. der am RT tatsächlich eingestellte. Denn der RT übernimmt meine Befehle ja gar nicht erst. Insofern denke ich, dass mein Problem ein anderes ist....

Gruß
Jonas
Edit: ich werde es später aber in jedem Fall testen!

Edit2: Jetzt stehen die Devices auf CMDs_done - ohne dass ich nochmal was verändert hätte. Grade noch mal testweise eien Befehl geschickt - der steht aktuell auf MISSING ACK ... ich bin gespannt :)
Edit3: MISSING ACK hält nun auch schon seit ~20 min an. RT zeigt noch den alten Stand

Hallo Jonas,

du unterscheidset sicher
- CMDS_done : alles ok, fertig
- CMDS_pending : sind in wartestellung...
- missing ack: device hat nicht wie erwartet geantwortet. Nach einer Anzahl versuche wird das kommando gelöscht

Du kannst einmal loggen, dann kann ich nachsehen...

Gruss Martin

Hallo zusammen,

wollte bloß mal kundtun, dass ich auch mit dem heutigen FHEM Stand (09.02.) immer noch das pending-Problem habe.
Wenn ich besagte Zeile aus der 00_CUL.pm auskommentiere, flutscht es aber wie geschmiert.

Gebt Bescheid, wenn ich mit Logs oder Tests unterstützen kann.

Gruß
Leo

Hallo Leo,

schicke bitte einen roh-log sowie die devices, welche das Problem haben.

Gruss Martin

Hallo Martin,

hier das Log, nachdem ich auf getConfig und burstXmit gedrückt hab.


2014.02.09 21:34:29.480 4: CUL_Parse: CUL A 0C 9E 8670 1FC928 000000 007C3736 -47
2014.02.09 21:34:36.506 4: CUL_Parse: CUL A 0C A9 8670 1FCB96 000000 006A34FF -74.5
2014.02.09 21:34:46.900 4: CUL_send:  CULAs 09 01 B112 F12332 23505A
2014.02.09 21:34:47.416 4: CUL_Parse: CUL A 0A 01 8002 23505A F12332 0023 -56.5
2014.02.09 21:34:47.519 4: CUL_send:  CULAs 10 02 A001 F12332 23505A 00040000000000
2014.02.09 21:34:47.687 4: CUL_Parse: CUL A 1A 02 A010 23505A F12332 020101020109010AF10B230C320E0A0F0023 -56.5
2014.02.09 21:34:47.750 4: CUL_send:  CULAs 0A 02 8002 F12332 23505A 00
2014.02.09 21:34:47.945 4: CUL_Parse: CUL A 18 03 8010 23505A F12332 02110012151600180019001A00000022 -57
2014.02.09 21:34:48.047 4: CUL_send:  CULAs 0B 03 A001 F12332 23505A 0103
2014.02.09 21:34:48.203 4: CUL_Parse: CUL A 0E 03 8010 23505A F12332 010000000023 -56.5
2014.02.09 21:34:48.305 4: CUL_send:  CULAs 10 04 A001 F12332 23505A 01040000000001
2014.02.09 21:34:48.462 4: CUL_Parse: CUL A 0E 04 8010 23505A F12332 020800000023 -56.5
2014.02.09 21:34:48.564 4: CUL_send:  CULAs 0B 05 A001 F12332 23505A 0203
2014.02.09 21:34:48.720 4: CUL_Parse: CUL A 0E 05 8010 23505A F12332 010000000022 -57
2014.02.09 21:34:48.822 4: CUL_send:  CULAs 10 06 A001 F12332 23505A 02040000000001
2014.02.09 21:34:48.978 4: CUL_Parse: CUL A 0E 06 8010 23505A F12332 020800000023 -56.5
2014.02.09 21:34:49.080 4: CUL_send:  CULAs 0B 07 A001 F12332 23505A 0303
2014.02.09 21:34:49.241 4: CUL_Parse: CUL A 12 07 8010 23505A F12332 01247D7A010000000023 -56.5
2014.02.09 21:34:49.344 4: CUL_send:  CULAs 10 08 A001 F12332 23505A 03040000000001
2014.02.09 21:34:49.501 4: CUL_Parse: CUL A 0E 08 8010 23505A F12332 020800000023 -56.5
2014.02.09 21:34:49.604 4: CUL_send:  CULAs 10 09 A001 F12332 23505A 04040000000001
2014.02.09 21:34:49.760 4: CUL_Parse: CUL A 0E 09 8010 23505A F12332 020800000023 -56.5
2014.02.09 21:34:49.862 4: CUL_send:  CULAs 10 0A A001 F12332 23505A 00040000000007
2014.02.09 21:34:50.030 4: CUL_Parse: CUL A 1A 0A A010 23505A F12332 03012A22093D18030016073000640F050023 -56.5
2014.02.09 21:34:50.092 4: CUL_send:  CULAs 0A 0A 8002 F12332 23505A 00
2014.02.09 21:34:50.289 4: CUL_Parse: CUL A 1A 0B A010 23505A F12332 03100000090E444855084520452045204523 -56.5
2014.02.09 21:34:50.351 4: CUL_send:  CULAs 0A 0B 8002 F12332 23505A 00
2014.02.09 21:34:50.547 4: CUL_Parse: CUL A 1A 0B A010 23505A F12332 03100000090E444855084520452045204523 -56.5
2014.02.09 21:34:50.610 4: CUL_send:  CULAs 0A 0B 8002 F12332 23505A 00
2014.02.09 21:34:50.806 4: CUL_Parse: CUL A 1A 0B A010 23505A F12332 03100000090E444855084520452045204522 -57
2014.02.09 21:34:50.868 4: CUL_send:  CULAs 0A 0B 8002 F12332 23505A 00
2014.02.09 21:35:33.327 4: CUL_Parse: CUL A 0F A7 8610 23505A 000000 0AB0E50F5A5823 -56.5
2014.02.09 21:35:33.480 4: CUL_send:  CULAs 09 0B A112 F12332 23505A
2014.02.09 21:36:34.630 4: CUL_Parse: CUL A 0C 9F 8670 1FC928 000000 007C3736 -47
2014.02.09 21:36:51.701 4: CUL_Parse: CUL A 0C AA 8670 1FCB96 000000 006A3500 -74
2014.02.09 21:38:34.637 4: CUL_Parse: CUL A 0C A0 8670 1FC928 000000 007C3736 -47
2014.02.09 21:38:37.082 4: CUL_Parse: CUL A 0F A8 8610 23505A 000000 0AB0E60F5A5823 -56.5
2014.02.09 21:38:37.184 4: CUL_send:  CULAs 09 0C A112 F12332 23505A
2014.02.09 21:38:37.336 4: CUL_Parse: CUL A 0A 0C 8002 23505A F12332 0023 -56.5
2014.02.09 21:38:37.439 4: CUL_send:  CULAs 10 0D A001 F12332 23505A 00040000000007
2014.02.09 21:38:37.606 4: CUL_Parse: CUL A 1A 0D A010 23505A F12332 03012A22093D18030016073000640F050023 -56.5
2014.02.09 21:38:37.669 4: CUL_send:  CULAs 0A 0D 8002 F12332 23505A 00
2014.02.09 21:38:37.865 4: CUL_Parse: CUL A 1A 0D A010 23505A F12332 03012A22093D18030016073000640F050023 -56.5
2014.02.09 21:38:37.928 4: CUL_send:  CULAs 0A 0D 8002 F12332 23505A 00
2014.02.09 21:38:38.124 4: CUL_Parse: CUL A 1A 0D A010 23505A F12332 03012A22093D18030016073000640F050023 -56.5
2014.02.09 21:38:38.186 4: CUL_send:  CULAs 0A 0D 8002 F12332 23505A 00
2014.02.09 21:38:56.455 4: CUL_Parse: CUL A 0C AB 8670 1FCB96 000000 006A35FF -74.5
2014.02.09 21:41:24.396 4: CUL_Parse: CUL A 0C A1 8670 1FC928 000000 007C3737 -46.5
2014.02.09 21:41:26.334 4: CUL_Parse: CUL A 0F A9 8610 23505A 000000 0AB0E60F5A5822 -57
2014.02.09 21:41:26.436 4: CUL_send:  CULAs 09 0E A112 F12332 23505A
2014.02.09 21:41:26.588 4: CUL_Parse: CUL A 0A 0E 8002 23505A F12332 0022 -57
2014.02.09 21:41:26.690 4: CUL_send:  CULAs 10 0F A001 F12332 23505A 00040000000007
2014.02.09 21:41:26.859 4: CUL_Parse: CUL A 1A 0F A010 23505A F12332 03012A22093D18030016073000640F050022 -57
2014.02.09 21:41:26.921 4: CUL_send:  CULAs 0A 0F 8002 F12332 23505A 00
2014.02.09 21:41:27.117 4: CUL_Parse: CUL A 1A 0F A010 23505A F12332 03012A22093D18030016073000640F050023 -56.5
2014.02.09 21:41:27.179 4: CUL_send:  CULAs 0A 0F 8002 F12332 23505A 00
2014.02.09 21:41:27.377 4: CUL_Parse: CUL A 1A 0F A010 23505A F12332 03012A22093D18030016073000640F050022 -57
2014.02.09 21:41:27.439 4: CUL_send:  CULAs 0A 0F 8002 F12332 23505A 00
2014.02.09 21:41:27.634 4: CUL_Parse: CUL A 1A 10 A010 23505A F12332 03100000090E444855084520452045204522 -57
2014.02.09 21:41:27.696 4: CUL_send:  CULAs 0A 10 8002 F12332 23505A 00
2014.02.09 21:41:27.892 4: CUL_Parse: CUL A 1A 10 A010 23505A F12332 03100000090E444855084520452045204522 -57
2014.02.09 21:41:27.955 4: CUL_send:  CULAs 0A 10 8002 F12332 23505A 00
2014.02.09 21:41:28.151 4: CUL_Parse: CUL A 1A 10 A010 23505A F12332 03100000090E444855084520452045204522 -57
2014.02.09 21:41:28.213 4: CUL_send:  CULAs 0A 10 8002 F12332 23505A 00
2014.02.09 21:41:50.718 4: CUL_Parse: CUL A 0C AC 8670 1FCB96 000000 006A35FE -75


Und hier der Auszug aus meiner cfg:

define Bad.Heizung CUL_HM 23505A
attr Bad.Heizung IODev CUL
attr Bad.Heizung actCycle 000:10
attr Bad.Heizung actStatus alive
attr Bad.Heizung autoReadReg 4_reqStatus
attr Bad.Heizung expert 2_full
attr Bad.Heizung firmware 1.0
attr Bad.Heizung model HM-CC-RT-DN
attr Bad.Heizung peerIDs
attr Bad.Heizung room Bad
attr Bad.Heizung serialNr KEQ0574318
attr Bad.Heizung subType thermostat
attr Bad.Heizung webCmd getConfig:clear msgEvents:burstXmit
define FileLog_Bad.Heizung FileLog ./log/Bad.Heizung-%Y.log Bad.Heizung
attr FileLog_Bad.Heizung logtype text
attr FileLog_Bad.Heizung room CUL_HM
define Bad.Heizung_Weather CUL_HM 23505A01
attr Bad.Heizung_Weather model HM-CC-RT-DN
attr Bad.Heizung_Weather peerIDs 00000000,
attr Bad.Heizung_Weather room Bad
define Bad.Heizung_Climate CUL_HM 23505A02
attr Bad.Heizung_Climate model HM-CC-RT-DN
attr Bad.Heizung_Climate peerIDs 00000000,
attr Bad.Heizung_Climate room Bad
define Bad.Heizung_WindowRec CUL_HM 23505A03
attr Bad.Heizung_WindowRec model HM-CC-RT-DN
attr Bad.Heizung_WindowRec peerIDs 00000000,247D7A01,
attr Bad.Heizung_WindowRec room Bad
attr Bad.Heizung_WindowRec stateFormat last:trigLast
define Bad.Heizung_Clima CUL_HM 23505A04
attr Bad.Heizung_Clima model HM-CC-RT-DN
attr Bad.Heizung_Clima peerIDs
attr Bad.Heizung_Clima room Bad
define Bad.Heizung_ClimaTeam CUL_HM 23505A05
attr Bad.Heizung_ClimaTeam model HM-CC-RT-DN
attr Bad.Heizung_ClimaTeam peerIDs
attr Bad.Heizung_ClimaTeam room Bad
define Bad.Heizung_remote CUL_HM 23505A06
attr Bad.Heizung_remote model HM-CC-RT-DN
attr Bad.Heizung_remote peerIDs
attr Bad.Heizung_remote room Bad


Hilft dir das weiter?

Gruß
Leo

das war jetzt ein log mit burstXmit, also ohne Problem.

kannst du noch einen schicken, wenn kommands pending sind und der RT nicht antwortet? Min 10 min aufzeichenen, damit ein aufwachen dabei ist

Gruss Martin

Hallo Martin,

aber trotz burstXmit geht das Device nur kurz auf PROCESSING und bleibt danach ewig in  "CMDs PENDING" stehen. Wenn ich das richtig verstanden habe, müssten doch alle CMDs mit einem burstXmit abgearbeitet werden, oder?
Aber ich schick dir heut abend nochmal einen Log ohne burstXmit.

Gruß
Leo

Hi Leo,

ok, habe es daraufhin noch einmal durchgesehen - ja, da besteht ein Problem.
kannst du 2 tests durchfuehren: 00_HMLAN etwa Zeile 696

    my $dDly = $modules{CUL_HM}{defptr}{$id}{helper}{io}{nextSend} - $now;
    $dDly -= 0.04 if ($mTy eq "02");
    if ($dDly > 0.01){# wait less then 10 ms will not work
      $dDly = 0.1 if($dDly > 0.1);
      Log3 $hash->{NAME}, 5, "CUL $id dly:".int($dDly*1000)."ms";
      select(undef, undef, undef, $dDly);
    }
Aendern in

    $dDly -= 0.10 if ($mTy eq "02");
und dann in
   $dDly -= 0.00 if ($mTy eq "02");

beide male testen, ob ein getConfig durchlaeuft

Gruss Martin

Hallo Martin,

ich hänge mich hier einmal mit dran, weil ich seit meinem Update vom 09.02. ähnliche Probleme, d.h. vor allem pending commands bei getConfig auf dem HM-CC-RT-DN habe. Vorher (alle Module Stand letzter Update 14.01.) gab es keinerlei Probleme (getConfig, TempListen setzen, desired temp setzen etc etc).

Meine Umgebung: FB7390 mit CUL, 4 x HM-CC-RT-DN nur WakeUp / kein BurstXmit und noch ein paar weiter HM Schalter

Hier die Ergebnisse meiner Tests mit dDly in 00_CUL.pm:

1. Original - ohne Änderung
$dDly -= 0.04 if ($mTy eq "02");

=> bei getConfig "pending" für mehrere (viele) WakeUp Zyklen, je Zyklus wird der Resend Counter um 1 hochgezählt
=> irgendwann geht das getConfig auf done
=> dann aber trotzdem häufig "missing Reglist .7" für den Clima / ClimRT Channel im HMinfo ConfigCheck
=> Beheben durch getConfig auf den Clima, weitere "pending" Zyklen, irgendwann ok

2. Auskommentieren der Zeile
#$dDly -= 0.04 if ($mTy eq "02");
=> bei getConfig "pending" für wenige (2-3) Zyklen, je Zyklus wird der Resend Counter um 1 hochgezählt
=> nach "done" trotzdem häufig "missing Reglist .7" für den Clima / ClimRT Channel im HMinfo ConfigCheck
=> Beheben durch getConfig auf den Clima, weitere "pending" Zyklen, irgendwann ok

3. Edit1 für den dDly Wert: (siehe vorherigen Post)
$dDly -= 0.10 if ($mTy eq "02");
=> bei getConfig "pending" von 12cmds für viele WakeUp Zyklen, je Zyklus wird der Resend Counter um 1 hochgezählt
=> Anzahl pending Commands wird nicht weniger, Test abgebrochen

4. Edit2 für den dDly Wert: (siehe vorherigen Post)
$dDly -= 0.00 if ($mTy eq "02");
=> getConfig wird meist nach einem Zyklus abgearbeitet, selten dauert es einen zweiten Zyklus
=> ConfigCheck ist nach getConfig sauber - insbesondere die problematische Übertragung der Reglist 7 des Clima Channel scheint ok zu sein
=> Härtetest bestanden: gleichzeitiges Absetzen von getConfig auf alle 4 RTs und statusRequest für die übrigen Schalter: nach ca 5 Minuten (1 - 2 WakeUp Zyklen) keine pending commands, configCheck ist sauber

Ich werde jetzt einstweilen die Zeile wie in Test 4 beibehalten. Vom Gefühl her noch nicht ganz so robust wie vor den Updates in der 00_CUL (04.02.) aber deutlich besser als mit dem aktuellen Stand.

Hier noch zum Vergleich die relevanten Modulstände in meiner Installation:

# $Id: fhem.pl 4829 2014-02-07 07:27:47Z rudolfkoenig $
# $Id: 00_CUL.pm 4803 2014-02-04 08:07:28Z rudolfkoenig $
# $Id: 10_CUL_HM.pm 4864 2014-02-09 18:02:23Z martinp876 $
# $Id: 98_HMinfo.pm 4850 2014-02-08 18:27:06Z martinp876 $

Bei Bedarf kann ich gerne noch weitere Tests (ggf. auch mit Raw Messages) durchführen.

Danke & Gruß
Tobias

Hallo Tobias,

ok - dein Device brauch also ein delay von 100ms vor einem ACK.
Im Prinzip sollte das wie vor der Aenderung sein - vielleicht kommt dein Gefueh dem noch nach.

hm  - wieder das delay problem, das ich noch entschluessen muss.

Gruss Martin

Hallo Martin,

brauchst du meinen überhaupt Test noch, nachdem Tobias das so schön dokumentiert hat?

Gruß
Leo

PS: Sind die Versuche 2 und 4 von Tobias nicht identisch?!?

Hi Leo,

ja, 2 und 4 sind identisch

beim Fix leigt das Problem darin, festzustellen welches Device einen delay zwingend braucht und welches zwingend Null delay fordert.
Die aktuellen 60ms scheinen ihm nicht zu reichen...

Gruss Martin

Hallo - von mir auch wieder ein Feedback.

Wenn ich nach dem Befehl nichts mache stehen die Befehle manchmal in pending (Stundenlang) und manchmal auf MISSING ACK. Wenn ich nach dem Befehl auf burstXmit funktioniert es allerdings tatsächlich - der RT empfängt den Wert, zeigt ihn an und reagiert bald darauf entrsprechend - CMDs_done :D DANKE! Das habe ich mal gebraucht.

Ich habe mal meine Logs alle geleert und die FB neu gestartet. Anschließend ein wenig an den Reglern rumgespielt. Am Ende mit burstXmit. Da ich nicht weiß welche Logs dabei interessant sind, habe ich alle die etwas enthalten mal in einem zip angehängt. Hoffe es hilft weiter...

Gruß
Jonas

Zitat von: martinp876 am 10 Februar 2014, 18:08:02

ja, 2 und 4 sind identisch

beim Fix leigt das Problem darin, festzustellen welches Device einen delay zwingend braucht und welches zwingend Null delay fordert.
Die aktuellen 60ms scheinen ihm nicht zu reichen...

Danke, Martin für die Klarstellung - wegen des if Statements in der Zeile war ich mir nicht sicher, ob Auskommentieren  (Test2) wirklich den gleichen Testfall wie 4 darstellt. Die Tests 3 und 4 hatte ich unmittelbar vor meiner Antwort durchgeführt - Tests 1 und 2 gestern (spät) abend - kann ich mir jetzt nicht erklären, warum 2 dann trotzdem noch Probleme mit nicht (komplett) übertragener Reglist 7 beim Clima Channel ergeben hat.

Und ja, Timing macht in der IT fast soviel Scherereien wie Drucken :-)

Gruss
Tobias

Hi,

Sollte einmal ein RT auf CMD_Pending haengen bleiben bitte ein list des Device und einen Mitschnitt der Rohmessages von etwa 10 min schicken.

Gruss Martin

Zitat von: martinp876 am 05 Februar 2014, 14:59:24
- mit welcher Version ging es, mit welcher nicht?
- Welches Device?
- mit HMLAN/USB oder CUL (hier eigentlich nur CUL/CUNO,...)
- virtueller Peer oder Aktion mit FHEM/Zentrale
- ggf logs

So, auch meine 2ct:

• Gentoo Linux mit FHEM, letztes Update am 4.2., kurz danach begannen die CMDs_pending
• 3 HM-CC-RT-DN
• V 1.55 CUL868
• set desired-temp und getConfig

Nach Auskommentierung von der o.a. Zeile läuft alles wieder wie die Wutz! :)
Log anbei

hi Rockojfonzo,

ZitatNach Auskommentierung von der o.a. Zeile läuft alles wieder wie die Wutz!

Du meinst
$dDly -= 0.00 if ($mTy eq "02");
ist komplett auskommentiert? das log ist ohne diese Zeile?
der delay fuer ack ist 60ms... da muesste die Zeile aktiv gewesen sein

Gruss Martin

Sorry, blöd formuliert: Das Log ist mit aktiver Zeile (so hatte ich Deine Bitte verstanden), nach Erzeugung des Logs habe ich die Zeile auskommentiert, seitdem ist allen wieder wohlig warm! :-)

Dank & Gruß

Tino

Hallo zusammen,

@Martin: ich glaube, meine Logs kannst Du getrost ignorieren, ich hatte offenbar ein Hardware-Problem. Nachdem mein HM-CFG-USB von heute auf morgen per USB nicht mehr ansprechbar war, habe ich mir einen HM-CFG-USB2 besorgt. Damit lassen sich alle RTs ohne irgendwelche Änderungen an fhem problemlos anlernen und auch Temperaturlisten etc. werden sauber übertragen. Ob es damit auch im Zusammenspiel mit der HomeMatic-Software ohne Fehlermeldungen funktioniert, habe ich noch nicht getestet, weil kein Grund bestand, etwas anderes als fhem zu testen.

Wenn ich noch Merkwürdigkeiten feststellen sollte, melde ich mich.

Seltsam ist die Geschichte schon, zumal ich bei einem RT sogar ein FW-Update durchführen konnte und das Schalten eines 1-Kanal-Schalters (Bausatz) ebenso wie das Auslesen der RTs mit dem CFG-USB funktioniert hat. Allerdings hatte ich beim Pairen das Gefühl, als wenn der alte CFG-USB bisweilen Pakete verschluckt hat. Aber mit dem neuen funktioniert es so reibungslos ohne irgendwelche sonstigen Änderungen, dass es schlicht der alte CFG-USB gewesen sein muss.

Schönes WE,
Sebastian

Habe auch seit ca. Donnerstag letzer Woche ein Problem mit den Missing ACK

    Debian Whezzy auf Raspberry mit FHEM
    3 HM-CC-RT-DN
    V 1.57 CUL868
    set desired-temp und getConfig

Die angegebene Zeile

#$dDly -= 0.04 if ($mTy eq "02");

ist standardmäßig ausdokumentiert....

Hallo,

ich bin neu hier und habe vor kurzem einen HM-CFG-USB 2 und 2 HM-CC-RT-DN geholt.
An sich funktioniert es, aber ich habe den Eindruck, dass das senden von Commandos aus dem FHEM meist erst nach ein paar sende versuchen ankommt, wenn überhaupt.

System:
ubuntu 10.04
hmland 0.094-git
FHEM alle Updates bis heute

Anbei ein Log wo ich die Temperatur ändern möchte, beim dritten Versuch hat es dann geklappt.

2014.03.04 22:04:24.149 0: HMLAN_Parse: HMLAN0 R:E241293   stat:0000 t:04A72060 d:FF r:FFC9     m:FE 8610 241293 000000 0AA0CD10182F
2014.03.04 22:04:24.151 4: RCV L:0F N:FE F:86 CMD:10 SRC:wz_heizung DST:broadcast 0AA0CD10182F (INFO_TEMP SET:40 ACT:205 ERR:0x10 VALVE:0x10 MODE:0x10) (,WAKEMEUP,CFG,RPTEN)
2014.03.04 22:04:24.250 0: HMLAN_Send:  HMLAN0 S:S8EE9659D stat:  00 t:00000000 d:01 r:8EE9659D m:26 A112 548623 241293
2014.03.04 22:04:24.251 4: SND L:09 N:26 F:A1 CMD:12 SRC:548623 DST:wz_heizung  (HAVE_DATA) (,WAKEUP,BIDI,RPTEN)
2014.03.04 22:04:24.885 0: HMLAN_Parse: HMLAN0 R:R8EE9659D stat:0008 t:00000000 d:FF r:7FFF     m:26 A112 548623 241293
2014.03.04 22:04:24.885 0: HMLAN_Parse: HMLAN0 no ACK from 241293
2014.03.04 22:06:03.336 0: HMLAN_Parse: HMLAN0 R:E24124D   stat:0000 t:04A8A3E8 d:FF r:FFC6     m:58 8610 24124D 000000 0A80C7100018
2014.03.04 22:06:03.337 4: RCV L:0F N:58 F:86 CMD:10 SRC:sz_heizung DST:broadcast 0A80C7100018 (INFO_TEMP SET:32 ACT:199 ERR:0x10 VALVE:0x10 MODE:0x10) (,WAKEMEUP,CFG,RPTEN)
2014.03.04 22:06:53.153 0: HMLAN_Parse: HMLAN0 R:E241293   stat:0000 t:04A96667 d:FF r:FFCA     m:FF 8610 241293 000000 0AA0CD10182F
2014.03.04 22:06:53.155 4: RCV L:0F N:FF F:86 CMD:10 SRC:wz_heizung DST:broadcast 0AA0CD10182F (INFO_TEMP SET:40 ACT:205 ERR:0x10 VALVE:0x10 MODE:0x10) (,WAKEMEUP,CFG,RPTEN)
2014.03.04 22:06:53.253 0: HMLAN_Send:  HMLAN0 S:S8EEBABA8 stat:  00 t:00000000 d:01 r:8EEBABA8 m:27 A112 548623 241293
2014.03.04 22:06:53.255 4: SND L:09 N:27 F:A1 CMD:12 SRC:548623 DST:wz_heizung  (HAVE_DATA) (,WAKEUP,BIDI,RPTEN)
2014.03.04 22:06:53.889 0: HMLAN_Parse: HMLAN0 R:R8EEBABA8 stat:0008 t:00000000 d:FF r:7FFF     m:27 A112 548623 241293
2014.03.04 22:06:53.889 0: HMLAN_Parse: HMLAN0 no ACK from 241293
2014.03.04 22:08:30.099 0: HMLAN_Parse: HMLAN0 R:E24124D   stat:0000 t:04AAE127 d:FF r:FFC6     m:59 8610 24124D 000000 0A80C7100018
2014.03.04 22:08:30.101 4: RCV L:0F N:59 F:86 CMD:10 SRC:sz_heizung DST:broadcast 0A80C7100018 (INFO_TEMP SET:32 ACT:199 ERR:0x10 VALVE:0x10 MODE:0x10) (,WAKEMEUP,CFG,RPTEN)
2014.03.04 22:09:07.630 0: HMLAN_Parse: HMLAN0 R:E241293   stat:0000 t:04AB73CD d:FF r:FFC9     m:00 8610 241293 000000 0AA0CD10182F
2014.03.04 22:09:07.632 4: RCV L:0F N:00 F:86 CMD:10 SRC:wz_heizung DST:broadcast 0AA0CD10182F (INFO_TEMP SET:40 ACT:205 ERR:0x10 VALVE:0x10 MODE:0x10) (,WAKEMEUP,CFG,RPTEN)
2014.03.04 22:09:07.731 0: HMLAN_Send:  HMLAN0 S:S8EEDB8F7 stat:  00 t:00000000 d:01 r:8EEDB8F7 m:28 A112 548623 241293
2014.03.04 22:09:07.732 4: SND L:09 N:28 F:A1 CMD:12 SRC:548623 DST:wz_heizung  (HAVE_DATA) (,WAKEUP,BIDI,RPTEN)
2014.03.04 22:09:07.950 0: HMLAN_Parse: HMLAN0 R:R8EEDB8F7 stat:0001 t:04AB74F8 d:FF r:FFC9     m:28 8002 241293 548623 00
2014.03.04 22:09:07.952 4: RCV L:0A N:28 F:80 CMD:02 SRC:wz_heizung DST:548623 00 (ACK) (,RPTEN)
2014.03.04 22:09:08.051 0: HMLAN_Send:  HMLAN0 S:+241293,00,01,1E
2014.03.04 22:09:08.052 0: HMLAN_Send:  HMLAN0 S:S8EEDBA36 stat:  00 t:00000000 d:01 r:8EEDBA36 m:29 A011 548623 241293 860424
2014.03.04 22:09:08.053 4: SND L:0C N:29 F:A0 CMD:11 SRC:548623 DST:wz_heizung 860424 (SetTemp B1:0x04 B2:0x24) (,BIDI,RPTEN)
2014.03.04 22:09:08.334 0: HMLAN_Parse: HMLAN0 R:R8EEDBA36 stat:0001 t:04AB767C d:FF r:FFC9     m:29 8002 241293 548623 01042420342F
2014.03.04 22:09:08.337 4: RCV L:0F N:29 F:80 CMD:02 SRC:wz_heizung DST:548623 01042420342F (ACK_STATUS CHANNEL:0x04 STATUS:0x24 UP:0 DOWN:1 LOWBAT:0 RSSI:-52) (,RPTEN)


und hier noch das Gerät im FHEM
fhem> list wz_heizung
Internals:
   DEF        241293
   HMLAN0_MSGCNT 49
   HMLAN0_RAWMSG E241293,0000,0496E809,FF,FFCA,F786102412930000000AA0D1100E2F
   HMLAN0_RSSI -54
   HMLAN0_TIME 2014-03-04 21:46:41
   IODev      HMLAN0
   LASTInputDev HMLAN0
   MSGCNT     49
   NAME       wz_heizung
   NR         37
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 wz_heizung_Weather
   channel_02 wz_heizung_Climate
   channel_03 wz_heizung_WindowRec
   channel_04 wz_heizung_ClimRT_tr
   channel_05 wz_heizung_ClimaTeam
   channel_06 wz_heizung_remote
   lastMsg    No:F7 - t:10 s:241293 d:000000 0AA0D1100E2F
   protLastRcv 2014-03-04 21:46:41
   protResnd  3 last_at:2014-03-04 19:54:45
   protSnd    5 last_at:2014-03-04 19:57:43
   protState  CMDs_done
   rssi_HMLAN0 avg:-51 min:-51 max:-51 lst:-51 cnt:1
   rssi_at_HMLAN0 avg:-55.77 min:-60 max:-52 lst:-54 cnt:49
   Readings:
     2014-03-04 19:47:39   Activity        alive
     2014-03-04 19:57:43   CommandAccepted yes
     2014-03-04 19:47:39   D-firmware      1.2
     2014-03-04 19:47:39   D-serialNr      KEQ0907769
     2014-03-04 08:24:16   PairedTo        0x548623
     2014-03-04 08:24:16   R-backOnTime    10 s
     2014-03-04 08:24:16   R-btnLock       off
     2014-03-04 08:24:16   R-burstRx       on
     2014-03-04 08:24:16   R-cyclicInfoMsg on
     2014-03-04 08:24:16   R-cyclicInfoMsgDis 0
     2014-03-04 08:24:16   R-globalBtnLock off
     2014-03-04 08:24:16   R-localResDis   off
     2014-03-04 08:24:16   R-lowBatLimitRT 2.1 V
     2014-03-04 08:24:16   R-modusBtnLock  off
     2014-03-04 08:24:16   R-pairCentral   0x548623
     2014-03-04 08:24:16   RegL_00:        01:01 02:01 09:01 0A:54 0B:86 0C:23 0E:0A 0F:00  11:00 12:15 16:00 18:00 19:00 1A:00 00:00
     2014-03-04 21:46:41   actuator        14 %
     2014-03-04 21:46:41   battery         ok
     2014-03-04 21:46:41   batteryLevel    3.1 V
     2014-03-04 21:46:41   desired-temp    20
     2014-03-04 21:46:41   measured-temp   20.9
     2014-03-04 19:57:43   state           CMDs_done
     2014-03-04 16:35:05   time-request    -
     Regl_07::
       TIME       2014-03-04 19:47:32
       VAL
   Helper:
     cSnd       11548623241293860428
     mId        0095
     rxType     140
     Io:
       newChn     +241293,00,01,1E
       nextSend   1393966001.22745
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
     Rssi:
       Hmlan0:
         avg        -51
         cnt        1
         lst        -51
         max        -51
         min        -51
       At_hmlan0:
         avg        -55.7755102040816
         cnt        49
         lst        -54
         max        -52
         min        -60
     Shregw:
       07         04
     Shadowreg:
Attributes:
   IODev      HMLAN0
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_full
   firmware   1.2
   model      HM-CC-RT-DN
   peerIDs
   room       Wohnzimmer
   serialNr   KEQ0907769
   subType    thermostat
   webCmd     getConfig:clear msgEvents:burstXmit

fhem> list wz_heizung_ClimRT_tr
Internals:
   DEF        24129304
   HMLAN0_MSGCNT 50
   HMLAN0_RAWMSG E241293,0000,049B6284,FF,FFCB,F986102412930000000AA0D0100E2F
   HMLAN0_RSSI -53
   HMLAN0_TIME 2014-03-04 21:51:34
   LASTInputDev HMLAN0
   MSGCNT     50
   NAME       wz_heizung_ClimRT_tr
   NR         45
   STATE      T: 20.8 desired: 20 valve: 14 %
   TYPE       CUL_HM
   chanNo     04
   device     wz_heizung
   Readings:
     2014-03-04 19:57:43   CommandAccepted yes
     2014-03-04 08:24:22   R-boostPeriod   5 min
     2014-03-04 08:24:22   R-boostPos      80 %
     2014-03-04 08:24:22   R-btnNoBckLight off
     2014-03-04 08:24:22   R-dayTemp       21 C
     2014-03-04 08:24:22   R-daylightSaveTime on
     2014-03-04 08:24:22   R-decalcTime    11:00
     2014-03-04 08:24:22   R-decalcWeekday Sat
     2014-03-04 08:24:22   R-modePrioManu  all
     2014-03-04 08:24:22   R-modePrioParty all
     2014-03-04 08:24:22   R-nightTemp     17 C
     2014-03-04 08:24:22   R-noMinMax4Manu off
     2014-03-04 08:24:22   R-regAdaptive   on
     2014-03-04 08:24:22   R-reguExtI      15
     2014-03-04 08:24:22   R-reguExtP      30
     2014-03-04 08:24:22   R-reguExtPstart 30
     2014-03-04 08:24:22   R-reguIntI      17
     2014-03-04 08:24:22   R-reguIntP      32
     2014-03-04 08:24:22   R-reguIntPstart 40
     2014-03-04 08:24:22   R-showInfo      time
     2014-03-04 08:24:22   R-showWeekday   off
     2014-03-04 08:24:18   R-sign          off
     2014-03-04 08:24:22   R-tempMax       30.5 C
     2014-03-04 08:24:22   R-tempMin       4.5 C
     2014-03-04 08:24:22   R-tempOffset    0.0K
     2014-03-04 08:24:22   R-valveErrPos   15 %
     2014-03-04 08:24:22   R-valveMaxPos   100 %
     2014-03-04 08:24:22   R-valveOffsetRt 0 %
     2014-03-04 08:24:22   R-winOpnBoost   off
     2014-03-04 08:24:22   R-winOpnDetFall 1.4 K
     2014-03-04 08:24:22   R-winOpnMode    on
     2014-03-04 08:24:22   R-winOpnPeriod  15 min
     2014-03-04 08:24:22   R-winOpnTemp    12 C
     2014-03-04 21:51:34   ValvePosition   14 %
     2014-03-04 21:51:34   desired-temp    20
     2014-03-04 21:51:34   measured-temp   20.8
     2014-03-04 21:51:34   mode            auto
     2014-03-04 21:51:34   motorErr        ok
     2014-03-04 19:57:43   recentStateType ack
     2014-03-04 21:51:34   state           T: 20.8 desired: 20 valve: 14 %
     2014-03-04 08:24:22   tempListFri     24:00 17.0
     2014-03-04 08:24:22   tempListMon     24:00 17.0
     2014-03-04 08:24:22   tempListSat     24:00 17.0
     2014-03-04 08:24:22   tempListSun     24:00 17.0
     2014-03-04 08:24:22   tempListThu     24:00 17.0
     2014-03-04 08:24:22   tempListTue     24:00 17.0
     2014-03-04 08:24:22   tempListWed     24:00 17.0
     2014-03-04 08:24:22   tempList_State  verified
   Helper:
     Role:
       chn        1
     Shregr:
       07         00
     Shadowreg:
Attributes:
   expert     1
   model      HM-CC-RT-DN
   peerIDs
   room       Wohnzimmer


Wenn ich noch Infos beisteuern kann, einfach melden.

ZitatAn sich funktioniert es, aber ich habe den Eindruck

da hast du recht - und du solltest nicht nur den eindruck haben sondern es auch im resend counter sehen koennen. HMInfo zeigt es als Tabelle.

Ein Problem aus FHEM kann ich nicht erkennen. Es gibt leichte timing schwankungen, die eigentlich ausgeglichen werden sollten... kann ich aber gerade nicht erkennen, dass es passiert.
Sollte dein System eine prinzipielle Verzoegerung haben koennte ich es nicht rueckrechnen/ausgleichen.

Hallo Martin,

ich habe dieses Thema entdeckt, weil ich genau den selben Fehler habe.

Meine FB 7390 hat OS6.2, verwende Cul und 13 HM-CC-RT-DN. Mittlerweile läuft mein (mehrfach) ganz neu aufgesetztes FHEM wieder einigermassen.

Allerdings kommt der Fehler mit dem missing ack und "motorErr communicationERR" ab und zu.

Und zwar bei einem Regler, ohne das ich was sende!
Nun habe ich versucht an einen anderen Temperaturlisten zu übertragen.

Damit:

my $WZ1;
sub
WZ1 ()
{
#

   { fhem ("set WZ1_4 tempListMon prep 05:30 17.0 07:00 22.5 24:00 17.0")};
   { fhem ("set WZ1_4 tempListTue prep 05:30 17.0 10:00 22.5 24:00 17.0")};
   { fhem ("set WZ1_4 tempListWed prep 05:30 17.0 08:00 22.5 24:00 17.0")};
   { fhem ("set WZ1_4 tempListThu prep 05:30 17.0 08:00 22.5 24:00 17.0")};
   { fhem ("set WZ1_4 tempListFri prep 05:30 17.0 07:00 22.5 24:00 17.0")};
   { fhem ("set WZ1_4 tempListSat prep 07:30 17.0 10:00 22.5 24:00 17.0")};
   { fhem ("set WZ1_4 tempListSun exec 07:30 17.0 10:00 22.5 24:00 17.0")};
}

Ergebnis: missing ack....
auch wenn ich die Temperaturlisten einzeln übertrage, geht es nicht,  nach clear readings und getconfig steht nix drin....

Was kann ich tun?

Ergänzung:
Readings  R-burstRx set_on 2014-11-05 15:02:26
RegL_07: CA:11 CB:20 CC:24 2014-11-05 13:37:16
actuator 35 2014-11-05 16:00:21
batteryLevel 2.8 2014-11-05 16:00:21
desired-temp 22.5 2014-11-05 16:00:21
measured-temp 23.6 2014-11-05 16:00:21
state MISSING ACK 2014-11-05 15:24:

update:

Ich habe alle 13 RTs auf Firmware 1.4 upgedated.... das hat ja ewig gedauert.
Nun setze ich nochmal alles komplett neu auf. Wenns dann nicht bald funktioniert, fliegt der ganze Mist raus.
Seit 4 Arbeitstagen würge ich jetzt rum,,, so langsam reicht es mir, trotz aller Begeisterung..



Sodele,,,, alles nochmal komplett neu aufgesetzt, Temperaturlisten überspielen hat bei einigen RT´s funktioniert, aber 2 bringen immer noch den Fehler communication err,,,, der eine ist 2m neben dem Sender, der andere 3m mit ner Betondecke dazwischen.

???????

Sodele... jetzt habe ich die beiden spinnenden Regler nochmal aus FHEM gelöscht, die Geräte geresettet - und zwar erst die Batterie raus, dann nochmal über das Menü  - dann neu angelernt und die Temperaturlisten mit BurstX übertragen. Dazu kurz die mittlerre Taste am RT gedrückt, dann wurden die Commands schnell abgearbeitet.

Zugegeben, mein zutrauen in diese Technik hier schwindet.... so eine Murkserei. Ich bin nun 4 volle Tage mit diesem Mist hier beschäftigt, mit dem Erfolg ,das es wieder so läuft wie vorher. Toll. Meine Namenszuweisungen und Raumzuweisungen habe ich mittlerweile in der Mutils.pm integriert, so das ich die ganze Konfiguration mit einem Click machen kann. 13 Rt´s im Haus verteilt - ich kann es niemanden empfehlen.

Beim nächsten Ausfall fliegt homematic wieder raus bei mir.

ZitatIch habe alle 13 RTs auf Firmware 1.4 upgedated.... das hat ja ewig gedauert.

könnte man tunen - habe aber keine Zeit dafür. tut mir leid, wichtig ist mir, dass es stabil klappt - dauer 1-2min pro device?

ZitatZugegeben, mein zutrauen in diese Technik hier schwindet.... so eine Murkserei

schade, dass wir dir so viel verdruss bereiten.

kannst du einmal ordentliche Daten schicken oder sollen wir raten, was bei dir passiert?
logge die rohmessages, schcke eine Beschreibung, was du gemacht hast. Nur dann kann jemand feststellen, was du so treibst. Im Traumdeuten murkse ich noch viel mehr.

Hallo Martin,

mein System läuft wieder. Ich habe nach dem Fritzbox-update das Drama mit dem nicht mehr starten von FHEM erlebt, dann ein update der FHEM gemacht, mit dem Erfolg, das mein FHEM-System nicht funktioniert hat. Nicht mal desired temp ging durch. Keine Ahnung warum.
Dann habe ich FHEM neu aufgesetzt, alles eingelernt und eingerichtet, allerdings das update FHEM vergessen, also alles nochmal neu gemacht. So was braucht Zeit.
Am Ende hab ich nun die RT´s von firmware 1.0 bzw. 1.1 auf 1.4 upgedated, nochmal komplett FHEM installiert, update gemacht, alles neu eingelernt, dann gings bis auf 2 Regler. Die habe ich nochmal in FHEM gelöscht, die Regler selbst erst durch Batterie raus und dann noch per Software-Reset gelöscht (eigentlich würde ich sagen, das ist Blödsinn, aber der reine Batterie-Reset hat nicht gereicht), nochmal angelernt. Jetzt läuft es wieder.

(Ich bin ein Windows-Kind, deshalb installiere ich lieber neu als lang rumzumachen, weil Windows ja immer sinnlose Registry-Einträge nicht löscht, und dadurch das System leidet.....)

Aber es hat 4 Tage gekostet.....Dank starker Erkältung war meine Frustgrenze etwas tiefer gelegt (aber dadurch hatte ich die 4 Tage Zeit!)....

Ich habe allerdings noch  nie einen Save-Config gemacht. Den Knopf hab ich jetzt erst entdeckt, was wohl auch den Fehler erklärt, das die Konfiguration nach Shutdown weg war ::)

Gewundert hat mich nur, das manche Einstellungen gespeichert waren, manche nicht,,,,

Keinesfalls wollte ich Deine Arbeit hier angreifen, ich war und bin Dir für Deinen Support sehr, sehr dankbar.

Liebe Grüße
Andreas

Oh je,
Man sollte eben nicht voreilig aufgeben und sich immer bewusst sein, das das hier
Alle ganz freiwillig und neben dem normalen Job machen.
Son paar Tiefschläge gehören halt dazu ... Geht auch wieder aufwärts ...ging mir auch. ;)

Martin hat mir und sicher vielen vielen anderen schon sehr oft geholfen.

Also Kopf hoch .