HM-CC-RT-DN Wochenplan Senden unzuverlässig

[greuff]

Hallo,

ich hoffe es kann mir hier jemand weiterhelfen Ich habe auf einem Raspberry Pi mit USB-CUL FHEM 5.6.8674 laufen. In meinem Haus gibt es u.a. 11 HM-CC-RT-DN Funkheizkörperthermostate. Ich sende an diese FHTs Wochenpläne aus, mit "set [device] tempListMon (prep bzw. exec)" für alle Wochentage. Das geht ein paar Tage lang gut, dann auf einmal bleiben die Kommandos "stecken", soll heißen, ich bekomme CMDs_Pending und das wird nie fertig. Ein getConfig funktioniert dann genauso wenig wie ein burstXmit, da erscheint dann immer nur "Processing..." und dann wieder "Pending". Im Logfile sehe ich (trotz verbose 4) nichts auffälliges.

Hier ein HM-Sniff im steckengebliebenen Zustand:

Code Auswählen Erweitern


2015.09.25 10:03:06.699 4: CUL_Parse: CUL_HM A 0F 0F 8610 33B24B 000000 0A88E311000010 -66
2015.09.25 10:03:06.804 4: CUL_send:  CUL_HMAs 09 10 A112 CAFFEE 33B24B
2015.09.25 10:03:07.002 4: CUL_Parse: CUL_HM A 0A 10 8002 33B24B CAFFEE 0010 -66
2015.09.25 10:03:07.106 4: CUL_send:  CUL_HMAs 10 11 A001 CAFFEE 33B24B 00050000000007
2015.09.25 10:03:07.268 4: CUL_Parse: CUL_HM A 0A 11 8002 33B24B CAFFEE 000F -66.5
2015.09.25 10:03:07.372 4: CUL_send:  CUL_HMAs 19 12 A001 CAFFEE 33B24B 0008144515202E452F20484549206245
2015.09.25 10:03:07.533 4: CUL_Parse: CUL_HM A 0A 12 8002 33B24B CAFFEE 0010 -66
2015.09.25 10:03:07.637 4: CUL_send:  CUL_HMAs 19 13 A001 CAFFEE 33B24B 000863207C457D2096459720B045B120
2015.09.25 10:03:07.799 4: CUL_Parse: CUL_HM A 0A 13 8002 33B24B CAFFEE 000F -66.5
2015.09.25 10:03:07.904 4: CUL_send:  CUL_HMAs 0B 14 A001 CAFFEE 33B24B 0006
2015.09.25 10:03:08.064 4: CUL_Parse: CUL_HM A 0A 14 8002 33B24B CAFFEE 0010 -66
2015.09.25 10:03:08.168 4: CUL_send:  CUL_HMAs 10 15 A001 CAFFEE 33B24B 00050000000007


Und hier, nach einem Reboot, funktioniert alles wieder (anderer FHT, aber selbes Phänomen), die Abfolge wird mit "CMDs_done" quittiert:

Code Auswählen Erweitern


2015.09.25 10:14:45.387 4: CUL_Parse: CUL_HM A 0F 1C 8610 336736 000000 0A88EB11000022 -57
2015.09.25 10:14:45.492 4: CUL_send:  CUL_HMAs 09 1D A112 CAFFEE 336736
2015.09.25 10:14:45.716 4: CUL_Parse: CUL_HM A 0A 1D 8002 336736 CAFFEE 0023 -56.5
2015.09.25 10:14:45.820 4: CUL_send:  CUL_HMAs 10 1E A001 CAFFEE 336736 00050000000007
2015.09.25 10:14:45.983 4: CUL_Parse: CUL_HM A 0A 1E 8002 336736 CAFFEE 0022 -57
2015.09.25 10:14:46.090 4: CUL_send:  CUL_HMAs 19 1F A001 CAFFEE 336736 00081456157216451708185719202E56
2015.09.25 10:14:46.252 4: CUL_Parse: CUL_HM A 0A 1F 8002 336736 CAFFEE 0023 -56.5
2015.09.25 10:14:46.357 4: CUL_send:  CUL_HMAs 19 20 A001 CAFFEE 336736 00082F72304531083257332048564972
2015.09.25 10:14:46.520 4: CUL_Parse: CUL_HM A 0A 20 8002 336736 CAFFEE 0023 -56.5
2015.09.25 10:14:46.624 4: CUL_send:  CUL_HMAs 19 21 A001 CAFFEE 336736 00084A454B084C574D20625663726445
2015.09.25 10:14:46.788 4: CUL_Parse: CUL_HM A 0A 21 8002 336736 CAFFEE 0022 -57
2015.09.25 10:14:46.893 4: CUL_send:  CUL_HMAs 19 22 A001 CAFFEE 336736 00086508665767207C567D727E457F08
2015.09.25 10:14:47.055 4: CUL_Parse: CUL_HM A 0A 22 8002 336736 CAFFEE 0023 -56.5
2015.09.25 10:14:47.160 4: CUL_send:  CUL_HMAs 19 23 A001 CAFFEE 336736 00088057812096569772984599089A57
2015.09.25 10:14:47.321 4: CUL_Parse: CUL_HM A 0A 23 8002 336736 CAFFEE 0022 -57
2015.09.25 10:14:47.426 4: CUL_send:  CUL_HMAs 19 24 A001 CAFFEE 336736 00089B20B056B172B245B308B457B520
2015.09.25 10:14:47.609 4: CUL_Parse: CUL_HM A 0A 24 8002 336736 CAFFEE 0022 -57
2015.09.25 10:14:47.714 4: CUL_send:  CUL_HMAs 0B 25 A001 CAFFEE 336736 0006
2015.09.25 10:14:47.877 4: CUL_Parse: CUL_HM A 0A 25 8002 336736 CAFFEE 0023 -56.5


Wird daraus jemand schlau? Ich befürchte ja, dass mich da die 1%-Regel beißt.

Danke & lg

[martinp876]

Scheint nicht die timing angepasste cul zu sein.
Bitte für hm die timing Adaptionen durchführen wie schon so oft beschrieben. Ohne die ist hm in fhem eine Lotterie.

[greuff]

Hallo Martin,

danke, handelt es sich um diese alternative Firmware? https://github.com/heliflieger/a-culfw

Habe von diesen Timing-Problemen noch nie etwas gehört ("wie schon so oft beschrieben"), in der Doku die Einsteiger zu dem Thema zu Gesicht bekommen steht jedenfalls nichts davon. Obwohl ich auch selbst die ursprüngliche Firmware geflasht habe usw.

Hier wird auch von einem alternativen Modul für FHEM gesprochen, wo bekomme ich das her? http://forum.fhem.de/index.php/topic,41313.msg335477.html#msg335477

Würde mich über einen Stups in die richtige Richtung freuen. Von dort kann ich dann ja selber weiterlesen.

Danke & lg

[martinp876]

Das problem ist seit geraumer zeit bekannt.
M.W. ist die letzte Version in

http://forum.fhem.de/index.php/topic,24436.msg288122.html#msg288122

Ich teste es nur gelegentlich. Leider habe ich meine letzte getestete version nicht mehr. Werde bei Gelegenheit wieder eine testen und dann sichern.

[greuff]

Danke nochmals. Ich werde mir aber vermutlich eine HM-CFG-LAN zulegen, das scheint (von den Infos die ich jetzt gelesen habe) die problemfreiere Variante zu sein...

[martinp876]

Nutzt man hm ist hmlan eine gute Wahl. Einziges Problem: ein update der device ist nicht moeglich. Das kann ein hmusb und eine cul.
Ich habe alle updates mit der cul gemacht. Das geht mit der default fw. Sonst nutze ich hmlan, hmusb habe ich nicht.

Mein hmlan läuft zuverlässig.

[greuff]

Spitze, danke für die Bestätigung. Ich bin gerade am Firmware-Updaten aller meiner HM-CC-RT-DNs bevor morgen der CUL rausfliegt als Hardware-Backup stromlos zwischengelagert wird.