Automatische Beschattung

[McTao]

Hallo,

ich habe bei mir jetzt die Version vom 25.6. morgens aus Develop am laufen. Ich kann keine Fehler feststellen, habe nur an 2 Stellen "negate" einbauen müssen.

Ich dachte eher daran, im Plugin zu filtern. Das würde aber voraussetzen, dass der Caller beim manuellen Fahren und beim Fahren über das Plugin unterschiedlich ist.
Die entsprechende Stelle zum Ausfiltern ist in AutoBlindItem.py direkt am Anfang von "__watch_manual_callback". Dort werden bereits "plugin" und "timer" ausgefiltert.

Danke, diese Info in Verbindung mit dem Hinweis neue Items anzulegen hat dazu geführt, dass ich eine Lösung gefunden habe:
meine Items haben nun ein dummy Objekt:
[move_manual]
type = bool
knx_dpt = 1
enforce_updates = yes

und dieses ist in watch_item eingetragen.

Wenn ich dann automatisch hoehe/move in meiner eigenen Logik setze, wird dieses gesetzt, wenn der "Absender" KNX bzw VISU ist.

Gruss Andreas

[offline]

Kurze Zwischeninfo: Mit dem nächsten Push auf GitHub werden noch weitere Umstellungen in der Konfiguration erforderlich sein. Wer nicht zweimal umbauen möchte sollte mit dem Test noch etwas warten. Der Push wird vermutlich Freitag oder Samstag morgen passieren. Grüße Offline

[Onkelandy]

Hehe, meine Geisterpost wurde in dem Fall noch gelesen Ich dachte, dass es irgendwie am Aktor liegt, da er nämlich so getan hat, als wäre er schon oben (Wert 0 in der ETS). Okay, cool, dann probier ich's mal mit der neuen Developversion...

[offline]

Aber in dem Fall muss man jetzt alle Zeiten nochmals umbasteln, sehe ich das richtig? Ich denke, ich warte bis zum nächsten großen Push und teste dann

Grundsätzlich betrifft das die Bedingungen, bei denen bisher ein "Nulldurchgang" erlaubt war (time, sun_azimut, weekday). Sofern eine Bedingung mit einem "Nulldurchgang" definiert war (z. B. "von 20:00 Uhr bis 08:00 Uhr"), muss diese Bedingung wie von firefox beschrieben umgestellt werden. Wenn man das vergisst, gib es entsprechende Warnungen im smarthome.py log.

Onkelandy Das Phänomen, dass du aus deinem Post wieder rausgenommen hast, ist bekannt und sollte im aktuellen Develop-Branch behoben sein: Wenn die Automatik deaktiviert war und bei der Positionsermittlung nach der Reaktivierung die gleiche Position wie vor der Deaktivierung ermittelt wurde, wurde die Position nicht immer richtig angesteuert.

Für mich wäre z.B. auch eine Item Bedingung hilfreich à la --> verlasse position 5 minuten nach dem Item Anwesenheit = True ist

Das sollte mit der neuen Struktur kein Problem darstellen. Ich würde es so realisieren, dass zu jedem "item_(name)" zusätzlich ein "minage_(name)" und "maxage_(name)" definiert werden kann, um zusätzlich nach dem Alter des Item-Werts einzuschränken.

Grüße
offline

[Onkelandy]

Super Entwicklungen hier, klingt interessant. Aber in dem Fall muss man jetzt alle Zeiten nochmals umbasteln, sehe ich das richtig? Ich denke, ich warte bis zum nächsten großen Push und teste dann

[firefox]

Hi,

• Standardtrennzeichen für Zeitangaben ist in Zukunft der Doppelpunkt. Das Komma wird aber vorerst weiterhin unterstützt
• Einige Bedingungen (time, sun_azimut, weekday) konnten bisher mit min > max definiert werden. Das wird in Zukunft nicht mehr gehen.
• Als Ersatz dafür wird es die Möglichkeit geben, Bedingungen zu negieren. (aus min=22:00, max=08:00 wird dann min=08:00, max=22:00, negate=True)

• Trennzeichen funktioniert bei mir wunderbar
• Fehler wurde mir nachvollziehbar angezeigt:
  

  2015-06-24 19:27:27,504 ERROR    autoblind    Item 'EG.Bad.Rollo.AutoBlind.night', Condition Set 'enter', condition 'time': Condition time: 'min' must not be greater than 'max'! -- AutoBlindLogger.py:error:135

• Zeiten gedreht, negate = true ergänzt. --> alles wunderbar.

Funktionert bis jetzt problemlos.

Im nächsten Schritt ist geplant, dass zu jeder Position beliebig viele Items auf beliebige Werte (statisch oder dynamisch) gesetzt werden können. Außerdem sollen beispielsweise Logiken getriggert werden können. Hierbei wird es weitere Änderungen geben, die eine Anpassung der bisher verwendeten Konfiguration erforderlich machen. Wahrscheinlich wird die feste Ankopplung an in Item mit Sub-Items für "hoehe" und "lamelle" sowie die Angabe der Zielposition entfallen. Das hat jedoch den Vorteil, dass man die gesamte Beschattungssteuerung zusammen (beispielsweise in einer .conf-Datei) haben kann und nicht über alle Jalousieitems verteilen muss.

Grüße
offline

Da bin ich schon gespannt. Für mich wäre z.B. auch eine Item Bedingung hilfreich à la --> verlasse position 5 minuten nach dem Item Anwesenheit = True ist

[offline]

Nabend zusammen,

ich werde erst am Wochenende auf die neue Version umstellen können, da ich dann sturmfreie Bude habe

Bis zum Wochenende kann ich auch die restlichen Änderungen auf GitHub pushen. Fertig ist fast alles, ich teste im Moment im Selbstversuch. Meine Frau hatte keine Beschwerden als ich heute von der Arbeit gekommen bin, also läuft der Versuch gut ;-))
Es fehlen nur noch Kleinigkeiten und die Doku ...

Danke, habe ich im Log gesehen. Ich prüfe gerade ob es einfacher ist eine hörende "Move"-Adresse anzulegen oder in der Logic zu filtern.

Ich dachte eher daran, im Plugin zu filtern. Das würde aber voraussetzen, dass der Caller beim manuellen Fahren und beim Fahren über das Plugin unterschiedlich ist.
Die entsprechende Stelle zum Ausfiltern ist in AutoBlindItem.py direkt am Anfang von "__watch_manual_callback". Dort werden bereits "plugin" und "timer" ausgefiltert.

Grüße
offline

[McTao]

Hi,

Wenn das Plugin auf manuelle Änderungen reagiert, schreibt es ins erweiterte Log, wer welches Item geändert hat (bei loglevel=2). Schau mal, was da bei dir steht, wenn die Höhe über das Plugin angepasst wird und wenn die Höhe manuell angepasst wird. Ggf. lässt sich da was ausfiltern.

Danke, habe ich im Log gesehen. Ich prüfe gerade ob es einfacher ist eine hörende "Move"-Adresse anzulegen oder in der Logic zu filtern.

Gruss Andreas

[mumpf]

Hi,

das ging jetzt schneller als gedacht... ich werde erst am Wochenende auf die neue Version umstellen können, da ich dann sturmfreie Bude habe (Frau und Kinder sind unterwegs).
Werde dann entsprechend Feedback geben.

Gruß, Waldemar

[firefox]

Hallo zusammen,
bei mir läuft das Plugin auch schon seit einigen Tagen. Werde mich dem Test ebenfalls anschließen und nachher mal auf die neue Version umschalten.

Gruß Thomas

[offline]

Vielen Dank für eure Test-Angebote. Ich habe gerade den bisherigen develop-Branch in den master gemerged und anschließend die bisherigen Umstellungen in den devevelop-Branch committed. Ihr könnt damit testen.

McTao Wenn das Plugin auf manuelle Änderungen reagiert, schreibt es ins erweiterte Log, wer welches Item geändert hat (bei loglevel=2). Schau mal, was da bei dir steht, wenn die Höhe über das Plugin angepasst wird und wenn die Höhe manuell angepasst wird. Ggf. lässt sich da was ausfiltern.

Grüße
offline

[mumpf]

Hi, mein Vorschlag ist nicht vollständig, du brauchst auch 2 GA für move, der Aktor muss auf beide hören. Gruß Waldemar

[mumpf]

Hi,

mal auf die schnelle, ohne es ausprobiert zu haben: Mach für Move 2 Items (MoveAuto und MoveManual), eines macht nur knx_send (das ist das MoveAuto) und eines nur ein knx_listen (MoveManual). Dann kannst Du das MoveManual zum sperren nehmen und das MoveAuto zum fahren.

Ist nur ne Idee,
Gruß, Waldemar

[McTao]

Hi,

Da es bisher gut lief und ich meine auch das aktuelle Plugin verstanden zu haben, biete ich mich auch als Tester an.

Ich brauche aber im Moment erst eine andere Lösungsidee:

Meine Aktoren kennen kein Item Höhe. Wie schon geschrieben, habe ich jetzt eine Logik, die bei Änderung der Höhe ein Move ausführt und bei einem Move die Höhe (für die ViSu und AutoBlind) entsprechend setzt.

Mein Problem ist nun, wenn ich für das Deaktivieren ein Watch_item auf move lege deaktiviert sich Autoblind selber, da jede Höhenänderung ein Move mit einem Source aus einer anderen Logik ausführt (hier musste ich changed_by auf den Namen der Logik ändern um rekursive Aufrufe abfangen zu können.)

Kann mir jemand helfen. Würde gerne das AutoBlind weiter nutzen, aber finde auch das manuelle Deaktivieren super.

Gruss Andreas

[offline]

Guten Morgen Waldemar,

das Problem dass Nachrichten verschluckt werden, wenn auf dem Bus zu viel los los ist kenne ich auch (Das ist einer der Gründe für das im Moment hartcodierte 10 Sekunden Delay beim Start des Plugins ...).
Der Hinweis mit dem separaten cycle pro AutoBlind-Item ist gut, das macht auf jeden Fall Sinn. Auch ein Startup-Delay pro AutoBlind-Item sollte ohne größere Probleme zu realisieren sein.

Grüße
offline