HomeMatic-Forum / FHZ-Forum

Liebe Community,

über eine Direktverknüpfung von mehreren HmIP-BROLL mit einem virtuellen Taster wollte ich die Grundlage legen, um meine Rollläden etagenweise zu steuern.

Ich habe dafür das "zu / herunter"- bzw. "auf / zu"-Profil verwendet, jeweils mit Parametrisierung "dauerhaft" und "nicht aktiv".

Bei Betätigung des Tasters treten sporadisch (bei ca. der Hälfte aller Betätigungen) folgende Fehler auf (mal nur einer, mal beide):

1. Die Rollläden beginnen zwar herunterzufahren, aber stoppen teilweise an einer zufälligen Position, während andere ganz herunterfahren. Sie melden dann diese Position konsequenterweise aber auch korrekt zurück (z. B. Behanghöhe = 54 %). Es kann also nicht an einer falschen Kalibrierung liegen, sondern aus mir unerfindlichen Gründen scheint die CCU tatsächlich ein STOP-Signal zu senden. Dieses Phänomen tritt nie auf, wenn ich die Rollläden einzeln per WebUI ansteuere (mit Pfeil hoch / runter).

2. Ein bestimmter Rollladen wird manchmal gar nicht angesteuert. Per Einzelbefehl ist er aber immer erreichbar, hier gab es noch nie Probleme.

Dutycycleprobleme kann ich übrigens ausschließen.

Habt ihr eine Idee, woran das liegen könnte und wie man es beheben kann?

Viele Grüße

dunu

dunu hat geschrieben: ↑

14.05.2020, 07:53

....sondern aus mir unerfindlichen Gründen scheint die CCU tatsächlich ein STOP-Signal zu senden.

Was meinst Du mit "scheint"? Tut sie es oder tut sie es nicht? Woraus leitest Du das ab? Gibt es Programme, die sich gegen eine solche Bevormundung durch den Anwender "wehren"? Hast Du noch irgendwelche anderen Abhängigkeiten hinterlegt (Mitnahmeschaltungen)?

Im Normalfall sind bei einer Direktverknüpfung die Parameter in den Rollladenaktoren hinterlegt. Soll heißen, die Tasterbetätigung löst nur das Signal "ich wurde lang/kurz gedrückt!" aus und die direktverknüpften Geräte wissen dann, was sie tun sollen. Keiner weiß vom anderen. Und jeder macht sein Ding. Das legt wiederum den Verdacht nahe, dass die CCU ihre Finger im Spiel hat. Und da können es nur Programme/Scripte sein, die durch irgendwelche Statuswechsel getriggert werde und versuchen, dazwischenzufunken.

Ich habe jetzt meinen BROLL noch nicht genau angeschaut, aber meine klassischen Rollladenaktoren sind recht geschwätzig, wenn sie was tun. Sie quittieren nicht nur den Empfang eines Steuersignals, sondern senden zu Beginn der Fahrt ihre Ausgangsbehanghöhe und zum Ende dann noch mal die aktuelle. Kann sein, dass sich da was in die Quere kommt. Die Rückmeldungen sind aber eher nicht die Ursache. Eher irgenwelche Programme, die durch Behanghöhen getriggert werden, würde ich vermuten. Schau mal eventuell angelegte Beschattungsprogramme durch.

Gruß Xel66

Ich schließe die Existenz eines STOP-Signals rein daraus, dass die Rollläden nicht vollständig herunter-/rauffahren, obwohl sie das bei Einzelansteuerung immer tun.

Ich habe in meiner ganz neuen Neubau-Installation noch gar keine Programme, die auf Rollläden triggern oder diese auslösen, außer den genannten Direktverknüpfungen und Programme, die bei Hardware-Tastendrücken die virtuellen Taster auslösen. Und das Phänomen tritt ja auch nur sporadisch auf.

Was aber auch auffällt, ist, dass beim virtuellen Tastendruck die Rollläden teilweise stark asynchron (mehrere Sekunden Verzögerung) auslösen. Ich nehme an, hier sendet der virtuelle Taster seinen "ich wurde gedrückt"-Status mehrmals, wenn er von einzelnen Aktoren nicht bestätigt wurde. Könnte ein doppelter Empfang des "ich wurde gedrückt"-Signals durch einzelne Aktoren ggf. dieses Verhalten auslösen?

Viele Grüße!

Normalerweise wird bei Betätigung in Gegenrichtung gestoppt. Aber woher soll die mehrfache Aussendung kommen. Dann würde die CCU sich anders als Hardwaretaster verhalten. Durchaus möglich, dass sie von einem Rollladen keine Quittung erhalten hat und darum nochmals sendet. Zuzutrauen ist ihr das.

Ich hatte damals auch mal auf direktverknüpfte virtuelle Taster gesetzt, um Duty Cycle zu sparen. Allerdings habe ich Thermostate angesteuert. Der Einspareffekt war kaum feststellbar, da die CCU mehr kommuniziert als Hardwaretaster. Betreibe die Lösung trotzdem noch, weil sie so schön einfach in Programmen zu handhaben ist.

dunu hat geschrieben: ↑

14.05.2020, 11:57

Was aber auch auffällt, ist, dass beim virtuellen Tastendruck die Rollläden teilweise stark asynchron (mehrere Sekunden Verzögerung) auslösen.

Das würde ich auf die "listen before talk"-Funktion der IP-Aktoren schieben. Sie schauen nämlich vor der eigenen Aussendung, ob der Funkkanal belegt ist. Steuert man viele Aktoren gleichzeitig an, ist die Wahrscheinlichkeit sehr hoch, dass sie sich gegenseitig "blockieren". Vielleicht ist es wirklich eine gute Idee, die Aktoren in den Programmen direkt anzusteuern und auf die Direktverknüpfung zu verzichten.

Gruß Xel66

Xel66 hat geschrieben: ↑

14.05.2020, 12:16

...um Duty Cycle zu sparen. Allerdings habe ich Thermostate angesteuert. Der Einspareffekt war kaum feststellbar, ...

Wenn ich nicht falsch liege:
Es gab ihn nicht..
Erst wird ein Broadcast an alle gesendet.
Dann wird jeder einzelne Aktor angefunkt und der Befehl nochmal einzeln durchgegeben.
Machen Hardwaretaster nicht anders als die Virtuellen Tasten der CCU.

Sven_A hat geschrieben: ↑

14.05.2020, 15:59

Machen Hardwaretaster nicht anders als die Virtuellen Tasten der CCU.

Mag sein. Aber bei Hardwaretastern quittieren sie nur den Empfang und übertragen nachher ihren Status an die CCU. Unter dem Strich teilt sich aber die Funkzeit zwischen Taster und CCU auf. Bei der Benutzung der virtuellen Tasten geht aber die gesamte Kommunikation zulasten des CCU-DC. Darum kommt man bei einem Hardwaretaster etwas besser weg.

OT: Ist aber bei mir kein Problem. Mein DC ist bei weitem nicht ausgelastet. Im Normalfall liegt dieser um die 6% (aber immer einstellig). Nur wenn ich "intensiv" die Keymatic nutze, dann springt er über die 25%-Marke. Beim Verlassen des Hauses drücke ich einen "Leaving-Home"-Taster. Dann bekommt die Keymatic ihren zuletzt gespeicherten Zustand geschickt. Stände sie durch eine eventuelle manuelle Betätigung im Nirvana, würde sie auf den Zustand "offen" laufen. Im Normalfall piepst sie nur zwei Mal (für mich auch die Quittung, dass meine Tasterbetätigung angekommen ist). Nach dem Schließen der Haustür wird dann abgeschlossen und das Haus geht in den Abwesenheitsmodus. Hat man dann was vergessen und öffnet noch mal, dann läuft der Vorgang nochmalig ab und das treibt den DC (insgesamt vier Befehle an die Keymatic). Da diese signiert mit der CCU kommuniziert, kommt mächtiger Protokollüberhang zusammen. Aber das ist hier OT.

BTT: Grundsätzlich kommunizieren IP-Geräte auch mit Signatur (ist dort gar nicht abschaltbar). Aus diesem Grund sind die Funkverbindungen auch "länger" im Vergleich zu klassischem HM und belegen so länger den Kanal. Dazu kommt dann noch das "listen before talk" bei IP-Geräten. Das alles kann schon zu den beschriebenen Verzögerungen führen, besonders, wenn mehrere Aktoren quasi gleichzeitig angesprochen werden sollen. Ein Stop-Befehl durch die CCU ohne Veranlassung würde ich mal ausschließen. Das macht die im Allgemeinen nicht von allein, wenn es keine dementsprechenden Programme gibt.

Ich gehe daher von Funkkollisionen bei den BROLL als eigentliche Ursache aus. Wird wohl nichts weiter übrig bleiben, als seriell alle Rollladen durch ein Programm anzusteuern und auf die Ansteuerung durch eine Direktverknüpfung zu verzichten, obwohl dieses definitiv der galantere Weg ist. Meine Rollladen laufen nur in Abhängigkeit von Systemvariablen (drei pro Rollladen). Es gibt für jeden Rollladen nur ein einziges Programm mit direktem Zugriff auf den Aktor, welches den Rollladen auf die jeweilig in den Systemvariablen definierten Sollwerte fährt. Alle anderen Programme setzen nur die Systemvariablen (egal ob Lüfungsstellung, Beschattungsfunktion oder Zeitsteuerungen). Mag sich zwar kompliziert anhören, aber so können die Programme sich nicht gegenseitig beeinflussen. So ist es auch möglich, einen Rollladen direkt aus dem geschlossenen Zustand in die Beschattungsstellung zu fahren, wenn man später aufsteht und inzwischen Beschattungsbedarf besteht (bei einem Schichtler nichts ungewöhnliches und bei einem jugendlichen Nachwuchs auch nicht ). Das ganze Konstrukt habe ich an einem repräsentativen Beispiel neulich erst hier im Forum beschrieben.

Gruß Xel66

Xel66 hat geschrieben: ↑

14.05.2020, 17:25

Ich gehe daher von Funkkollisionen bei den BROLL als eigentliche Ursache aus. Wird wohl nichts weiter übrig bleiben, als seriell alle Rollladen durch ein Programm anzusteuern und auf die Ansteuerung durch eine Direktverknüpfung zu verzichten, obwohl dieses definitiv der galantere Weg ist.

Vielleicht bringt es was in den DV's mit Einschaltverzögerungen zu arbeiten. Wobei ich aber nicht weiß ob die Einschaltverzögerung im Aktor abläuft oder der Befehl verzögert gesendet wird.

Vor einiger Zeit gab es schon mal ähnliche Probleme wenn eine virtuelle Taste mit mehreren Aktoren verknüpft war. Da blockierte die CCU mehrere Sekunden quasi das ganze Funksystem. Das das jetzt mit dem Problem hier zusammenhängen könnte möchte ich aber nicht behaupten.
Hier mal der Link zum Thread: viewtopic.php?f=60&t=54169

Grüße
Baxxy

Baxxy hat geschrieben: ↑

14.05.2020, 17:44

Wobei ich aber nicht weiß ob die Einschaltverzögerung im Aktor abläuft oder der Befehl verzögert gesendet wird.

Wird im Aktor konfiguriert und sollte deshalb auch dort laufen. Der Taster sendet nur sein "Hallo, ich wurde kurz/lang gedrückt!" und die Aktoren quittieren den Empfang und tun dann, was in der Verknüpfung hinterlegt ist. Einschaltzeiten oder eben bei Rollladenaktoren die Dauer der Stellung ist im Aktor hinterlegt. Zumindest würde man dadurch Kollisionen durch Statusmeldungen der Aktoren zeitlich etwas entzerren.

Gruß Xel66