Eigentlich suche ich seit Jahren schon nach einer einfacher Lösung den Präsenzmelder (MDT) in bestimmten Situationen sperren zu können. Das Ganze ist immer relativ aufwändig über mehrere Logiken. Nun wollte ich das ändern, damit es übersichtlicher ist und das direkt in SmartHomeNG umsetzen. Es läuft aber nicht erwartungsgeäß, weil die Sperre nicht mehr aufzuheben ist. Sinn und Zweck ist das Licht mit dem Präsenzmelder zu schalten, gleichzeitig aber auch mit einem Tastsensor und auch mit der SmartVISU.
Mittels Sperre_erlauben kann man überhaupt festlegen, ob der entsprechende Päsenzmelder (mit der Betätigung des Tastsensors AUS) gesperrt werden kann, mit automatisch_entsperren legt man fest, dass die Sperre beendet wird, wenn die Rolläden sich entweder komplett geöffnet oder komplett geschlossen haben. Das soll man dann in der VISU pro Raum auch konfigurieren können.
Das Problem ist aber der Punkt schalten. Ich habe es bewusst so gelegt, dass ich dort 2 lesende Adressen eingefügt habe. Denn an knx_send und an knx_listen ist der Tastsensor angebunden, dessen Gruppenadresse am externen Tastereingang des PM angebunden ist. Dennoch möchte ich aber ermitteln, ob das Licht an ist, was ich mit knx_cache an der GA des Schaltaktors gemacht habe, um das in der Visu anzuzeigen. Und da wird ein wenig kompliziert. Denn ich möchte:
- am Tastsensor an- und aussschalten können
- in der Visu an- und ausschalten können (Ersatz für Tastsensor)
- Statusrückmeldungen sowohl in der Visu (auch bei Neustart) als auch in KNX
Das Problem ist nun, dass der gesperrte Präsenzmelder sich nicht wieder wecken lässt, zumindest nicht nach einer Betätigung. Ich habe das zwar versucht zu lösen, indem ich "- .self = True if value and not sh...sperren() and not sh...sperren.prev_value() else None" zugefügt habe, weil der PM natürlich nicht angeht, aber das geht auch nicht. Gibt es da schlauere Lösungen?
Hier der Code aus meinem Item-struct:
Und hier aus der entsprechenden Item-yaml.
Sonst habe ich noch 2 Anmerkungen:
1. Ich finde die Umsetzung mit den structs grandios, denn so vereinfacht man dich vieles, weil es einfach übersichtlicher wird. Stück für Stück setze ich alle meine Items damit um.
2. Die Properties funktionieren, wie ich schon mal anmerkte nicht immer zuverlässig. So ist ein Ersatz der Zeile oben, durch ein property "- .self = True if value and not sh...sperren() and not sh...sperren.last_value else None" nicht möglich, weil dann ein Fehler auftritt: 'Item' object has no attribute 'last_value'. Ferner sind auch die Bezeichnungen verwirrend, weil das property last_value der Funktion prev_value() entspricht und nicht dem Property prev_value. Bei beidem würde ich mir Änderungen wünschen. Auch wenn klar ist, dass ein umbennenen von Funktionen oder Properties dazu führen müsste, dass bei einem Update auch vorhandene Items und Logiken korrigiert werden müssten. Es wäre aber auf lange Sicht konsequenter.
Mittels Sperre_erlauben kann man überhaupt festlegen, ob der entsprechende Päsenzmelder (mit der Betätigung des Tastsensors AUS) gesperrt werden kann, mit automatisch_entsperren legt man fest, dass die Sperre beendet wird, wenn die Rolläden sich entweder komplett geöffnet oder komplett geschlossen haben. Das soll man dann in der VISU pro Raum auch konfigurieren können.
Das Problem ist aber der Punkt schalten. Ich habe es bewusst so gelegt, dass ich dort 2 lesende Adressen eingefügt habe. Denn an knx_send und an knx_listen ist der Tastsensor angebunden, dessen Gruppenadresse am externen Tastereingang des PM angebunden ist. Dennoch möchte ich aber ermitteln, ob das Licht an ist, was ich mit knx_cache an der GA des Schaltaktors gemacht habe, um das in der Visu anzuzeigen. Und da wird ein wenig kompliziert. Denn ich möchte:
- am Tastsensor an- und aussschalten können
- in der Visu an- und ausschalten können (Ersatz für Tastsensor)
- Statusrückmeldungen sowohl in der Visu (auch bei Neustart) als auch in KNX
Das Problem ist nun, dass der gesperrte Präsenzmelder sich nicht wieder wecken lässt, zumindest nicht nach einer Betätigung. Ich habe das zwar versucht zu lösen, indem ich "- .self = True if value and not sh...sperren() and not sh...sperren.prev_value() else None" zugefügt habe, weil der PM natürlich nicht angeht, aber das geht auch nicht. Gibt es da schlauere Lösungen?
Hier der Code aus meinem Item-struct:
Code:
# Schalten und ggf. Präsenzmelder (Licht/DALI) sperren
Schalten_mit_Sperrfunktion:
schalten:
type: bool
knx_dpt: 1
visu_acl: rw
on_change:
- ..sperren = not value if sh...Sperre_erlauben() else None
- .self = True if value and not sh...sperren() and not sh...sperren.prev_value() else None
Sperre_erlauben:
type: bool
initial_value: False
visu_acl: rw
cache: yes
automatisch_entsperren:
type: bool
initial_value: False
visu_acl: rw
cache: yes
sperren:
type: bool
knx_dpt: 1
visu_acl: rw
cache: yes
entsperren:
type: bool
visu_acl: ro
eval: value if sh....automatisch_entsperren() else None
eval_trigger:
- .....Rollladen.ist_oben
- .....Rollladen.ist_unten
on_change: ..self = False
Code:
WC:
Licht:
Decke:
struct: Schalten_mit_Sperrfunktion
schalten:
knx_send: 0/5/1
knx_cache: 0/2/4
knx_listen: 0/5/1
sperren:
knx_send: 0/4/6
knx_reply: 0/4/6
1. Ich finde die Umsetzung mit den structs grandios, denn so vereinfacht man dich vieles, weil es einfach übersichtlicher wird. Stück für Stück setze ich alle meine Items damit um.
2. Die Properties funktionieren, wie ich schon mal anmerkte nicht immer zuverlässig. So ist ein Ersatz der Zeile oben, durch ein property "- .self = True if value and not sh...sperren() and not sh...sperren.last_value else None" nicht möglich, weil dann ein Fehler auftritt: 'Item' object has no attribute 'last_value'. Ferner sind auch die Bezeichnungen verwirrend, weil das property last_value der Funktion prev_value() entspricht und nicht dem Property prev_value. Bei beidem würde ich mir Änderungen wünschen. Auch wenn klar ist, dass ein umbennenen von Funktionen oder Properties dazu führen müsste, dass bei einem Update auch vorhandene Items und Logiken korrigiert werden müssten. Es wäre aber auf lange Sicht konsequenter.
)
Kommentar