Jalousie / Markise

Ich betrieb o.g. Aktor problemlos an einem HmIP-Access Point.
Als manuelle Bedienung ist vorgegeben:

- kurzer Tastendruck: fährt bis in Endlage
- kurzer Tastendruck in Gegenrichtung: Stopp

Das funktionierte auch so.

Nun habe ich eine CCU3 eingesetzt und die Aktoren angelernt. Über die Zentrale lassen sich die Aktoren auch tadellos betreiben, nur manuell nicht mehr richtig. Nach einem kurzen Tastendruck fahren sie in die Endlage und lassen sich auf keine Weise mehr während der Fahrt stoppen. Das ist bei allen Aktoren nun so.

Melde ich sie aus der Zentrale ab und setze sie wieder in den Werkszustand zurück, geht wieder alles.

Es muß mit der Anmeldung an der CCU3 zusammenhängen, am Access Point geht es ja auch.

Nachdem ich ja probeweise einen der Aktoren abgemeldet und rückgesetzt hatte, habe ich ihn ein zweites Mal angemeldet an der CCU3. Plötzlich funktioniert auch die manuelle Bedienung wieder normal. Das gleiche Spiel auch an den anderen Aktoren.

Wie kann es sein, dass ALLE erstmalig angemeldeten Aktoren das gleiche Fehlverhalten zeigten und ALLE nach der zweiten Anmeldung korrekt funktionieren?

Zu früh gefreut.
Nachdem ich ein bißchen Programm ausprobiert habe, wieder das Gleiche: Keine Wirkung der Tasten am Aktor mehr zum Stoppen!
Ich kann aber auch alle Programme deaktivieren, es bleibt dabei.

Manchmal startet der Antrieb noch nicht mal beim Drücken des Tasters. Die Wippe scheint nur noch zufällig zu funktionieren, wobei manchmal das Starten nicht funktioniert, oft aber das Stoppen nicht, manchmal geht aber auch das Stoppen.

Wie gesagt, am Access Point funktionierte das alles prima - trotz vieler Automatisierungsroutinen.
Über die Neo-App funktioniert aber alles reibungslos. Aber da gibt es ja auch einen separaten Stopp-Befehl, da wird zum Stoppen ja nicht die Gegenrichtungstaste benutzt.

So, jetzt weiß ich mehr über die Ursache. Vielleicht begehe ich ja auch nur einen Anfängerfehler.

Mein Ansinnen:
Ich möchte im Programm in einer Wenn-Bedingung auswerten, ob jemand den Wippenschalter betätigt, also der Rollladen manuell bewegt wird.
Die Tasterkanäle 1 und 2 sind standardmäßig intern verknüpft mit dem Aktor Kanal 4.

Sobald ich nun im Programm in einer Wenn-Bedingung die Abfrage der Taster Kanal 1 und 2 einbaue (Tastendruck kurz/lang), arbeitet die Funktiomn der Wippe anschließend nicht mehr vollständig.

Was mache ich falsch oder wie kann ich ermitteln, dass der Rollladen manuell bewegt wird, entweder per Wippe oder per App?

Vielleicht würde es helden, wenn du das Programm genau hier darstellst

Eigentlich ein ganz einfaches Programm. Es soll erkennen, wenn jemand den Rollladen außerhalb der automatischen Programmroutinen bewegt. Dann soll ein Flag (Systemvariable kennzeichnet Automatikbetrieb) gelöscht werden.
Das Problem verursachen die Abfragen des Aktors auf Tastendruck im zweiten Teil der WENN-Bedingung.
Solange ich diesen ODER-Block nicht einfüge und der Aktor vorher auf Werkseinstellungen zurückgesetzt war, funktioniert auch die Steuerung per Wippe.
Sobald ich jedoch diese Tastenabfrage ergänze, funktioniert die Wippe auf dem Aktor nicht mehr richtig. Irgendwie scheint dadurch die interne Verknüpfung von Tasterkanal zum Aktor gestört.
Es hilft auch kein Löschen der Programmzeilen oder des ganzen Programms, bislang hilft nach meiner Erkenntnis nur das Löschen der Abfrage und das anschließende Rücksetzen des Aktors.

Nur zur Info:

Der Kundendienst von eQ-3 hat nach Prüfung das Problem an die Entwicklung weitergegeben, scheint also doch ein Bug zu sein.

Hallo Matsch2,

ich weiß nicht ob es heute immer noch so gelten soll: zu früheren Zeiten der CCU1/2 sollte in der ersten "Wenn..."-Bedingung nicht "...nur Prüfen" stehen. Da wurden die Programme nicht oder nicht richtig ausgeführt. Das habe ich aber lange Zeit nicht überprüft.

Gruß

Nach mehreren Wochen noch immer keine Stellungnahme von eQ-3! :o

Noch folgende Erkenntnisse:

Als ich die HmIP-BROLL das erste Mal in der CCU3 angelernt habe, wurden sofort ohne mein Zutun für jedes Gerät automatisch zwei Direktverknüpfungen angelegt. Die Kanäle 1 und 2 werden mit Kanal 4 des gleichen Gerätes verbunden und als "Interne Verknüpfung" benannt. Das gleiche passiert übrigens auch beim Anlernen eines Dimmaktors HmIP-BDT.

Nachdem ich nun das o.g. Problem hatte und ich zur Behebung der Auswirkung die Geräte wieder abgemeldet, zurückgesetzt und erneut angemeldet hatte, wird eine solche automatische Verknüpfung nicht wieder angelegt! Wieso nur beim allerersten Anlernen?

Weiter kann ich feststellen, wenn ich mir die Verknüpfungen durch "Bearbeiten" mal anschaue, dass dann im Dimmaktor je ein konkretes plausibles Profil pro Verknüpfung eingetragen ist, bei den Rollladenaktoren aber lediglich "Unbekanntes Profil". Liegt da der Hase im Pfeffer?

Hallo Matsch2,

nachdem Anlernen..egal wann..sollte vorzugsweise die CCU2/CCU3 nochmals kurz vom Netz getrennt werden. Dieser Hinweis erfolgt im allgemeinen auch beim Software/changelog.
So kann es bei einigen HmIP-Schaltaktoren durchaus vorkommen, dass nicht alle zur Verfügung stehenden Kanäle im Gerätemenü aufgeführt werden. Sinnvoll immer...Abmelden --> Browser cache leere --> CCU2/CCU3 neu starten.
Den von Dir beschriebenen Fehler kann ich nicht nachvollziehen. Eine direkte Abfrage der Tasten würde ich vorzugsweise über ein script lösen...auslösende Tastendruck TA1 bzw.TA2 kurz/lang.

Gruß elkotek

Genau darum geht's ja - siehe Anfang und siehe screenshot meines Programms!
Sobald ich eine Abfrage der Tasterkanäle im Programm einbaue, funktioniert die Wippe bei manueller Betätigung dauerhaft nicht mehr! Erst nach Geräteentfernen, Rücksetzen und Neuanlernen geht's wieder - wenn ich die Abfrage im Programm wieder vorher entfernt habe. Das ist 100%-ig reproduzierbar, bei allen 5 Aktoren.
Irgendetwas in der Konfiguration der Kommunikation wird dadurch irreversibel verändert.

Ich hab's noch nicht über eine Scriptabfrage probiert, aber sollte da wirklich ein Unterschied zur Abfrage im "normalen" Programm bestehen? Und wenn, dann ist auch das ein Bug.

Aber hast du denn eine Erklärung dafür, dass automatisch solch eine direkte interne Verknüpfung eingerichtet wird und manchmal nicht? Und wozu? Man könnte denken, die Wippe hätte gar keine direkte Wirkung über die Hardware im Aktor, sondern nur über die softwaremäßige Verknüpfung wie irgendein externes Gerät. Das passt aber auch nicht, denn mit und auch ohne eine solche Verknüpfung funktioniert die Wippe - solange ich sie nicht im Programm einbaue.

Hast Du evtl. noch den vereinfachten Modus eingestellt, denn dann gibt es in der WebUI-DV keine Möglichkeiten einen Profileinstellung/Empfänger durchzuführen.

Hallo Matsch2,

Deine Systemkonfiguration habe ich noch einmal nachgebildet. Unabhängig, ob die Tasten anderweitig in einem WebUI-Programm verwendet werden, tritt das von Dir beschriebene Fehlverhalten auf.

Systemkonfiguration:
*..CCU3/FW3.37.8
*..HmIP-BROLL/FW1.0.10
Folgende Einstellungen im Gerätemenü vom HmIP-BROLL:
Doppelklick Tastensperre: 0sec
Timeaout für langen Tastendruck: 3 sec
Langer Tastendruck: > 0,4 sec
Zum testen wurde die Fahrzeiten auf 10 sec eingestellt
WebUI-Direktverknüpfung: TA 1/TA2 mit der Profileinstellung: auf/hoch bzw. zu/ herunter.

Nun wurde die CCU3 vom Netz getrennt und die DV/HmIP-BROLL ..also ohne CCU3..getestet.

Ergebnis:
Die Funktion geht wie in der Bdienungsanleitung mit kurzen/langen Tastendruck beschrieben..allerdings mit einer leichten Verzögerung beim Tastendruck. Nach einem kurzen Tastendruck etwas warten..bis dass die Funktion greift. (Warum auch immer..)
Dies wurde nun ein paar mal durchgeführt..einmal mit kurzen Tastendruck einmal mit langen Tastendruck...dann war Schluß.. Der Aktor konnte erst wieder nach einer Netztrennung genutzt werden.
Dieser Fehler ist reproduzierbar und tritt eigentlich immer wieder auf, unabhängig ob eine WebUI-Programmverknüpfung mit Abfrage der Tasten (vorher) erfolgte. So wie ich sehe..tritt das Problem einfach irgendwann einmal auf, wenn die Taste TA1/TA2 einmal kurz/lang betätigt wurden.

Mit Deiner Feststellung hast Du also recht.

Ich werde an einem anderen Objekt einmal die Sache mit der CCU2 nachbilden..mal sehen ob diese das gleiche Problem hat.

Gruß elkotek

Da hast du ja noch einen anderen Aspekt ermittelt, der mir noch nicht bekannt war. Allerdings hatte bereits ein anderer User hier berichtet über das Nichtfunktionieren der Wippe.
Hier:

Ich kann es aber 100%-ig sofort und ohne jede Verzögerung provozieren durch die Abfrage eines Tasterkanals im Programm.

Ich gehe nun ohnehin davon aus, weil auch nach 6 Wochen Prüfung durch die Entwicklung von eQ-3 keine Stellungnahme erfolgt, dass es sich nicht einfach nur um einen Anfängerfehler handelt, sondern etwas dahinter steckt, das anscheinend auch die Entwickler bisher nicht erklären oder lösen konnten.

Erfreulich:

eQ-3 konnte die Fehler nachvollziehen. Ein Update für den HmIP-BROLL befindet sich im Test und wird demnächst veröffentlicht!

Hallo Matsch2,

ich Danke Dir für den Hinweis..schön zu wissen, dass wir keinem Phantom aufgesessen sind.
Was mich generell bei eQ-3 hier stört. Den HmIP-BROLL gibt es nun seit mehr als 1 Jahr. Es gibt keinerlei aussagefähige Beschreibungen hierzu..auch wieder nicht im WebUI-Handbuch (Ausgabe: Oktober 2018).

Vielleicht kann hier einmal "unser Lieferant" bei eQ-3 nachhaken. Aber mir ist schon die eQ-3 Philosophie klar..was nicht beschrieben ist, kann auch nicht falsch sein.

Gruß elkotek

Nur eine kurze Frage, wenn der Rolladenaktor an eine CCU2 angemeldet wird, ist mit dem gleichen Fehler zu rechnen? Möchte in Kürze 4 Stück einsetzen.

Na wenn du einen fehlerfreien Aktor haben willst, dann warte noch ein bißchen. Ich werde die neue Firmware, sobald sie da ist, ganz sicher testen und überprüfen, ob die erfolgreich ist.

So, die neue Firmware-Version für HmIP-BROLL 1.6.2 ist ausgerollt.
Ich update die Geräte gerade und werde anschließend ein paar Tests durchführen.

Sooo, das Update scheint zu funktionieren. Der oben beanstandete Fehler trat bisher noch nicht wieder auf.

Leider sind noch immer standardmäßig alle virtuellen Kanäle auf aktiv gesetzt, das kann zu ungewolltem und unverständlichen Verhalten führen.