Hallo zusammen,
folgende Situation - ich habe ein Velux-Dachfenster nachgerüstet mit einem
a) elektrischen Rolladenmotor (hängt an HM-LC-Bl1PBU-FM)
b) elektrischen Kettenantrieb (hängt ebenfalls an einem HM-LC-Bl1PBU-FM)
c) Fenstergriff-Sensor HM-SEC-RHS
Ich möchte nun folgendes sicherstellen:
1) sofern der Fenstergriff geschlossen ist, soll es nicht möglich sein, das Fenster mittels des Kettenantriebs zu öffnen
2) sofern das Fenster mittels Kettenantrieb hochgefahren ist, soll es nicht möglich sein, den Rolladen herunterzufahren
3) sofern der Rolladen heruntergefahren ist, soll es nicht möglich sein, das Fenster mittels des Kettenantriebs zu öffnen
Ich habe es mal versucht mit einem Notify auf set_.* an den Antriebs-Aktoren, das reagiert aber zu langsam... und ich bin mir auch nicht sicher, dass man das "set_off"-Event bekommt, wenn direkt am Aktor geschaltet wird...
Frage ist also:
a) ist es möglich, den Befehl zum Schließen des Fensters, Schließen des Rolladens etc. in einer Art Callback-Funktion abzubrechen, bevor es ausgeführt wird?
oder b) alternativ: ist es möglich, z.B. den Befehl "off" für den Rolladen zu sperren, sobald das Fenster geöffnet ist?
Vielen Dank & beste Grüße
Michael
Inhibit schaltet die lokalen Tasten ab
Bleibt dann noch etwas Logik in fhem über
Gesendet von meinem iPad mit Tapatalk
Zitat von: Wuppi68 am 11 Juli 2014, 16:23:08
Inhibit schaltet die lokalen Tasten ab
Bleibt dann noch etwas Logik in fhem über
Gesendet von meinem iPad mit Tapatalk
Hallo Wuppi68,
vielen Dank dafür - dadurch wird aber noch nicht verhindert, dass man z.B. über Web Command das Fenster öffnet o.ä. - d.h. "set Rolladen_XXX off" in FHEM fährt immer noch den Rolladen herunter...
Es wäre halt cool zu wissen, wie die Event-Verarbeitung in FHEM funktioniert und ob man dort Kommandos zwischen "set" und Ausführung noch löschen kann...
also generalisiert:
1) set <Aktor> <Zielwert>
2) Filterlogik prüft, ob Befehl durchgeführt werden darf
3) FHEM gibt Kommando nur dann an Aktor weiter, wenn diese Prüfung positiv ist...
Falls es das noch nicht gibt, schaue ich es mir mal an...
Viele Grüße
Michael
ich meine nach inhibit on ist alles gesperrt bis es wider aufgehoben wird. also auch die steuerung. aus fhem heraus.
gruss
andre
Zitat von: justme1968 am 11 Juli 2014, 17:33:17
ich meine nach inhibit on ist alles gesperrt bis es wider aufgehoben wird. also auch die steuerung. aus fhem heraus.
gruss
andre
Hallo,
habe etwas anderes gefunden:
attr <Aktor> ignore 1 sperrt alles (set-Kommandos werden dann nicht mehr verarbeitet),
attr <Aktor> ignore 0 hebt die Sperrung wieder auf...
Viele Grüße
Michael
das verhindert aber die lokale bedienung nicht und das device taucht im web interface und bei list nicht mehr auf.
gruss
andre
alle "set Rollo" ersetzen durch
secureset("Rollo") ??
und dann die Funktion (natürlich jetzt nur grob und nicht zu Ende gedacht) hinterlegen:
sub secureset{
$name=$_[0];
$status=$_[1];
if($value{"fenstergriff_".$name} eq "auf"){
fhem "set $name $status";
}else{
notify("Unerlaubter Zugriff...bla", ..., ...);
}
}
Ich kann bestätigen, dass inhibit alle Aktionen im Aktor unterbindet, sowohl durch lokale Taster als auch durch Funkkommandos.
Kai
Zitat von: kaihs am 11 Juli 2014, 18:42:46
Ich kann bestätigen, dass inhibit alle Aktionen im Aktor unterbindet, sowohl durch lokale Taster als auch durch Funkkommandos.
Kai
Hallo Kai,
hmm... vielleicht funktioniert das nicht für alle Aktoren?
Hier ist, was ich gerade probiert habe:
set Rolladen.Terrasse.Rechts inhibit onDanach per Web-Command einmal on, einmal off gesetzt - hat er anstandslos ausgeführt...
Im Log dann:
2014.07.11 19:01:40.923 3: CUL_HM set Rolladen.Terrasse.Rechts inhibit on
2014.07.11 19:01:54.527 3: CUL_HM set Rolladen.Terrasse.Rechts on
2014.07.11 19:01:56.891 3: CUL_HM set Rolladen.Terrasse.Rechts offDie lokalen Tasten sind aber lahmgelegt.
Rolladen.Terrasse.Rechts ist ein HM-LC-Bl1PBU-FM.
Muss ich vielleicht noch was anderes einstellen im Aktor, damit das "inhibit" auch für Kommandos per Funk funktioniert?
Hier mal ein "list Rolladen.Terrasse.Rechts":
Internals:
DEF 52A1AA
HMLAN1_MSGCNT 6
HMLAN1_RAWMSG E52A1AA,0000,00508A7A,FF,FFCB,12A41052A1AA26EC1A06010000
HMLAN1_RSSI -53
HMLAN1_TIME 2014-07-11 19:02:11
HMLAN2_MSGCNT 5
HMLAN2_RAWMSG E52A1AA,0000,0F6E4257,FF,FFBE,12A41052A1AA26EC1A06010000
HMLAN2_RSSI -66
HMLAN2_TIME 2014-07-11 19:02:11
HMUSB_MSGCNT 5
HMUSB_RAWMSG E52A1AA,0000,3E3C73DD,FF,FFC6,12A41052A1AA26EC1A06010000
HMUSB_RSSI -58
HMUSB_TIME 2014-07-11 19:02:11
IODev HMLAN1
LASTInputDev HMUSB
MSGCNT 16
NAME Rolladen.Terrasse.Rechts
NR 65
STATE off
TYPE CUL_HM
lastMsg No:12 - t:10 s:52A1AA d:26EC1A 06010000
protLastRcv 2014-07-11 19:02:11
protSnd 6 last_at:2014-07-11 19:02:11
protState CMDs_done
rssi_HMLAN1 lst:-52 max:-39 min:-52 cnt:4 avg:-47
rssi_at_HMLAN1 lst:-53 max:-44 cnt:6 min:-56 avg:-50.33
rssi_at_HMLAN2 lst:-66 max:-66 cnt:5 min:-70 avg:-67
rssi_at_HMUSB min:-61 cnt:5 avg:-58.4 lst:-58 max:-57
Readings:
2014-07-11 19:01:57 CommandAccepted yes
2014-05-02 22:38:18 D-firmware 2.3
2014-05-02 22:38:18 D-serialNr LEQ0069552
2014-05-05 13:49:12 PairedTo 0x26EC1A
2014-05-02 22:38:43 R-confBtnTime 255 min
2014-05-05 13:48:57 R-driveDown 24 s
2014-05-02 22:38:45 R-driveTurn 0.5 s
2014-05-05 13:48:33 R-driveUp 26 s
2014-05-05 13:48:32 R-intKeyVisib invisib
2014-05-05 13:48:32 R-localResDis off
2014-05-05 13:48:32 R-pairCentral 0x26EC1A
2014-05-05 13:48:28 R-refRunCounter 0
2014-05-05 13:48:28 R-sign off
2014-05-02 22:38:45 R-statusInfoMinDly 2 s
2014-05-02 22:38:45 R-statusInfoRandom 1 s
2014-05-05 13:48:28 R-transmitTryMax 6
2014-05-05 13:49:12 RegL_00: 02:01 0A:26 0B:EC 0C:1A 15:FF 18:00 00:00
2014-05-05 13:49:13 RegL_01: 08:00 09:00 0A:00 0B:00 0C:F0 0D:01 0E:04 0F:05 10:00 30:06 57:24 00:00
2014-07-11 19:02:11 deviceMsg off (to HMLAN1)
2014-07-11 19:02:11 level 0
2014-07-11 19:02:11 motor stop:off
2014-07-11 19:02:11 pct 0
2014-07-11 19:02:11 recentStateType info
2014-05-02 20:58:58 running -
2014-07-11 19:02:11 state off
2014-07-11 19:02:11 timedOn off
Helper:
cSnd 1126EC1A52A1AA0201000000
dlvlCmd ++A01126EC1A52A1AA0201000000
mId 006A
rxType 1
Io:
newChn +52A1AA,00,01,00
nextSend 1405098131.91988
rxt 0
p:
52A1AA
00
01
00
Mrssi:
mNo 12
Io:
HMLAN1 -51
HMLAN2 -66
HMUSB -58
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
prs 1
Rpt:
IO HMLAN1
flg A
ts 1405098131.83646
ack:
HASH(0x2e62110)
12800226EC1A52A1AA00
Rssi:
Hmlan1:
avg -47
cnt 4
lst -52
max -39
min -52
At_hmlan1:
avg -50.3333333333333
cnt 6
lst -53
max -44
min -56
At_hmlan2:
avg -67
cnt 5
lst -66
max -66
min -70
At_hmusb:
avg -58.4
cnt 5
lst -58
max -57
min -61
Attributes:
IODev HMLAN1
autoReadReg 4_reqStatus
devStateIcon { rolladen_dsIcon($name) }
expert 2_full
firmware 2.3
fm_type upbutton,downbutton
group Rolladen.Gartenseite,Rolladen
model HM-LC-Bl1PBU-FM
peerIDs 00000000,
room Rolladen,EG,Wohnzimmer,Favourites
serialNr LEQ0069552
subType blindActuator
webCmd 37:on:off Im Endeffekt muss ich wohl beides setzen - der Nebeneffekt von Ignore, dass das Device temporär aus dem Webinterface verschwindet, ist für mich akzeptabel.
Viele Grüße
Michael
Sorry, du hast recht.
Kommandos aus dem fhem Frontend werden nicht ignoriert wenn inihibit on ist.
Allerdings werden die Kommandos eines gepeerten Schalters sehr wohl ignoriert.
Daher war ich davon ausgegangen, dass das für alle Funkkommandos gilt.
Kai
und die device attribute dummy oder disable?
gruss frank
Hm, laut commandref sollte es aber wie erwartet funktionieren:
Zitat
inhibit [on|off]
Block / unblock all changes to the actor channel, i.e. actor state is frozen until inhibit is set off again. Inhibit can be executed on any actor channel but obviously not on sensors - would not make any sense.
Practically it can be used to suspend any notifies as well as peered channel action temporarily without the need to delete them.
Und bei einem meiner Rolladenaktoren tut es das auch, bei dem anderen dagegen nicht.
Werde mal versuchen den Unterschied zu finden.
Kai
Inhibit verhindert, dass das Device trigger annimmt - von anderen Aktoren. Von der Zentrale nimmt es noch kommandos an (so weit ich es bisher gesehen habe). HM denkt wohl, dass man von der Zentrale, von der man es sperrt sowieso entsperren kann.
wenn man "ignore" setzt werden keine Kommandos mehr verarbeitet (auch keine Ankommenden) - das ist evtl nicht sinn der Sache.
"dummy" sperrt das senden des gesamten Device (alle Channel)
Hallo zusammen,
hier ist, was ich jetzt gemacht habe - eine Möglichkeit geschaffen, Device-spezifische Callback-Funktionen zu definieren, die aufgerufen werden, bevor ein set-Befehl an das Device weitergereicht wird mit der Möglichkeit, den Befehl abzubrechen.
Bin auf Kommentare/Anregungen gespannt ;-)
1) ich habe in 10_CUL_HM.pm ein zusätzliches Attribut für alle Devices angelegt: "callbackFor"
[...]
$hash->{Attr}{dev} = "ignore:1,0 dummy:1,0 " # -- device only attributes
."IODev IOList IOgrp callbackFor "
Im Moment ist bei mir "set" der einzige sinnvolle Wert, es ist aber denkbar, das für weitere Kommandos zu erweitern.
Der Plan ist: wenn callbackFor = set gesetzt ist, wird vor Ausführung des set-Kommandos geprüft, ob eine sub mit Namen cb_<device name>_set definiert ist; sollten Punkte (".") im Device-Namen enthalten sein, sind sie im Funktionsnamen durch "_" zu ersetzen (Beispiel: Device = "Rolladen.Terrasse.Links", Callback-Funktion müsste dann "cbRolladen_Terrasse_Links_set" heißen, damit sie gefunden wird). Ich lege diese Funktionen in 99_MyUtils.pm an.
2) in fhem.pl, in DoSet ergänzt:
my $retCb = "continue"; # Vorgabe - Kommando wird ausgeführt
if (defined($attr{$dev}{callbackFor})) { # prüfen, ob "callbackFor"-Attribut gesetzt...
my $callbackFor = $attr{$dev}{callbackFor};
if ($callbackFor =~ m/.*set.*/) { # ...und das für "set"
Log 3, "callback function for 'set' defined";
my $cbFnName = "cb" . $dev . "_set"; # Funktionsnamen ermitteln
$cbFnName =~ tr|.|_|;
if (!defined(&$cbFnName)) { # prüfen, ob Funktion existiert
Log(3, "fhem.pl - DoSet - callback function '$cbFnName' not defined!");
} else {
my $cbFn = \&{$cbFnName};
no strict "refs";
$retCb = $cbFn->(@_); # Callback-Funktion aufrufen mit ursprünglichen Parametern des set-Kommandos
use strict "refs";
}
Log(3, "fhem.pl - DoSet - retCb = '$retCb'");
}
}
if ($retCb ne "abort") { # falls Callback-Funktion "abort" zurückgibt, wird die Weitergabe des Kommandos an das Device unterbunden
my ($ret, $skipTrigger) = CallFn($dev, "SetFn", $hash, @a);
return $ret if($ret);
return undef if($skipTrigger);
} else {
Log(3, "fhem.pl - DoSet - set command aborted");
return undef;
}
Funktioniert prima... und werde ich sicher noch für weitere Zwecke verwenden...
Das Schalten am Aktor selbst kann ich derzeit leider nur über "ignore" unterbinden - grundsätzlich lieber wäre es mir, wenn ich in FHEM das Betätigen des Schalters am Aktor mitbekommen würde und dann entsprechend reagieren könnte - die ActionTypes für self01 und self02 würde ich dann auf "off" setzen. Aber dazu wäre wohl eine Custom-Firmware für den Rolladen-Aktor nötig (analog der für den Unterputz-Schaltaktor 1-fach...).
Viele Grüße
Michael
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
Zitat von: martinp876 am 17 Juli 2014, 20:33:26
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
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