Bedienung für HM-LC-BL1-FM (Rolladen-Aktor) sperren

[cseuss]

Hallo zusammen,

ich habe mehrere HM-LC-BL1-FM im Einsatz. Ich möchte gerne die direkte Bedienung per lokalem Taster und(!) per Modul in der FHEM-Oberfläche sperren für den Fall das z.B. eine Tür geöffnet ist.

Am Wochenende hat leider ein Freund die Rollade versehentlich lokal fahren lassen, während die Fliegentür geöffnet war. Die Rolladen hat sich dann schön im Kasten aufgewickelt. 

Die Sperre aller automatischen Steuerungen habe ich bereits durch die Einbindung des Status von Tür- und Fensterkontakten erreicht.

Für den lokalen Taster habe ich mir die Möglichkeit mittels "inhibit" angeschaut und getestet. Das gefällt mir schon ganz gut.

Ich suche nun nach einer Möglichkeit, auch die Bedienung des Aktors direkt über die FHEM-Oberfläche zu sperren, da dort natürlich versehentlich auch eine manuelle Fehlbedienung passieren kann, wenn man die Rollade nicht direkt einsehen kann.

Gibt es hier Möglichkeiten? Ich könnte natürlich zur Bedienung über die Oberfläche komplett einen Dummy zwischenschalten und "aufwändig" den Status synchronisieren. Geht das nicht einfacher?

Ich freue mich auf Euren Gedankenaustausch.

Vielen Dank und Gruß

Christian

[LuckyDay]

probiere mal attr <> dummy 1

[Beta-User]

probiere mal attr <> dummy 1

Wäre klasse, wenn das klappt!

Ansonsten: neulich habe ich eine myUtils Funktion gebastelt, die "set"-Befehle an HM-Rolladenaktoren abfängt und ggf. auf einen neuen Wert "umbiegt", wenn das zugehörige Fenster offen ist. Da dauert es zwar uU. einen kleinen Moment, bis das "stop" bzw. "auf" wieder am Aktor ankommt, aber immerhin sollte sich mit so etwas auch das "schlimmste" verhindern lassen.
Code ist hier, Diskussion dazu hier zu finden.

Das zugehörige notify steht als Kommentar im code.

Bitte bei Fragen einfach melden.

Gruß, Beta-User

[cseuss]

Hallo,

danke für die schnelle Rückmeldung.

probiere mal attr <> dummy 1

Bevor ich mich später ransetze: Was passiert mit diesem Attribut genau? Veränderungen von Attributen zur Laufzeit ist ja immer ein bisschen komisch.

Gibt Du mir noch mehr Infos. 

Vielen Dank

[LuckyDay]

  jaja fragen erspart manchmal 1 std Arbeit 

Code Auswählen Erweitern

kannst auch attr <> ignore 1
mal asprobieren, da warne ich dich, weil da verschwindet dein device aus Fhemweb, bekommst du dann nur noch zu Gesicht mit

Code Auswählen Erweitern

attr <> ignore 0 bzw das attr <> ignore über commandfeld  löschen


wenn dir das auch noch zu unsicher ist könntest auch das Device von Fhem lösen mit unpair,
und später mit hmPairSerial xxxxx wieder pairen

[gamauf]

Hallo Christian!
Schau dir mal "cmdalias" an. Damit kannst du einen Befehl auf etwas anderes umbiegen.

LG
Rainer

[martinp876]

ein consolControl inhibit scheint mir eine sinnvolle Erweiterung. das problem haben mehrere. wenn gesetzt wuerden alle kommandos die etwas steuern verhindert. abfragen sind weiter möglich.
man muss beachten, dass nicht nur on und Off betroffen sind. auch pct, press, up, down,... ebenso aktionen wie regset und peerings.
mal sehen am Wochenende

[cseuss]

Hallo,

gibt es schon Neuigkeiten in diesem Thema?

Gruß

Christian

[martinp876]

gerade fertig: Attr readOnly

[cseuss]

Hallo Martin,

prima, vielen Dank.

Eine Umsetzung über set wäre nicht möglich gewesen. Er möchte ja bedarfsabhängig die Fernsteuerung deaktivieren, wenn z.B. eine Tür geöffnet ist.
Mit einem Attribut ändere ich dann ja zur Laufzeit die Konfig. Oder verstehe ich das falsch?

Ich dachte an so was wie "inhibit"

Aber ich will nicht nur nörgeln.

Gruß und schönes Wochenende

Christian

[martinp876]

Beides nicht schlecht. Es muss gespeichert werden um reset zu überleben. Attr oder readings sind möglich. Beides hat nachteile. Attr hat vorteile, da man beim sperren des device alle Kanäle sperrt.

[cseuss]

Hallo Martin,

zunächst noch alles Gute im neuen Jahr 2020.

Hast Du in dieser Thematik noch einmal darüber nachgedacht, ein set-Komando zu implementieren?
Die Lösung über attr verursacht ja m.E., dass ich bei jedem Öffnen oder Schließen der Terassentür die Konfig des Rollanden-Device ändern würde.

Vielen Dank und Gruß vom Niederrhein.

Christian

[cseuss]

push

[Pfriemler]

ACK.
Das Attribut "readOnly" ist ein guter Schritt. Ich würde es ganz anders angehen.

Ein set-Kommando zur Verhinderung von Aktionen durch peers haben wir ja bereits und es wird genutzt: inhibit.
Es bräuchte einen Mechanismus, der die Ausführungen von set-Kommandos durch die Zentrale (also via CUL_HM) dazu bringt, bedarfsweise (und das könnte durch ein Attribut wie "inhibitBlocksGlobal" (Vorschlag) festgelegt sein) vom Wert des "inhibit" abhängig zu machen (was aufgrund von fehlenden Rückmeldungen nur "set_on" oder "set_off" ist derzeit, aber das ist ja auch abzufangen).

So könnte man für jeden Aktor per Attribut festlegen, ob ein inhibit nur auf peers oder auch auf Zentralensteuerung wirkt.

[frank]

funktioniert das nicht schon mit attr dummy?