- √ - Bug bei Boolean Typen?

[katmic]

Hallo zusammen,

ich habe zwei geniale Logiken geschrieben, die einen Rollladen hoch und wieder runterfahren:

ShuttersEG_UP.py

sh.Arbeitszimmer.Rollladen.move(False)

ShuttersEG_DOWN.py

sh.Arbeitszimmer.Rollladen.move(True)

Die Item-Definition dazu sieht so aus:

['Arbeitszimmer']
      [['Rollladen']]
          name = Rollladen
          [[['move']]]
                name = fahren
                type = bool
                knx_dpt = 1
                knx_send = 5/0/0
                visu = toggle
           [[['stop']]]
                name = stop
                type = bool
                knx_dpt = 1
                knx_send = 5/0/1
                visu = toggle

Der Rollladen steht in der Mitte, so dass ich hoch- und runterfahren kann. Jetzt starte ich die CLI Telnet-Verbindung:

> lo
Logics:
Init
ShuttersEG_DOWN (scheduled for 2013-02-22 21:57:00)
ShuttersEG_UP (scheduled for 2013-02-22 21:55:00)
> tr ShuttersEG_UP           
> tr ShuttersEG_UP
> tr ShuttersEG_DOWN 
> tr ShuttersEG_UP

Die ersten beiden UPs funktionieren nicht! Der anschließende DOWN funktioniert dann. Der letzte UP funktioniert dann auch.

Wenn ich smarthome.py neu starte und mit einem DOWN beginne, funktioniert es gleich, auch ein anschließender UP.

Ich vermute es liegt daran, dass initial bei dem move-Item ein True gesetzt werden muß, anschließend funktioniert auch das setzen von False.

Mache ich was falsch oder ist es ein Bug?

Grüße,
Michael

[katmic]

Meine Vermutung hat sich nochmal bestätigt. Wenn ich in der ShuttersEG_UP.py ein DOWN vorsetze, um das Setzen des True-Wertes initial zu erzwingen, funktioniert das Hochfahren sofort nach Neustart von smarthome.py:

sh.Arbeitszimmer.Rollladen.move(True)
sh.Arbeitszimmer.Rollladen.stop(True)
sh.Arbeitszimmer.Rollladen.move(False)

Grüße,
Michael

[callidomus]

Bug bei Boolean Typen?

Hi Michael,

lies mal die Doku zu enforce_updates. Das muss in Deinem Fall gesetzt werden.

Bis bald

Marcus

[katmic]

Hallo Marcus,

hmm, wäre es nicht sinnvoll das enforce_update als Default-Einstellung zu setzen? Ich glaub, man übersieht das schnell, mich hat es heute mehr als 2h gekostet. Warum sollte ich ein KNX Item setzen und es nicht auf den Bus schicken wollen?

Grüße,
Michael

[katmic]

Hallo Marcus,

ich kann aber bestätigen, dass es mit enforce_updates funktioniert!

Grüße,
Michael

[2ndsky]

Hallo Michael,

enforce_updates macht nur manchmal Sinn wie in deinem Fall. Generell möchte ich aber nicht, dass immer jedes Wertsetzen auf den Bus geschrieben wird wenn sich der Wert gar nicht geändert hat. Im Falle von Rollladen macht enforce_updates Sinn und ist für problemlosen Betrieb sogar zwingend (ein Taster sendet den Wert auch jedes mal), aber das kann man halt nicht verallgemeinern. Wenn ich einen Aktorkanal auf EIN schalte, dann braucht beim nächsten EIN nicht noch ein Telegramm gesendet werden, denn er ist ja schon EIN. Außerdem gibt es ja auch genug Items, die mit KNX nichts zu tun haben.

Ob man jetzt enforce_updates standardmäßig setzt und sonst immer abschalten muss macht IMHO keinen Unterschied. Jetzt sollte soetwas nicht mehr geändert werden, denn sonst müssten zuviele Installationen umgestellt werden. Außerdem brauche ich enforce_updates nur etwa bei gefühlten 20% der Items. Wenn ich bei 80% nun jedesmal enforce_updates auf False setzen müsste, hätte ich auch kein Spass

Übrigens, wenn du die aktuelle Version aus'm Git nutzt kannst du crontab und cycle auch bei Items angeben und musst nicht extra ne Logik dafür verwenden

[callidomus]

Hallo Michael,

leider habe ich Dich auf die falsche Fährte geführt.
Dein eigentliches Problem hat nichts mit 'enforce_updates' zu tun. Das ist lediglich ein Workaround.

Der 'richtige' KNX-Way wäre es eine Statusadresse für jeden Aktorkanal festzulegen der mit 'knx_cache' beim Start ausgelesen wird.
Dann ist Dein Problem weg.

Ansonsten kann ich mich nur den Erläuterungen von Niko anschließen.

Bis bald

Marcus

[l0wside]

Hallo Michael,

leider habe ich Dich auf die falsche Fährte geführt.
Dein eigentliches Problem hat nichts mit 'enforce_updates' zu tun. Das ist lediglich ein Workaround.

Sehe ich anders. Überlege folgendes Szenario:
2/1/10 = RL hoch/runter
2/1/11 = RL stop

Nun sende ich:
2/1/10 = 0 (RL hoch)
Wenn der RL halb oben ist, dann
2/1/11 = 1 (RL stop)
Der Wert von 2/1/10 ändert sich nicht, trotzdem hat sich etwas geändert (der Rolladen steht).
Nun will ich weiter hochfahren und schreibe erneut
2/1/10 = 0 (RL hoch).

Ohne enforce_updates tut sich nun gar nichts. Um deine Idee mit dem Verfahrstatus zu verwenden, müsste man

• entweder alles auf prozentuale Verfahrwerte umstellen (d.h. statt "RL hoch" zu senden "RL 0%" senden)
• oder intern ein item "rolladen_verfahrstatus" o.ä. einführen, das die drei Zustände "läuft nach oben, steht, läuft nach unten" abbilden kann und über eine value-Berechnung sich seinen aktuellen Zustand holt. Das wird aber ein num, in einen bool passen die drei Zustände nicht. Elegant ist das aber auch nicht gerade.
  Außerdem befürchte ich, dass man auch da nicht ohne enforce_updates auskommt.

Max

[katmic]

Hallo Marcus, Max,

bei meinem Jalousieaktor habe ich 3 Status Meldungen:
Position (in %), Status Position oben (Bool: ist der Rollladen oben?),
Status Position unten.
Wäre es technisch egal welche Status-Info abgefragt wird, Hauptsache das Item wird beim Start von smarthome geändert?

Die Frage ist auch, ob eine zwischenzeitliche Bedienung des Rollladens mit Tastern Einfluss auf Smarthome hat, im Sinne das Zustände entstehen
können, bei denen ein Werte-Update nicht gesendet wird?

Grüße,
Michael

[callidomus]

Hallo Michael,

die drei Statuswerte helfen dann doch nicht.

Bleibt, neben enforce_updates, könntest Du den letzten Wert cachen ('cache = yes')

Bis bald

Marcus

P.S. Bitte mache den Thread zu wenn es passt.

[katmic]

Hallo Marcus,

danke für die Rückmeldungen. Enforce_update funktioniert, deshalb schließe ich den Thread.

Grüße,
Michael