UZSU Widget für Lüftung

[KF55W]

hi tom,
danke für dein Tipp.
Ich werde mir das zip nochmals genau am WE ansehen.

mein *.conf Datei hab ich grade wie du geschrieben hast geändert.
folgendes im LOG:

2016-11-16 20:25:43 WARNING  item         kwl.boost-Timer Item kwl.boost: value sh.kwl.level_alt() does not match type num. Via Autotimer None -- item.py:__update:454
2016-11-16 20:25:49 DEBUG    __init__     Main         192.168.100.75:58867 sent '{"cmd":"item","id":"kwl.boost","val":"205"}' -- __init__.py:json_parse:329
2016-11-16 20:25:49 DEBUG    item         Main         Item kwl.boost = 205 via Visu 192.168.100.75:58867 None -- item.py:__update:470
2016-11-16 20:25:49 DEBUG    scheduler    Main         Triggering kwl.level_alt - by: Visu source: 192.168.100.75:58867 dest: None value: {'value': 205, 'source': 'kwl.boost'} -- scheduler.py:trigger:165

2016-11-16 20:26:29 WARNING  item         kwl.boost-Timer Item kwl.boost: value sh.kwl.level_alt() does not match type num. Via Autotimer None -- item.py:__update:454

hatte am ende noch den effekt, dass ich kein 2tes mal mehr den Boost-Taster drücken konnte...

grüße
ANDI

[Tom Bombadil]

Vermutlich hat das Item 'level' beim ersten Drücken noch kein prev_value. War auch nur so eine fixe Idee. Hatte gehofft, das über Items lösen zu können, aber läuft wohl doch auf eine Logik hinaus ...
/tom

[wvhn]

Mach doch mal das Backend auf und gib dem item level_alt einen Startwert, bevor Du die Stoßlüftung zum ersten Mal startest. Dann kannst Du die Zustände Deiner items im Backend verfolgen und das Ergebnis posten, wenn etwas noch nicht richtig funktioniert.

Wichtig ist m.E., dass das item level_alt niemals den Wert der Stoßlüftung annimmt, weil sonst nicht mehr gewährleistet ist, dass das item boost triggert. Das kann erreicht werden, indem man level_alt über das eval etwas erhöht oder reduziert.

Ein enforce_updates im item boost könnte auch helfen, muss aber auf unerwünschte Nebenwirkungen untersucht werden.

Gruß Wolfram

[KF55W]

hi wolfram,

wie kann ich das in eine Datei initialisieren, dass es beim ersten start ausgelesen wird. wie muss die datei heißen und wohin muss die gespeichert werden?
sry für die ganzen anfängerfragen, es kann nur besser werden

[wvhn]

Hi,

das weiß ich auch noch nicht, aber ich vertraue voll auf dieses tolle Forum, in dem man sich vieles erlesen kann.

Der erste Schritt sollte aber erst mal wie oben beschrieben der Test sein, ob der fehlende Initialwert das einzige Problem ist. Dann sehen wir weiter.

[wvhn]

Hab mal ein bisschen im Forum gesucht. Dieser Beitrag beschreibt das Problem des nicht vorhandenen previous_value samt Lösung: https://knx-user-forum.de/forum/supp...655#post842655 (Post #51 bis #57). Dort gibt es auch ein paar Hinweise zur enforce_updates und cache=true.

Analog zu der Lösung dort müsste Dein eval wie folgt heißen:

[FONT=courier new]eval = sh.kwl.level() if sh.kwl.level.changed_by() == 'Init' else sh.kwl.level.prev_value() # Wert *vor* dem jetzigen Boost-Wert[/FONT]

Gruß Wolfram

[KF55W]

Hi Wolfram,
echt klasse, deine Unterstützung.

das Problem mit dem Initialwert sollte gelöst sein, siehe letzte Zeile im Log

DEBUG

2016-11-19 19:22:01 DEBUG    __init__     Main         192.168.100.68:54644 sent '{"cmd":"item","id":"kwl.boost","val":"205"}' -- __init__.py:json_parse:329
2016-11-19 19:22:01 DEBUG    item         Main         Item kwl.boost = 205 via Visu 192.168.100.68:54644 None -- item.py:__update:470
2016-11-19 19:22:01 DEBUG    scheduler    Main         Triggering kwl.level_alt - by: Visu source: 192.168.100.68:54644 dest: None value: {'value': 205, 'source': 'kwl.boost'} -- scheduler.py:trigger:165
2016-11-19 19:22:01 DEBUG    item         kwl.level_alt Item kwl.level_alt = 104 via Eval kwl.boost None -- item.py:__update:470

allerdings schreibt der autotimer kein Wert:

2016-11-19 20:01:55 WARNING  item         kwl.boost-Timer Item kwl.boost: value sh.kwl.level_alt() does not match type num. Via Autotimer None -- item.py:__update:454

Gibt es hier eine Regel, in welchem Format der Autotime angesprochen werden muss, wenn kein direkter Wert geliefert wird?

hier nochmals der Item-Code

[kwl]
    [[level]]
        type = num
        visu_acl = rw
        knx_dpt = 5
        knx_cache = 0/4/10
        knx_send = 0/4/9
        sqlite = no
        [[[uzsu1]]]
            type=dict
            uzsu_item=kwl.level
            visu_acl=rw
            cache = True    
    [[boost]]
       type = num
       visu_acl = rw
       autotimer = 25 = sh.kwl.level_alt()
       knx_dpt = 5
       knx_cache = 0/4/8
       knx_send = 0/4/9
       sqlite = no    
    [[level_alt]]
      type = num
      knx_dpt = 5
      visu_acl = rw
      cache = True
      eval = sh.kwl.level_alt() if sh.kwl.level.changed_by() == 'Init' else sh.kwl.level.prev_value()
      eval_trigger = kwl.boost

[Tom Bombadil]

Ich hab mehrfach versucht, mir die Befehlsreihenfolge vorzustellen, aber bekomme mangels eigenem KNX jedesmal einen Knoten in's Hirn.

sh.py startet, setzt Werte
Knx sagt irgendwann 'mach mal Boost'
sh.py sagt 'mach ich, ich schalt in xx Sekunden wieder auf wert 'xyz'
autotimer wird mit den aktuell gesetzten Werten gestartet
autotimer wird nach xx Sekunden beendet

Mein Bauchgefühl sagt mir, dass zwischendurch da ein 'update' im [[boost]] nach der ersten Initialisierung fehlt - die Stufe könnte ja mittlerweile eine ganz andere als beim Start sein. Aber woher weiß [[boost]] das?

Würde das selbst gern gelöst haben - die Umsetzung über Items scheint wesentlich eleganter und weniger fehleranfällig zu sein als über Logiken, aber auch gedanklich deutlich komplizierter ...

/tom

[wvhn]

Tom,
das Update würde durch den Autotimer selbst kommen. Insofern ist Deine Lösung m.E. schon richtig - im Prinzip - denn nach einigem Lesen denke ich, dass der Fehler in der Parametrierung des Autotimers steckt. Es ist wohl nicht vorgesehen, dass er Variablen als Parameter verarbeitet, sondern nur feste Werte. (Womit wir einen Featurewunsch hätten )

Als Lösung könnte man [[boost]] zum Typ bool machen. Knx oder Visu starten es mit Wert 1 und Autotimer setzt es auf 0 zurück. Dann brauchen wir noch die Verknüpfung mit dem kwl-level.

    [[boost]]
          type = bool
          visu_acl = rw
          autotimer = 25 = 0
          knx_dpt = 1
          knx_cache = 0/4/8
          [[[level]]]
              type = num
              eval = 104 if sh.kwl.boost == 1 else sh.kwl.level_alt()
              eval_trigger = kwl.boost
              knx_dpt = 5
              knx_send = 0/4/9
              sqlite = no
      [[level_alt]]
          type = num
          knx_dpt = 5
          visu_acl = rw
          cache = True
          eval = sh.kwl.level() if sh.kwl.level.changed_by() == 'Init' else sh.kwl.level.prev_value()
          eval_trigger = kwl.boost.level 
 [FONT=Arial][/FONT]

Wenn jemand während des Boost-Modus den Level manuell verstellt, dann geht die Lüftung am Ende des Autotimers wieder auf den Wert von level_alt. Das auch noch abzufangen wird kompliziert. Gruß Wolfram

[KF55W]

Wenn jemand während des Boost-Modus den Level manuell verstellt, dann geht die Lüftung am Ende des Autotimers wieder auf den Wert von level_alt. Das auch noch abzufangen wird kompliziert. Gruß Wolfram[/FONT]

oder nochmals auf "Boost" betätigt.

Gibt es hier die Möglichkeit, dass man kwl.level_alt() < 200 einschränkt? (Taster Stoßlüften / Boost setzt Wert auf 204).

Das wäre die Lösung

[wvhn]

Hast Du schon getestet, ob die Lösung so funktioniert?

Wenn jemand während "Boost" noch einmal "Boost" betätigt, dürfte das nichts ausmachen, weil das item kein update erfährt, solange sich der Wert nicht ändert und kein "enforce_updates" im item steht.

[KF55W]

hallo Wolfram,

ich hab es kurz eingespielt.
Es hat noch nicht ganz funktioniert, wenn ich heute abend zeit finde, werde ich es mit im Detail anschauen und analysieren...

[KF55W]

hallo nochmal.
folgendes kommt im Debug mode:

2016-11-20 18:38:55 DEBUG    __init__     Main         192.168.100.68:56715 sent '{"cmd":"item","id":"kwl.boost","val":"1"}' -- __init__.py:json_parse:329
2016-11-20 18:38:55 DEBUG    item         Main         Item kwl.boost = True via Visu 192.168.100.68:56715 None -- item.py:__update:470
2016-11-20 18:38:55 DEBUG    scheduler    Main         Triggering kwl.boost.level - by: Visu source: 192.168.100.68:56715 dest: None value: {'source': 'kwl.boost', 'value': True} -- scheduler.py:trigger:165

d.h. dass [[boost]] korrekt angesprochen wird und es durchläuft bis [[[level]]].
Hier hab ich ein Verständnisproblem, bei eval:
Ich dachte, dass eval nur Bedingungen vergleicht.
Aber eigentlich brauche ich eine Funktion, die einen Wert setzt, wenn [[[level]]] getriggert wird, oder über sehe ich was?

Frage noch: 104? warum dieser Wert? ist das der angenommene Boost-Wert?
Dieser wurde aber noch nie gesetzt, so dass eval auch keine Bedingung vergleichen kann...

Grüße

[[[level]]]
type = num              
eval = 104 if sh.kwl.boost == 1 else sh.kwl.level_alt()              
eval_trigger = kwl.boost              
knx_dpt = 5              
knx_send = 0/4/9              
sqlite = no

[Tom Bombadil]

104 war wohl nur ein Tippfehler von Wolfram, gemeint war ziemlich sicher 204 (=von Dir genannter Wert bei Stosslüftung), also:

eval = [COLOR=#FF0000]204[/COLOR] if sh.kwl.boost() else sh.kwl.level_alt()

/tom

[Tom Bombadil]

Ich dachte, dass eval nur Bedingungen vergleicht. Aber eigentlich brauche ich eine Funktion, die einen Wert setzt, wenn [[[level]]] getriggert wird, oder über sehe ich was?

Eval setzt den Wert des Items, wobei dieser Wert durch Bedingungen gesteuert werden kann (if). Dabei kann auch Veränderungen eines oder mehrerer "watch-items" (="eval_trigger") gelauscht werden, die das eval auslösen.

Sollte eigentlich alles laufen:

- Du drückst den bzw. einen Deiner Taster für Stoßlüftung
- KNX setzt den Wert boost auf 1
- Level stellt fest "oh, boost hat sich geändert" und stellt sich auf den per eval ermittelten Wert ein
- Dieser Wert wird gleichzeitig über KNX an die KWL gesendet
- Nach der im Autotimer eingestellten Zeit fällt boost zurück auf 0, erneutes eval im Level, Senden des gespeicherten 'alten' Wertes über KNX

Sieht für mich soweit eigentlich alles ganz logisch und richtig aus - ob bei dem ganzen KNX-Gedöns (knx_dpt, knx_cache, knx_send) alles richtig gesetzt ist, kann ich allerdings nicht beurteilen.

/tom