logic/plugin - Nachts nachdimmen

[2ndsky]

Daran sieht man, dass so etwas als Plugin für alle in einem Repo wohl ungeeignet ist. Mit der Helligkeit könnte ich z.B. nicht arbeiten. Beispiel: Unser Flur EG wird nach 22 Uhr auf nur noch 30% gedimmt. Das reicht zum auf die Toilette gehen. Im Winter wird es früh dunkel. Wenn wir also um 20 Uhr vom Einkaufen kommen, dann will ich im Flur Licht haben. Gesteuert über die Helligkeit würde das z.B. nicht funktionieren.

[greentux]

Naja, die Szene "schlafen" wird natürlich noch ausgewertet

[Robert]

Hi!

Sorry, ich wollte nicht den Thread kapern. Intention war, alles was in Richtung "nachts nachdimmen" geht zusammenzuhalten. Klar gibt es da mehrere Wege.

Ja, ein Plugin könnte die von mir gewünschten Funktionen abdecken, aber in der Tat würde ich "Plugins" hier wirklich eher in Richtung "Bindings" verstehen. Evtl. wäre das auch langfristig ein passenderer Name?

Das auswählen der Items per Wildcard ist schon mal gut. Allerdings würden dann auch etliche Lampen ausgewählt, die kein Attribut "night_brightness" o.Ä. haben. Eine Frage die hier weiter verfolgt werden sollte: https://knx-user-forum.de/smarthome-...tml#post320803

Zudem: Lauffähige, halbwegs dokumentierte Logiken könnten doch schon unter "examples". Dort könnte es eine Logik geben, die es abhängig von der Zeit machen, eine die es abh. vom Status ("Nachtmodus") macht und halt auch eine abh. von der (Außen?)Helligkeit.

Grüße
Robert

[2ndsky]

Also nur wenn "schlafen" aktiviert ist? Und wenn du am WE länger schläfst und es draußen schon hell ist, aber die Rollläden noch unten wird höher gedimmt als wenn du nachts Pipi musst?

[JuMi2006]

Also Logiken zentral zu sammeln sollte schon irgendwo machbar sein.
Dass die Logiken und Plugins sich i.S.v. "WireGate-Plugins" unterscheiden ist auch klar. Aber gerade deswegen...warum sollte eine logic nicht so ausgereift sein dass sie möglichst viele Anwendungsfälle abdeckt? Den Vergleich Binding=Plugin finde ich sehr passend.

Ich werde mir das erstmal so einbauen wie von Niko vorgeschlagen oder arbeitet Robert parallel daran? Unterschiedliche Logiken für die Anwendungsfälle bedarf es imho nicht. Im jetzigen Stand wird ja sowohl ein Objekt als auch die Uhrzeit unabhängig überwacht. Dann fügen wir eben die Helligkeit noch mit ein oder der Spezialfall nutzt noch ein weitere Logik.

Was mir garnicht gefällt ist die Tatsache dass jeder seine eigenen Logiken zusammenstricken soll weil sie einfach nirgends gesammelt sind. Ein "kapern" des Threads sehe ich nicht ... die (hoffentlich nicht ergebnisoffene) Diskussion fördert das Verständnis und lässt was anständiges entstehen.

[callidomus]

Ich dachte daran, das die Logiken einfach im SmartHome.py Wiki gesammelt werden. Darin darf jeder git-Benutzer editieren.

Man könnte dadurch eine die Logik und eine kleine Beschreibung aktuell halten.

Bis bald

Marcus

[JuMi2006]

Wie komme ich denn an das item welches die logic ausgelöst hat?

[Robert]

trigger['source']

SmartHome.py - Logic Configuration

[JuMi2006]

Danke.

Habs beim zweiten lesen auch gerade überblickt und wollte zurückrudern ... ich dachte es müsste ein logic.trigger['source'] sein ...

[Robert]

Hi!

Mein Quick-Hack gestern (nachdem ich per ETS das manuelle vom automatischen Licht anschalten per GA getrennt hatte):

item.conf

[Nachtmodus]
  type = bool
  visu = yes
  knx_dpt = 1
  knx_cache = 0/4/3 

[Wohnzimmer]
  [[Essbereich]]
    [[[Haengelampe]]]
      type = bool
      visu = yes
      knx_dpt = 1
      knx_send = 2/1/204
      knx_cache = 2/1/204
      [[[[Automatikschalter]]]]
        type = bool
        enforce_updates = true
        knx_dpt = 1
        knx_listen = 5/1/206
        nacht_helligkeitswert = 40
      [[[[Helligkeitswert]]]]
        type = num
        visu = yes
        knx_dpt = 5001
        knx_send = 2/1/206
        knx_cache = 2/1/206

logic.conf

[nachtbeleuchtung]
    filename = 'nachtbeleuchtung.py'
    watch_item = *.Automatikschalter

Selektiert ALLE Items die auf 'Automatikschalter' enden - hier wäre nun ein Filter auf Basis von Attributen gut, siehe:

nachtbeleuchtung.conf

#!/usr/bin/env python

if not sh.Nachtmodus:
    exit()

source_item = sh.return_item(trigger['source'])
# check if switching off (0)
if not source_item:
    exit()

# check for attribute
if 'nacht_helligkeitswert' not in source_item.conf:
    logger.warning('LOGIC---{0}---: {1} lacks attribute \'nacht_helligkeitswert\''.format(logic.name, source_item))
    exit()
    
parent_item = source_item.return_parent()
#if '{0}.Helligkeitswert'.format(parent_item) not in parent_item.return_children():
#    logger.warning('LOGIC---{0}---: {1} lacks sibling {2}.Helligkeitswert'.format(logic.name, source_item, parent_item))
#    exit()
    
parent_item.Helligkeitswert(source_item.conf['nacht_helligkeitswert'])

- Das prüfen, ob das Attribut 'Helligkeit' existiert, könnte man sich sparen wenn man watch_item filtern könnte.
- Etwas seltsam ist, dass man die Attribute von "logic" und "plugin" mit 'hasattr' checken kann, während "item" ein dictionary '.conf' verwendet. Vielleicht kann man das vereinheitlichen?
- Gibt es eine elegante Methode, ob ein Item ein Schwester-Item x hat? Also Umweg über 'return_parent()', dann aber nicht über 'return_children()' iterieren?
- Aufgrund der 'exit()' habe ich noch fiese Probleme mit der Zuverlässigkeit. Ich gehe stark davon aus, dass das mit https://knx-user-forum.de/smarthome-...telegramm.html zusammenhängt und mittlerweile im git bzw. Release 0.9 behoben ist (prüfe ich heute Abend)

Generell:
+ Das logic.py und die logic.conf sind schön kompakt (da kommt logischweise noch mehr hinzu).
+ Die Dimmwerte usw. sind unmittelbar dem Item zugeordnet (in der item.conf)
- Die Dimmwerte usw. sind unmittelbar dem Item zugeordnet (in der item.conf)
(ich bin mir gar nicht mehr so sicher ob das übersichtlicher ist...)

Grüße
Robert