HmIP-BROLL Probleme mit der Firmware 1.6.2

[Harry-Homematic]

Auch wenn der Thread nun 10 Monate inaktiv ist - ich sehe das genau so.
Gleiches Verhalten beim IP wired Aktor.
Eine virtuelle Verknüpfung macht dann für mich überhaupt keinen Sinn. Werde mal sehen, ob man das dieses Jahr in Kassel mal adressieren kann.

[bumaas]

Werde mal sehen, ob man das dieses Jahr in Kassel mal adressieren kann.

Das wäre toll. Ich habe mir bisher die Zähne ausgebissen. Außer einem Ticket beim Support habe ich nichts erreicht.
Seitdem liegt HM-IP bei mir auf Eis.

Burkhard

[Matsch]

Ich kenne die Diskussion um den BROLL und Kanal 4 und weiß auch, dass es Befürworter und Gegner der aktuellen Lösung gibt, die Argumenten oft kaum zugänglich sind.

Ich habe mich überzeugen lassen, dass es kontraproduktiv wäre, wenn der Aktor selbstständig Kanal 4 nachziehen würde auf die Istposition.
Damit würde der Nutzer nämlich sehr stark eingeschränkt in seinen Einsatzmöglichkeiten, wie ich selbst erlebt habe.

In meinem Fall wollte ich einen Aussperrschutz per Direktverknüpfung realisieren. An sich kein Thema, nur, ich wollte auch die Möglichkeit haben, diese Sperre zeitweise gezielt außer Kraft setzen zu können. Das wiederum erforderte die Benutzung aller 3 Kanäle.

- ein Kanal für Sollwertvorgabe
- ein Kanal für Sperrwert vom Türgriffsensor
- ein Kanal für gezielte Unterdrückung des Sperrwertes

So müssen Sperrwert und Unterdrückungswert zuerst miteinander verknüpft werden, erst danach kann man das Ergebnis auf den Sollwert anwenden.
Auf Grund der Verknüpfungslogik der Kanäle (erst Kanal 4, dann 5, dann 6) muß der Unterdrückungswert in Kanal 4 geladen werden, der Sperrwert wie bisher in Kanal 5 und der Sollwert nun aber in Kanal 6!

Nicht auszudenken, wenn jetzt der Aktor selbständig den Istwert nach Kanal 4 übernehmen würde!
Alles klar?

Ihr sprecht hier ausschließlich vom einfachen Standardanwendungsfall, aber der Aktor soll ja noch mehr können als nur einfache Lösungen umsetzen.

[bumaas]

Ihr sprecht hier ausschließlich vom einfachen Standardanwendungsfall, aber der Aktor soll ja noch mehr können als nur einfache Lösungen umsetzen.

Nun gut, aber so ist er für "einfache" Anwendungen nicht brauchbar. Gibt es nicht sogar irgendwo einen Parameter, ob man die Kanäle getrennt sehen möchte oder nicht? Mir fällt nur gerade der Name nicht ein.
Beim einfachen Anwendungsfall sollte der Kanal nachgeführt werden.

Beim IP Dimmer ist übrigens genau das der Fall. Ich verstehe nicht, warum es bei dem einen Aktor geht und beim anderen nicht. Zudem ist das Verhalten in keinster Weise dokumentiert.

Leider ist auch mein Ticket noch nicht beantwortet worden. Von daher lasse ich weiterhin die Finger davon

[Matsch]

Gibt es nicht sogar irgendwo einen Parameter, ob man die Kanäle getrennt sehen möchte oder nicht? Mir fällt nur gerade der Name nicht ein.

Die Einstellung gibt's. Es bleibt aber nur eine andere Anzeigeoberfläche. Im Hintergrund funktioniert der Aktor davon völlig unbeeindruckt wie vorher auch.

Von daher lasse ich weiterhin die Finger davon

Und warum? Man kann sich doch auch auf die Gegebenheiten einlassen statt rigoros abzulehnen?

[nimmnenkeks]

Habe am WE den HmIP-K-DRBLI4 in Betrieb genommen.
Dort sind nun die Kanalaktionen und auch die Anzeige der realen Behanghöhe geändert.

Bsp.
vChn1 30%
or
vChn2 20%
Kanal Status 30%

vChn1 15%
or
vChn2 18%
Kanal Status 18%

Denke mal, dass diese Änderung in eine kommende Firmware einfließen wird (war in vergangenen Changelogs glaube ich bereits angekündigt).
Leider kann man bei den Kanalaktionen nur vordefinierte Werte auswählen...


..

[elbast]

Hallo zusammen,

Ich habe gleiches Problem mit dem Kanal 4 der HmIP-FROLL. Dabei arbeite ich mit einer Direktverbindung zu HmIP-RC8 und einer aktuellen Rasperrymatic.

Tasten der RC8 sind einzeln mit Kanal 4 verknüpft. Einige davon mit der Funktion "Position anfahren" mit der hinterlegten Erläuterung "Mit einem langen Tastendruck fährt die Markise / der Rollladen nur so lange wie die Taste gedrückt bleibt."
Kanal 5 ist mit dem Regensensor direkt verknüpft, Kanal 6 mit dem Windsensor (SWO-PL). So soll über die Kanalverknüpfung (Verknüpfungsregel ODER) gewährleistet sein, dass bei Regen oder stärkerem Wind die Markise für 30 Minuten eingefahren wird und anschliessend wieder in die ursprüngliche Position (Maßgebend Kanal 4, weil 5 & 6 sind wieder 0%) zurück fährt. Genau hier macht sich dann jedoch nachfolgender Fehler dramatisch bemerkbar!

FEHLER:
Bediene ich die FROLL über die RC8 (insbesondere bei langem Tastendruck, Rest noch nicht ausführlich getestet), so wird bei x-beliebiger Position die Taste losgelassen, die Markise bleibt stehen, Kanal 3 zeigt passenden Wert an, Kanal 4 jedoch 0% oder 100% (abhängig von der Fahrtrichtung). Das macht sich dann bemerkbar, wenn die Markise durch Wind oder Regen (Kanal 5 & 6) kurzzeitig begrenzt und eingefahren wird. Fällt die durch den Wettersensor verursachte Begrenzung weg, fährt die Markise ganz oder garnicht aus, weil Kanal 4 auf 0% oder 100%. Es kommt also dazu, dass die Markise eine Position hat, der mit keinem der drei virtuellen ODER-vernüpften Kanäle übereinstimmt.

Das finde ich äußerst ärgerlich (weil unzuverlässig) und auch gefährlich, wenn z.B. die Markise per FB nicht voll ausgefahren wird, weil dort ein Hindernis (z.B. ein Sonnenschirm) steht, nach der Wetter-Begrenzung jedoch voll ausgefahren wird.

Ich bin erschrocken, dass dieses Problem schon länger besteht, eq3 aber scheinbar nicht reagiert. Denn gerade für diese Automatisierung sind die Kanäle doch gedacht. Es kommt also dazu, dass die Markise einen Wert annimmt, der mit keinem der drei virtuellen ODER-vernüpften Kanäle übereinstimmt.

Gibt es da aktuelle Kommunikation mit eq3 (oder Jens)? Andernfalls möchte ich da noch mal zeitnah intervenieren.

Gruß

[Matsch]

Ich bin erschrocken, dass dieses Problem schon länger besteht, eq3 aber scheinbar nicht reagiert. Denn gerade für diese Automatisierung sind die Kanäle doch gedacht.

Dir gehts darum, dass der Kanal, der von den Wippen bedient wird, in diesem Fall nach Fahrtabbruch (Stopp) den dazugehörigen Sollwert annimmt?
Wie soll das gehen? Schließlich müßte das ja mit allen 3 Kanälen möglich sein, denn jeder Kanal kann für die Wippen benutzt werden.
Ich benutze z.B. den Kanal 6 wegen der logischen Verknüpfungsreihenfolge K4 -> K5 -> K6 als Wippeneingang.
Dann müßte der Aktor immer den zugehörigen Kanal behandeln - und niemals stur Kanal 4! Ich weiß nicht, ob das so ohne weiteres und überhaupt möglich wäre.

D.h. es wäre akzeptabel, nach einem manuellen Stopp den auslösenden Kanal (also derjenige, der mit den Wippen verknüpft ist), auf die aktuelle Istposition zu setzen (so als sei es seine Zielposition gewesen), wenn es möglich und gesichert ist, dass dies sowohl mit Kanal 4 oder 5 oder 6 genauso funktioniert.
Aber ist so eine Umsetzung technisch überhaupt möglich?

[elbast]

Dir gehts darum, dass der Kanal, der von den Wippen bedient wird, in diesem Fall nach Fahrtabbruch (Stopp) den dazugehörigen Sollwert annimmt?
Wie soll das gehen? Schließlich müßte das ja mit allen 3 Kanälen möglich sein, denn jeder Kanal kann für die Wippen benutzt werden.
Ich benutze z.B. den Kanal 6 wegen der logischen Verknüpfungsreihenfolge K4 -> K5 -> K6 als Wippeneingang.
Dann müßte der Aktor immer den zugehörigen Kanal behandeln - und niemals stur Kanal 4! Ich weiß nicht, ob das so ohne weiteres und überhaupt möglich wäre.

Nein, Wippen habe ich nicht angeschlossen. Bediene (aktuell) nur per HmIP-RC8 mit Direktverbindungen (selten via GUI).
Aber wie Du schon andeutest: wenn die Verknüpungsregel aller drei Kanäle ODER ist und alle drei Kanäle nicht dem entsprechen, wie die Markise steht, die drei Kanäle also scheinbar in dem Moment nicht beachtet werden, dann ist da meiner Ansicht nach etwas schief programmiert

D.h. es wäre akzeptabel, nach einem manuellen Stopp den auslösenden Kanal (also derjenige, der mit den Wippen verknüpft ist), auf die aktuelle Istposition zu setzen (so als sei es seine Zielposition gewesen), wenn es möglich und gesichert ist, dass dies sowohl mit Kanal 4 oder 5 oder 6 genauso funktioniert.
Aber ist so eine Umsetzung technisch überhaupt möglich?

Genau, die RC8 Fernbedienung ist direkt mit dem Kanal 4 der FROLL verknüpft. Hört der lange Tastendruck auf, sollte Kanal 4 (oder der jeweils letzte aktive Kanal) auch die neue Position übernehmen und nicht einfach bis zur Endposition (0% oder 100%) weiterlaufen.

[Matsch]

Hört der lange Tastendruck auf, sollte Kanal 4 (oder der jeweils letzte aktive Kanal) auch die neue Position übernehmen und nicht einfach bis zur Endposition (0% oder 100%) weiterlaufen.

Nun, du skizzierst ja gleich selbst, wie komplex und nahezu unlösbar das Problem ist. Ich bin ja nur davon ausgegangen, dass die Wippe eines BROLL verknüpft ist. Aber das ist ja wieder viel zu einseitig gesehen. Du benutzt z.B. eine Fernbedienung als Quelle.
Woher sollte der Aktor denn nun wissen, bei welchem Ereignis nun der Istwert übernommen werden soll und wann nicht? Schließlich dürfen keine Kanäle, die z.B. als Sperre oder Begrenzung funktionieren, mit dem Istwert überschrieben werden!
Ich glaube, das ist nicht händelbar.