Automatische Beschattung

[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

[Dragonos2000]

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

[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

[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

[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

[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

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

[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

[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

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

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

[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

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

[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

[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