Automatische Beschattung

[offline]

Hi Waldemar,

ich denke, man kann zwei verschiedene Sichtweisen auf "suspend" (und parallel auch auf "Lock") haben. Auf der einen Seite können das Zustände der jeweiligen Items sein, die sich wie andere Zustände auch verhalten. Auf der anderen Seite können es Betriebs"zustände" des Plugins sein, die damit den Zuständen der jeweiligen Items übergeordnet sind. Von der Programmierung her orientiert sich das Plugin bisher am zweiten Ansatz.

Ich habe mich bisher nicht damit beschäftigt, einen "Suspend" über Zustände zu bauen. Du kannst ja mal ein Beispiel posten wie du das gemacht hast. Evtl. ist das ja ein Thema für das Wiki ...

Nichtsdestotrotz ist es nicht besonders aufwändig, zusätzliche "besondere" Bedingungen zu integrieren, über der "Aufrufer", der die Statusermittlung ausgelöst hat, mit abgeprüft werden kann. Ich habe das mal eingebaut und in den Branch "feature/update_conditions" gepusht. Die Namen der "besonderen" Bedingungen sind "update_caller", "update_source" und "update_dest". Bei den ersten Tests habe ich jedoch gesehen, dass ich hier weniger Informationen bekomme, als bei der anderen Lösung, da jeder Aufruf nochmal durch ein "Eval" geschickt wird, wenn Items über "eval_trigger" überwacht werden.

Grüße
offline

[mumpf]

Hi offline,

wow! Das ist jetzt abgedreht. Obwohl ich es schade finde, dass Du nochmal ein "suspend"-Regelwerk neben dran gestellt hast - irgendwie hätte ich es besser gefunden, wenn man nach item/source/caller in den Zuständen hätte abfragen können und sich somit "normale" Zustände definieren könnte, die suspend-Charakter haben.
Ich habe immer wieder das Problem, dass der Suspend gesetzt wird (wodurch auch immer, jetzt durchaus komfortabel einstellbar), und auch nach einer Zeit zurückgesetzt wird, ich aber in der Zeit (ohne externe Logik) nicht die Möglichkeit habe, wichtigere Zustände zu aktivieren.

Typisches Beispiel: Rolladen wurde 10 Minuten vor "Zentral runter" manuell auf 50% gefahren. Wenn jetzt der Befehl "Zentral runter" kommt, ist dieser Rolladen im suspend und geht erst später runter. Hätte ich einen suspend-Zustand, könnte ich den hinter den "Zentral runter" setzen und so selber bestimmen, wer gewinnt.

Versteh mich nicht falsch, ich finde immer noch irre, was Du hier leistest und wie viel komfortabler sh.py mit autoblind wird. Ich habe auch keinen konkreten Feature-Wunsch, denn letztendlich bastle ich mir meine Suspend-Zustände selber und nutze Deinen Suspend-Mechanismus kaum. Ich hätte es irgendwie nur besser gefunden, wenn man den alten Suspend als "Mittel für den Gelegenheits-User" gelassen hätte und einen neuen Suspend in die State-Engine reingezogen hätte, vielleicht mit einem Beispiel, wie man Suspend-Zustände bauen kann. Dann hätte man "item/source/caller" auch bei normalen Regeln zur Verfügung...

Gruß, Waldemar

P.S.: Dieses Feature werde ich wohl nicht testen, da ich es nicht brauche...

[Onkelandy]

Genial! Vielen Dank! Musste den Text zwar 2 Mal lesen, aber jetzt scheint alles so zu klappen wie es soll

[offline]

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.

Die Limitierungen für die Suspend-Funktionalität sind eingebaut. Push ist in den Branch feature/suspend_limit erfolgt.

Items, die mit zusätzlichen Bedingungen überwacht werden sollen, müssen aus "as_suspend_watch" herausgenommen werden. Sie müssen einzeln über "as_suspend_watch_<Bezeichnung>"-Attribute angegeben werden. Das Format dieses Attributs ist wie folgt:

as_suspend_watch_irgendwas = [!]item[:caller][;source]

Also nach dem Item der geforderte "Caller" mit vorangestelltem Doppelpunkt und die geforderte "Source" mit vorangestelltem Semikolon. Stellt man dem ganzen ein Ausrufezeichen voran, wird die komplette Bedingung negiert.

z. B.

 as_suspend_watch_VisuOnly = my.item:Visu

Suspend wird nur getriggert, wenn my.item über die Visu geändert wurde

 as_suspend_watch_NoVisu = !my.item:Visu

Suspend wird nur getriggert, wenn my.item nicht über die Visu geändert wurde

 as_suspend_watch_IgnoreKnxReply = !my.item:KNX;1.2.3

Suspend wird nur getriggert, wenn my.item nicht über KNX von der physischen Adresse 1.2.3 geändert wurde

Es ist möglich, für ein Item mehrere Bedingungen anzugeben.

Die Funktionalität von as_suspend_watch bleibt unverändert, Items, die über dieses Attribut gelistet werden, werden als Items ohne zusätzliche Bedingungen behandelt.

Grüße
offline

[offline]

Das mit den CLI Commands ist ein noch undokumentiertes Feature. Es gibt einen Pull-Request für smarthome.py von mir, der es Plugins ermöglicht, eigene Kommandos für das CLI-Plugin zu definieren. Wenn diese Erweiterung in smarthome.py integriert ist, registriert das AutoBlind Plugin eigene CLI-Kommandos. Die Meldung besagt, dass die Erweiterung von smarthome.py nicht vorhanden ist und das AutoBlind Plugin daher garnicht erst versucht, die CLI-Kommandos zu registrieren ...

Grüße
offline

[Onkelandy]

CLI = Command Line Interface. Also, wenn du dich mit dem Smarthome.py mittels CLI verbindest, um zB Logiken neu zu laden, Werte auszulesen, etc., dann wird es in Zukunft wohl auch noch Funktionen für Plugins geben... aber derzeit noch nicht. So interpretiere ich die Meldung. Hat nichts mit deinen Definitionen zu tun.

[Dragonos2000]

Nunja, aber was ist mit "CLI commands" gemeint ? Mit meinen Definitionen habe ich wohl irgendeine Grenze ausgereizt...

[Onkelandy]

Ich behaupte mal, diese Meldung kannst du getrost ignorieren. Heißt wohl genau das, was es sagt

[Dragonos2000]

Ich hab' mal mit dem Debugging angefangen und unabhängig von meinem eigentlichen Problem: Was will mir diese Meldung im SH.py Log sagen?

2015-12-19 16:26:41,855 DEBUG    autoblind    Additional CLI commands can not be registered. Required functinality is not yet included in your smarthome.py version -- AutoBlindCliCommands.py:__init__:42

[Dragonos2000]

Hallo Waldemar,

danke für den Tipp! Werd ich versuchen.

Gruss
Jochen.

[mumpf]

Hallo Jochen,

mir ist noch was eingefallen, es könnte sein, dass Dein Startup-Delay einfach zu kurz ist (ich hab ihn inzwischen bei 60 Sekunden). Wenn ich mich recht erinnere, führt der erste Aufruf des Plugins - nach der durch StartupDelay vorgegebenen Zeit - dazu, dass der Anfangszustand festgestellt wird (deswegen steht da auch nichts von laststate). Wenn jetzt der StartupDelay auf 10 Sekunden (default) steht, kann es passieren, dass sh.py noch nicht alle Items initialisiert hat, die für die Bestimmung des ersten Zustands notwendig sind. Somit kann es passieren, dass ein (oder mehrere) Item(s), die bei Dir für den "Zu"-Zustand sorgen, noch nicht gesetzt sind und somit Autoblind als erstes den "Auf"-Zustand annimmt. Nach dem ersten cycle sind dann alle Items gesetzt und autoblind geht dann in den "Zu"-Zustand.

Das kann man erstmal ganz einfach testen, indem man StartupDelay global erstmal auf nen großen Wert (z.B. 5 Minuten) setzt und dann schaut, ob das Problem verschwindet. Wenn ja, kannst Du versuchen, den StartupDelay immer wieder zu verkleinern, bis Du zufrieden bis.

Alternativ kannst Du die Zeit verkürzen, die zum initialisieren der Items benötig wird:

• wo immer möglich knx_cache statt knx_init einsetzen
• wenn es geht cache=true nutzen, um den letzten gültigen Wert im Item nach dem Startup zu haben

Gruß, Waldemar

[Dragonos2000]

Hi offline,

danke für die Beschreibung des Plugin-Verhaltens, das ist schonmal gut zu wissen.
Erster Update ist "Triggered by Timer" - das dürfte wohl das Startup Delay sein. Was mir auffällt ist, dass er da nichts von laststate schreibt, obwohl ich das Caching für die Items aktiviert habe...
Werd' wohl wirklich im SH Debug-Log fischen müssen- juhuu...

Gruss
Jochen.

[offline]

So, die neuen Funktionalitäten sind nun auch im Develop-Zweig und die Doku ist aktualisiert.

Dragonos2000 Grundsätzlich werden auch Trigger verarbeitet, die vor Ablauf des Startup-Delays ausgelöst werden. Ab wann genau die Trigger aktiv sind, lässt sich im Smarthome.py-Log sehen, wenn das Loglevel mindestens "Info" ist. Mit nach dem Eintrag "Complete AutoBlind items" beginnt das Plugin damit, für alle AutoBlind Items die Trigger zu aktivieren. Außerdem wird in diesem Schritt das Startup-Delay gestartet. Mit dem Eintrag "Using AutoBlind for ## items" ist dieser Vorgang abgeschlossen, ab diesem Zeitpunkt sind alle Trigger aktiv, auch wenn das Startup-Delay noch läuft.

Zum Debugging der AutoBlind-Konfiguration solltest du, wie mumpf schon geschrieben hat, das log_level der erweiterten Protokollierung in der Plugin-Konfiguration auf 2 setzen (Doku im Wiki auf GitHub). Im entsprechenden Protokoll wird dann im Detail mitgelogt, was das Plugin getriggert hat, welche Bedingungen wie geprüft wurden und welche Aktionen ausgeführt wurden.
Wenn dort keine Hinweise auf ein Triggern des Plugins stehen, dann bleibt eigentlich nur, das smarthome.py Loglevel auf "debug" zu stellen und in den Unmengen von dann entstehenden Log-Zeilen nach den betroffenen GAs bzw. Items zu suchen.

Grüße
offline

[Dragonos2000]

Hallo Waldemar,
ja, hab ich gesetzt...
Werd mal das Plugin deaktivieren und schauen, wie es sich verhält.

Gruß Jochen.

[mumpf]

Hast Du im autoblind auch log_level = 2? Wenn ja, würde ich wetten, dass es nicht am autoblind liegt, solange nichts im log steht.

Gruß, Waldemar