HmIP-BROLL Probleme virtuellen Kanälen (Steuerung für Lüften)
Moderator: Co-Administratoren
-
- Beiträge: 175
- Registriert: 10.04.2020, 07:55
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 42 Mal
- Danksagung erhalten: 5 Mal
HmIP-BROLL Probleme virtuellen Kanälen (Steuerung für Lüften)
Muss mich hier leider nochmal anhängen:
Ich hatte gehofft, mit einer DV zwischen Fensterkontakt und Kanal 5 des BROLL (OR-verknüpft zu Kanal 4) eine Öffnung auf min. 25% zu realisieren (zum Lüften im Badezimmer).
Das klappt auch super, wenn die Behanghöhe 0 oder 100 ist bzw. auf einen bestimmten Wert gesetzt ist.
Nun ist es aber auch so, und das ist ja wohl die Thematik dieses Threads, dass Kanal 4 bei manueller Tasterbedienung nur 0 oder 100 annimmt, auch wenn eine Zwischenposition angefahren wird. Damit ist obige Logik natürlich im Eimer
Jetzt habe ich schon diverse Workarounds probiert:
- In der Middleware (iobroker) den Level von Kanal 4 auf die tatsächliche Behanghöhe setzen wenn der Fensterkontakt "sendet" -> Ergebnis: Die Jalousie "ruckelt" immer wenn das Fenster geöffnet wird (wahrscheinlich wegen Rundungsdifferenzen).
- Direktverknüpfung zu Kanal 4 anstelle 5 -> Ergebnis: Die Jalousie fährt immer nur auf 25 oder 0%.
- keine DV verwenden und in der Middleware bei Fensteröffnung sicherstellen, dass die Jalousie min. 25% offen ist -> Ergebnis: Wahrscheinlich machbar, jedoch müsste ich diverse Situationen abfangen (z. B. ob die Jalousie währenddessen manuell betätigt wird).
Kennt jemand noch andere Möglichkeiten?
Ich hatte gehofft, mit einer DV zwischen Fensterkontakt und Kanal 5 des BROLL (OR-verknüpft zu Kanal 4) eine Öffnung auf min. 25% zu realisieren (zum Lüften im Badezimmer).
Das klappt auch super, wenn die Behanghöhe 0 oder 100 ist bzw. auf einen bestimmten Wert gesetzt ist.
Nun ist es aber auch so, und das ist ja wohl die Thematik dieses Threads, dass Kanal 4 bei manueller Tasterbedienung nur 0 oder 100 annimmt, auch wenn eine Zwischenposition angefahren wird. Damit ist obige Logik natürlich im Eimer
Jetzt habe ich schon diverse Workarounds probiert:
- In der Middleware (iobroker) den Level von Kanal 4 auf die tatsächliche Behanghöhe setzen wenn der Fensterkontakt "sendet" -> Ergebnis: Die Jalousie "ruckelt" immer wenn das Fenster geöffnet wird (wahrscheinlich wegen Rundungsdifferenzen).
- Direktverknüpfung zu Kanal 4 anstelle 5 -> Ergebnis: Die Jalousie fährt immer nur auf 25 oder 0%.
- keine DV verwenden und in der Middleware bei Fensteröffnung sicherstellen, dass die Jalousie min. 25% offen ist -> Ergebnis: Wahrscheinlich machbar, jedoch müsste ich diverse Situationen abfangen (z. B. ob die Jalousie währenddessen manuell betätigt wird).
Kennt jemand noch andere Möglichkeiten?
Zuletzt geändert von Roland M. am 22.04.2021, 15:28, insgesamt 1-mal geändert.
Grund: Abgetrennt von https://homematic-forum.de/forum/viewtopic.php?f=58&t=47686
Grund: Abgetrennt von https://homematic-forum.de/forum/viewtopic.php?f=58&t=47686
RaspberryMatic 3.65.11.20221005 RPi4 4GB
RPI-RF-MOD mit ext. Stabantenne und HAP
ioBroker
RPI-RF-MOD mit ext. Stabantenne und HAP
ioBroker
-
- Beiträge: 9681
- Registriert: 27.04.2020, 10:34
- System: CCU
- Hat sich bedankt: 700 Mal
- Danksagung erhalten: 1626 Mal
Re: HmIP-BROLL Probleme mit der Firmware 1.6.2
Das ist IMHO kein FW Problem. Passt also nicht in diesen Thread.
LG, Michael.
Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.
Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++
Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.
Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++
-
- Beiträge: 175
- Registriert: 10.04.2020, 07:55
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 42 Mal
- Danksagung erhalten: 5 Mal
Re: HmIP-BROLL Probleme mit der Firmware 1.6.2
Naja, darüber wurde ja schon kräftig gestritten
Frage ist ja, ob der Kanal 4 nicht die tatsächliche Behanghöge anzeigen sollte.
Aber stimmt, müsste verschoben werden. Ich hoffe, ich kann das selber.
Sorry!
Frage ist ja, ob der Kanal 4 nicht die tatsächliche Behanghöge anzeigen sollte.
Aber stimmt, müsste verschoben werden. Ich hoffe, ich kann das selber.
Sorry!
RaspberryMatic 3.65.11.20221005 RPi4 4GB
RPI-RF-MOD mit ext. Stabantenne und HAP
ioBroker
RPI-RF-MOD mit ext. Stabantenne und HAP
ioBroker
-
- Beiträge: 9681
- Registriert: 27.04.2020, 10:34
- System: CCU
- Hat sich bedankt: 700 Mal
- Danksagung erhalten: 1626 Mal
Re: HmIP-BROLL Probleme mit der Firmware 1.6.2
Nein Kanal 4 hat noch nie die tatsächliche Behanghöhe angezeigt.
LG, Michael.
Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.
Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++
Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.
Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++
-
- Beiträge: 5452
- Registriert: 30.05.2019, 11:37
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Chemnitz
- Hat sich bedankt: 116 Mal
- Danksagung erhalten: 741 Mal
Re: HmIP-BROLL Probleme mit der Firmware 1.6.2
Ist es nicht, da es keinerlei Sinn macht, 2 verschiedene Kanäle zu haben, die den gleichen Istwert zurückgeben.
Und zum 10ten Mal: Sollwerte kann man auch über Kanal 6 bereitstellen, ebenso kann man die Wippen auf Kanal 5 oder 6 legen (beides mache ich z.B.). Was sollte es in diesem Fall bringen, den Istwert auf Kanal 4 zu überschrieben? Außer Chaos und Fehlfunktionen?
Da wäre doch der alte HM-Aktor der richtige. Der kann so wunderbar wenig (nur rauf- und runterfahren) - und ganz toll:
Der hat nur einen Datenkanal und nur einen einzigen Datenpunkt für die Höhe, egal ob Soll- oder Istwert.
Ich befürchte, eines Tages wird eQ-3 die Firmware des BROLL/FROLL/BBL/FBL ändern und einen Minimalmodus ohne virtuelle Kanäle integrieren müssen, weil die Nutzung der virtuellen Kanäle partout nicht verstanden wird (ok, eine ausführliche Dokumentation im Handbuch könnte schon ein bißchen weiterhelfen, existiert aber nicht). Optional kann dann wieder in den gegenwärtigen erweiterten Mode gewechselt werden.
-
- Beiträge: 175
- Registriert: 10.04.2020, 07:55
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 42 Mal
- Danksagung erhalten: 5 Mal
Re: HmIP-BROLL Probleme mit der Firmware 1.6.2
Okay, verstehe. Dann kann man die virtuellen Kanäle ja nicht wirklich benutzen wenn man die LONG PRESS Funktion des Tasters nutzt, oder?
RaspberryMatic 3.65.11.20221005 RPi4 4GB
RPI-RF-MOD mit ext. Stabantenne und HAP
ioBroker
RPI-RF-MOD mit ext. Stabantenne und HAP
ioBroker
-
- Beiträge: 5452
- Registriert: 30.05.2019, 11:37
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Chemnitz
- Hat sich bedankt: 116 Mal
- Danksagung erhalten: 741 Mal
Re: HmIP-BROLL Probleme mit der Firmware 1.6.2
Da gibt es keinen Zusammenhang, ich verstehe die Frage leioder gar nicht. Wie denn nutzen?
Wie gesagt, ich habe einen Anwendungsfall, da sind die Wippenkanäle auf Kanal 6 des BROLL gelegt und tun dort ihren Dienst, egal ob kurzer oder langer Tastendruck.
-
- Beiträge: 175
- Registriert: 10.04.2020, 07:55
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 42 Mal
- Danksagung erhalten: 5 Mal
Re: HmIP-BROLL Probleme mit der Firmware 1.6.2
Um die tatsächliche Behanghöhe des Aktor zu steuern. Meiner Auffassung nach ist doch der Sinn der virtuellen Kanäle der, dass man durch logische Verknüpfungen regelt, was der Aktor nun tatsächlich tun soll.
Daher erschien mir meine Herangehensweise logisch sinnvoll:
Kanal 4 (DV zu den Tastern) OR Kanal 5 (DV zum Fensterkontakt)
Beispiel: Jalousie wird mit Tastern ganz geöffnet - also Kanal 4 100% / Fensterkontakt ist geschlossen - also Kanal 5 0%
--> Aktor fährt Jalousien auf 100%
Jalousie ist mit Tastern ganz geschlossen - also Kanal 4 0% / Fensterkontakt wird geöffnet - also Kanal 5 25% (in meinem Fall)
--> Aktor fährt Jalousien auf 25%
Jalousie ist mit Tastern ganz geschlossen - also Kanal 4 0% / Fensterkontakt wird geschlossen - also Kanal 5 0%
--> Aktor fährt Jalousien auf 0%
Diese Logik würde ja völlig schieflaufen, wenn ich mittels langem (oder entgegengesetztem Tastendruck) die Aktion stoppe.
Was habt ihr denn für Anwendungsfälle/logische Verknüpfungen bei Euch realisiert die trotz langem Tastendruck einwandfrei funktionieren?
RaspberryMatic 3.65.11.20221005 RPi4 4GB
RPI-RF-MOD mit ext. Stabantenne und HAP
ioBroker
RPI-RF-MOD mit ext. Stabantenne und HAP
ioBroker
-
- Beiträge: 9681
- Registriert: 27.04.2020, 10:34
- System: CCU
- Hat sich bedankt: 700 Mal
- Danksagung erhalten: 1626 Mal
Re: HmIP-BROLL Probleme mit der Firmware 1.6.2
Mit dem langen Tastendruck legst du doch nur einen neuen Sollwert für Kanal 4 fest. Wo ist das Problem? Auf jeden Fall hier nicht die FW
LG, Michael.
Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.
Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++
Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.
Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++
-
- Beiträge: 5452
- Registriert: 30.05.2019, 11:37
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Chemnitz
- Hat sich bedankt: 116 Mal
- Danksagung erhalten: 741 Mal
Re: HmIP-BROLL Probleme mit der Firmware 1.6.2
Wenn du vorher mit der Wippe gefahren bist und dann das Fenster öffnest und wieder schließt, dann fährt die Rolllade nicht wieder auf den Punkt vor dem Öffnen zurück, weil das händische Stoppen mit der Wippe nichts weiter ist als eine Unterbrechung der Fahrt, nicht das Festlegen eines neuen Ziels.
Dort steht ja als Ziel 0% oder 100%.
Mit einer DV ist das wohl nicht zu lösen. Ich handhabe das so, dass immer dann, wenn mit der Wippe gefahren wird, ein Programm ausgelöst wird, sobald die Rolllade wieder steht (z.B. durch stoppen). Dann übertrage ich im Programm den Istwert aus K3 auf den Sollwertkanal (hier K4, bei mir K6), nicht aber, wenn die Rolllade über die CCU gesteuert wird.
So kehrt die Rolllade nach dem Schließen immer wieder auf die alte Position zurück oder im Falle der CCU-Steuerung auf den inzwischen aktuellen Wert.
Jetzt werden einige sagen: Ja aber das ist doch genau das, was wir eigentlich wollen, dass der Sollwert in Kanal 4 auf den Istwert gesetzt wird nach dem Stoppen!
Wer mitgelesen hat, wird merken, nein, es ist nicht dasselbe. Ich lege nämlich selbst fest, in welchen Kanal der Istwert zu übertragen ist (weil eben K4 nicht per se der Stellwertkanal ist!) und zudem, in welchen Situationen das getan werden soll und wann nicht!
Ein interner Automatismus, der immer und eigenständig den Istwert nach K4 überträgt, würde die Verwendungsmöglichkeiten des Aktors extrem einschränken.
Aber das alles hat rein gar nichts mit der Firmware zu tun, betrifft alle bisher veröffentlichte Versionen, sondern ist spezifisch für die Aktoren BROLL/FROLL/BBL/FBL.
Dort steht ja als Ziel 0% oder 100%.
Mit einer DV ist das wohl nicht zu lösen. Ich handhabe das so, dass immer dann, wenn mit der Wippe gefahren wird, ein Programm ausgelöst wird, sobald die Rolllade wieder steht (z.B. durch stoppen). Dann übertrage ich im Programm den Istwert aus K3 auf den Sollwertkanal (hier K4, bei mir K6), nicht aber, wenn die Rolllade über die CCU gesteuert wird.
So kehrt die Rolllade nach dem Schließen immer wieder auf die alte Position zurück oder im Falle der CCU-Steuerung auf den inzwischen aktuellen Wert.
Jetzt werden einige sagen: Ja aber das ist doch genau das, was wir eigentlich wollen, dass der Sollwert in Kanal 4 auf den Istwert gesetzt wird nach dem Stoppen!
Wer mitgelesen hat, wird merken, nein, es ist nicht dasselbe. Ich lege nämlich selbst fest, in welchen Kanal der Istwert zu übertragen ist (weil eben K4 nicht per se der Stellwertkanal ist!) und zudem, in welchen Situationen das getan werden soll und wann nicht!
Ein interner Automatismus, der immer und eigenständig den Istwert nach K4 überträgt, würde die Verwendungsmöglichkeiten des Aktors extrem einschränken.
Aber das alles hat rein gar nichts mit der Firmware zu tun, betrifft alle bisher veröffentlichte Versionen, sondern ist spezifisch für die Aktoren BROLL/FROLL/BBL/FBL.