Alle Homematic Heizkörper gleichzeitig stellen funktioniert nicht mehr

Begonnen von mkriegl, 28 November 2015, 13:37:53

Vorheriges Thema - Nächstes Thema

phil82

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.

martinp876

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

phil82

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.

martinp876

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.

baukater

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.
FB7490,Raspi 2/3,HM-Lan,Jeelink Classic (868),Logilink BT0015 Bluetooth 4.0, 2x mySmartUSB light,RS485USB , entities:272 device:14 channel:27 virtual:1, 6 x HM-LC-BL1-FM,4 x HM-LC-SW4-WM, 1 x HM-LC-SW2-FM,1 x Fensterkontakt,1 1x Türkontakt, 1 1x Bewegungsmelder, DECT-200,DECT100,6xAuthentic Xiaom

martinp876

Auf rollos sollte es nicht zutreffen. Das sind keine burst devices. Logge einmal.

martinp876

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

phil82

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.Ä.