Bester Weg, Kommandos bedingungsabhängig zu sperren?

[mmattern]

Dass es einen allg. Bedarf gibt, kommandos zu sperren, sehe ich nicht. Wenn doch, dann solltest du es in der zentrale einkippen- dann brauchen es andere auch.
Wenn du die eingebauten nicht brauchst, schalte sie ab. Fuer alle anderen peers: peere nicht direkt sondern schalte per notify. Inhibit gefaellt dir ja nicht.
Du kannst auch eine eigene entity creieren die dann kommamdos an die hmdevices sendet.
Das aendern von culhm schneidet dich von updazes
updates ab

Hi Martin,

ich habe es im wesentlichen geschrieben für den Fall, dass jemand anders per Google drauf kommt... mag gut sein, dass ich derzeit der Einzige bin, der sich das wünscht und kann gut damit leben, das nach FHEM- oder CULHM-Updates immer wieder manuell nachzutragen...
Inhibit nutze ich parallel, um in definierten Situationen das direkte Schalten am Aktor zu unterbinden. Die internen Peerings von self01/self02 so umzubiegen, dass ich per notify dran komme, ist mir nicht gelungen und ich denke, das ist in der Firmware fest verdrahtet - oder habe ich etwas übersehen?

Viele Grüße
Michael

[martinp876]

Hallo Michael,

- sollte der Bedarf bestehen, kommandos zu sperren ist das kein FHEM-HM spezifika. das sollte dann generell eingekippt werden - in der Zentrale. Ich werden es ggf entsprechend einbauen.

- die internen peers kann man nicht abfangen. man kann die Reaktion ändern oder disabeln. Einen trigger erhält man für den Taster nie (ohne FW änderung). Ich habe verstanden, dass du auf die internen verzichten kannst - also schalte sie ab. Das ist möglich.
- die externen kannst du über FHEM schalten und dort ein eigenes Inhibit berücksichtigen.

Für das sperren der Kommandos würde ich mir ein eigenes modul bauen (99 myutil) das die HM aktoren steuert - und disabled. Für den Fall, dass im Kernal das sperren nicht eingebaut wird - oder du den Vorschlag nicht vortragen willst
Gruss Martin