Automatische Beschattung

[offline]

Hi Onkelandy,

bei welchen Items die Automatik temporär deaktiviert wird, wird über das Attribut "watch_manual" angegeben. Ich habe da jeweils die Items für "auf/ab" bzw. "step/stop" hinterlegt, über die die Raffstores manuell von den Tastern gefahren werden. Wielange die Automatik temporär deaktiviert wird, wird über das Attribut "manual_break" festgelegt. Wenn zu einem AutoBlind-Item kein "manual_break"-Attribut angegeben ist, wird der in der Plugin-Konfiguration angegebene Wert von "manual_break_default" verwendet. Der Vorgabewert dafür sind 3600 Sekunden (1 Stunde)

Grüße
Offline

[Onkelandy]

Hi offline!

Auch von mir mal ein Danke für dein Plugin! Im Großen und Ganzen komm ich so langsam mit.. Das Aktivitem wird bei jedem Anfahren eines Zustands auf 0 gesetzt.. aber wie lange genau? Wie das manual_delay eingestellt ist? Oder min_age beim Leave-Zustand?

Das mit dem Dummy-Item für die Lamellen funktioniert bei unseren Screens und Rolläden auch wunderbar.

Danke jedenfalls vorerst und schöne Grüße!

[mumpf]

Hi Thomas,
ich habe bei meinen Rollläden wirklich für die Lamellenposition ein Zusatzitem spendiert und setze das immer auf 0. Klappt super.
Danke für die String-Korrektur, aber ich habe gerade alles auf num umgebaut, insofern kann ich es nicht mehr testen. Aber gut zu wissen, dass ich in Zukunft auch die checken kann.
Gruß,
Waldemar

[offline]

Hallo Waldemar,

freut mich, wenn es bei dir funktioniert. Wie hast du dass mit den Rolläden gemacht, hast du wie ich mal vorgeschlagen hatte einfach ein Dummy-Item für die Lamellenstellung genommen?
Das mit den String-Conditions sollte jetzt auch funktionieren. Ich habe die beiden Feature-Branches für den watch_trigger und die delay-Condition in den develop-Branch gemerged und noch den Fix für die String-Conditions eingebaut.

Grüße
Thomas

[mumpf]

Hallo Thomas,

ich habe Dein Plugin jetzt mal ausprobiert, bin gerade dabei, es für alle Rollläden im Haus zu adaptieren. Das mit watch_trigger passt prima, danke für Deinen Support.
Du solltest vielleicht noch in die Doku aufnehmen, dass bei generischen Conditions alle Werte nummerisch oder bool sein müssen... ich hatte auch ein String-Item dabei, und dann initialisiert sich AutoBlind nicht, schreibt nicht ins log (weder das eigene noch das von sh.py) und ich habe ziemlich lange suchen müssen, um die Fehlerursache zu finden.

Danke nochmal,
Gruß, Waldemar

[panzaeron]

Etwas schnell abgeschickt, danke für das Beispiel, ich schaue mir das demnächst genauer an.

[panzaeron]

offline Danke für die Info, mit dem Fenster hoch hast du recht, sollte im Aktor passieren. Bei mir habe ich aber zwei Kontakte die ausgewertet werden müssen um sicher drehgeöffnet zu erkennen, daher habe ich das mit einer Logik gelöst.

[offline]

Hi panzaeron,

also ich habe sicherheitsrelevante Funktionen wie z. B. das Hochfahren/Obenbleiben der Raffstores bei geöffneter Tür oder auch den Windalarm direkt im Aktor realisiert. Solche Funktionen sollten meiner Meinung nach nicht in irgendeiner Programmierung versteckt sein, sondern so einfach wie möglich implementiert sein.

Für die Rolladensteuerung bei geöffnetem Fenster brauchst du zwei Positions-Items für Nacht-Positionen. Über eine generische Bedingung kannst du dabei den Fensterkontakt einbauen. Verkürzt kann das etwa so ausschauen:

[[[AutoBlind]]]
    item_fensterkontakt = item.fuer.fensterkonakt
    [[[[active]]]]
        (...)
    [[[[lastpos_id]]]]
        (...)
    [[[[lastpos_name]]]]
        (...)  
    [[[[nacht_fensterzu]]]]
        type = foo
        name = Nacht und Fenster zu
        position = 100,0
        [[[[[enter]]]]]
            value_fensterkontakt = False
            (weitere Nachbedingungen)
    [[[[nacht_fensterauf]]]]
        type = foo
        name = Nacht und Fenster auf
        position = 90,0
        [[[[[enter]]]]]
            value_fensterkontakt = True
            (weitere Nachbedingungen)
    [[[[tag]]]]
        type = foo
        name = Tag
        position = 0,0
        [[[[[enter]]]]]
            (Tagbedingungen)

@mumpf:
Mit dem Gedanken spiele ich auch schon länger. Ich bin nur am überlegen wie ich das genau realisiere. Ich möchte die Konfiguration nicht unnötig verkomplizieren.

Grüße
Thomas

[panzaeron]

OK, danke für die Info, ich werde mich demnächst mal genauer mit dem Plugin auseinander setzen.

[mumpf]

Hi panzaeron,

unter Anderem dafür wollte ich die ereignisgetriggerte Auswertung der Zustände haben: Beim Fenster öffnen (Ereignis) sofort die Zustandsauswertung - und dann muss es eben einen Zustand offen geben, der dann die Position 0,0 anfährt. Alles andere, was Du geschrieben hast, sollte auch schon vorher gegangen sein.

@offline:
Lieber Thomas, Dein plugin wird mir wunderbar auch bei meiner Lüftungssteuerung helfen, das ist nämlich mit einem Zustandsautomaten wesentlich übersichtlicher zu schaffen als Ereignisgesteuert mit vielen kleinen scripts. Vielleicht solltest Du Dein Plugin aufteilen: Allemeiner Zustandsautomat und darauf aufbauend die Verschattungssteuerung...

Vielen Dank für Deine Arbeit,
Waldemar

[panzaeron]

@offline
Ich habe bei mir die Rolladensteuerung auch mit vielen kleinen Logiken realisiert, deshalb wäre es interessant für mich dies mit deinem Plugin zu lösen.
Was ich beim Lesen der Doku noch nicht sehen konnte ist, wie ich am Besten meine Tür-/Fensterkontakte (geschlossen/offen/gekippt) einbinden kann. Damit meine ich, Rollladen hoch, wenn z.B. eine Tür geöffnet ist/wird oder Nachts wenn das Fenster gekippt ist, den Rollladen auf 90% fahren statt ganz nach unten.

Ist sowas mit deinem Plugin möglich?

[mumpf]

Cool - und irre schnell - DANKE!

Allerdings kann ich das erst kommende Woche ausprobieren, ich bin - wie schon erwähnt - noch im Urlaub...
Das der watch_trigger die Zeit für das reguläre Update nicht ändert, sollte ja bei einem Zustandsautomaten kein Problem sein...

Ich werde das mal austesten und Dir kommende Woche Feedback geben,
Danke nochmal, Waldemar

[offline]

Hi Waldemar,

über eine solche Funktion habe ich mir auch schon Gedanken gemacht gehabt. Ich habe mal was gebaut und auf GitHub im Branch "feature-watch-trigger" eingestellt. Mit der Erweiterung kann im AutoBlind-Item über das Attribut "watch_trigger" eine Reihe von Items angegeben werden, die ein Update des jeweiligen AutoBlind-Objekts auslöst. Das reguläre Update wird dabei im Moment nicht beeinflusst, dass heist, dass ggf. das reguläre Update kurz darauf nochmal läuft.

Grüße
Thomas

[mumpf]

Hi offline,

vielen Dank für das Plugin - es sieht sehr gut aus.

Ich versuche gerade, meine existierende script-Sammlung durch Dein Plugin abzulösen - derzeit allerdings nur theoretisch, da ich im Urlaub bin. Ich vermisse eigentlich nur eine Sache: Ich würde gerne auch ereignisgesteuert bestimmte Zustände anspringen können (und nicht nur alle n Sekunden).
Das kann man auf mehrere Weisen erreichen, z.b. indem man in den Zustands-Items noch einen trigger einbaut oder indem man eine (bzw. mehrere, wie beim eval_trigger) Trigger-Bedingung(en) am "AutoBlind"-Item zuläßt, die einfach eine erneute Auswertung der Regeln "außer der Reihe" erzwingen (fände ich am besten). Man hätte dann einfach ein passendes Zustands-Item, dass die Trigger-Bedingung auch mit evaluiert und so könnte man bestimmte Zustände anspringen.

Derzeit behelfe ich mir mit einem solchen Zustands-Item (das dann ja auch nach spätestens 5 Minuten angesprungen wird) und schicke zusätzlich die entsprechende Position an den Aktor, sobald das Ereignis erfolgt - allerdings kollidiert das mit der manuellen Bedienung, so dass dafür wieder Sonderlogik und extra-Items nötig sind (und was nicht nötig wäre, wenn alles durch Deinen Zustandsautomaten geht).

Langer Rede kurzer Sinn: Könntest Du noch eine Art "eval_trigger" an das AutoBlind-Item basteln, das dann die Zustände neu evaluiert?

Wäre toll,
Gruß, Waldemar

[offline]

Hallo zusammen,

es gab noch einen Bug, das die Items zu den generischen Bedingungen nicht korrekt ermittelt wurden, wenn man zu einem AutoBlind-Objekt alternative Bedingungssets definiert hat, die Basiskonfiguration zu diesem Objekt aber über "use" aus anderen Bedingungen ermittelt hat. Ein Fix ist im develop-Zweig auf Github.
Vor dem Merge von develop in master werde ich noch verzögern und noch ein wenig testen ...

Grüße
Thomas