- √ - unterscheiden was die Logik triggert

[Mike01]

Hallo,

Ich würde gerne bei einer Logik unterscheiden, ob die Logik durch einen Tasterbefehl oder durch einen crontab aufruf getriggert wurde, es will mir aber nicht so recht klappen.

Vorgeschichte: :-)
Ich will folgendes vorhaben realisieren:
Ich hab einen Taster als UM Programmiert, der mir meine Heizung im Raum zwischen 2 Betriebsarten wechselt, beim 1-Befehl soll er die heizung in Frostschutz schalten, und beim 0-Befehl soll er die Heizung in den Standby Betrieb und nach 15 min. wieder in den Komfortbetrieb schalten.
Das funktioniert auch soweit, jedoch würde ich gerne um 23:00 Uhr die Heizung absenken in den Standbybetrieb, das soll über einen Crontab Befehl funktionieren. Bisher hatte ich in der item.conf direkt die Betriebsart geschaltet, was immer funktioniert hat, allerdings muß man dann je nach Tasterstellung das nächste mal den Taster 2x betätigen, da er den Betriebsartwechsel nicht direkt mitbekommt.

Deshalb würde ich das ganze jetzt in einer Logik lösen.
Die Logik wird ja bereits über den Taster getriggert, und die Befehle werden gesendet, wird die Logik aber über den crontab getriggert, sieht man im Logfile, dass die Logik aufgerufen wird, aber es werden keine Befehle gesendet.

logic.conf

[Heizungen]
     filename = 'heizung.py'
     watch_item = *.*.heizung.lueften
     crontab = 0 23 * *

heizung.py

#!/usr/bin/env python

if trigger['by']=='Item' and trigger['source']=='og.wohnen.heizung.lueften':
  if trigger['value']==True:
    sh.og.wohnen.heizung.modus(4)
  if trigger['value']==False:
    sh.og.wohnen.heizung.modus(2)
    sh.og.wohnen.heizung.modus.timer('15m', 1)

if trigger['by']=='Scheduler':
  sh.og.wohnen.heizung.lueften('False')
  sh.og.wohnen.heizung.modus(2)

2. Problem:
Wenn der Crontab den knx Befehl für den Taster rücksetzen sendet, wie kann ich dann verhindern dass er mir die Logik erneut durch das Tasteritem triggert ?

mfg Mike

[2ndsky]

Bisher hatte ich in der item.conf direkt die Betriebsart geschaltet, was immer funktioniert hat, allerdings muß man dann je nach Tasterstellung das nächste mal den Taster 2x betätigen, da er den Betriebsartwechsel nicht direkt mitbekommt.

Hast du ein knx_send an dem Item? Denn dann sollte er die Umstellung mitbekommen. Manche Taster haben für UM ein spezielles KO um den Status vom Bus zu lesen und machen das nicht über das KO zum Senden. Vielleicht mal danach schauen.

[Mike01]

Danke für deine Antwort,

Das Problem mit der Rückmeldung ist ja, dass der UM Befehl nur ein simpler 0/1 Befehl ist, dadurch kann der Taster mit der Rückmeldung auch nur auf ein 1-Bit Telegramm hören, der Betriebsmodus der Heizung ist aber ein 1-Byte Wert.
Mit dem Crontab in der item schalte ich bisher nur den Bytewert des Betriebsmodus um, das kriegt dann der Taster nicht mit.

Der Schalter soll als Heizungsabschaltung beim Lüften des Raumes dienen, weil leider keine Fensterkontakte und nur Objektthermostate vorhanden sind.
Im Winter hat das ganze so super funktioniert, weil der Taster wurde gedrückt, Raum wurde gelüftet, und nach 10 min. wurde der Taster wieder gedrückt, und die Heizung schaltete auf Standby und nach 15min. wieder auf Komfort, nur jetzt wo es draußen wärmer wird wird der Taster beim öffnen der Terrassentür auch gedrückt, und dann reicht meist die Wärme aus, so dass der Taster abends nicht mehr gedrückt wird sondern auf Frostschutz bleibt. Um 23:00 Uhr schaltet dann der Scheduler auf Standby und der Tasterzustand bleibt dann leider unverändert. Am nächsten Morgen hat man dann den effekt dass man 2x auf den Taster drücken muss.

Ich bin auch für jeden anderen Lösungsvorschlag dankbar, wenn jemand einen besseren vorschlag hat wie ich das ganze lösen könnte.

[2ndsky]

Mach doch an dem Bit Item für UM noch zusätzlich ein eval und eval_trigger in dem du den Heizungsstatus auswertest und dementsprechend den Wert für das UM Item setzt.

[Mike01]

Bin mir nicht sicher ob ich jetzt das selbe meine wie du, aber hab grad nen neuen Lösungsansatz: Es wäre ja egal ob der Taster 0 oder 1 sendet, bei jedem Tastendruck wird mit eval die Logik getriggert, und damit frage ich dann nicht den Tasterzustand, sondern den Heizungszustand ab.
Wenn Komfortbetrieb, muss bei Tastendruck auf Frostschutz schalten, und wenn nicht Komfort, dann einfach auf Standby, und nach 15min. auf Komfort.
Das werd ich heut Abend mal testen.

[2ndsky]

So gehts natürlich auch

Was ich meinte, bei dem Bool Item, das vom Taster gesendet wird, machst du ein

eval = False if sh.heizungsstatus() == 0 else True
eval_trigger = heizungsstatus

UM wäre also 0 wenn die Betriebsart 0 ist, ansonsten 1. Keine Ahnung, ob dieses Mapping des Heizungsstatus so passen würde. Könnte aber ebenfalls funktionieren.

[Mike01]

Danke,

Ich habs jetzt mal so gelöst:

Crontab in der Items.conf angelegt um die Heizung Abends abzusenken, und Logik für den Taster angelegt zum umschalten der Lüftungsfunktion.

Funktioniert soweit wunderbar:

heizung.py

if trigger['by']=='Item' and trigger['source']=='og.wohnen.heizung.lueften':
  if sh.og.wohnen.heizung.modus() == 1:
    sh.og.wohnen.heizung.modus(4)
    sh.og.wohnen.heizung.modus.timer('0', 4)
  elif sh.og.wohnen.heizung.modus() == 2:
    sh.og.wohnen.heizung.modus(4)
    sh.og.wohnen.heizung.modus.timer('0', 4)
  else:
    sh.og.wohnen.heizung.modus(2)
    sh.og.wohnen.heizung.modus.timer('15m', 1)

Gruß, Mike

P.S.: Rein Interessehalber würde mich aber trotzdem interessieren, warum

if trigger['by']=='Scheduler':

nicht funktioniert, wie muss der Befehl lauten, damit der Logikabschnitt nur reagiert, wenn er durch den Crontab aufgerufen wird ?

[callidomus]

Hallo,

würde mich aber trotzdem interessieren, warum

if trigger['by']=='Scheduler':

nicht funktioniert,

mich auch. Das sollte so gehen. Aber ohne Log ist das wieder mal Glaskugel...

Bis bald

Marcus

[Mike01]

Danke Marcus,
War mir nicht sicher, ob mein ansatz für die Logik so richtig war, deshalb hab ich das nicht näher verfolgt.

Habs aber gerade nochmal mit einer Testlogik erstellt, und da hats mit dem Scheduler eintrag geklappt.

Logik

if trigger['by']=='Scheduler':
  logger.info("Durch Timer getriggert")

Logfile

2014-04-15 20:05:00,455 INFO     testlogik    {'dest': None, 'source': None, 'by': 'Scheduler', 'value': None} -- testlogik.py:<module>:2
2014-04-15 20:05:00,460 INFO     testlogik    Durch Timer getriggert -- testlogik.py:<module>:16

Gruß, Mike