Ankündigung

Einklappen
Keine Ankündigung bisher.

Automatische Beschattung

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

    Hi,

    bei mir werden Hausweite Zustände werden aus dem Google-Kalender berechnet, in dem Urlaub, Schulferien, Feiertag/Wochenende stehen (den man natürlich pflegen muss, aber das mache ich sowieso). Raumweise gibt es noch Schlafen, Krank, Besuch, die werden durch Taster/Visu eingestellt (Besuch meint Leute, die länger da sind - wie z.B. Großeltern - kann ich zusätzlich auch über Kalender abbilden). Abwesend ist derzeit per Taster an der Haustür, ich arbeite aber parallel (mit autoblind) an einer Zustandsmaschine, die das aus allen Informationen rausfindet. PM geht bei mir auch nicht (wegen Katzen).

    Ich lasse meistens neue Zustandsautomaten (wie z.B. Abwesend) ne Weile ohne Funktion mitlaufen, die schalten nur Items, die ins log schreiben, dann schaue ich mir an, wie es funktioniert hätte, und wenn es passt, wird es aktiv geschaltet. Fehlzustände, die manuell übersteuert werden, versuche ich zu loggen, damit ich irgendwann weitere Regeln einbauen kann, die eine Übersteuerung unnötig machen.

    Aus meiner Sicht ist das ein langer Prozess, der durch viele Iterationen läuft und sich nach und nach der Wunschsituation annähert, ein Smart Home zu haben, dass einfach weiß, wie es sich verhalten soll.

    Das ist auch der Grund, warum ich vom Autoblind begeistert bin - meiner Meinung nach kann man mit einem Zustandsautomaten so viele Einflußfaktoren wesentlich besser in den Griff bekommen als mit einer Logik, vor allem im Hinblick auf Erweiterbarkeit und Fehlersuche.

    Also nochmal vielen Dank für Deine Bemühungen, offline.

    Gruß, Waldemar


    OpenKNX www.openknx.de

    Kommentar


      Ich hab' die Anwesenheitserkennung per PM (IR und teilweise auch HF) gemacht. Ich habe in jedem Raum einen PM und wenn sich eine Stunde nichts im Haus tut, wechselt die Bude in den Abwesenheitsmodus. Wenn sich was im Haus tut, dann erfolgt nach 2-3 Minuten automatisch ein Wechsel in Anwesenheitsmodus. Nachts verhinder ich durch eine Belegterkennung im Bett, dass in Abwesenheit gewechselt wird.
      Zusätzlich habe ich neben der Tür einen Taster zum umschalten, den ich normalerweise verwende. Die Automatik ist nur ein Fallback, wenn ich das mal vergesse. Weitere Zustände:
      • Urlaub
      • Advent (zum Schalten der Steckdosen mit der Weihnachtsbeleuchtung und sperren der Rolläden mit derselben)
      • Sleep (sperren des Rolladens im Schlafzimmer)
      • Sommer/Winter


      Wie Waldemar schon gechrieben hat: Ein iterativer Prozess...

      Gruss
      Jochen

      Kommentar


        Hi zusammen,

        ich hab schon wieder ein kleines Problem:

        Das mit dem Nachführen beim geöffneten oder geschlossenem Fenster funktioniert einwandfrei.

        Das Problem ist, dass es nich nach 0 Uhr funktioniert - was ja auch Sinn macht:

        Hier die Config:

        Code:
            [[night_open_werktag]]
            name = Nacht Werktag Fenster auf
            type = foo
            as_set_height = value:85
                    [[[enter]]]
                     as_min_time = 22:00
        #          as_max_time = 06:00
        #            as_negate_time = true
                     as_min_weekday = 0
                    as_max_weekday = 4
        <------><------>as_value_schlkontakt = true
        Also habe ich das Ganze eben auf max_time erweitert = 6 Uhr

        Dann meckert das Plugin mit folgendem Text:

        Code:
        015-09-30 18:25:27.075875 Check if state 'schlafzimmerdefs.night_open_werktag' ('Nacht Werktag Fenster auf') can be entered:^M
        2015-09-30 18:25:27.076122<----> Check condition set 'enter':^M
        2015-09-30 18:25:27.077837<----><------> condition'time': Ignoring because of error: Condition time: 'min' must not be greater than 'max'!^M
        2015-09-30 18:25:27.077911<----><------> Condition 'schlkontakt': value=True negate=False current=True^M
        2015-09-30 18:25:27.077969<----><------><------> OK -> matching^M
        2015-09-30 18:25:27.078029<----><------> Age of 'schlkontakt': No limits given^M
        2015-09-30 18:25:27.078095<----><------> Condition 'weekday': min=0 max=4 negate=False current=2^M
        2015-09-30 18:25:27.078156<----><------><------> given limits ok -> matching^M
        2015-09-30 18:25:27.078214<----><------> Age of 'weekday': No limits given^M
        Klar, dachte ich mir. negate_time ist das Zauberwort!!

        Leider wirft negate_time die gleiche Fehlermeldung raus.

        Was habe ich übersehen?

        Viele Grüße

        Miguel

        Kommentar


          Hi,

          die Meldung sagt genau das, was Du machen sollst: min soll nicht größer sein als max!
          Bei Dir ist min = 22:00 Uhr und max = 6:00 Uhr, also falsch!
          Mach einfach min = 6:00 Uhr und max = 22:00 Uhr und negate_time = true und Du hast den Zeitraum 22:00 Uhr bis 6:00 Uhr, wie Du es willst.

          Gruß, Waldemar
          OpenKNX www.openknx.de

          Kommentar


            Hallo offline,

            erst einmal herzlichen Dank für dieses grossartige Plugin, es ist weit mehr als nur ein Autoblind...

            Ich bin gerade dabei von den nicht sicherheitsrelevanten Programmen der Quadra auf das Plugin umzustellen - Quadra ist zwar mächtig bzgl. der Programme, aber da fehlen für mich noch ein paar Bedingungen ;-)

            Ich habe den master branch ausgescheckt und in die Plugins eingebunden. Konfiguration an Hand des Beispiels aus dem Wiki, läuft prima...

            Dann habe ich auf meine Strukturen angepasst und eine Bedingung mit Abfrage auf Monate erstellt -> Sommer/Winter Umschaltung auf die harte Tour an Hand von Datum/Monat.

            Dabei verwende ich folgende Bedingung, in Autoblind.default definiert und per "as_use = autoblind.default.day_workingdaysummer" in die dem Objekt zugeordnete Bedingung eingebunden:

            Code:
                    [[[night_workingdaysummer]]]
                        name = Nacht Werktag Sommer
                        [[[[enter]]]]
                            as_min_time = 08:30
                            as_max_time = 12:00
                            as_negate_time = True
                            as_min_month = 5
                            as_max_month = 8
                            as_min_weekday = 0
                            as_max_weekday = 4
                    [[[night_workingdaywinter]]]
                        name = Nacht Werktag Winter
                        [[[[enter]]]]
                            as_min_time = 08:30
                            as_max_time = 19:00
                            as_negate_time = True
                            as_min_month = 5
                            as_max_month = 8
                             as_negate_month = True
                            as_min_weekday = 0
                            as_max_weekday = 4
            Die Bedingungen können aber nicht abgearbeitet werden: Im Log findet sich dann:

            Code:
             2015-10-01 11:42:16.429538 Update state of item Raffstore FZ West =========================================
            2015-10-01 11:42:16.431326 Update triggered by Scheduler (source=None dest=None)
            2015-10-01 11:42:16.434897 Last state: z_Raffstore_FZ_West.night ('Nacht')
            2015-10-01 11:42:16.446165 Check if state 'z_Raffstore_FZ_West.night' ('Nacht') can be left:
            2015-10-01 11:42:16.447804     No condition sets defined -> matching
            2015-10-01 11:42:16.449298 State can be left
            2015-10-01 11:42:16.450900 Check if state 'z_Raffstore_FZ_West.day_workingdaysummer' ('Tag Werktag Sommer') can be entered:
            2015-10-01 11:42:16.452525     Check condition set 'enter':
            2015-10-01 11:42:16.465236         Condition 'time': min=08:30:00 max=12:00:00 negate=False current=11:42:16.441770
            2015-10-01 11:42:16.466801             given limits ok -> matching
            2015-10-01 11:42:16.468376         Age of 'time': No limits given
            2015-10-01 11:42:16.470060         Condition 'weekday': min=0 max=4 negate=False current=3
            2015-10-01 11:42:16.471711             given limits ok -> matching
            2015-10-01 11:42:16.473421         Age of 'weekday': No limits given
            2015-10-01 11:42:16.486025         Condition 'month': min=5 max=8 negate=False current=10
            2015-10-01 11:47:16.269015 Update state of item Raffstore FZ West =========================================
            und die Abarbeitung scheint zu stoppen.

            Im smarthome.py Log ist folgendes zu finden (Zeitstempel matchen nicht, stammt aus einer anderen Session...)

            Code:
            2015-10-01 11:47:16 ERROR    z_Raffstore_FZ_West Item z_Raffstore_FZ_West: problem running <bound method AbItem.update_state of <plugins.autoblind.AutoBlindItem.AbItem object at 0x2142490>>: unorderable types: int() < str()
            Traceback (most recent call last):
              File "/usr/smarthome/lib/item.py", line 375, in __update
                method(self, caller, source, dest)
              File "/usr/smarthome/plugins/autoblind/AutoBlindItem.py", line 185, in update_state
                if state.can_enter(self.__myLogger):
              File "/usr/smarthome/plugins/autoblind/AutoBlindState.py", line 60, in can_enter
                result = self.__enterConditionSets.one_conditionset_matching(logger)
              File "/usr/smarthome/plugins/autoblind/AutoBlindConditionSets.py", line 76, in one_conditionset_matching
                if self.__condition_sets[conditionset_name].all_conditions_matching(logger):
              File "/usr/smarthome/plugins/autoblind/AutoBlindConditionSet.py", line 128, in all_conditions_matching
                if not self.__conditions[condition_name].check(logger):
              File "/usr/smarthome/plugins/autoblind/AutoBlindCondition.py", line 201, in check
                if not self.__check_value(logger):
              File "/usr/smarthome/plugins/autoblind/AutoBlindCondition.py", line 301, in __check_value
                if min_value is not None and current < min_value:
            TypeError: unorderable types: int() < str()
            Wenn ich in dem Plugin den Code in der Datei AutoBlindCondition.py (Master-Branch) wie folgt ändert, dann funktioniert es:

            Code:
            output 'git diff master'
            
            diff --git a/AutoBlindCondition.py b/AutoBlindCondition.py
            index 7504686..a84e557 100644
            --- a/AutoBlindCondition.py
            +++ b/AutoBlindCondition.py
            @@ -288,6 +288,16 @@ class AbCondition:
                             min_value = self.__get_min()
                             max_value = self.__get_max()
             
            +                # If current and min_value and max_value have different types, convert both to string
            +                if type(min_value) != type(current):
            +                    min_value = str(min_value)
            +                    max_value = str(max_value)
            +                    current = str(current)
            +                if type(max_value) != type(current):
            +                    min_value = str(min_value)
            +                    max_value = str(max_value)
            +                    current = str(current)
            +
                             # 'value' is not given. We check 'min' and 'max' (if given)
                             logger.debug("Condition '{0}': min={1} max={2} negate={3} current={4}",
                                          self.__name, min_value, max_value, self.__negate, current)
            Bei Verwendung des develop branches funktioniert es auch nicht, da werden sogar die Abfragen auf die as_min_time und as_max_time in den Bedingungen im LOG nicht mit angezeigt und ausgewertet.

            In dem Zusammenhang:
            Ist es eigentlich notwendig, den Objekten/Bedingungen bestimmte Typen (z.T. wird in einigen Beispielen type = foo verwendet, in anderen keine Typzuordnung) zu zuordnen? Ich habe es so verwendet, wie es im vollständigen Beispiel des Wiki's gezeigt wurde.

            Gruss, Holger
            Zuletzt geändert von 2pi; 01.10.2015, 11:49.

            Kommentar


              Korrektur:

              Funktioniert bei Bedingungen mit den as_min_month/as_max_month, die anderen Vergleiche gehen dann aber nicht mehr bzw. nur auf String Vergleichs Basis - da ist dann schon mal 5>30000 ;-)

              Gruss Holger

              Kommentar


                Hi,

                bist Du sicher, dass Dein month-Item ein num ist? Oder ist der als string definiert? Ich habe dieses Problem noch nicht gehabt, und ich habe viele nummerische Vergleiche...

                Gruß, Waldemar
                OpenKNX www.openknx.de

                Kommentar


                  Hi Waldemar,

                  mein month item ist gar nicht mein month item ;-)

                  Es ist eines der Items aus den "besonderen" Bedingungen, siehe Autoblind Wiki:

                  https://github.com/i-am-offline/smar...---Bedingungen

                  month 1 = Januar, ..., 12 = Dezember

                  Ich vergleiche in der Bedingung nicht gegen ein eigenes item, sondern das autoblind interne, sollte also genauso funktionieren wie as_min_time, as_min_weekday.

                  Ich setze jetzt mal ein minimal smarthome.py auf, um das ganze entkoppelt vom Produktivsystem zu testen...

                  Gruss, Holger

                  Kommentar


                    Ok, mit dem month habe ich wohl noch nichts gemacht... war somit ein Denkfehler! Dann kann ich dir hier leider nicht weiter helfen. Gruß Waldemar
                    OpenKNX www.openknx.de

                    Kommentar


                      Hi zusammen,

                      da waren noch zwei Bugs drin die 2pi beide voll getroffen hat.
                      • Nach der Änderung aus diesem Post wurden time-Bedingungen nicht mehr korrekt verarbeitet
                      • Für die "besonderen" Bedingungen "month", "random" und "laststate" fehlte der cast

                      Die Fixes für beide Bugs habe ich gerade in den develop-Zweig auf GitHub gepusht

                      Grüße
                      offline

                      Kommentar


                        Hi offline,

                        herzlichen Dank für die - wie immer - schnelle Fehlerbehebung.

                        Gruß, Holger

                        Kommentar


                          Hi offline,

                          in github steht derzeit der letzte commit im develop noch auf 29.09. Magst du bitte die letzten Änderungen noch freigeben?

                          Danke,
                          Holger

                          Kommentar


                            Hi Holger,

                            ups ... hatte zwar auf meinen lokalen Git-Server gepusht, aber von da nicht weiter auf GitHub. Hab ich nun nachgeholt.

                            Grüße
                            offline

                            Kommentar


                              Hi offline,

                              ich habe mittlerweile in 2 von 3 Etagen die Rollladensteuerung durch dein Plugin ersetzt, sie lief bisher auf Basis der früheren Logik. Es funktioniert soweit alles, aber zu zwei Punkten habe ich noch Fragen:

                              1) Die Rollladen laufen nicht mehr alle gleichzeitig, sondern teilweise um einige Sekunden versetzt. Macht zwar eigentlich keinen Unterschied, aber man ist ja manchmal etwas pingelig. Ich nehme an, dieses Phänomen rührt vom unterschiedlich startenden Cycle-Beginn, je nachdem, wann das jeweilige Rollo zum ersten mal durch das Plugin konfiguriert wurde. Ist es denn mittlerweile möglich, das Plugin per Crontab zu steuern? Damit müsste es doch dann gleichzeitig laufen, oder? In der Anleitung steht allerdings, dass es nicht per Crontab funktioniert. Ist das noch aktuell?

                              2) Ich habe meine Rollladen so gesteuert, dass sie bspw. morgens um 08:15 hochfahren. Oft werden einige Rollladen schon vorher manuell hochgefahren, was ja auch durch das suspend möglich ist. Beim Verlassen des Hauses drücken wir aber gerne die "Gehen"-Tase um das Haus in den Abwesenheitsmodus zu setzen, womit auch die suspends in den Rollladen wieder aufgehoben werden sollen. Allerdings macht es keinen Sinn, bereits geöffnete Rollladen wieder zu schließen, wenn vor 08:15 die Gehen-Taste gedrückt wird. Abends beim Schließen der Rollladen gibt es ähnliche Situationen. Ich will in meine Rollladenkonfiguration daher ein Item einbringen, in dem vermerkt ist, ob der Rolladen in den letzten Stunden bereits nach oben gefahren wurde. Dieses Item dient als Ausschlusskriterium für alle Zustände, die den Rollladen prinzipell nach unten fahren würden ("nachts"). Umgehrt will ich auch ein Item einbringen, dass True ist, wenn der Rollladen in den letzten 2 Stunden geschlossen wurde. Damit würden widerum Zustände ausgeschlossen, die den Rollladen öffnen ("tags"). Im Prinzip kann ich das mit einem entsprechenden Item in der Rollladenkonfiguration realisieren, was durch eine Logik jeweils gesetzt und auch wieder gelöscht wird, wenn der Rollladen bewegt wird.
                              Meine Frage ist nur, ob ich diesen Umweg überhaupt gehen muss oder ob es bei deiner Logik ohnehin eine Funktion gibt, mit der ich das realisieren kann! Das Suspend registriert ja bereits jede Bewegung, kann ich daher irgendwie ableiten, ob nach oben oder unten bewegt wurde und wann dies geschehen ist und dies in die Enter-Bedigungen einbauen?

                              Danke und viele Grüße

                              Arne



                              Kommentar


                                Hi arnix,

                                zu 1) Zum gleichzeitigen Triggern gibt's einen Eintrag im Wiki auf GitHub: https://github.com/i-am-offline/smar...-mehrere-Items Crontab geht grundsätzlich, was nicht geht ist "Crontab=init".

                                zu 2) Zur Berücksichtigung der aktuellen Position des Rolladens würde ich das Item, das mit dem Objekt "Behanghöhe" des Aktors verknüpft ist, verwenden. Ich würde aber nicht unbedingt den Zeitpunkt der letzten Fahrt auswerten (ginge über die agemin und agemax-Bedingungen des Behanghöhe-Items), sondern einfach die Bedingungen so gestalten, dass nicht mehr heruntergefahren wird, wenn z. B. nach 6:15 Uhr der Behang bereits oben ist.

                                Grüße
                                offline

                                Kommentar

                                Lädt...
                                X