HomeMatic-Schalter mit Smart Bulbs - Frage nach Lösungsmöglichkeiten

Begonnen von sledge, 05 April 2018, 20:03:31

Vorheriges Thema - Nächstes Thema

sledge

Hallo zusammen,

ich stehe davor, meine Gira S55-Schalter-Infrastruktur nach und nach auf HM umzurüsten, um sämtliche Beleuchtung via FHEM steuern zu können.

Dabei unterscheide ich derzeit mehrere Fälle:


  • Einfacher Schalter / keine Smart Bulbs (zB Halogenstrahler usw.)
    Hier ist es einfach. Würde ich gegen einen HM-LC-Sw1PBU-FM austauschen
  • Mehrere Taster mit Eltako - Stromstoß / keine Smart Bulbs
    Auch einfach. Plane ich auszutauschen gegen HM-LC-Sw1-DR

Problematisch wird es für mich, wenn ich Schaltungen mit Smart Bulbs betreibe - in meinem Fall YeeLight. Diese Leuchtkörper kennen ja mehrere Zustände:


  • disconnected - stromlos
  • opened / 0% - ansteuerbar, aber auf "aus"
  • opened / >0% - ansteuerbar, aber "leuchtend"

Jetzt die Fragestellung: Befindet sich eine solche Smart Bulb im Zustand "leuchtend", soll sie ja durch Druck auf "irgendeinen" Schalter / Taster idR nicht stromlos geschaltet werden, sondern nur auf 0% gedimmt / runtergedrosselt werden. Ursprünglich hatte ich vor, alle einfachen Schalter durch HM-LC-Sw1PBU-FM zu ersetzen - aber dieser schaltet ja in jedem Fall aus, oder wie sehe ich das?

Und bei einer Kreuz- / Wechselschaltung ebenfalls: Entweder besorge ich mir einen HM-LC-Sw1PBU-FM mit modifizierter Firmware oder ich setze den vanilla HM-LC-Sw1PBU-FM ein und ersetze alle anderen Schalter in der Schaltung durch HM-RC-2-PBU-FM. Und auch hier wieder die Frage: Wie verhindere ich, dass die Smart Bulb durch den HomeMatic Schalter stromlos gemacht wird?

Bevor ich jetzt alles kaufe und mein Elektriker der Wahl anfängt, die Schalter auszutauschen, möchte ich diese Fragestellung gerne mal in die Runde werfen und diskutieren - also wie geht man mit den HomeMatic Schaltern im Zusammenhang mit Smart Bulbs um? Oder stelle ich alles auf "Sender" um und FHEM übernimmt die ganze Logik / Steuerung? Das wiederum ist gerade bei Beleuchtung und einem möglichen Systemausfall ja nicht gerade sinnvoll - mittels Peering wären die Schalter-bezogenen Lösungsansätze diesbezüglich autark.

Ich freue mich über Input und Anregungen!


Gruß,
Tom




FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

Pfriemler

Die wenigsten Fragen in einem Forum verdienen es unbeantwortet zu bleiben...

Direkt geschaltete und "getastete" "Normal-Lampen" hast Du ja bereits ganz richtig beschrieben. Für den Ersatz einer herkömmlichen Wechselschaltung ist der Ersatz eines Schalters durch einen Sw1-PBU und der restlichen Schaltstellen durch die RC-2-PBU das Mittel der Wahl.

Mir ist aber gewüschnte Funktion mit den Yeelink nicht klar. Offenbar sollen die Lampen nicht leichtfertig in den offline-Zustand versetzt werden, damit sie fernsteuerbar bleiben. Das verbietet aber regulär betätigte Schalter im Signalweg. Eine reine Homematic-Lösung wären Unterputzaktoren in Kombination mit darüberliegenden Tastern - auch hier wäre ein modifizierter Sw1-PBU sehr geeignet. Platztechnisch bietet sich auch ein Hm-pb-2-wm55 an, wenn er optisch passt. Er ist zwar batteriebetrieben, diese lassen sich aber extrem leicht wechseln und halten Jahre.

Das Auslösen des Tasters erzeugt dann nur das Event, was über FHEM an die Yeelinks weitervermittelt wird, ohne dass der versorgende Aktor ausgeschaltet wird - der wird stattdessen als Hauptschalter für Abwesenheit oder Urlaub benutzt, damit die Lampen nicht unter Dauerstrom stehen. Allerdings missfällt mir energetisch der Energiebedarf der dauereingeschalteten Aktoren - hier wären Eltakos mit bistabilen Relais die bessere Wahl.

Bei Homematic wird üblicherweise von einer zu dichten Positionierung von Taster und Aktor abgeraten. Das betrifft aber hauptsächlich lokale Direktverknüpfungen, also wo der Taster den Aktor immer ohne externe Mithilfe steuern soll. Die Funkmodule brüllen sich dann zu sehr an. In diesem Fall wird aber eine Zentrale als Vermittlung benutzt, da ist das dann kein Problem mehr.

Jm2c.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

sledge

Zitat von: Pfriemler am 12 April 2018, 11:55:17
Die wenigsten Fragen in einem Forum verdienen es unbeantwortet zu bleiben...

Danke.

Zitat
Direkt geschaltete und "getastete" "Normal-Lampen" hast Du ja bereits ganz richtig beschrieben. Für den Ersatz einer herkömmlichen Wechselschaltung ist der Ersatz eines Schalters durch einen Sw1-PBU und der restlichen Schaltstellen durch die RC-2-PBU das Mittel der Wahl.
Naja - dann ist der von mir geschilderte Ansatz ja nicht komplett falsch. Generell finde ich ja den Gedanken, 2 der 3 verbauten Schalter "in der Wand" lassen zu können, wenn ich den Sw1-PBU mit der geänderten FW verwende, aber diese Art von Modifikation übersteigt meine Löt-Fertigkeiten schlichtweg.
Zitat
Mir ist aber gewüschnte Funktion mit den Yeelink nicht klar. Offenbar sollen die Lampen nicht leichtfertig in den offline-Zustand versetzt werden, damit sie fernsteuerbar bleiben. Das verbietet aber regulär betätigte Schalter im Signalweg. Eine reine Homematic-Lösung wären Unterputzaktoren in Kombination mit darüberliegenden Tastern - auch hier wäre ein modifizierter Sw1-PBU sehr geeignet. Platztechnisch bietet sich auch ein Hm-pb-2-wm55 an, wenn er optisch passt. Er ist zwar batteriebetrieben, diese lassen sich aber extrem leicht wechseln und halten Jahre.

Das Auslösen des Tasters erzeugt dann nur das Event, was über FHEM an die Yeelinks weitervermittelt wird, ohne dass der versorgende Aktor ausgeschaltet wird - der wird stattdessen als Hauptschalter für Abwesenheit oder Urlaub benutzt, damit die Lampen nicht unter Dauerstrom stehen. Allerdings missfällt mir energetisch der Energiebedarf der dauereingeschalteten Aktoren - hier wären Eltakos mit bistabilen Relais die bessere Wahl.
Du hast den Ansatz schon richtig erkannt: Im Normalfall sollen die YeeLights (gilt aber vermutlich für jede andere Smartbulb auch) über FHEM steuerbar sein - zB für den Lichtwecker am Morgen - aber auch beim Druck auf den Schalter / Taster an der Wand reagieren. In einigen Forenbeiträgen wurde der Effekt des "2-3mal Drückens" beim Einschalten ja schon beschrieben. Mein Besuch schaut mich jedesmal fragend an, warum beim ersten Tastendruck die Lampe nicht angegangen ist (tja, weil halt... smart). Und dann sieht smart ganz schnell "dumb" aus. OK, hier und da noch Bewegungsmelder, Anwesenheitskontrolle usw - alles machbar. Aber generell möchte ich auf den Tastendruck an der Wand "Licht an / Licht aus" - und hin und wieder auch "Strom weg" - ohne direkt die Sicherung rausnehmen zu müssen. Schalter sind nunmal ein IODev, dass allen geläufig ist - auch dann, wen Alexa spinnt oder eine andere Komponente nicht tut.

Und sollte FHEM mal abgeschmiert sein (trotz aller Vorsichtsmaßnahmen - und sei es, dass ich auf Dienstreise bin und gerade nicht das Backup einspielen kann oder ...) - dann gibt es da immer noch diesen einen Schalter, der alles richtet, weil er halt "Strom an / Strom aus" kann.

Das war so ein bisschen die Intention hinter der Frage.

Meine aktuelle Stoßrichtung ist die zuerst von mir beschriebene Lösung anzugehen: Sw1-PBU und eine entsprechende Anzahl von Unterputzsendern mit Taster drauf. Sollte jemand "aus Versehen" die smartbulb über den einzigen echten Schalter (Sw1-PBU) ausgeschaltet haben, obwohl diese nur auf "0%", jedoch nicht auf "disconnected" stand, dann wird halt wieder angeschaltet und die Lampe mit einem entsprechenden Einschaltbefehl versorgt. Leider - durch die vergehende Zeitdauer, bis die Lampe wieder im WLAN ist und auf Befehle reagiert, wird vermutlich "x-mal" auf den (echten) Schalter gehämmert, bis die Lampe brennt. Das ist dann halt so.

Falls Du mich noch in die richtige Richtung schubst, was die bistabilen Eltakos angeht - ggfs bringt mich das ja weiter?

Danke in jedem Fall für Deine Gedanken zu dem Thema - aktuell hilft alles, bevor ich jetzt für großes Geld HM-Komponenten bestelle und den Elektriker meiner Wahl beauftrage.

Gruß,

Tom


FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

Pfriemler

Zitat von: sledge am 12 April 2018, 19:21:26
Generell finde ich ja den Gedanken, 2 der 3 verbauten Schalter "in der Wand" lassen zu können, wenn ich den Sw1-PBU mit der geänderten FW verwende, aber diese Art von Modifikation übersteigt meine Löt-Fertigkeiten schlichtweg.
Das ist in der Tat ein schicker Lösungsansatz dieser Firmware. Überhaupt ein Jammer, welches Potential da brach liegt. Es gibt z.B. immer noch kein Modul mit Ein- und Ausgängen gleichzeitig.

Zitatgenerell möchte ich auf den Tastendruck an der Wand "Licht an / Licht aus" - und hin und wieder auch "Strom weg" - ohne direkt die Sicherung rausnehmen zu müssen. Schalter sind nunmal ein IODev, dass allen geläufig ist - auch dann, wen Alexa spinnt oder eine andere Komponente nicht tut.
Also die "Smarten" in der Regel unter Strom lassen und nur gelegentlich ausstromen. Mir fiele da etwa sequence ein: dreimal aus = ganz aus.

Aber
ZitatUnd sollte FHEM mal abgeschmiert sein (trotz aller Vorsichtsmaßnahmen - und sei es, dass ich auf Dienstreise bin und gerade nicht das Backup einspielen kann oder ...) - dann gibt es da immer noch diesen einen Schalter, der alles richtet, weil er halt "Strom an / Strom aus" kann.
Das funktioniert aber nur, wenn die smarten Lampen beim Einstromen automatisch einschalten. Und dann braucht es doch zwingend eine Direktverknüpfung zwischen den HomeMatic-Geräten (oder zumindest einer Notbedienung wie etwa einer Fernbedienung). Natürlich reicht auch ein Sw1-PBU, aber meine oben vorgeschlagene Lösung mit dem Unterputzaktor und dem separaten Taster darüber wäre damit wieder aus dem Rennen.

ZitatMeine aktuelle Stoßrichtung ist die zuerst von mir beschriebene Lösung anzugehen: Sw1-PBU und eine entsprechende Anzahl von Unterputzsendern mit Taster drauf. Sollte jemand "aus Versehen" die smartbulb über den einzigen echten Schalter (Sw1-PBU) ausgeschaltet haben, obwohl diese nur auf "0%", jedoch nicht auf "disconnected" stand, dann wird halt wieder angeschaltet und die Lampe mit einem entsprechenden Einschaltbefehl versorgt.

Das hinkt noch: Die klassische Wechselschaltung zu ersetzen mit einem Aktor und Unterputzsendern erfordert normalerweise eine Direktverknüpfung der Taster mit dem Aktor - das funktioniert immer und ohne FHEM, macht aber eine smarte Lampe dahinter immer ganz aus. Für smarte Ansteuerung bist Du darauf angewiesen, dass FHEM die Tastendrücke in Schaltbefehle an die Yeelinks übersetzt und den Schaltzustand des Aktors nicht beeinflusst. Das widerspricht sich. Komfort und Ausfallsicherheit sind gleichzeitig so nicht zu erreichen.
Man kann die Verknüpfung einseitig begrenzen, etwa den Aktor nur einschalten lassen - so wird eine versehentlich stromlos gemachte smarte Lampe wenigstens von allen Bedienstellen reaktiviert, mit der Boot- und Anmeldeverzögerung natürlich. Nur wenn FHEM down ist und die Lampe beim Einstromen nicht einschaltet, wie bekommst Du sie dann überhaupt an? Mit dem Handy?

ZitatFalls Du mich noch in die richtige Richtung schubst, was die bistabilen Eltakos angeht - ggfs bringt mich das ja weiter?
Das ist ja eher eine Ökofrage - und kein Gedanke in Richtung Ausfallsicherheit, wenn der Übersetzer HomeMatic-Taste -> EnOcean ausfällt. Außerdem habe ich kein EnOcean am Start (nur einen Sensor) und daher keine Erfahrungen, geschweige denn Kaufvorschläge.

"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Beta-User

Ein paar Anmerkungen:

m.E. kommen WLAN-abhängige Lampen nicht für Bereiche in Frage, die zwingend funktionieren müssen - dafür ist mir die Kette bis zum "Erfolg" Einschalten viel zu unsicher. Ist also besten Falles was für eine Effektbeleuchtung.

Und auf ein IO wie einen Schalter sollte eine (sehr) zeitnahe Reaktion erfolgen. Wenn dann noch längere Bootzeiten im Sekundenbereich dazu kommen: Welcher Besucher versteht so was?

Noch weniger versteht ein DAG (G für Gast) Dinge wie "sequence". Ich habe das bei mir im Einsatz (HM-Taster für Milights), aber das benutze wirklich nur ich, und das auch eher zu Demo-Zwecken, um dem Rest der Familie zu zeigen, dass man nicht zwingend ein Handy braucht...

Und "smarte" Lösungen im Reiheneinsatz sind m.E. nicht so toll, weil sich erfahrungsgemäß keiner damit befassen will, an welcher Stelle er jetzt schalten müßte. Also: Smart bulbs sollten sinnigerweise immer Strom haben, und wer einen "Schalter" benötigt, braucht halt eine dazu passende (direkt verknüpfte) Fernbedienung (oder einen Taster usw.).

Daher hängen z.B. meine Milights alle hinter einem Schalter (keiner will FB's suchen, diese Art der Beschaltung ist für die Technik aber auch eher suboptimal), weil alle erwarten, die darüber schalten zu können (die schalten wirklich auf den letzten Zustand, wenn man sie frisch versorgt; sollte halt nicht "aus" gewesen sein, das ist sonst nicht so spaßig, siehe HM Taster oben...). Lediglich im Urlaub (für die Anwesenheitssimulation) bekommen die Dauerstrom.

Oder es sind halt HM-Aktoren/Dimmer im Einsatz, dann dahinter aber keine weitere Logik mehr, sondern dazu passende Leuchtmittel (wieder ein anderes Thema, das man aber beachten sollte).

Soviel dazu erst mal von meiner Seite.

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

sledge

Hi,

danke - und noch mehr Anregungen.

Um jetzt keine Zitat-Schlacht loszutreten, die wichtigsten Punkte von oben nach unten numeriert ;-)

ad 1) Ich teile Deine Meinung - aber das bleibt mir baw verwehrt.

ad 2) Sequence - darüber habe ich noch garnicht nachgedacht.

ad 3) Die Lampen schalten sich aut. ein wenn Strom anliegt... insofern passt das.

Somit folgende Lösung - ins unreine gedacht:

ad 4)


  • Der Sw1-PBU schaltet nur ein - geht das überhaupt? Also wie folgt: Taste oben berührt schaltet immer die Lampe ein oder den Strom über den Aktor Sw1-PBU ein. Also gehen die Smart-Bulbs entweder via Yeelight-Kommando oder durch den Strom an - fein für mich
  • Werden die Schalter / Tasterwippen unten berührt, werden die SmartBulbs entsprechend auf 0% gedimmt. Auch schick
  • Echtes Ausschalten via FHEM / Sequence. Da bin ich noch garnicht drauf gekommen... nett.

Bleibt nur offen: Kann ich verhindern, dass der Sw1-PBU echt ausschaltet? Also eine Art "inhibit" auf dem Channel / Aktor? Oder zielt der Ansatz darauf ab, einen anderen Aktor zu verwenden?

Vielen Dank in jedem Fall - werde mir das nochmal in Ruhe durch den Kopf gehen lassen und in einem unkritischen Bereich mal eine Teststellung machen.

FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

sledge

Zitat von: Beta-User am 13 April 2018, 16:30:46
Ein paar Anmerkungen:

m.E. kommen WLAN-abhängige Lampen nicht für Bereiche in Frage, die zwingend funktionieren müssen - dafür ist mir die Kette bis zum "Erfolg" Einschalten viel zu unsicher. Ist also besten Falles was für eine Effektbeleuchtung.

Und auf ein IO wie einen Schalter sollte eine (sehr) zeitnahe Reaktion erfolgen. Wenn dann noch längere Bootzeiten im Sekundenbereich dazu kommen: Welcher Besucher versteht so was?

Noch weniger versteht ein DAG (G für Gast) Dinge wie "sequence". Ich habe das bei mir im Einsatz (HM-Taster für Milights), aber das benutze wirklich nur ich, und das auch eher zu Demo-Zwecken, um dem Rest der Familie zu zeigen, dass man nicht zwingend ein Handy braucht...

Und "smarte" Lösungen im Reiheneinsatz sind m.E. nicht so toll, weil sich erfahrungsgemäß keiner damit befassen will, an welcher Stelle er jetzt schalten müßte. Also: Smart bulbs sollten sinnigerweise immer Strom haben, und wer einen "Schalter" benötigt, braucht halt eine dazu passende (direkt verknüpfte) Fernbedienung (oder einen Taster usw.).

Daher hängen z.B. meine Milights alle hinter einem Schalter (keiner will FB's suchen, diese Art der Beschaltung ist für die Technik aber auch eher suboptimal), weil alle erwarten, die darüber schalten zu können (die schalten wirklich auf den letzten Zustand, wenn man sie frisch versorgt; sollte halt nicht "aus" gewesen sein, das ist sonst nicht so spaßig, siehe HM Taster oben...). Lediglich im Urlaub (für die Anwesenheitssimulation) bekommen die Dauerstrom.

Oder es sind halt HM-Aktoren/Dimmer im Einsatz, dann dahinter aber keine weitere Logik mehr, sondern dazu passende Leuchtmittel (wieder ein anderes Thema, das man aber beachten sollte).

Soviel dazu erst mal von meiner Seite.

Gruß, Beta-User

Generell bin ich da bei Dir - ich möchte die Smart Bulbs auch nicht via Handy o.ä. schalten müssen - das macht  mE keinen Sinn. Und daher ja auch der Ansatz, die entsprechend immer unter Strom zu haben. Dennoch gibt es den Bedarf, diese Geräte hin und wieder stromlos zu machen (zB neue SSID oder ähnliches) - und dazu möchte ich dann nicht am Sicherungskasten rumspringen müssen.

Schalte ich meine Smartbulbs via Sender ein, erfolgt die Reaktion für meine Zielgruppe hinreichend schnell ;-) - in jedem Fall besser als "Alexa, macht  das <XYZ wie heißt die Lampe hier> an" - passiert zur Zeit über den Schlüsselanhängersender von HM.

Mich stört aktuell halt diese Mischung: Schalter in der Wand alle Strom an / Strom aus - der "smarte" Teil kommt dann erst danach. Und halt der beschriebene Effekt des Doppelschaltens.

Durch eine rein Sender-basierte (oder siehe meine letzte Antwort) Lösung wäre das nach meinem Empfinden eine gute Synthese der beiden Welten: Licht an/aus über Schalter, stromlosmachen geht auch, der smarte Teil über FHEM. Und: Selbst das stroman kann ich über FHEM steuern, wenn meine beschriebene Annahme richtig ist.

Der Vorschlag mit Sequence ist doch eher eine Lösung, meine "Frage" nach stromlos in seltenen Fällen zu lösen - und daher auch nicht DA(U|G)-relevant - sondern eher für mich.

Und in jedem Fall Danke für die Anregungen und Szenariendiskussion.

Merci
FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

Beta-User

Da schon  fertig:

Also wenn unbedingt ein Aktor davor sitzen soll: Die HM-Geräte kann man nur durch eine Modifikation der firmware dazu überreden, Taster und Aktor getrennt zu betrachten - fällt also vermutlich flach. Und inhibit wirkt nach meiner Kenntnis immer auf beide Taster, vermutlich kommen bei der Standard-firmware dann auch keine Events mehr.

Dann mußt du beides trennen (Batteriebetrieb...). Man kann auch einen Aktor hinter einen 2- oder 6-fach-Taster verbauen; ist nicht optimal, wie Pfriemler zurecht schon geschrieben hat, funktioniert aber, wenn man den Aktor bei Problemen ggf. verdreht und/oder eine Schirmung dazuwischensetzt (Alufolie).

Wenn, würde ich einen mehrfach-Taster verwenden und dann eben das Peering nur auf eine Taste legen ("single") - dann mußt du aber Registereinstellungen am Aktor ändern (Einsteiger-pdf hinten, jumptable für Details, es müssen ggf. auch die Register für long geändert werden). (Ich habe sowas damals als Einsteiger hinbekommen, aber ca. 25 mal lesen müssen).

Ein "Aus" bekommt der HM-Aktor dann ausschließlich von der Zentrale, oder von einem "zentralen Taster" (ginge für Ausfallsicherheit auch beides parallel, ich würde empfehlen, da auch "dual" zu peeren, kann ja ggf. für alle betreffenden Aktoren sein), wie du das in FHEM antriggerst: Dein Problem ::) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Pfriemler

zu ad4): genau so. Die Sequence ist nur für den kundigen Benutzer für ein Haupt-Power-Off gedacht - der DAG bekommt davon nix mit.

Einen Sw1-PBU kann man auch ganz prima - ohne Firmwaremodifikation - so programmieren, dass er auf den unteren Tastendruck nicht ausschaltet, aber auf den oberen sehr wohl ein. Inhibit ist in der Tat der falsche Weg dafür. Sequence geht nicht, weil die Signale nicht nach außen geleitet werden (das kann nur die alternative Firmware). Denkbar wäre ein Off über einen langen Tastendruck - aber leider lässt sich die Länge des langen Tastendrucks nicht bei direkten Aktortasten ändern, nur bei echten Fernbedienungen - und die zeitliche Nähe zum kurzen Tastendruck wird über kurz oder lang dazu führen, dass ein Benutzer den Aktor öfter unbeabsichtigt ausschaltet.

Aber wie Beat-User schon sagt: Das Haupt-Aus kann auch prima ein General-Aus-Taster oder eben FHEM erledigen.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."