HmIP-BROLL Probleme mit der Firmware 1.6.2

HMIP Sender und Empfänger der Serie Homematic IP

Moderator: Co-Administratoren

elbast
Beiträge: 9
Registriert: 27.06.2020, 17:13
System: Alternative CCU (auf Basis OCCU)

Re: HmIP-BROLL Probleme mit der Firmware 1.6.2

Beitrag von elbast » 28.06.2020, 00:28

Dann ist mein Problem vielleicht noch nicht deutlich geworden.
Die RC8 Fernbedienung ist direktverknüpft mit dem Kanal 4 vom FROLL. Dabei löst ein kurzer Tastendruck die Funktion "Position anfahren" aus und ein langer Tastendruck verfährt die Makise so lange, bis die Taste los gelassen wird. Bei letzterem wird im Kanal 4 trotz eindeutiger Direkter Verknüpfung immer eine der Endpositionen (0% oder 100%) angezeigt, obwohl die Taste schon eher losgelassen wurde und die Markise in einer Zwischenposition stoppt. Der Kanal drei zeigt auch die korrekte Position an. Nur der Kanal, der mittels direkter Verknüpfung die Stellbefehle erhält, der speichert falsche Werte.

Matsch
Beiträge: 5359
Registriert: 30.05.2019, 11:37
System: Alternative CCU (auf Basis OCCU)
Wohnort: Chemnitz
Hat sich bedankt: 113 Mal
Danksagung erhalten: 722 Mal

Re: HmIP-BROLL Probleme mit der Firmware 1.6.2

Beitrag von Matsch » 28.06.2020, 10:08

elbast hat geschrieben:
28.06.2020, 00:28
Dann ist mein Problem vielleicht noch nicht deutlich geworden.
Doch, das ist es. Und ich habe nichts anders getan, als genau darauf zu antworten.
Der Kanal drei zeigt auch die korrekte Position an. Nur der Kanal, der mittels direkter Verknüpfung die Stellbefehle erhält, der speichert falsche Werte.
Nochmal: Die Werte weichen vom ISTWERT ab, sind aber eben nicht FALSCH! Ein Tastendruck funktioniert im Aktor nicht anders als jede andere Sollwertvorgabe.
Der Unterschied ist aber, dass der Taster/die Fernbedienung nicht wissen kann, wie lange der Kunde den Finger auf der Taste lassen wird und er deshalb keine konkrete Zielposition vorgeben kann. Damit er also zuverlässig auch mal bis zum Anschlag fahren kann, setzt der Tastendruck das Ziel auf 100% bzw. 0%. Es geht nicht anders, ansonsten müßte das ganze System HomeMatic komplett neu konzipiert werden - nicht nur BROLL/FROLL.

Nochmal: der Kanal 4 (oder welcher auch immer benutzt wird) ist der SOLLWERT - und der muß und kann nicht zwingend dem ISTWERT entsprechen, insbesondere nicht bei einem Fahrtabbruch, wie er mit dem zweiten kurzen Tastendruck oder dem Loslassen der langen Taste vorgenommen wird (Stopp-Befehl)!

Es mag ja sein, dass das von dir gewünschte Verhalten deinem aktuellen Anliegen dienlich wäre, aber die Entwickler blicken halt über den Tellerrand hinaus und wissen auch, dass sie mit so einer Maßnahme eine Menge anderer komplexer Anwendungen (für die ich dich oben sensibilisieren wollte) unmöglich machen würden.

Ja, das Verhalten ist in deinem konkreten Fall nicht so schön, aber ich sagte ja schon, dass es m.E. keine Lösung gibt, die in jedem Anwendungsfall perfekt funktionieren würde. Ein selbsttätiges Überschreiben eines Sollwertes mit der Istposition kann aber niemals eine Option sein. Aber anders käme der von dir gewünschte Zustand des Sollwertkanals ja nicht zustande.
Zuletzt geändert von Matsch am 28.06.2020, 11:28, insgesamt 1-mal geändert.

Xel66
Beiträge: 14085
Registriert: 08.05.2013, 23:33
System: Alternative CCU (auf Basis OCCU)
Wohnort: Nordwürttemberg
Hat sich bedankt: 580 Mal
Danksagung erhalten: 1492 Mal

Re: HmIP-BROLL Probleme mit der Firmware 1.6.2

Beitrag von Xel66 » 28.06.2020, 10:18

elbast hat geschrieben:
28.06.2020, 00:28
Dann ist mein Problem vielleicht noch nicht deutlich geworden.
Ja, ist es. Du hast die Anleitung bzw. die Funktion der virtuellen Kanäle nicht verstanden. Der Aktor bzw. die virtuellen Kanäle verhalten sich bestimmungsgemäß. Leider ist die Hersteller-Dokumentation sehr oberflächlich. Die virtuellen Kanäle können verschiedene Werte annehmen, die man untereinander verknüpfen kann. So ist eine Addition oder Multiplikation möglich, man kann sogar invertieren usw. Mit der Multiplikation könnte man sogar eine Öffnungsbegrenzung (Stichwort: Sonnenschirm) realisieren. Es gibt ein Erklärvideo zu den virtuellen Kanälen und auch eine PDF zum Download. Beides stammt von Vorträgen aus dem Usertreffen und erklärt die Möglichkeiten.

Gruß Xel66
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch

elbast
Beiträge: 9
Registriert: 27.06.2020, 17:13
System: Alternative CCU (auf Basis OCCU)

Re: HmIP-BROLL Probleme mit der Firmware 1.6.2

Beitrag von elbast » 28.06.2020, 16:42

Der Unterschied ist aber, dass der Taster/die Fernbedienung nicht wissen kann, wie lange der Kunde den Finger auf der Taste lassen wird und er deshalb keine konkrete Zielposition vorgeben kann. Damit er also zuverlässig auch mal bis zum Anschlag fahren kann, setzt der Tastendruck das Ziel auf 100% bzw. 0%.
Ok, leuchtet ein, dass der Kanal 4 mit der Vorgabe der jeweiligen Endposition die unbestimmt lange Fahrt durch beliebig langen Tastendruck zu ermöglichen.
Was spricht nun dagegen, zu prüfen, ob der neue Istwert bei STOP dem verursachenden Sollwert (hier Kanal 4) entspricht oder diesen ggf. anzupassen um die gewünschte/gewollte Position auch als Sollwert zu übernehmen und zu speichern (sofern aktuelle Position nicht durch Begrenzungsvorgabe eines anderen Kanals bedingt)? Denn schließlich ist die aktuelle Position (Istwert) ja die vom Nutzer gewollte Position (Sollwert) und nicht die Endposition).
Nochmal: der Kanal 4 (oder welcher auch immer benutzt wird) ist der SOLLWERT - und der muß und kann nicht zwingend dem ISTWERT entsprechen,
Verstehe ich z.B. im Verbindung mit einer Positionsbegrenzung durch einen anderen Kanal oder maximale Positionsvorgaben in den Geräteeinstellungen. Nicht jedoch bei manuellem Stopp-Befehl bei unbegrenzter Fahrt.
insbesondere nicht bei einem Fahrtabbruch, wie er mit dem zweiten kurzen Tastendruck oder dem Loslassen der langen Taste vorgenommen wird (Stopp-Befehl)!

Nun ja, als Anwender habe ich doch aber mit dem STOPP-Befehl die neue Position als SOLLWERT (auch für den Kanal) bestimmt und nicht nur eine Fahrt abgebrochen. Der Wert kann hier doch ganz unkritisch als bewusste Sollwertvorgabe angenommen und und in dem auslösenden Kanal übernommen werden. Die Endposition ist ja nicht der gewollte Sollwert, sonst hätte der Nutzer nicht gestoppt.
Es geht nicht anders, ansonsten müßte das ganze System HomeMatic komplett neu konzipiert werden - nicht nur BROLL/FROLL.
Hier reicht vielleicht mein Verständnis des System nicht aus (ich habe auch nicht alle Sensoren / Aktoren), aber mit meinem jetzigen Verständnis kann ich diese absolute Aussage nicht nachvollziehen. Es geht letztlich ja nur um die Sollwertübernahme und -Speicherung bei Stopp-Befehlen durch den Nutzer.
Es mag ja sein, dass das von dir gewünschte Verhalten deinem aktuellen Anliegen dienlich wäre, aber die Entwickler blicken halt über den Tellerrand hinaus und wissen auch, dass sie mit so einer Maßnahme eine Menge anderer komplexer Anwendungen (für die ich dich oben sensibilisieren wollte) unmöglich machen würden.
Mag gut sein. Mir fällt leider kein Beispiel ein, bei dem dieses Verhalten (Nutzer stellt Position ein, die nicht übernommen bzw. gespeichert wird und bei nächster Fahrt mit Endposition "überschrieben" wird) bei Markisen oder Rollos einen gewünschten Effekt mit sich bringt.
Ein selbsttätiges Überschreiben eines Sollwertes mit der Istposition kann aber niemals eine Option sein. Aber anders käme der von dir gewünschte Zustand des Sollwertkanals ja nicht zustande.
Warum kann das niemals eine Option sein? Das verstehe ich nicht. Hilf mir. Ich sehe die Istposition bei manuellem Stop als gewollte Sollposition. Der Nutzer hat ja nicht die Endposition gewollt und vorgegeben. Die Endposition ist nur als Hilfweg für die unbestimmte Fahrtdauer gewählt.
Möglich das dies ein spezieller Anwendungsfall ist, aber mir fällt kein Fall ein, in dem dies Verhalten Sinn ergibt. Welcher schwebt Dir vor?

elbast
Beiträge: 9
Registriert: 27.06.2020, 17:13
System: Alternative CCU (auf Basis OCCU)

Re: HmIP-BROLL Probleme mit der Firmware 1.6.2

Beitrag von elbast » 28.06.2020, 16:55

Xel66 hat geschrieben:
28.06.2020, 10:18
Ja, ist es. Du hast die Anleitung bzw. die Funktion der virtuellen Kanäle nicht verstanden. Der Aktor bzw. die virtuellen Kanäle verhalten sich bestimmungsgemäß. Leider ist die Hersteller-Dokumentation sehr oberflächlich.
Ja, leider nicht nur an dieser Stelle
Die virtuellen Kanäle können verschiedene Werte annehmen, die man untereinander verknüpfen kann. So ist eine Addition oder Multiplikation möglich, man kann sogar invertieren usw. Mit der Multiplikation könnte man sogar eine Öffnungsbegrenzung (Stichwort: Sonnenschirm) realisieren. Es gibt ein Erklärvideo zu den virtuellen Kanälen und auch eine PDF zum Download. Beides stammt von Vorträgen aus dem Usertreffen und erklärt die Möglichkeiten.
Nein, es Mangelt mir nicht am am Verständnis der logischen Verknüpfung der Kanäle. Aber Danke für deine Antwort.
Mit der logischen Verknüpfung hat mein 'Problem' nur am Rande etwas zu tun. Die Verknüpfung der Kanäle tut hier unkritisch das, was sie soll.

Mich stört oder ärgert es, dass ich über ein mit z.b. Kanal 4 direkt verknüpftes Gerät (Wippe, Fernbedienung, ...) eine beliebige Position anfahren kann, selbiger Kanal aber dabei eine Endposition speichert und nicht die vom Nutzer gewollt angefahren Position (die eigentlich zu übernehmende Sollposition). Ich finde auch keinen Fall, in dem dieser Effekt gewollt sein könnte und halte es deshalb für einen Fehler, lasse mich aber gerne mit Beispielen vom Gegenteil überzeugen.

Matsch
Beiträge: 5359
Registriert: 30.05.2019, 11:37
System: Alternative CCU (auf Basis OCCU)
Wohnort: Chemnitz
Hat sich bedankt: 113 Mal
Danksagung erhalten: 722 Mal

Re: HmIP-BROLL Probleme mit der Firmware 1.6.2

Beitrag von Matsch » 28.06.2020, 17:25

elbast hat geschrieben:
28.06.2020, 16:42
Ein selbsttätiges Überschreiben eines Sollwertes mit der Istposition kann aber niemals eine Option sein. Aber anders käme der von dir gewünschte Zustand des Sollwertkanals ja nicht zustande.
Warum kann das niemals eine Option sein? Das verstehe ich nicht. Hilf mir. Ich sehe die Istposition bei manuellem Stop als gewollte Sollposition. Der Nutzer hat ja nicht die Endposition gewollt und vorgegeben. Die Endposition ist nur als Hilfweg für die unbestimmte Fahrtdauer gewählt.
Zunächst einmal, weil man Soll- und Istwerte nicht miteinander mischt. Einen Sollwert intern mit dem Istwert zu überschreiben, ist grauslige Bastelei. Standardmäßig wird Kanal 4 sowohl für Vorgaben aus der CCU wie auch für die Steuerung mit Tastern benutzt. Was, wenn die Fahrt per Taster gestoppt wird und der Kanal 4 mit dem Istwert überschrieben wird, aber gleichzeitig die CCU einen neuen Sollwert sendet? Geht der dann verloren, weil er intern überschrieben wird?
Du siehst m.E. das ganze viel zu simpel, das Thema ist viel komplexer.

Ansonsten habe ich das oben schon beschrieben. Der Aktor arbeitet (wie alle Aktoren des Systems), indem er eine Sollposition bekommt, egal, ob von der CCU oder einer DV. Er kennt keine Unterschiede, ob der Auslöser nun eine direkte Vorgabe oder eine Taste war.
Woher sollte der Aktor denn wissen, in welchen Kanal er den Istwert nach einem Stopp schreiben soll? Auf den zuletzt benutzten Kanal?
Geht nicht, denn während der Fahrt kann sich ja einer der anderen Kanäle geändert haben, dann würde auf diesen geschrieben. Zudem könnten ja mehrere Tasten auf mehreren Kanälen Fahrtbeginn und -stopp auslösen (Bsp: Mit Kanal 4 ist die Wippe des BROLL verknüpft, mit Kanal 5 oder 6 eine Fernbedienung). Wer soll das noch zuordnen können? Muß dann der Sollwert aller Kanäle, an denen Tasten hängen, überschrieben werden? Oder nur der Kanal, der den Stopp auslöste? Letzteres macht auch keinen Sinn, denn dann wären ja die Werte der anderen Kanäle nach deiner Meinung auch wieder "falsch".

Ich benutze für solche Fälle ein kleines Programm in der CCU. Sobald die Sperre (z.B. Aussperrschutz) aufgehoben wird, triggert diese Änderung das Programm, das den Istwert ausliest und auf den benutzten Sollwertkanal kopiert. So bleibt der Aktor auf der aktuellen Position stehen.
Das ist prinzipiell das Gleiche, was du vom Aktor erwartest. Nur mit dem Unterschied, dass ich selbst es in der Hand habe und weiß, wann ich welchen Kanal womit beschreiben muß. Ich glaube nicht, dass der Aktor in den zahllosen unterschiedlichen Anwendungsvarianten das wirklich fehlerfrei leisten könnte. Die Variationsvielfalt ist sehr hoch.

Xel66
Beiträge: 14085
Registriert: 08.05.2013, 23:33
System: Alternative CCU (auf Basis OCCU)
Wohnort: Nordwürttemberg
Hat sich bedankt: 580 Mal
Danksagung erhalten: 1492 Mal

Re: HmIP-BROLL Probleme mit der Firmware 1.6.2

Beitrag von Xel66 » 28.06.2020, 18:26

elbast hat geschrieben:
28.06.2020, 16:55
Ich finde auch keinen Fall, in dem dieser Effekt gewollt sein könnte und halte es deshalb für einen Fehler, lasse mich aber gerne mit Beispielen vom Gegenteil überzeugen.
Du hast den Sinn der virtuellen Kanäle eben nicht erfasst. Mit diesen lassen sich für Direktverknüpfungen durch geschickte Kombinationen Zustände erreichen, die sonst eben nur in Programmen abzubilden wären. Mach es Dir einfach und lasse alle Deine Trigger auf den gleichen Kanal wirken, und Du hast nicht die beschriebene (Verständnis-)Problematik. Den Vorzug der virtuellen Kanäle habe ich erst auch recht spät schätzen gelernt. Mit denen kann man sich auseinandersetzen, wenn man das Grundsystem intus hat.

Gruß Xel66
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch

elbast
Beiträge: 9
Registriert: 27.06.2020, 17:13
System: Alternative CCU (auf Basis OCCU)

Re: HmIP-BROLL Probleme mit der Firmware 1.6.2

Beitrag von elbast » 28.06.2020, 18:58

Matsch hat geschrieben:
28.06.2020, 17:25
Zunächst einmal, weil man Soll- und Istwerte nicht miteinander mischt. Einen Sollwert intern mit dem Istwert zu überschreiben, ist grauslige Bastelei.

Natürlich kann und darf man einen Istwert in den Sollwert übernehmen. Wird hier ja auch irgendwo in der Regelung passieren. Andernfalls: warum fährt die Markise nach dem Stopp nicht weiter, wenn die drei virtuellen Kanäle eine andere Position vorgeben, der Istwert also von allen drei Sollwerten (nach Logik verknüpft nur noch ein gemeinsamer Sollwert) abweicht? Jede Regelung versucht den Istwert dem Sollwert anzugleichen. Also wird irgendwo mit dem Stop-Signal ja eh die Istposition als Sollwert übernommen.

Dass hier in den Sollwert (Kanal 4) eine Endposition eingetragen wird, obwohl das vom Nutzer nicht gewollt ist, halte ich für bzw. einen technisch unausgereiften Umweg, der wie anfangs beschrieben zu Problemen führen kann (Hindernis) und auch sonst (nach der Fahrt) keinen Sinn macht.
In diesem Fall übernimmt er ja auch nicht irgendeinen Istwert, sondern den eigentlich vom Nutzer angestrebten Sollwert.Ich kenne immer noch kein Beispiel, in dem es Sinn macht, die Endpositionen zu hinterlegen.
Zudem könnten ja mehrere Tasten auf mehreren Kanälen Fahrtbeginn und -stopp auslösen (Bsp: Mit Kanal 4 ist die Wippe des BROLL verknüpft, mit Kanal 5 oder 6 eine Fernbedienung). Wer soll das noch zuordnen können?
Muß dann der Sollwert aller Kanäle, an denen Tasten hängen, überschrieben werden? Oder nur der Kanal, der den Stopp auslöste? Letzteres macht auch keinen Sinn, denn dann wären ja die Werte der anderen Kanäle nach deiner Meinung auch wieder "falsch".
Ok, ... muss ich ne Nacht drüber schlafen. Danke für das Beispiel.
Ich benutze für solche Fälle ein kleines Programm in der CCU. Sobald die Sperre (z.B. Aussperrschutz) aufgehoben wird, triggert diese Änderung das Programm, das den Istwert ausliest und auf den benutzten Sollwertkanal kopiert.

Oh, das machst du weil...
weil man Soll- und Istwerte nicht miteinander mischt.
??? Sorry, aber da widerlegst Du doch selbst dein obriges Postulat, oder? Ich verstehe den Unterschied hier nicht.

Zurück zu deiner Herangehensweise ... das könnte fast eine Lösung für mich sein. Wenn Wind oder Regen einsetzt, wird die Istposition in den Kanal 4 Übertragen. Mein Hindernis dabei: Wind und Regen sind und sollen direkte Verknüpfungen sein, damit bei einem Ausfall der CCU-(Kommunikation) keine Schäden eintreten. Der Wert kann aber nur in einem Programm übernommen werden. Ob das vom Timing her klappt?

Ich glaube eher, es ist einfach recht unsicher, den langen Tastendruck (Start ... Stop) zu verwenden und wesentlich sicherer, nur noch absolute (X%) oder differenzielle (ist% +/- x%) Positionen per Taster/Befehl vorzugeben. Damit vermeide ich die ungewollte Endpositions-Sollwerte.

elbast
Beiträge: 9
Registriert: 27.06.2020, 17:13
System: Alternative CCU (auf Basis OCCU)

Re: HmIP-BROLL Probleme mit der Firmware 1.6.2

Beitrag von elbast » 28.06.2020, 19:13

Xel66 hat geschrieben:
28.06.2020, 18:26
Du hast den Sinn der virtuellen Kanäle eben nicht erfasst. Mit diesen lassen sich für Direktverknüpfungen durch geschickte Kombinationen Zustände erreichen, die sonst eben nur in Programmen abzubilden wären. Mach es Dir einfach und lasse alle Deine Trigger auf den gleichen Kanal wirken, und Du hast nicht die beschriebene (Verständnis-)Problematik. Den Vorzug der virtuellen Kanäle habe ich erst auch recht spät schätzen gelernt. Mit denen kann man sich auseinandersetzen, wenn man das Grundsystem intus hat.
Ich finde an der hier angewendeten ODER-Verknüpfung (Maximalwert zählt), als auch an den anderen logischen Verknüpfungen nichts kompliziert. Das ist Schulmathematik. Gib mir drei Werte und deren Verknüpfung und ich sage dir, was am Ende raus kommt.
Die Verknüpfung selbst funktioniert ja auch so wie gewollt. Nur wird bei langem Tastendruck (Fahrt bist Taste losgelassen) nicht der von mir gewünschte Wert (die aktuelle Position) sondern eine Endposition an den Kanal übergeben. Die Verknüpfungs-Funktion arbeitet mit der Endposition nachvollziehbar und in sich korrekt. Halt nur mit (meiner Ansicht nach, und in dieser Anwendungsform) falsch vorgegebenen Kanalwerten.
Mit allen Triggern (manuelle Position, temporäre Regen-Einfahrt, temporäre Wind-Einfahrt) auf einem einzelnen Kanal muss ich die ganze vKanal-Logik ja selber Programmieren. Da verzichte ich lieber auf den langen Tastendruck und arbeite nur noch mit absoluten oder relativen Positions-Sollwerten. Kann ich zwar die Markise nur noch diskret in +/- x% Schritten bewegen und nicht mehr beliebig kontinuierlich, aber diese kleinen Komforteinbußen nehme ich in Kauf.

Matsch
Beiträge: 5359
Registriert: 30.05.2019, 11:37
System: Alternative CCU (auf Basis OCCU)
Wohnort: Chemnitz
Hat sich bedankt: 113 Mal
Danksagung erhalten: 722 Mal

Re: HmIP-BROLL Probleme mit der Firmware 1.6.2

Beitrag von Matsch » 28.06.2020, 19:31

elbast hat geschrieben:
28.06.2020, 18:58
Ich benutze für solche Fälle ein kleines Programm in der CCU. Sobald die Sperre (z.B. Aussperrschutz) aufgehoben wird, triggert diese Änderung das Programm, das den Istwert ausliest und auf den benutzten Sollwertkanal kopiert.

Oh, das machst du weil...
weil man Soll- und Istwerte nicht miteinander mischt.
??? Sorry, aber da widerlegst Du doch selbst dein obriges Postulat, oder? Ich verstehe den Unterschied hier nicht.
Jetzt verdrehst du aber die Fakten, wie es dir paßt.
Ein Aktor darf niemals von sich aus eingreifen in Sollwerte, das darf nur der Anwender! Eine Vermischung zwischen Soll und Ist darf der Aktor nicht eigenmächtig tun!
In meinem geschilderten Fall tue ich das ja aus eigenem Willen und überlasse das nicht dem Aktor - weil das in dieser speziellen Anwendung geboten ist. Ich lasse mir nicht vom Aktor vorschreiben, dass ich dieses Verhalten ohne mein Zutun immer akzeptieren muß, weil es oft genug fehl am Platze wäre.
Zurück zu deiner Herangehensweise ... das könnte fast eine Lösung für mich sein. Wenn Wind oder Regen einsetzt, wird die Istposition in den Kanal 4 Übertragen. Mein Hindernis dabei: Wind und Regen sind und sollen direkte Verknüpfungen sein, damit bei einem Ausfall der CCU-(Kommunikation) keine Schäden eintreten. Der Wert kann aber nur in einem Programm übernommen werden. Ob das vom Timing her klappt?
Ich sehe keinen anderen Weg. Über eine DV allein ist es wohl nicht realisierbar, wenn man unter diesen Randbedingungen händisch in die Steuerung eingreift.

So ganz habe ich aber deine Bedenken nicht verstanden. Im Notfall sollte es doch keine Probleme geben, nur mit der Rückkehr aus dem Notfall.
Mit anderen Worten: der Schutz der Anlage ist nicht gefährdet. Es bliebe dann nur, wenn überhaupt, ein Komfortproblem.
Ich habe keine Markise, vielleicht sehe ich das aber auch nicht richtig.

Im Übrigen funktioniert eine DV zwischen HmIP-Geräten ja bei Ausfall der CCU ohnehin nicht bzw. nur mit starker zeitlicher Verzögerung. War hier schon oft ein Thema.

Antworten

Zurück zu „HomeMatic IP Aktoren und Sensoren“