Hallo,
das Problem besteht bei mir scheinbar schon seit einiger Zeit, da ich aber mit meiner Presence Funktion zu tun hatte ist es mir erst jetzt aufgefallen:
Wenn ich das Haus verlasse schalte ich alle Heizkörper auf "manual" und "night", entsprechend wenn ich wieder zurück bin auf "auto".
Beispiel:
set model=HM-TC-IT-WM-W-EU:FILTER=chanNo=02 controlMode auto
Ich habe mir das ganze mal genauer angeschaut und festgestellt, dass nur der letzte angesprochene Heizkörper (laut Log) auch geschalten wird bzw antwortet.
2015-11-28 13:15:31 CUL_HM Baden_Wandthermostat controlMode: set_manual
2015-11-28 13:15:31 CUL_HM Kochen_Wandthermostat controlMode: set_manual
2015-11-28 13:15:31 CUL_HM Schlafen_Wandthermostat controlMode: set_manual
2015-11-28 13:15:31 CUL_HM Wohnen_Wandthermostat controlMode: set_manual
2015-11-28 13:15:33 CUL_HM Wohnen_Wandthermostat controlMode: manual
2015-11-28 13:15:33 CUL_HM Wohnen_Wandthermostat desired-temp: 21.5
2015-11-28 13:16:47 CUL_HM Baden_Wandthermostat controlMode: set_auto
2015-11-28 13:16:47 CUL_HM Kochen_Wandthermostat controlMode: set_auto
2015-11-28 13:16:48 CUL_HM Schlafen_Wandthermostat controlMode: set_auto
2015-11-28 13:16:48 CUL_HM Wohnen_Wandthermostat controlMode: set_auto
2015-11-28 13:16:49 CUL_HM Wohnen_Wandthermostat controlMode: auto
2015-11-28 13:16:49 CUL_HM Wohnen_Wandthermostat desired-temp: 21.5
Auch nach längerem Warten passiert weiter nichts. Zum Spaß habe ich das Ganze auch mal in Tasker als Einzelaufrufe mit anderer Reihenfolge umgesetzt. Auch hier wird nur der letzte Befehl ausgeführt. Nur wenn ich eine Pause von 1s zwischen die Aufrufe setze funktioniert es einwandfrei.
Wurde hier etwas geändert bzw wie kann ich dem Ganzen Abhilfe schaffen, da dieser Aufruf früher immer einwandfrei funktioniert hat.
Aenderung ist mir nicht bekannt.
Ich habe nicht so viele tcs. Logge einmal rohmessages dazu.
Was sagt hminfo protoevents dazu? Da sollten fehler anstehen. Vorher loeschen, damit du dieaktuellwk fehler sehen kannst.
a
Danke für den Tipp. Den Logger kannte ich noch nicht. Werde ich morgen mal laufen lasse und posten
Also ich habe jetzt einmal "set model=HM-TC-IT-WM-W-EU:FILTER=chanNo=02 controlMode auto" ausgeführt und bekomme folgendes Bild - auch nach längerer Wartezeit (>30min). "Pending" sind die, die nicht schalten. Bei jeder Ausführung erhöht sich dieser wert auch um 1. Ein weiterer "Snd" findet wohl nicht statt wie beim Wohnzimmer Wandthermostat.
protoEvents done:
name :State |CmdPend |Snd |LastRcv |Resnd #CmdDel |ResndFail |Nack |IOerr
Baden_HR : Info_Cleared | - | - | 11-29 17:14:01| - # - | - | - | -
Baden_WT : pending | 1 CMDs pending | 1:11-29 17:15:29 | 11-29 17:14:39| - # - | - | - | -
Kochen_HR : Info_Cleared | - | - | 11-29 17:16:09| - # - | - | - | -
Kochen_WT : pending | 1 CMDs pending | 1:11-29 17:15:29 | 11-29 17:14:46| - # - | - | - | -
Schlafen_HR : Info_Cleared | - | - | 11-29 17:15:23| - # - | - | - | -
Schlafen_WT : pending | 1 CMDs pending | 1:11-29 17:15:29 | 11-29 17:15:35| - # - | - | - | -
Wohnen_HR1 : Info_Cleared | - | - | 11-29 17:14:30| - # - | - | - | -
Wohnen_HR2 : Info_Cleared | - | - | 11-29 17:15:39| - # - | - | - | -
Wohnen_WT : done | - | 2:11-29 17:15:30 | 11-29 17:15:59| - # - | - | - | -
================================================================================================================
sum 0 |3 |5 |99 |0 #0 |0 |0 |0
CUL_HM queue length:0
requests pending
----------------
autoReadReg :
recent : Kochen_WT
status request :
autoReadReg wakeup :
status request wakeup:
autoReadTest :
IODevs:CUL_0:Initialized condition:-
Wenn ich danach die fehlenden einzeln ansteuere funktioniert es dann ohne Probleme. Keine Ahnung was da los ist.
protoEvents done:
name :State |CmdPend |Snd |LastRcv |Resnd #CmdDel |ResndFail |Nack |IOerr
Baden_HR : Info_Cleared | - | - | 11-29 17:27:04| - # - | - | - | -
Baden_WT : done | - | 4:11-29 17:27:18 | 11-29 17:27:19| - # - | - | - | -
Kochen_HR : Info_Cleared | - | - | 11-29 17:28:51| - # - | - | - | -
Kochen_WT : done | - | 4:11-29 17:27:54 | 11-29 17:27:55| - # - | - | - | -
Schlafen_HR : Info_Cleared | - | - | 11-29 17:28:47| - # - | - | - | -
Schlafen_WT : done | - | 4:11-29 17:28:21 | 11-29 17:28:38| - # - | - | - | -
Wohnen_HR1 : Info_Cleared | - | - | 11-29 17:27:00| - # - | - | - | -
Wohnen_HR2 : Info_Cleared | - | - | 11-29 17:28:23| - # - | - | - | -
Wohnen_WT : done | - | 2:11-29 17:15:30 | 11-29 17:28:47| - # - | - | - | -
================================================================================================================
sum 0 |0 |14 |99 |0 #0 |0 |0 |0
CUL_HM queue length:0
requests pending
----------------
autoReadReg :
recent : Kochen_WT
status request :
autoReadReg wakeup :
status request wakeup:
autoReadTest :
IODevs:CUL_0:Initialized condition:-
ah - wichtiger Hinweis. Offensichtlich wird das Pending nicht korrekt erkannt. Es müsste für jeden TC ein burst gesendet werden.
mache ein List des hängenden Device
Ich verstehe nicht ganz was du meinst. Ich habe 4 Wandthermostate HM-TC-IT-WM-W-EU und 5 Heizungsregler HM-CC-RT-DN (zwei im Wohnzimmer). Thermostate sind gepaired mit CUL. Regler sind gepeered mit Thermostaten. Einzeln ansteuern macht keine Probleme, aber eben die Ansteuerung der Channel Gruppe.
Ich teste aktuell mal die Tasker App und habe dort direkt mal unterschiedliche Szenarien ausprobiert.
- set model=HM-TC-IT-WM-W-EU:FILTER=chanNo=02 controlMode auto: Problem wie schon beschrieben
- set Wandthermostate controlMode auto (alle 4 Thermostate einzeln hintereinander ohne Pause in anderer Reihenfolge als zuvor): gleiches Problem mit dem Unterschied dass immer das zuletzt aufgerufene Thermostat anspricht und die anderen im Pending bleiben (hab hier auch mehrere Kombinationen ausprobiert)
- set Wandthermostate controlMode auto (alle 4 Thermostate einzeln hintereinander mit 1s Pause zwischen den Aufrufen): jeders einzelne Thermostat wird angesprochen und antwortet auch bevor das nächste angesprochen wird
Mir kommt es eher so vor das beim ansprechen der Channel Gruppe irgendwas zu schnell läuft und nur an den letzten aufgerufenen gesendet wird und die zuvor irgendwie im pending landen
Wenn msg s in pending stehen bleiben haben wir bei burst ein Problem. Wann soll es weiter gehen.....
Die list und die messages sind interessant. Danach eine Idee wie man es zum laufen bekommt.
Ist msgrepeat aktiv?
Ich kenne mich ja nicht so gut aus, aber mir scheint es das er an alle 4 in so kurzem Zeitrahmen sendet, dass er die Antwort überhört und nur die Antwort vom letzten auswerten kann.
msgRepeat steht auf 1
Hier mal nur ein Auszug. Sollte eigentlich der Startpunkt beim Auslösen sein:
2015.11.29 22:24:13.777 4: CUL_send: CUL_0As 09 F5 B112 4D6178 335994
2015.11.29 22:24:13.830 4: CUL_send: CUL_0As 09 F8 B112 4D6178 3358D6
2015.11.29 22:24:13.878 4: CUL_send: CUL_0As 09 FB B112 4D6178 3358CD
2015.11.29 22:24:13.928 4: CUL_send: CUL_0As 09 FF B112 4D6178 335973
2015.11.29 22:24:15.942 4: CUL_Parse: CUL_0 A 0A FF 8002 335973 4D6178 0033 -48.5
2015.11.29 22:24:16.044 4: CUL_send: CUL_0As 0B 00 A011 4D6178 335973 8002
2015.11.29 22:24:18.373 4: CUL_Parse: CUL_0 A 0F 00 8002 335973 4D6178 01022B00270033 -48.5
2015.11.29 22:24:20.366 4: CUL_Parse: CUL_0 A 0F 65 8610 2E6CCD 000000 0A8CE68D004041 -41.5
2015.11.29 22:24:21.733 4: CUL_Parse: CUL_0 A 0C F6 8470 3358D6 000000 00D92937 -46.5
2015.11.29 22:24:23.467 4: CUL_Parse: CUL_0 A 0C FE 8470 335973 000000 00CB3534 -48
2015.11.29 22:24:28.424 4: CUL_Parse: CUL_0 A 0F 1C 8610 2E6C4C 000000 0A8CD98D004027 -54.5
2015.11.29 22:24:31.492 4: CUL_Parse: CUL_0 A 0F A8 8610 2EEFCC 000000 0A8CCF8D00002C -52
2015.11.29 22:25:01.322 4: CUL_Parse: CUL_0 A 0F 1D 8610 2E1C01 000000 0AACCB8C640035 -47.5
2015.11.29 22:25:18.534 4: CUL_Parse: CUL_0 A 0C F5 865A 335994 000000 8CE62F3E -43
2015.11.29 22:25:38.535 4: CUL_Parse: CUL_0 A 0C F5 8470 335994 000000 00E62F3E -43
2015.11.29 22:26:21.869 4: CUL_Parse: CUL_0 A 0F 66 8610 2E6CCD 000000 0A8CE68D004041 -41.5
2015.11.29 22:26:24.030 4: CUL_Parse: CUL_0 A 0C FB 865A 3358CD 000000 8CCF3432 -49
2015.11.29 22:26:39.237 4: CUL_Parse: CUL_0 A 0C F7 865A 3358D6 000000 8CD92937 -46.5
2015.11.29 22:26:44.031 4: CUL_Parse: CUL_0 A 0C FB 8470 3358CD 000000 00CF3432 -49
2015.11.29 22:26:55.922 4: CUL_Parse: CUL_0 A 0F F8 8610 2E6CC5 000000 0AACCB8C640036 -47
2015.11.29 22:26:56.746 4: CUL_Parse: CUL_0 A 0F A9 8610 2EEFCC 000000 0A8CCF8D00002D -51.5
2015.11.29 22:26:59.236 4: CUL_Parse: CUL_0 A 0C F7 8470 3358D6 000000 00D92937 -46.5
2015.11.29 22:26:59.726 4: CUL_Parse: CUL_0 A 0C FF 865A 335973 000000 ACCB3635 -47.5
2015.11.29 22:27:09.721 4: CUL_Parse: CUL_0 A 0E 04 8410 335973 000000 0BACCB090034 -48
2015.11.29 22:27:19.719 4: CUL_Parse: CUL_0 A 0C FF 8470 335973 000000 00CB3634 -48
2015.11.29 22:27:19.786 4: CUL_Parse: CUL_0 A 0C F6 865A 335994 000000 8CE62F3E -43
2015.11.29 22:27:29.678 4: CUL_Parse: CUL_0 A 0F 1D 8610 2E6C4C 000000 0A8CD98D004028 -54
Ja, die burst kommen zu schnell.
Welche cul fw hast du? Die empfohlene?
Ich weiß nicht was die empfohlene Firmware ist. Ist die Firmware VERSION V 1.61 CUL868? Irgendwann habe ich mal ein update gemacht. Weiß aber nicht mehr wann.
CUL Ist ein 3.4
http://forum.fhem.de/index.php/topic,31421.msg350833.html#new
Das ist meine Empfehlung.
Ob das besser geht kann ich nicht sagen, es gibt aber eine flowcontrol. Ich müsste es noch testen, schon lange her.
Fhem sollte min auf das ACK warten. Beim burst etwas länger.
hänge mich hier dran, da ich in die selbe "Falle" getappt bin. Wenn ich aus meiner 99_my* fünf Stück HM-TC-IT-WM-W-EU hintereinander ansprechen (set TC controlMode bzw. controlManu) will, geht nur einer der fünf TCs in den Burst und setzt den Befehl um - Bei den anderen vier TCs bleibt das cmd pending.
@martin: In Verwendung ist hierbei die empfohlene CUL FW (99.75) und 00_CUL.pm - ändert allerdings nichts am Verhalten. msgRepeat ist bei allen TCs auf 1 und burstAccess auf 1_auto. Du hattest hier schon eine Idee... was brauchst du zum verifizieren dieser?
Wenn du sie einzeln aufrufst probiere es mal mit einer Sekunde Pause dazwischen. So funktioniert es bei mir zumindest mit Tasker.
Danke an Martin. Bin leider noch nicht dazu gekommen mir das alles durch zu lesen und umzusetzen. Vielleicht bleibe ich auch bei der jetzigen Lösung
Ja, so "umgehe" ich das Problem, aber ...
Naja, (perl) sleep ist halt nicht mein Geschmack.
Muss ich einmal nachdenken. Die sequenzialisierung ist ein bisschen aufwändig. Man muss erkennen, dass gerade ein burst läuft, und wann er zu Ende ist. Und od noch einer ansteht......
Geht alles, dauert aber etwas.......
Hallo zusammen,
ich häng mich ebenfalls mal an das Thema an, da ich exrakt das gleich Problem hab.
Gibt es bereits eine Lösung?
Ich versuche aus meinem eigenen Perl-Unterprogramm mehrere Kommandos an insgesamt drei HM-TC-IT-WM-W-EU abzusetzen und auch bei mir gehen nur die "Kommandos" an das letzte WandTherostat durch.
Ich hab das Verhalten auch mal mit nem dummy und einem Notify nachgestellt:
define d1_night notify d1:night {\
fhem("set hwAzWandThermo_Climate controlMode night");;\
fhem("set hwSzWandThermo_Climate controlMode night");;\
}
- hwSzWandThermo wird geschaltet
- hwAzWandThermo steht auf CMDs_pending (auch noch nach 30 Minuten)
Wenn ich nicht die WandThermostate (HM-TC-IT-WM-W-EU), sondern die Heizungsthermostate (HM-CC-RT-DN) schalte, dann kommt das Kommando bei den Heizungsthermostaten korrekt an - aber auch hier nicht per Burst, sondern erst mit der nächsten Meldung vom Thermostat.
Martin hat irgendwo geschieben, dass die WandThermostate immer ein Burst brauchen. Das erklärt zumindest, dass die Kommandos an die WandThermostate nicht nach 3 Minuten abgeholt werden.
Der Workaround mit Sleep scheint bei mir nicht wirklich sauber zu funktionieren:
- Teilweise bleiben die WandThermostate auch weiterhin im CMDs_pending. (mal der erste, mal der zweite und mal der letzte)
- Teilweise gehen die WandThermostate in "MISSING ACT"
Außerdem "hängt" das TabletUI, da die Verarbeitung ja künstlich angehalten wird.
Ich verwende eine CUL V3-USB-Stick mit V 1.61 CUL868. Die 00_CUL.pm ist die Version aus der Standard-Auslieferung.
Für eine Lösung wäre ich dankbar.
Korrekt, der tc braucht burst.
Der rt kann burst.
Muss einmal pruefen was passiert, wenn am tc etwas s hief geht. Vorstellbar, dass es dann haengen bleibt, da ich keinen timer habe.....
Logge es einmal, immer gut
Ich hab das ganze mal geloggt (Ich hoffe, das war so richtig).
Getestet hab ich das mit nem einfachen Dummy und einem Notify, der zwei "Befehle" absetzt:
define d1_day notify d1:day {\
fhem("set hwAzWandThermo_Climate controlMode day");;\
fhem("set hwSzWandThermo_Climate controlMode day");;\
}
Log:
2016.03.26 13:30:30.483 4: CUL_Parse: hwCulHM A 13 0E 8670 37473C 000000 00A1300382C05B0E284304 -72
2016.03.26 13:30:43.170 4: CUL_Parse: hwCulHM A 0C A3 8470 3F1B05 000000 00D0310B -68.5
2016.03.26 13:31:05.569 4: CUL_send: hwCulHMAs 09 23 B112 54F82C 4331C9
2016.03.26 13:31:05.598 4: CUL_send: hwCulHMAs 09 CC B112 54F82C 433424
2016.03.26 13:31:06.452 4: CUL_Parse: hwCulHM A 0A CC 8002 433424 54F82C 0020 -58
2016.03.26 13:31:06.553 4: CUL_send: hwCulHMAs 0B CD A011 54F82C 433424 8402
2016.03.26 13:31:06.716 4: CUL_Parse: hwCulHM A 0F CD 8002 433424 54F82C 01022610330020 -58
2016.03.26 13:31:15.964 4: CUL_Parse: hwCulHM A 0C BF 8670 289D42 000000 00AE3BD8 -94
2016.03.26 13:31:34.437 4: CUL_Parse: hwCulHM A 0C CC 865A 433424 000000 98B73520 -58
2016.03.26 13:31:44.439 4: CUL_Parse: hwCulHM A 0E 2B 8410 433424 000000 0B98B70E0020 -58
2016.03.26 13:31:47.922 4: CUL_Parse: hwCulHM A 0F A1 8610 36BA88 000000 0AA0D00E000046 -39
2016.03.26 13:31:52.904 4: CUL_Parse: hwCulHM A 0F 1C 8610 42CB93 000000 0A98B70F00001E -59
2016.03.26 13:31:53.006 4: CUL_send: hwCulHMAs 09 1C A112 54F82C 42CB93
2016.03.26 13:31:53.021 4: CUL_send: hwCulHMAs 0B 1D A011 54F82C 42CB93 8402
2016.03.26 13:31:53.163 4: CUL_Parse: hwCulHM A 0A 1C 8002 42CB93 54F82C 001E -59
2016.03.26 13:31:54.437 4: CUL_Parse: hwCulHM A 0C CC 8470 433424 000000 00B73520 -58
2016.03.26 13:31:55.748 4: CUL_send: hwCulHMAs 09 1D B112 54F82C 42CB93
2016.03.26 13:31:56.257 4: CUL_Parse: hwCulHM A 0A 1D 8002 42CB93 54F82C 001D -59.5
2016.03.26 13:31:56.359 4: CUL_send: hwCulHMAs 0B 1D A011 54F82C 42CB93 8402
2016.03.26 13:31:56.521 4: CUL_Parse: hwCulHM A 0F 1D 8002 42CB93 54F82C 0104260038001D -59.5
2016.03.26 13:32:11.016 4: CUL_Parse: hwCulHM A 0F 60 8610 302A7A 000000 0AA0D00E000025 -55.5
2016.03.26 13:32:30.077 4: CUL_Parse: hwCulHM A 0F 84 8610 38E336 000000 0A88B80E00001B -60.5
2016.03.26 13:32:30.178 4: CUL_send: hwCulHMAs 09 84 A112 54F82C 38E336
2016.03.26 13:32:30.194 4: CUL_send: hwCulHMAs 0B 85 A011 54F82C 38E336 8402
2016.03.26 13:32:30.336 4: CUL_Parse: hwCulHM A 0A 84 8002 38E336 54F82C 001A -61
2016.03.26 13:32:34.201 4: CUL_send: hwCulHMAs 09 85 B112 54F82C 38E336
2016.03.26 13:32:34.721 4: CUL_Parse: hwCulHM A 0A 85 8002 38E336 54F82C 0019 -61.5
2016.03.26 13:32:34.823 4: CUL_send: hwCulHMAs 0B 85 A011 54F82C 38E336 8402
2016.03.26 13:32:34.985 4: CUL_Parse: hwCulHM A 0F 85 8002 38E336 54F82C 01042910390019 -61.5
2016.03.26 13:32:38.241 4: CUL_Parse: hwCulHM A 0F D8 8610 38EECA 000000 0AA0D00E000030 -50
2016.03.26 13:32:41.921 4: CUL_Parse: hwCulHM A 0C A4 865A 3F1B05 000000 A0D0310C -68
2016.03.26 13:32:50.632 4: CUL_Parse: hwCulHM A 0C 23 865A 4331C9 000000 88B83747 -38.5
2016.03.26 13:32:59.734 4: CUL_Parse: hwCulHM A 13 0F 8670 37473C 000000 00A4300382C024102B4501 -73.5
2016.03.26 13:33:01.921 4: CUL_Parse: hwCulHM A 0C A4 8470 3F1B05 000000 00D0310E -67
2016.03.26 13:33:10.632 4: CUL_Parse: hwCulHM A 0C 23 8470 4331C9 000000 00B83747 -38.5
2016.03.26 13:33:46.938 4: CUL_Parse: hwCulHM A 0C CD 865A 433424 000000 98B73520 -58
2016.03.26 13:33:56.941 4: CUL_Parse: hwCulHM A 0E 2C 8410 433424 000000 0B98B70F0020 -58
2016.03.26 13:34:02.905 4: CUL_Parse: hwCulHM A 0F 1D 8610 42CB93 000000 0A98B70F64001E -59
2016.03.26 13:34:06.938 4: CUL_Parse: hwCulHM A 0C CD 8470 433424 000000 00B73521 -57.5
2016.03.26 13:34:24.674 4: CUL_Parse: hwCulHM A 0F A2 8610 36BA88 000000 0AA0D00E000046 -39
Ich glaube die ersten beiden Nachrichten und auch die letzten Nachrichten gehören nicht mit dazu (ab ca. 2016-03-26 13:32:34 müsste das "ganze" eigentlich vorbei sein).
An dem Beispiel sind die folgenden Devices von mit beteiligt:
ID Gerät Status nach dem Auslösen: Done um:
42CB93 hwSzHeizung CMDs_pending CMDs_done um 2016-03-26 13:31:56
433424 hwSzWandThermo CMDs_done CMDs_done direkt um 2016-03-26 13:31:06
38E336 hwAzHeizung CMDs_pending CMDs_done um 2016-03-26 13:32:34
4331C9 hwAzWandThermo CMDs_pending CMDs_pending bleibt so
54F82C hwCulHM (CUL Stick)
Diese Devices tauchen ebenfalls im Log auf, sind für den Fall aber nicht relevant:
37473C Wetterstation
3F1B05 WandThermo im Wohnzimmer
289D42 ???? Nachbar??
36BA88 Heizung im Wohnzimmer
302A7A Heizung Links in der Küche
38EECA Heizung Rechts in der Küche
Ich hoffe das hilft, ich kann damit recht wenig anfangen.
Ich hab mir einen kleinen Workaround mit einer selbstgeschriebenen Perl-Funktion geschaffen:
- In einem Dummy-Reading schreibe ich die zu versendenden Befehle als String rein (mit # getrennt).
- Ein AT-Timmer mit 3 Sekunden Pause ruft meine eigene Perl-Funktion auf
- In der Perl-Funktion lese ich wieder das Dummy-Reading und arbeite die Befehle der Reihne nach ab. (Immer ein Befehl je Aufruf damit ich immer 3 Sekunde Pause hab).
Super toll ist die Lösung nicht, aber sie funktioniert.
Die beiden burst werden parallel gestartet. Das klappt nicht. Schon lange nicht mehr angesehen, muss ich testen.
Bei RTS ist das einfach. Da sollte man keinen burst nutzen und die Daten werden automatisch entzerrt.
Dauert aber etwas.
Da hänge ich mich doch auch mal dran. Habe das Problem schon lange mit dem Schalten mehrerer Jalousien. Hab das Problem auch nur umgangen, in dem ich die
Jalousien einzeln (bzw. 2 Stück) mit mind. 3 Sekunden Pause ansteuere.
Auf rollos sollte es nicht zutreffen. Das sind keine burst devices. Logge einmal.
ich habe es getestet - es wird bei mir sequenziell bearbeitet. Dann kommt es nicht zur Kollision.
probiere es in einem Kommando
define d1_day notify d1:day {\
fhem("set hw[AS]zWandThermo_Climate controlMode day");;\
}
habe noch einen test gemacht. klappt alles, wenn man nicht übertreibt.
erstens rate ich (strikt) das Attribut burstAccess abzuschalten. Es wird schon 2 min zeit haben die temp zu setzen. so schnell ist dein HK eh nicht, also was soll so etwas? Bei dir scheint es eingeschaltet - warum macht man so etwas?
zum anderen sollte man Q-länge auf "1" lassen. setzt man im IO Device. dann kommt es nicht zu den kollisionen.
Du nutzt eine CUL - sicher mit der HM-relevanten FW und dem passenden 00_CUL. Wenn nicht, sollten wir hier aufhören - der default ist ein Glücksspiel
Hallo zusammen,
die Rollos machen bei mir auch keine Probleme. Ich hab vier Stück und schalte die immer über ein "Kommande":
define viZentralRollosHinten dummy
attr viZentralRollosHinten alias Rolladen Hinten
attr viZentralRollosHinten setList state:slider,0,1,100,1 hoch runter stop
attr viZentralRollosHinten webCmd state:hoch:runter:stop
define viZentralRollosHinten_set notify viZentralRollosHinten:* set hwKuRolloLinks,hwKuRolloRechts,hwWzRolloTuer,hwWzRolloFenster $EVENT
Das funktioniert bei mir super. Alle Rolladen schalten direkt ohne merkliche Verzögerung o.Ä.