Ankündigung

Einklappen
Keine Ankündigung bisher.

Automatische Beschattung

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    Hi,

    dann auch mal ein paar Infos von mir: Ich baue gerade einiges um, im Hinblick auf die Erweiterung des Plugins zu einem allgemeine verwendbaren Zustandsautomaten.
    Dabei ergeben sich zunächst einige kleinere Änderungen:
    • 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)

    Diese Dinge sind bereits soweit fertig, im Moment räume ich noch im Coding auf und teste das ganze. Das wird in den nächsten Tagen fertig sein, dann werde ich zuerst den aktuellen develop-Stand in den master-Branch übernehmen und anschließend die Neuerungen in den develop-Branch mergen.

    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

    Kommentar


      Cool!
      Bin schon gespannt - biete mich gerne als Tester an!
      Gruß, Waldemar
      OpenKNX www.openknx.de

      Kommentar


        Hi Thomas,

        nochmal danke für die Zeit mit Doppelpunkt - auch wenn es nur eine Kleinigkeit ist, mir hilft sie, Tippfehler zu vermeiden.
        Da Du sowieso vieles neu machst, wollte ich 2 sporadische Probleme ansprechen:
        1. Startup mit vielen AutoBlind-Items
        2. cycle mit vielen AutoBlind-Items
        Ich habe hier derzeit 22 AutoBlind-Items am laufen. Sowohl beim starten von sh.py wie auch bei einem cycle, der viele Zustände ändert (z.B. Abends alle Rollos runter) schleichen sich Fehler ein, die an zu vielen versendeten Nachrichten auf dem Bus liegen. Dann ist der Zustand vom AutoBlind nicht mehr in sync mit der Realität (z.B. Rollo ist noch oben, aber AutoBlind ist im Zustand "unten"). Das mag am eibd liegen, aber ich habe bisher keinerlei Konfiguration gefunden, die das Problem behebt (mir sind entsprechende Threads bekannt).

        Auch im Hinblick auf eine allgemeine Zustandsmaschine sollte es nicht mehr einen "globalen" cycle geben, sondern einzelne pro AutoBlind-Item (idealerweise mit cycle = 0). Und für den sh.py Start würde ich mir eine Art "delay" wünschen, so dass man pro AutoBlind-Item einstellen kann, wie lange nach dem sh.py-Start sich das Item das erste mal initialisiert. Ein solches Konzept würde auch meine Probleme lösen.

        Ich weiß nicht, ob und wie so was realisierbar ist und auch nicht, wie schwer das ist, aber ich wollte das als Denkanstoß mal loswerden.

        Danke für Dein tolles Plugin und gute Nacht,
        Waldemar
        OpenKNX www.openknx.de

        Kommentar


          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

          Kommentar


            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

            Kommentar


              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
              OpenKNX www.openknx.de

              Kommentar


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

                Kommentar


                  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

                  Kommentar


                    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

                    Kommentar


                      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
                      OpenKNX www.openknx.de

                      Kommentar


                        Hi,

                        Zitat von offline Beitrag anzeigen
                        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

                        Kommentar


                          Nabend zusammen,

                          Zitat von mumpf Beitrag anzeigen
                          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 ...

                          Zitat von McTao Beitrag anzeigen
                          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

                          Kommentar


                            Zitat von offline Beitrag anzeigen
                            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:
                              Code:
                              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.

                            Zitat von offline Beitrag anzeigen
                            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

                            Kommentar


                              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
                              Zuletzt geändert von Onkelandy; 24.06.2015, 19:49.

                              Kommentar


                                Zitat von Onkelandy Beitrag anzeigen
                                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.

                                Zitat von firefox Beitrag anzeigen
                                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

                                Kommentar

                                Lädt...
                                X