Tag/Nacht-Objekt mit externer Zeit realisieren

[Art Mooney]

Die Zeilen waren aus dem smarthome.py/var/log/smarthome.log

Im Backend eben nachgeschaut, es hat auch dort den Wert. Die Zeit wird auch entsprechend in der smartVISU angezeigt.

[Art Mooney]

muss ich der Logik noch sagen, dass der Wert auch auf den Bus gesendet werden soll, vielleicht?

[Art Mooney]

Noch was ausprobiert: habe die obere Zeitgrenze für Tagobjekt=true von 20:30 auf 23:30 gesetzt. Jetzt wird das item im Backend richtig als true angezeigt. Es scheint, die Logik funktioniert, der Wert wird nur nicht auf den Bus geschickt.

Was muss ich dafür noch einstellen?

[smai]

Hat denn nicht auch das eval funktioniert? Ich sehe da keinen Unterschied zur Logik.
Hast du immer nur auf dem Bus geschaut?

[Art Mooney]

Beim eval hatte ich ja beim ersten Ansatz auch im Backend keinen Erfolg gesehen. Bei den anderen Versuchen danach habe ich Fehlermeldungen im Log gesehen. So weit wie jetzt gerade war ich vorher nicht. Jetzt muss der Wert nur noch auf den Bus. Muss ich dafür im Item noch etwas angeben? Der Wert passt ja jetzt.

[bmx]

Du solltest noch eine Ergänzung auf None einfügen:

#Tagobjekt ist 1 am Tag und 0 bei Nacht
if sh.zeit.uhrzeit() is not None:
    if sh.zeit.uhrzeit() > datetime.time(6, 30) and sh.zeit.uhrzeit() < datetime.time(20, 30):
        sh.zeit.tagobjekt('true')
    else:
        sh.zeit.tagobjekt('false')

und IMHO könnte ein enforce_updates helfen zum Sende

zeit:
    datum:
        type: foo
        knx_dpt: 11
        knx_listen: 7/0/212
        visu_acl: rw
    uhrzeit:
        type: foo
        knx_dpt: 10
        knx_listen: 7/0/211
        visu_acl: rw
    tagobjekt:
        type: bool
        knx_dpt: 1
        knx_send: 0/0/222
        visu_acl: rw
        enforce_updates: true

[smai]

Du hattest keine Fehler, sondern Warnungen.
Und diese waren ja erklärbar beim Start. Du kannst sie also ignorieren.

Wenn du es mit der Logik lösen willst, solltest du unbedingt die Hochkommas um true und false entfernen. Einen String zu schicken, der dann in ein bool gecasted wird, ist nicht sinnvoll.
Alternativ gilt dasselbe wie beim eval Um einen bool zu setzen, braucht es kein if. Die tagobjekt.py könnte einfach so ausdehen:

sh.zeit.tagobjekt(sh.zeit.uhrzeit() > datetime.time(6, 30) and sh.zeit.uhrzeit() < datetime.time(20, 30))

Ich finde aber eine Logik für eine einzelne Zeile überflüssig und es wird nur unübersichtlich dadurch.

[smai]

Nactrag (habe den Beitrag von bmx erst danach gesehen):
Zusammen mit der None-Prüfung entspricht dies genau meinem letzten eval.

[Art Mooney]

Also erstmal: mit dem "enforce_updates: true" kommt das Tagobjekt auf den Bus.

Ich danke Euch für die Unterstützung.

Jetzt probiere ich noch, das Ganze aus der Logik wieder in das Item zu bringen, da ich es auch übersichtlicher finde.

[smai]

Zur Info: Das enforce_updates bewirkt, dass bei jeder empfangenen Uhrzeit das tagobjekt erneut gesendet wird.

[bmx]

Sowas könnte funktionieren denke ich:

eval: None if sh.zeit.uhrzeit() is None else sh.zeit.uhrzeit() > datetime.time(6, 30) and sh.zeit.uhrzeit() < datetime.time(20, 30)

Ich persönlich finde Logiken praktischer weil man die zur Laufzeit ändern und auslösen kann. Außerdem haben die den Vorteil des Logging.

[smai]

Sowas könnte funktionieren denke ich:

eval: None if sh.zeit.uhrzeit() is None else sh.zeit.uhrzeit() > datetime.time(6, 30) and sh.zeit.uhrzeit() < datetime.time(20, 30)

Dasselbe (in umgekehrter Reihenfolge) hatte ich ja schon in #24 geschrieben.

Ich persönlich finde Logiken praktischer weil man die zur Laufzeit ändern und auslösen kann. Außerdem haben die den Vorteil des Logging.

Das ist wohl Geschmacksache.
Ich mag Logiken für solche Fälle nicht, weil sie völlig entkoppelt vom Ziel-Item sind. So können andere Quellen den Wert des Items ohne auslösen der Logik ändern.
Das Reload ist zum Testen aber tatsächlich praktisch.

[Msinn]

Ich mag Logiken für solche Fälle nicht, weil sie völlig entkoppelt vom Ziel-Item sind. So können andere Quellen den Wert des Items ohne auslösen der Logik ändern.

Ob das möglich ist, hängt davon ab wie Du den Trigger für die Logik definierst.

[mumpf]

Hi Martin,

wie weit bist Du denn mit Deiner Idee, auch den eval eines Items zur Laufzeit ändern zu können? Selbst wenn das nur im Backend ginge, könnte man ohne Neustart so lange probieren, bis es funktioniert und dann per Copy&Paste in die eigentliche Item-Source übertragen. Das würde schon vielen helfen...

Gruß, Waldemar

[Msinn]

Hi Waldemar,

das ist noch im Backlog. Ich bin mir nicht sicher ob das ändern des eval Attributes (und evtl. des eval_trigger Attributes) zur Laufzeit es in die v1.6 schaffen. Zumal ich das Frontend um dieses zu tun gerne gleich im kommenden neuen Admin Interface implementieren würde und nicht mehr im Backend.