Items: Tipps und Tricks
Invertieren eines Item Wertes
Beispiel 1
Es geht um einen Reed-Kontakt am Fenster, der über einen 1-Wire Multi-I/O-Sensor per 1-Wire-Plugin abgefragt und auf den KNX-Bus gesendet wird.
Leider sind die Werte vertauscht, 0 soll 1 sein und umgekehrt, ein geschlossenes Fenster wird geöffnet angezeigt und umgekehrt.
Ein eval:
Attribut zum Item hinzufügen. eval: not value
Value
ist der Wert, der vom KNX Bus gelesen wird, der eval Ausdruck verändert
diesen Wert, bevor er in das Item geschrieben wird. Damit wird dann der
invertierte Wert auf den KNX Bus geschrieben.
OW:
Fenster:
EsszimmerLinks:
type: bool
visu_acl: rw
ow_addr: 3A.CBF713000000
ow_sensor: IB
knx_dpt: 1
knx_send: 2/1/82
knx_reply: 2/1/82
eval: not value
Beispiel 2
Es geht um einen Lautsprecher, der über einen GPIO Kontakt des Raspberry geschaltet werden soll. Der Wert kommt von einem Item das per knx bedient wird und dessen Item Wert nicht verfälscht werden soll.
Leider sind auch hier die Werte vertauscht, 0 soll 1 sein und umgekehrt.
Ein Hilfsitem hinzufügen und diesem mit relativer Adressierung auf das Elternelement
ein eval_trigger
und ein eval
zufügen.
Gaestezimmer_Lautsprecher:
type: bool
knx_dpt: 1
knx_listen: 5/0/5
visu_acl: rw
GPIO_Ausgabe:
type: bool
gpio_out: 38
eval: not sh...()
eval_trigger: ..
Item Strukturen bequem kopieren mit Hilfe relativer Item Adressierung
Es sollen Fensterkontakte ausgewertet werden (zwei Kontakte je Fenster oder z.B. Hoppe Fenstergriffe). Hierbei ergeben zwei Kontakte drei sinnvolle Stati (verschlossen, gekippt, offen). Die Auswertung setzt die Informationen der zwei Kontakte auf eigene Items für die drei Stati um.
Diese Lösung soll mit möglichst wenig Aufwand für alle Fenster des Objekts kopiert werden. Mit normaler (absoluter) Item Adressierung kann das folgendermaßen gelöst werden:
Test:
Buero:
Reed1:
type: num
knx_dpt: 1
knx_cache: 4/1/5
visu_acl: rw
Reed2:
type: num
knx_dpt: 1
knx_cache: 4/1/6
visu_acl: rw
zu:
type: bool
enforce_updates: yes
eval: True if sh.Test.Buero.Reed1() == 1 and sh.Test.Buero.Reed2() == 1 else False
eval_trigger:
- Test.Buero.Reed1
- Test.Buero.Reed2
gekippt:
type: bool
enforce_updates: yes
eval: True if sh.Test.Buero.Reed1() == 0 and sh.Test.Buero.Reed2() == 1 else False
eval_trigger:
- Test.Buero.Reed1
- Test.Buero.Reed2
offen:
type: bool
enforce_updates: yes
eval: True if sh.Test.Buero.Reed1() == 0 and sh.Test.Buero.Reed2() == 0 else False
eval_trigger:
- Test.Buero.Reed1
- Test.Buero.Reed2
Wenn dieser Block für weitere Fenster kopiert wird, muss jedoch außer
der Anpassung der Adressen für Reed1
und Reed2
auch noch
Buero
an diversen Stellen ersetzt werden, was einen gewissen Aufwand
erfordert und auch noch fehlerträchtig ist.
Mit relativer Item Adressierung kann das einfacher gelöst werden. Dann
müssen nach dem Kopieren des Blocks nur noch die Adressen für Reed1
und Reed2
angepasst werden:
Test:
Buero:
Reed1:
type: num
knx_dpt: 1
knx_cache: 4/1/5
visu_acl: rw
Reed2:
type: num
knx_dpt: 1
knx_cache: 4/1/6
visu_acl: rw
zu:
type: bool
enforce_updates: yes
eval: True if sh...Reed1() == 1 and sh...Reed2() == 1 else False
eval_trigger:
- ..Reed1
- ..Reed2
gekippt:
type: bool
enforce_updates: yes
eval: True if sh...Reed1() == 0 and sh...Reed2() == 1 else False
eval_trigger:
- ..Reed1
- ..Reed2
offen:
type: bool
enforce_updates: yes
eval: True if sh...Reed1() == 0 and sh...Reed2() == 0 else False
eval_trigger:
- ..Reed1
- ..Reed2
..<item>
referenziert hierbei ein Geschwister-Item. Es ist darauf zu
achten, dass dort wo Items über sh.<item>()
angesprochen werden (wie
im eval
Attribut) dann drei statt der erwarteten zwei Punkte stehen.
Ausführliche Informationen zur relativen Item Adressierung sind unter relative Itemreferenzen zu finden.
Das Beispiel ließe sich noch weiter vereinfachen, indem die Einträge durch structs referenziert werden. Detaillierte Informationen hierzu gibt es auf structs (Item Strukturen)
Nutzung der Tag-/Nacht-Items in KNX
Ein Tag- oder Nachtobjekt kann zur Ansteuerung von Status-LEDs, Präsenzmeldern oder ähnlichem genutzt werden.
Tag-Item: Ist “true” (also 1) von der bürgerlichen Dämmerung am Morgen bis zur Dämmerung am Abend, danach ist es “false” (also 0)
Nacht-Item: Ist “true” (also 1) von der bürgerlichen Dämmerung am Abend bis zur Dämmerung am Morgen, danach ist es “false” (also 0)
Bürgerliche Dämmerung bedeutet, dass sich die Sonne noch/schon unterhalb des Horizonts befindet, der Himmel aber dennoch leicht erhellt wird.
Welches der beiden Items man nutzen will, bleibt jedem selbst überlassen. Schließlich ist der Status des jeweiligen Items bereits eindeutig. Wichtig dafür ist natürlich, dass die richtigen Geo-Koordinaten und die Zeitzone in der Datei ../etc/smarthome.yaml hinterlegt sind sowie die aktuelle Uhrzeit auf dem Rechner eingestellt ist.
Um Tag/Nacht-Items zu erstellen, bringt SmarthomeNG bereits alles mit.
Man kann einfach auf die SmarthomeNG internen Items env.location.day
und env.location.night
zugreifen.
Beispiele
Nutzung mit neuen (zusätzlichen) Items
tag:
type: num
knx_dpt: 1
knx_send: 0/0/103
knx_reply: 0/0/103
eval: sh.env.location.day()
eval_trigger: env.location.day
nacht:
type: num
knx_dpt: 1
knx_send: 0/0/104
knx_reply: 0/0/104
eval: sh.env.location.night()
eval_trigger: env.location.night
Nutzung der SmarthomeNG internen Items
Dazu müssen die entsprechenden Items um die KNX Attribute erweitert werden:
env:
location:
day:
name: Tag
knx_dpt: 1
knx_send: 0/0/103
knx_reply: 0/0/103
night:
name: Nacht
knx_dpt: 1
knx_send: 0/0/104
knx_reply: 0/0/104
Da sich die internen Items von Release zu Release ändern könnten, ist der Weg der zusätzlichen Items zu bevorzugen.
Berechnung von Tag und Nacht
Die Berechnung der Items Tag und Nacht erfolgt SmarthomeNG-intern über sh.sun.rise(-6).day (bürgerliche Dämmerung).
Für eine Beleuchtungssteuerung (z.B. mit KNX) wäre es sinnvoll, die Berechnung von Tag/Nacht anders vorzunehmen, weil z.B. für Flurlichtsteuerung o.ä. vielleicht schon 1h vor Sonnenuntergang die “Nacht” beginnen soll. Das kann durch die Definition neuer Items erreicht werden. Im folgenden Beispiel wird die Tag/Nacht Grenze bei einem Sonnenstand von 4° unter dem Horizont festgelegt:
berechnung:
type: bool
crontab:
- init = 1
- sunrise-4 = 1
- sunset-4 = 1
enforce_updates: true
day:
type: bool
eval: sh.sun.rise(-4).day != sh.sun.set(-4).day
eval_trigger: ..berechnung
enforce_updates: true
Die Triggerung dieser Berechnung wird im berechnung - Item durch das Attribut crontab gesteuert. In diesem Beispiel erfolgt die Berechnung 4° vor Sonnenaufgang, 4° nach Sonnenuntergang, sowie beim Systemstart.