Automatische Beschattung

[McTao]

Hi Martin,

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

Nein, die gibt es schon nicht mehr, aber es ist noch kein "master"-Zustand erreicht:
Das README.md ist noch in der Entwicklung. Alles aus der Update.md steht inzwischen schon in der README.md aber diese ist noch nicht vollständig.
Es fehlen noch Teile der Beschreibung und Beispiele wollte offline auch noch ergänzen. Du kannst Dich also an die README.md halten und es fehlen dann keine Informationen. Einiges findest du in den letzten Beiträgen, was nicht nicht in der README.md steht, deshalb ist diese also noch nicht ganz fertig.

Gruss Andreas

[mumpf]

Gäbe es die Möglichkeit, einen "Toleranzbereich" für Soll-Position und Ist-Position zu implementieren,

Hi Jochen,

gibt es schon, schau mal in der Doku unter Using a delta to prevent small changes

Grüße, Waldemar

[martinb07]

Das README.md ist noch in der Entwicklung. Alles aus der Update.md steht inzwischen schon in der README.md aber diese ist noch nicht vollständig.

Die item-Struktur ist auf dem aktuellen Stand, oder? Da gab es doch mal Änderung, oder?

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

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

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]

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

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

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

[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

[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

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

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]

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]

Hallo offline,

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