Automatische Beschattung

[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]

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]

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]

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

[Dragonos2000]

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

Gruß 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]

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.

[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]

Hallo Waldemar,

danke für den Tipp! Werd ich versuchen.

Gruss
Jochen.

[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

[Onkelandy]

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

[Dragonos2000]

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

[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.

[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

[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