Automatische Beschattung

[mumpf]

@Andreas: Schau doch mal, ob sich das Problem mit enforce_updates = true am active-Item lösen läßt? Ich habe die von Dir beschriebene Kombi noch nicht gehabt...

Gruß, Waldemar

[Dragonos2000]

Ein großes Danke für die schnelle Umsetzung der Ideen/Anregungen und Fixes !!!

[McTao]

Hi,

habe etwas, was ich mir nicht erklären kann, kann das mal jemand prüfen, ich glaube es ist ein Fehler:

Ich fahre eine Jalousie per Hand, durch das watch_manual wird danach für eine Stunde der Sonnenschutz deaktiviert. (So weit richtig.)
Setze ich nun innerhalb dieser Stunde das active Item auf false, beginnt die Automatik nach einer Stunde wieder mit dem Sonnenschutz.

Die Deaktivierung scheint in der watch_manual Phase nicht berücksichtigt zu werden und wird danach auch nicht wieder abgefragt.

Wenn dieses Verhalten nur bei mir ist, werde ich mal Ausschnitte aus den Log-Dateien raussuchen.

Gruss Andreas

[jonah64]

Hallo offline,

Danke für die schnelle Antwort. Kapiert!
Gruß jonah

[offline]

Kannst Du mir das kurz erklären? Wie kann ein active-Item auf mehrere GA's hören?

In der AutoBlind-Konfiguration wird auf ein fensterspezifisches active-Item verwiesen:

    item_active = raum.raffstore.fenster1.auto_active

Dieses Item ist wie folgt definiert:

[raum]
    [[raffstore]]
        [[[fenster1]]]
            [[[[auto_active]]]]
                type = bool
                knx_dpt = 1                    
                knx_send = 1/1/67
                knx_listen = 1/1/67 | 1/1/57 | 1/1/17 | 1/0/17
                visu_acl = rw
                cache = on

Dadurch hört das Item nicht nur auf die 1/1/67 (die fensterspezifische GA) sondern zusätzlich noch auf 1/1/57 (raumspezifisch), 1/1/17 (stockwerksspezifisch) und 1/0/17 (gesamtes Haus). Die zusätzlichen Adressen sind dann auch jeweils bei den fensterspezifischen active-Items der anderen Fenster zugeordnet.

Grüße
offline

[jonah64]

Hi offline,
... klingt alles gut...

zu (1):

Die jeweiligen active-Items hören jeweils auf alle relevanten KNX-GA.

Kannst Du mir das kurz erklären? Wie kann ein active-Item auf mehrere GA's hören?

Gruß Jonah

[offline]

Hi Jonah,

(1) Ist es möglich, bei item_active mehrere items einzutragen? Falls nicht, würde ich mir so etwas wünschen. Ich hätte nämlich gerne die Funktionalität gegebenenfalls das automatische Fahren fürs ganze Haus abzustellen, pro Zimmer oder pro Rollo. Wenn also eins dieser Bedingungen erfüllt ist, soll das automatische Fahren deaktiviert werden.

Das Plugin kann hier nur ein Item auswerten, da ja der Wert dieses Items ggf. auch verändert wird. Ich habe das bei mir so gelöst, dass ich verschiedene KNX-GA für die Sperrfunktion habe (pro Raffstore, Zimmer, und für das gesamte Haus). Die jeweiligen active-Items hören jeweils auf alle relevanten KNX-GA.

(2) Defaultmässig ist der Pfad #log_directory = /usr/local/smarthome/var/log/AutoBlind/ eingestellt.
Ich würde mir wünschen, dass der Pfad standardmäßig relativ zum aktuellen smarthome-Verzeichnis eingestellt wird.

Das sollte realisierbar sein.

(3) Das log_directory ("AutoBlind"-)Unterverzeichnis muss schon vorhanden sein, richtig? Vielleicht kann man das automatisch anlegen, falls nicht vorhanden.

Das ist bereits eingeplant ...

(4) Ich finde die Plugin-spezifischen Attribute mit einem Prefix zu versehen, wir mknx in #132 vorschlägt, sinnvoll. Das beugt Konflikte mit anderen Komponenten vor.

Das Problem hierbei ist, dass es einige User gibt die das Plugin bereits umfangreich nutzen und einen dementsprechend großen Änderungsaufwand haben, wenn die Attribute umbenannt werden. Ich habe daher geplant die Funktionalitäten zunächst einmal fertigzustellen und anschließend einen großen Änderungsdurchgang zu machen, nachdem der fertige Stand in den master-Branch gemerged wurde. Dadurch müssen die vorhandenen Nutzer des Plugins nicht auf einen Schlag umstellen, sondern können das bei Bedarf noch hinauszögern. Kommen soll aber auch das auf jeden Fall.

Grüße
offline

[jonah64]

Hallo,
super Plugin, die letzten Erweiterungen kamen auch gerade zum richtigen Zeitpunkt, als ich die ersten Versuche unternahm und mir genau diese Funktionalität von "item:" wünschte. Damit ist für mich dieses Plugin variabler als die UZSU denke ich.

Paar Anmerkungen habe ich noch (konstruktive hoffe ich)
(1) Ist es möglich, bei item_active mehrere items einzutragen? Falls nicht, würde ich mir so etwas wünschen. Ich hätte nämlich gerne die Funktionalität gegebenenfalls das automatische Fahren fürs ganze Haus abzustellen, pro Zimmer oder pro Rollo. Wenn also eins dieser Bedingungen erfüllt ist, soll das automatische Fahren deaktiviert werden.
(2) Defaultmässig ist der Pfad #log_directory = /usr/local/smarthome/var/log/AutoBlind/ eingestellt.
Ich würde mir wünschen, dass der Pfad standardmäßig relativ zum aktuellen smarthome-Verzeichnis eingestellt wird.
(3) Das log_directory ("AutoBlind"-)Unterverzeichnis muss schon vorhanden sein, richtig? Vielleicht kann man das automatisch anlegen, falls nicht vorhanden.
(4) Ich finde die Plugin-spezifischen Attribute mit einem Prefix zu versehen, wir mknx in #132 vorschlägt, sinnvoll. Das beugt Konflikte mit anderen Komponenten vor.

Gruß jonah

[mumpf]

Der Wert, gegen den bei den Bedingungen min_*, max_* bzw. value_* geprüft wird, muss nun nicht mehr nur statisch sein, sondern kann auch über ein anderes Item angegeben werden. Dazu gibt man statt einem Festwert "item: (item name)" an.

Hi!

Der obige Punkt ist der Bringer - auch wenn er mich viel Zeit bei der Visu kosten wird. Aber es ist natürlich klasse, wenn man die Grenzwerte dynamisch einstellen kann.
Vielen Dank für die Erweiterungen,

Gruß, Waldemar

[offline]

Es gibt so viele Möglichkeiten. So langsam ist Zeit für ein "Special":
Best of, How I did it ...

Das Wiki auf GitHub (https://github.com/i-am-offline/smar...autoblind/wiki) ist der ideale Platz für sowas ...

Grüße
offline

[McTao]

Hi offline,

dein letztes update hat es noch mal so richtig rund gemacht. Jetzt muss ich mir nur noch einmal Gedanken bei der Logik machen (da gibt es ja so viele Möglichkeiten und Ideen, die man umsetzen kann). Die Grenzwerte lassen sich dann in der Oberfläche ändern. Das ergibt auch einen hohen WAF.

Ich musste bisher immer smarthome neu starten und dann gab es einige init Aktionen, die unschön waren. Das geht jetzt zur Laufzeit, super.
Jetzt muss ich mir nur noch die Möglichkeiten mit den run, eval etc ansehen, um noch flexibler zu werden.

Es gibt so viele Möglichkeiten. So langsam ist Zeit für ein "Special":
Best of, How I did it ...

Gruss Andreas

[offline]

Hallo zusammen,

ich habe gerade einige Änderungen in den develop-Zweig auf GitHub gepusht:

• Es gibt nun eine zusätzliche Action-Möglichkeit "run_(action name)" die nur eine Funktion ausführt (analog eval: ) aber kein Item setzt. Passend dazu gibt es in eine Standart-Eval Methoden eine Methode "execute" zum Ausführen eines Shell-Kommandos
• Der Wert, gegen den bei den Bedingungen min_*, max_* bzw. value_* geprüft wird, muss nun nicht mehr nur statisch sein, sondern kann auch über ein anderes Item angegeben werden. Dazu gibt man statt einem Festwert "item: (item name)" an.
• Zustände ohne Bedingungssets sind nun zulässig. Das kann man Nutzen, um als letzten Zustand einen Default-Zustand zu definieren.
• Es gibt nun eine Standardbedingung (month) zum Abprüfen des Monats
• Zu guterletzt ist die Doku jetzt komplett aktuell und sollte alle relevanten Punkte enthalten.

Grüße
offline

[Dragonos2000]

Kann ich eigentlich mit den vorhandenen Mitteln irgendwie den aktuellen Monat in eine Bedingung mit einbauen? Ein Ansatz, der mir ad hoc einfällt wäre, ein Monats-Item zu erzeugen und mit eval und datetime mit dem aktuellen Monat zu beschreiben.
Gibt's nen simplereren Weg?
Hintergrund ist, dass ich in den Sommer-Monaten eine agressivere Beschattung implementieren will, als sonst. Könnte man zwar alles mit Temperaturen und Sonnenwinkeln hinbasteln, per Monat ginge es aber simpler.

Gruss
Jochen.

[offline]

Ich wollte mich gerade dran machen die Item für das Plugin aufzubohren und habe folgenden Text in der Readme.md im dev-Zweig auf Github gelesen:

[...]

So weit so gut, aber wo finde ich die UPDATE.md? Bin ich blind?

Der Satz kann eigentlich wieder aus der Doku raus. Die wesentlichen Änderungen sind in der README.md enthalten, so dass sie aktuell ist. Ich werde am WE nochmal drüberschauen und den Satz dann entfernen.

Grüße
offline

[Dragonos2000]

Hi Waldemar,

danke für die Info.
Ich hatte so'n Bauchgefühl, dass ich das schon gelesen hatte und hab' aber im Thread vergeblich danach gesucht.

Gruss
Jochen.