Automatische Beschattung

[offline]

Hallo zusammen,

ich habe gerade die nächsten Änderungen auf GitHub gepusht:

• Alle Attribute haben nun das Prefix "as_" um die Zugehörigkeit zum Plugin zu kennzeichnen, wie von callidomus angeregt. Die vorherigen Attribute werden vorerst weiterhin ausgewertet, erzeugen jedoch eine Warnung im smarthome.py-Log.
• Der Pfad für das erweiterte Logging wird releativ zum smarthome.py Basisverzeichnis ausgewertet, sofern er nicht mit einem "/" beginnt (Sorry Windows-User ....)
• Wenn der Pfad zum erweiterten Logging nicht existiert, wird er angelegt.

Grüße
offline

[offline]

Hi Andreas,

du hast nichts übersesen. Bei enter-Condition Sets kann delay nicht verwendet werden. Das einzubauen ist auch eher aufwändig, denn man bräuchte ja für jeden Zustand einen eigenen delay-Zähler. Um ein Delay bei enter-Bedindungssets zu realisieren würde ich folgendes vorschlagen:

• Lege ein bool Item an, dass über eval "True" wird wenn dein Helligkeitsgrenzwert überschritten wird, und ansonsten False ist.
• Im AutoBlind-Plugin fragst du nun nicht mehr die absolute Helligkeit ab, sondern nur noch dieses neue Item. Über die agemin-Bedingung kannst du dann den Zeitraum vorgeben, seit dem das Item "True" bzw. "False" sein soll.

Grüße
offline

[McTao]

Hi,

ich habe jetzt den ganzen Thread noch mal von vorne gelesen. Echt spannend wie es sich entwickelt hat?

Was ich nirgendwo gefunden habe: gibt es bei enter auch ein delay.

Heute kam bei uns die Sonne für ganze 3 Minuten durch die Wolken => sunrise startet und durch das delay bei leave bleibt es erst mal so.

Habe ich da etwas überlesen oder muss ich mir für enter sunrise noch eine Funktion basteln?
Oder kann man da etwas mit eval machen (eval habe ich kaum benutzt und muss mich da noch etwas reindenken.)

Gruss Andreas

[offline]

Hallo zusammen,

der Push ist erfolgt. Die Doku ist bereits aktualisiert. Für die, die nicht die ganze Doku durchschauen wollen eine kurze Zusammenfassung der Änderungen:

• Es wurden diverse Attributnamen umbenannt. Soweit möglich werden die bisherigen Attribute übergangsweise weiter gelesen, wenn das neue Attribut nicht verwendet wird. In diesem Fall wird eine Warnung ins smarthome.py-Log geschriben.
• Die neuen Attributnamen beginnen bereits mit „as_“ (AutoState). Zukünftig sollen alle Attributbezeichnungen so umgestellt werden.
• "item_active" entfällt und wird durch "as_lock_item" ersetzt. Übergangsweise wird "item_active" noch unterstützt. "as_lock_item" ist eine negierte Form des früheren "item_active".
• "as_lock_item" enthält nur noch die manuelle Sperre der Automatik. Die automatische Unterbrechung nach manuellen Betätigungen kann über ein separates bool-Item ermittelt werden, das über das Attribut "as_suspend_item" angegeben wird. „as_suspend_item“ kann nur gelesen werden, schreiben hat keine Auswirkung auf das Plugin. Wird "as_lock_item" geändert, so wird "as_suspend_item" grundsätzlich zurückgesetzt.
• Das Attribut „manual_break“ wurde in „as_suspend_time“ umbenannt. „manual_break“ wird übergangsweise noch unterstützt
• Das Attribut „watch_manual“ wurde in „as_suspend_watch“ umbenannt. „watch_manual“ wird übergangsweise noch unterstützt.
• Die Plugin-Einstellung „manual_break_default“ wurde in „suspend_time_default“ umbenannt. „manual_break_default“ wird nicht mehr unterstützt, die Verwendung erzeugt eine Warnung im Log.

Grüße
offline

[offline]

Eine Option währe es eventuell, zwei bool-Items zu haben, eines für manuelle und eines für automatische Deaktivierung. Das muss ich mal durchdenken und ggf. auch mal ein wenig rumprobieren ...

Die Umstellung auf zwei bool-Items lässt sich ganz gut an. Sie führt aber dazu dass sich Attribute ändern werden. Zum einen werden neue Attribute gebraucht werden, andere Attribute habe ich umbenannt damit die Benennung einheitlich ist. Vorerst werden jedoch die "alten" Attribute als Rückfallebene verwendet, wenn die "neuen" nicht gesetzt sind. Es gibt dann aber eine Warnung im smarthome.py log. Die neuen Attribute bekommen bereits alle das Prefix "as_" (AutoState), das in Zukunft einmal alle Attribute des Plugins kennzeichnen soll. Ich denke dass ich das Ergebnis heute Abend oder morgen früh auf GitHub pushen kann..

Grüße
offline

[Dragonos2000]

Hi,

mit dem Link hast Du recht, der ist schwer zu finden, wenn man nicht von Beginn an bei dem Thread dabei war.

Was aber die Doku angeht, so ist die im GIT wirklich super und eigentlich vollständig und verständlich gemacht. Wichtig ist erstmal Smarthome.py zu verstehen, dann erklärt sich die Konfig des Plugins von alleine. Alles andere wäre nur Wiederholung der Smarthome.py Doku.
Zur Frage 1): Ja, geht. Du musst halt die Werte in Smarthome.py per Item verfügbar haben, um sie im Plugin nutzen zu können. Daraus musst Du ein entsprechendes Condition-Set und Position definieren. Für eine Anwesenheitserkennung gibt es zig Wege, das hat aber nichts mit dem Plugin zu tun.
Zur Frage 2): Siehe 1

Gruss
Jochen.

[Yfkt5A]

Jetzt muss ich mich hier auch mal zu Wort melden...

Bin hier eifrig am mitlesen, scheint mir ein wirklich tolles Plugin zu sein das hier auf die Beine gestellt wird. Leider konnte ich noch nicht testen da ich gerade auf SmartHome.py/smartVISU umstelle und hier immer nur sporadisch Zeit dafür habe.

Im Moment bin ich eher damit beschäftigt mir die Grundlagen anzueignen...

Was aber denke ich einem Anfänger wie mir wirklich weiterhelfen würde, wäre wenn ihr mal in einem Post(Startpost wäre m.M. nach dafür geeignet) zusammenfassen könntet welche Grundvorraussetzungen in welchen Dateien geschaffen werden müssen und am Beispiel einer Jalousie alle Konfigurationsmöglichkeiten mit Kommentar dahinter zeigt. Auch der Link zu Git würde dem ein oder Anderen schon etwas helfen, ist nämlich gar nicht so einfach zu finden. Evtl. könnte man die Beschreibung im Git ergänzen, aber deutsch wär mir etwas lieber
hier mal ein Beispiel:
plugin.conf

# plugin.conf
[autoblind]
    class_name = AutoBlind
    class_path = plugins.autoblind
    #cycle = 300                                 #Interval between two checks
    #item_id_height = hoehe                     #Id of the sub-item which is used to set the height value for the blinds
    #item_id_lamella = lamelle                     #Id of the sub-item which is used to set the lamella angle value for the blinds
    #log_level = 0                                 #Extended logging: Loglevel (0: off, 1: info, 2: debug
    #log_directory = /usr/local/smarthome/var/log/AutoBlind/ #Extended logging: Directory for Logfiles (directory has to exist!)
    #manual_break_default = 3600                 #Default time to deactivate the automatic controll after manual changes (Seconds)[B][/B]

waehledeinenNamen.conf

[essen]
    [[kueche]]
        name = Raffstore Fenster Kueche
        [[[AutoBlind]]]
            watch_manual = room1.raffstore.aufab | room1.raffstore.step        #watch this items to deactivate automatic control at manual action
            manual_break = 7200                                                #deactivation period in seconds
            [[[[active]]]]
                type = bool
                knx_dpt = 1
                knx_send = x/x/x
                knx_status = x/x/x
                knx_listen = x/x/x | x/x/x
                visu_acl = rw
                cache = on
            [[[[lastpos_id]]]]
                type = str
                visu_acl = r
                cache = on
            [[[[lastpos_name]]]]
                type = str
                visu_acl = r
                cache = on
            [[[[night]]]]
            type = foo
            name = Night                         #Name of position. Will be written in lastpos_name if position is active and can be displayed in visualization
            position = 100,0                    #Blind position to set if position is active. See below for possible values
                                                #For the attribute position there are two possible types of values that can be used:
                                                #    static position: To values separated by comma. First value his the value for heigth, second value is the value for lamella angle. Example: 100,0
                                                #    dynamic position: value "auto". Height will be set to 100%, lamella angle will be calculated based on sun position.
            use = some.default.item                #Import settings from a different item. If enter and/or leave are included in the current item too, the conditions in this child items overwrite the matching imported conditions
                [[[[[enter]]]]]                    #Condition set that has to be fulfilled before the position can become active
                    #(…)
                [[[[[leave]]]]]                    #Condition set that has to be fulfilled before the position can be left
                    #(…)[B][/B]

Und aus aktuellem Anlass noch zwei Fragen zur Funktion...
1. kann man das Plugin schon so konfigurieren das bei bestimmten Vorraussetzungen - in meinem Fall Abwesenheit, Helligkeit + Temperatur über bestimmten Wert - alle Jalousien herunterfahren und komplett zuklappen -> soll die Hitze noch besser draußen lassen
2. bei Temperatur <0 Jalousien nur noch 90% herunterfahren -> festfrieren vermeiden

Wäre toll wenn das funktionieren würde oder evtl. noch berücksichtigt werden könnte... Danke

[mumpf]

Eine Option währe es eventuell, zwei bool-Items zu haben, eines für manuelle und eines für automatische Deaktivierung.

Hi,
genauso meinte ich das... Hab mich nur nicht klar genug ausgedrückt.
Gruß, Waldemar

[offline]

ist das nicht nur eine Lösung für den eibd?

Ja, aber genau das sollte ausreichen. Mit enforce_updates = yes löst das KNX Plugin nochmal ein Update des Items aus (der gesendete Wert wird wieder empfangen).

Ich glaube nicht, dass Du auf Dauer mit einem bool-Item glücklich wirst, denn de Facto willst Du 3 Zustände auswerten: aktiv, automatisch deaktiviert, manuell deaktivert.

Ein bool-Item hat den Charme, dass es einfach auf einen Taster o. ä. gelegt werden kann. Mit einem num-Item wäre das aufwändiger. Eine Option währe es eventuell, zwei bool-Items zu haben, eines für manuelle und eines für automatische Deaktivierung. Das muss ich mal durchdenken und ggf. auch mal ein wenig rumprobieren ...

GRüße
offline

[mumpf]

... von der phys. Adresse 0.0.0 ausgelöst wurden...

Hi offline,

ist das nicht nur eine Lösung für den eibd? Ich dachte immer, IP-Schnittstellen bekommen eine eigene phys. Adresse, dann würde Dein Workaround nicht funktionieren.
Muss man das aktuelle "active" nicht eigenlich als ein Status verstehen und noch ein "manual_active" vorsehen - oder - um es so wie bei KNX üblich zu machen - ein "sperren" vorsehen? Sperren wäre dann natürlich im vergleich zu "active" eine Negierung.

Ich glaube nicht, dass Du auf Dauer mit einem bool-Item glücklich wirst, denn de Facto willst Du 3 Zustände auswerten: aktiv, automatisch deaktiviert, manuell deaktivert.

Just my 5 ct...
Gruß, Waldemar

[mumpf]

Hi,

mir fallen da spontan 2 Lösungen ein:

1. Wenn es um konstante Zeit oder einfache Bedingungen geht, nimm einfach ein crontab oder ein eval am active-Item.
2. Wenn es kompliziert werden soll, also verschiedene Bedingungen oder weitere Zustände, nimm einfache einen 2. Zustandsautomaten (also ein 2. AutoBlind-Item, bei dem Du die Regeln spezifizierst, die das eigentliche Autoblind aktivieren sollen und machst die set-Action auf das active-Item vom Ursprungs-Autoblind-Item.

Deswegen glaube ich nicht, dass man hier noch mehr Funktionalität in das Autoblind packen müsste...

Gruß, Waldemar

[Onkelandy]

Heho zusammen!

Bei mir läuft jetzt soweit mal alles wie es soll.. vielen Dank nochmals für die Top-Entwicklung!
Eine Frage hätte ich dennoch:
Es wurde hier mal diskutiert, dass die manuelle Deaktivierung wieder durch einen konkreten Zustand aufgehoben werden soll. Also zB ich habe ein 12stündiges manual_break und lasse die Rolläden um 15.00 Uhr rauf. Möchte aber, dass in der Nacht, zB um 21.30 Uhr auf jeden Fall die Läden wieder runter gehen. Gibt es hier einen aktuellen Lösungsansatz für sowas? Würde natürlich nur Sinn machen, wenn man das dezidiert für bestimmte Rollläden und nur einzelne Conditions so definieren könnte und das kein Standardverhalten ist.

[McTao]

Man kann nun enforce_updates setzen und wenn man dann bei automatisch deaktivierter Automatik nochmal ein "False" auf das active-Item schickt, wird daraus eine manuelle Deaktivierung.

Danke. Ist bei dir eigentlich nie Feierabend?

Ich werde es morgen dann testen.

gruss Andreas

[offline]

Mit "enforce_updates" führt ein manuelles Fahren schon zur permanenten Deaktivierung, da die Rückmeldung über KNX als manuelles Setzen des active-Items gewertet wird. Hier werde ich nochmal etwas nachsteuern müssen ...

Das Problem sind hier die Quittungstelegramme über KNX (ich glaube so ein Problem hatten wir schonmal). Es lässt sich leider nicht sauber feststellen, ob eine Item-Änderung durch ein "Write" oder ein "Response" auf dem KNX-Bus ausgelöst wurde. Als Hilfslösung habe ich eine kleine Änderung eingebaut, die Änderungen des active-Items ignoriert, wenn sie über KNX kommen und von der phys. Adresse 0.0.0 ausgelöst wurden. Damit werden die Quittungstelegramme ignoriert. Man kann nun enforce_updates setzen und wenn man dann bei automatisch deaktivierter Automatik nochmal ein "False" auf das active-Item schickt, wird daraus eine manuelle Deaktivierung.

Grüße
offline

[offline]

Hi Andreas,

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.

Ich habe das bei mir mal nachgestellt. Ohne "enforce_updates" kommt das zweite "False" nicht durch. Der Wert des active-Items ist ja bereits "False"
Mit "enforce_updates" führt ein manuelles Fahren schon zur permanenten Deaktivierung, da die Rückmeldung über KNX als manuelles Setzen des active-Items gewertet wird. Hier werde ich nochmal etwas nachsteuern müssen ...

Grüße
offline