Automatische Beschattung

[Dragonos2000]

Im Autoblind Log ist dazu leider nichts zu finden, die Zeiten für die Initialisierung der Zustände des Plugins korrelieren lediglich mit den Bus-Telegrammen. Insofern tappe ich schon noch im Dunkeln, was SH.py veranlasst die Telegramme zu senden.

Muss ich wohl den mühsamen Weg gehen und mich rantasten...

[mumpf]

Keine Ahnung, hab ich bisher nicht ausprobiert, hab ich nicht gebraucht - ich vermute aber, dass vor dem Ablauf des Startup-Delays nichts passiert. Schau doch mal in das Log vom Autoblind rein, ich finde die sehr ausführlich, da sieht man normalerweise direkt, warum irgendein Zustand angesprungen wurde. Vielleicht liegt es ja gar nicht am Autoblind, sondern an irgendwelchen Initialisierungen, die Du bei den Items machst...

Gruß, Waldemar

[Dragonos2000]

Ok, danke für's Feedback, das ist schonmal ganz hilfreich. Wie reagiert das Plugin, wenn vor Ablauf des Startup-Delays ein Trigger ausgelöst wird?

[mumpf]

Hi, bei mir passiert das nicht... Ist somit kein generelles autoblind Problem. Muss mit deinen Item-Definitionen zusammenhängen. Die Frage ist eher, mit welchen... Ich glaube, du mal eine .conf mit dem zugehörigen log Posten, vielleicht sieht man da was. Gruß Waldemar

[Dragonos2000]

Hi,

als ich gestern Abend einen Neustart von SH.py wegen einiger Änderungen durchgeführt habe, sind zunächst alle Rolläden nach oben gefahren, um dann beim nächsten Lauf des Plugins wieder nach unten zu fahren:
Es scheint so, dass zunächst der Sollwert 0 auf den Bus geschrieben wird, wenn sich das Plugin initialisiert. Danach ist Ruhe bis das Startup Delay abgelaufen ist und die korrekten Werte werden auf den Bus geschrieben. Das passiert in etwa dann, nachdem SH.py alle Items initialisiert und abgefragt hat (habe knx_init auch auf die Autblind-Höhe), noch bevor irgendwelche Skripte anlaufen.

Kann das Verhalten jemand bestätigen und lässt sich das irgendwie unterdrücken?

Gruss
Jochen.

[offline]

Das Plugin hat tatsächlich beim Ändern der unter as_suspend_watch angegebenen Items Änderungen, die das Plugin selbst ausgelöst hat, nicht ignoriert. Ich habe das nun eingebaut und der Einfachheit halber auch erst mal in den SplitActionClasses-Branch gepusht. Es gibt da außerdem noch zwei weitere kleine (kosmetische) Bugfixes.

Diese Änderung sorgt jedoch nur dafür, dass die Item-Änderungen kein Suspend mehr triggern. Die Positionsrückmeldung, die Aktoren nach dem Fahren melden triggert weiterhin das Suspend.
Abhilfe könnte man schaffen, in dem man bei den Suspend-Items zusätzliche "Bedingungen" wie z. B. einen bestimmten Caller (z. B. "Visu") oder eine bestimmte Source (z. B. eine physische Adresse von KNX) mit angeben kann, die dann ausgewertet werden.Dazu muss ich mir dann aber zum einen Gedanken machen, wie man solche "Zusätze" am sinnvollsten in die AutoBlind-Konfiguration einbaut. Zum anderen müssen diese "Zusatzbedingungen" zum Triggern des Suspend dann auch nochmal irgenwo abgelegt werden, damit Sie abgeprüft werden können, wenn eines der as_suspend_watch-Items geändert wird.

Ich werde mir da mal Gedanken machen, es kann jedoch ein wenig dauern, der Weihnachtsstress kommt so langsam auf Touren. Zunächst werde ich aber den SplitActionClasses-Branch in den Develop-Zweig mergen, da die neue Funktionalität bei euch scheinbar genausowenig Probleme macht, wie bei mir ...

Grüße
offline

[Onkelandy]

Ja, mit dem tigger(by) hatte ich das in einer anderen Situation mal gelöst, das klappt eigentlich recht gut. Vermutlich ist das auch gar nicht so komplex - generell dachte ich halt, dass es sich anbieten würde, das gleich im Plugin irgendwie abzufangen. Mal sehen, was Meister offline dazu noch meint, hehe

[mumpf]

Ah, ok. Dann schau aber mal, ob du das nicht besser über eine recht einfache Logik machst. Du machst ein eigenes suspend Item, das triggert eine Logik, in der wird trigger[by] ausgewertet. Und wenn der trigger die Visu ist, dann setzt du den suspend vom autoblind. Könnte so klappen, musst ein bisschen rumprobieren... Gruß Waldemar

[Onkelandy]

Danke Waldemar für den Tipp!
Scheint generell zu funktionieren, auch wenn es recht viel Aufwand ist... aber nachdem's sonst offenbar niemand betrifft muss ich mir das vermutlich antun?

Nochmals kurz zur Erklärung: ich möchte, dass jede manuelle Betätigung, ob per Schalter oder Visu als Suspend gewertet wird.
Über Schalter habe ich aber nur Auf/Ab und Stop oder eben Dimmen hoch/runter. Hier ist es kein Problem, auf diese Items das Suspend anzuwenden. Die Schalter bekommen ja keinen Status bzw. jedenfalls nicht den Wert der Jalousiehöhe oder Lichtintensität, maximal "ein/aus" für die LED.

Wenn ich allerdings möchte, dass das Anfahren einer bestimmten Höhe der Jalousie oder des direkten Dimmwerts des Lichts (zB über die Visu, theoretisch aber auch über das Schalten einer Szene o.ä.) ein Suspend erzwingen soll, gibt es ein kleines Dilemma. Denn diese Items sind ja auch mit knx_listen für den Höhe- oder Dimmwert versehen, um in der Visu immer die richtige Anzeige zu haben. Problem ist jetzt, dass bei jedem automatischen Anfahren einer bestimmten Höhe durch das Plugin der aktualisierte Status vom KNX System auf das Höhe Item geschrieben wird. Und so wäre ich immer bei jeder "Zustandsaktivierung" seitens autoblind wieder im Suspend Mode, was ja nicht Sinn der Sache ist.

[mumpf]

Hi,

ich weiß jetzt nicht, ob ich Dein Problem voll verstanden habe, aber das, was Du vohast, müsste folgendermaßen gehen (hab ich aber nicht ausprobiert):

[Licht]
    # Standard-Licht-Item, ist nur zu Demo-Zwecken hier, wird eigentlich nicht gebraucht
    type = bool
    visu_acl = ro
    knx_dpt = 1
    knx_cache = 1/1/1  # Status vom Aktor
    knx_send = 1/2/1    # normale Licht-Schalt-GA (z.B. in Tastern vergeben)
    [[LichtVisu]]
        # Dieses Item benutzt Du in der Visu
        type = bool
        visu_acl = rw
        knx_dpt = 1
        knx_cache = 1/1/1
        knx_send = 1/2/10    # Visu Licht-Schalt-GA, der Aktor hört auch auf diese
    [[SuspendByVisu]]
        # Dieses Item ist das, auf das der Autoblind-Suspend hört
        type = bool
        enforce_updates = true
        knx_dpt = 1
        knx_listen = 1/2/10 # hier wird auf die Schalt-GA von der Visu gehört und NICHT auf die von anderen Tastern

Ich hab versucht, in Kommentaren die Idee zu beschreiben, sollte eigentlich gehen. Bei Jalousien/Rolläden entsprechend...

Gruß, Waldemar

[Onkelandy]

Vielen lieben Dank, absolut top! Ich hab den Branch mal gepullt und soweit scheint noch alles zu klappen. Das byattr hab ich aber nicht getestet..

Jetzt nochmals zurück zu der Suspend Problematik, vielleicht kapier ich's ja nur nicht
Ich möchte in der Visu z.B. ein Licht einschalten und auch am Button sehen, ob es an ist oder nicht. Das Item hat daher sowohl knx_send als auch knx_listen. Wenn ich jetzt möchte, dass bei manuellem Schalten das auto_blind auf Suspend geht, müsste ich ja ein suspend_watch auch das Schalt-item des Lichts legen.
Nun bekommt dieses Item ja aber immer ein Update, sobald sich am Licht was tut und schaltet dann auch in den Suspend, wenn er es nicht sollte. Gleiches Problem gab es ja auch mit der Höhenverstellung der Jalousien.

Mit einem KNX Schalter gäbe es in dem Fall keine Probleme, da dort ja die Rückmeldung über eine eigene Gruppenadresse läuft. Somit könnte man dort ein eigenes Item ohne knx_listen anlegen, das als Suspend fungiert. Aber in der Visu bräuchte es nach der Logik ja alles doppelt: eine reine Statusanzeige mittels knx_listen im Item und ein eigener Schaltknopf, der nur das knx_send im Item hat.

Wäre echt super genial, wenn das noch gelöst werden könnte. Falls das irgendwie zu komplex wird, überleg ich mir halt doch was mit der Visu...

[offline]

So ... nach einem minderschweren Umbau im Coding unterstützt das Plugin die Angabe von Werten statisch/aus Item/per Eval nun an allen Stellen, an denen dies Sinnvoll sein könnte. Zudem habe ich einiges im Coding umgebaut um Redundanzen zu vermeiden.

Neben dem Attribut as_delay_[action name] funktionieren "value:[statisch]", "item:[item id]" und "eval:[funktion]" jetzt auch bei as_mindelta_[action name]

Der Umbau hat jedoch dazu geführt, dass Setzen von Items anhand von Attributen der Items nicht mehr über "as_set_[action name] = byattr: [attribut]" funktioniert. Für diese Funktionalität gibt es ab sofort die Action "as_byattr_[action_name] = [attribut]"

Ich habe das ganze auf GitHub gepusht. Auf Grund der nicht unerheblichen Umstellungen und des Breaking-Change mit byattr liegen die Änderungen zunächst nur im Branch "SplitActionClasses".

Grüße
Thomas

[Onkelandy]

Schade, aber dann kann man ja nix machen.. Einzig ein Definieren des Delays über ein Item wäre noch sehr fein

[offline]

Im Moment wird für das Delay ein nur ganzzahliger Festwert akzeptiert. Intern kann jedoch statt mit Sekunden auch mit Millisekunden gerechnet werden, was ich gerade mal versucht habe. Der Scheduler von smarthome.py ist jedoch nicht so genau. Ich habe mehrere Items mit unterschiedlichen Delays von 500, 600 und 700 Millisekunden definiert. Die tatsächliche Verzögerung lag dabei teilweise im Bereich von mehreren Sekunden. Ich habe auch feststellen können, dass nicht einmal die Reihenfolge, in der die Items bei korrektem Delay hätten gesetzt werden sollen, eingehalten wurde:

Einige Sekunden nach dem Starten von smarthome.py

2015-12-08 18:12:35.071252       Action 'data3: Add 600.0 millisecond timer 'test.data3-AbItemDelayTimer' for delayed execution.
2015-12-08 18:12:35.071535       Action 'data2: Add 500.0 millisecond timer 'test.data2-AbItemDelayTimer' for delayed execution.
2015-12-08 18:12:35.071776       Action 'data4: Add 700.0 millisecond timer 'test.data4-AbItemDelayTimer' for delayed execution.
2015-12-08 18:12:38.000758 Delay Timer 'test.data4-AbItemDelayTimer': Set 'test.data4' to '0'
2015-12-08 18:12:38.000950 Delay Timer 'test.data3-AbItemDelayTimer': Set 'test.data3' to '0'
2015-12-08 18:12:38.001106 Delay Timer 'test.data2-AbItemDelayTimer': Set 'test.data2' to '0'

Noch ein wenig gewartet ...

2015-12-08 18:14:09.293440       Action 'data3: Add 600.0 millisecond timer 'test.data3-AbItemDelayTimer' for delayed execution.
2015-12-08 18:14:09.293732       Action 'data2: Add 500.0 millisecond timer 'test.data2-AbItemDelayTimer' for delayed execution.
2015-12-08 18:14:09.293985       Action 'data4: Add 700.0 millisecond timer 'test.data4-AbItemDelayTimer' for delayed execution.
2015-12-08 18:14:10.090183 Delay Timer 'test.data4-AbItemDelayTimer': Set 'test.data4' to '42'
2015-12-08 18:14:10.090364 Delay Timer 'test.data3-AbItemDelayTimer': Set 'test.data3' to '42'
2015-12-08 18:14:10.090483 Delay Timer 'test.data2-AbItemDelayTimer': Set 'test.data2' to '42'

Der Scheduler scheint also zu jeder vollen Sekunde zu triggern ...

Der Anwendungsfalll für delay-Werte unter einer Sekunde besteht in meinen Augen darin, bestimmte Items in genau definierter Reihenfolge zu schalten. Leider klappt selbst das, wie oben getestet, nicht mit delay-Werten im Millisekundenbereich.

Grüße
offline

[Onkelandy]

Der Anwendungsfall ist sehr spezifisch.. momentan mach ich das über ne Logik und ich denke, das macht ohnehin so auch mehr Sinn.. insofern ist das kein Drama. Im weitesten Sinne gehört es halt zum Zustand dazu - dass, sobald dieser in der Visu adaptiert wird, auch gleich eine Änderung am KNX System sichtbar ist.

Konkret ginge es um das kurze Aus- und Einschalten des Triggers für den Bewegungsmelder, sobald der Dimm-Sollwert für das Licht (zB in der Visu) angepasst wird.
Also angenommen, der KNX BWM schickt den Sollwert 80% ans Licht, dann muss man eben kurz an und aus triggern, um einen neu eingestellten Wert von 70% sofort an die Leuchte zu senden.