Automatische Beschattung

[mumpf]

Das einzige, was dann wegfällt ist das startup_delay, denn wenn die updates von smarthome.py automatisch eingeplant werden, kann dieser Wert nicht gesetzt werden. Ich denke aber, dass die dadurch gewonnene Flexibilität das mehr aus ausgleicht.

Da fallen mir 2 denkbare Lösungen für ein startup_delay ein:

1. Wenn Du nicht gleich zu Anfang (also beim Init) eine Statusauswertung machst, sondern forderst, dass man das Item selbst triggert, dann kann man sich mit Standardmitteln ein delay bauen
2. Du führst einen neuen Zustand "Init" ein und wertest für den nur "leave"-Bedingungen aus. "enter" passiert quasi immer beim Initialisieren des AutoBlind-Items. Wenn man selber kein "Init"-Zustandsitem definiert, ist alles gut ("leave" ist ja leer") und läuft so, wie bisher. Man könnte aber ein "Init" mit "leave" auf "min_age" = 30 setzen, dann hätte man quasi ein startup_delay. Durch Deine Engine hätte man aber auch jede Menge weiterer Möglichkeiten, den Startup zu verzögern. Z.B. über eine Zufallszahl (was den Start von vielen AutoBlind-Items stark entspannen würde, da sich dann die Writes auf den Bus verteilen würden und nicht auf einmal kommen). Und hätte auch noch den Vorteil, dass der Zustand in lastpos_id und lastpos_name klar drin stehen würde - beantwortet auf einfache Weise die Frage "Warum läuft die Automatik nicht?", da man direkt erkennt, dass man eine schlechte "leave"-Bedingung beim "Init" hätte.

Mir gefällt Punkt 2 besser als Punkt 1, nachdem ich das mal niedergeschrieben habe... Wie immer - nur ein Vorschlag, ich mach mich jetzt mal ran, auf die aktuellste AutoBlind-Version umzustellen, sonst hast Du am Ende so viel geändert, dass ich gar nicht mehr hinterher komme...

Gruß, Waldemar

[offline]

Hi zusammen,

die Änderungen zum Triggern der Zustandsermittlung habe ich heute morgen gemacht. Es war kein großer Aufwand, ich habe nur ein bischen schauen müssen, wie ich das Item beim Initialisieren so anpasse, dass man z. B. bei cycle und crontab keinen Wert setzen muss und man auch kein enforce_updates selbst setzen muss.
Das startup_delay war doch kein Problem. Hinsichtlich der Konfiguration gibt es zwei Änderungen:

• "default_cycle" in der Plugin-Konfiguration fällt weg. Der "cycle" muss (wenn gewünscht) in jedem Objekt-Item gesetzt werden
• "watch_trigger" fällt weg, hierfür kann nun der "eval_trigger" von smarthome.py verwendet werden. "eval" selbst muss wiederum nicht gesetzt werden, das wird auch bei Bedarf vom Plugin im Item geändert.

Ich habe bereits begonnen die Doku zu aktualisieren und werde das ganze heute abend oder morgen früh auf GitHub pushen.

Grüße
offline

[offline]

Guten Morgen,

der push ist erfolgt. Es gibt zusätzlich zu den vorher beschriebenen Änderungen noch zwei Neuigkeiten:

• Wenn die Automatik für ein Objekt über das "active"-Item aktiviert wird (egal ob manuell, oder automatisch nach Ablauf des manual_delay) wird nun direkt eine Aktualisierung des Status ausgelöst. Das behebt das Problem von Onkelandy der das "active"-Item in den watch_trigger eingetragen hatte.
• Es gibt bei den Bedingungen für ein Item nun die Möglichkeit, nicht nur den Wert eines Items, sondern auch zusätzlich das Alter abzuprüfen firefox hatte nach dieser Möglichkeit gefragt.

Grüße
offline

[mumpf]

Hi,

habe heute auf die neueste Version umgestellt - leider gibt es Probleme und nach langem rumprobieren glaube ich, dass Du noch einen Fehler beim Initialisieren hast. Ich bekomme bei mir sehr häufig die Meldung

Item 'DG.DD.Rollo.Dach.AutoBlind.Rules.Morgen', Condition Set 'enter', condition 'Helligkeit': Condition Helligkeit: Neither 'item' nor 'eval' given!

Sind wirklich viele, nicht nur einer - und die sind garantiert vorhanden, ich habe es mehrfach verifiziert. Nachdem ich im Log gesehen hatte, dass es einzelne Items gibt, die erkannt wurden, habe ich etwas mit der Reihenfolge gespielt und bin inzwischen sicher, dass Du zu früh versuchst, das Item zu finden - und zwar noch bevor es deserialisiert worden ist.

Bevor ich jetzt ewig lange Definitionen und Logs poste, wollte ich nachfragen, ob das sein kann? Das war beim alten AutoPlugin nicht so... Ich steh zur Zeit auf dem Schlauch. Ich werde erstmal auf die alte Version zurückgehen.

Was kann ich noch versuchen (logging modifizieren? - wo?), damit ich klarer sehe? Im Prinzip erkennt er fast gar nichts bei mir, da ich fast immer den AutoBlind als erstes Item (vor allen action-Items) definiert habe.

Gruß, Waldemar

[offline]

[...] und bin inzwischen sicher, dass Du zu früh versuchst, das Item zu finden - und zwar noch bevor es deserialisiert worden ist.

Ja, du hast recht. Ich habe die Items initialisiert, während das parsen der item./*conf Dateien lief. Bei mir ist das nicht aufgefallen, weil ich zentrale Dinge (wie die AutoBlind Konfiguration) in conf-Dateien habe, die mit "z" beginnen, also am Ende geparst werden ...

Ich habe das wieder umgestellt, die Änderung liegt schon auf GitHub.

Grüße
offline

[mumpf]

Vielen Dank für die prompte Hilfe, habe es soeben eingespielt und es läuft wieder! Ich hatte schon an mir gezweifelt - zumindest bevor ich auf die Idee kam, dass der Fehler im Plugin liegen konnte. Da es sich ja früher nicht so verhalten hat, hatte ich das deserialisieren als Fehlerquelle gedanklich gestrichen.

Bei mir kommt noch erschwerend hinzu, dass ich meine *.conf-Files generieren lasse und natürlich einen Fehler in meinem Generator vermutet habe - jetzt hat der Generator einfach ein paar Check-Routinen mehr Schadet auch nichts.

Sag mal, arbeitest Du in einer anderen Zeitzone? Ich hatte die Meldung irgendwann gegen 1 Uhr geschrieben und nicht damit gerechnet, heute Morgen überhaupt irgendein Feedback zu haben oder vielleicht ein "Ich schau mal". Aber gleich eine Korrektur, die funktioniert?

Finde ich echt super, vielen Dank!

Ich meld mich, falls mir irgendwas auffällt, vor allem auch bei meiner Zirkulationspumpensteuerung, die ja so gesehen ein "fachfremder" Einsatz von AutoBlind ist.

Nochmal Danke und viele Grüße,
Waldemar

[McTao]

Hi,

bin jetzt bei der Version (develop) von heute. Habe ich in der Config etwas vergessen, oder wo kann ich nachsehen, um den Fehler zu finden. (Meine Config für die Jalousien ist inzwischen 1200 Zeilen groß). Ich bekomme beim Start folgenden Fehler:

 [FONT=Menlo][SIZE=11px]2015-06-29 13:58:31,863 INFO     autoblind    Complete AutoBlind items -- __init__.py:run:76[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-06-29 13:58:31,863 DEBUG    Main         Starting uzsu Plugin -- plugin.py:start:67[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-06-29 13:58:31,882 DEBUG    Main         Starting sql Plugin -- plugin.py:start:67[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-06-29 13:58:31,888 DEBUG    Main         Starting cli Plugin -- plugin.py:start:67[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-06-29 13:58:31,892 DEBUG    Main         Starting visu Plugin -- plugin.py:start:67[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-06-29 13:58:31,908 DEBUG    Main         Starting fritzbox Plugin -- plugin.py:start:67[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]Exception in thread autoblind:[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]Traceback (most recent call last):[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]  File "/usr/lib/python3.2/threading.py", line 740, in _bootstrap_inner[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]    self.run()[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]  File "/usr/local/smarthome/lib/plugin.py", line 86, in run[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]    self.plugin.run()[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]  File "/usr/local/smarthome/plugins/autoblind/__init__.py", line 81, in run[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]    item.write_to_log()[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]  File "/usr/local/smarthome/plugins/autoblind/AutoBlindItem.py", line 104, in write_to_log[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]    if "cron" in job and job["cron"] is not None:[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]TypeError: argument of type 'NoneType' is not iterable[/SIZE][/FONT]

Gruss Andreas

[mumpf]

Hi,

versuchst Du die AutoBlind-Aktivierung per crontab? Das würde ich aus dem Error schließen. Ich hab bei mir keine und habe das Problem nicht - vielleicht ist es ja das?

Gruß, Waldemar

[McTao]

Hi Waldemar,

nein, mache gar nichts mit Cron. Habe aber seit der Version von heute morgen folgende Einträge im Log: (weiss aber nicht wo diese her kommen)

 [FONT=Menlo][SIZE=11px]eg.esszimmer.jalousie.Tuer-Timer Item eg.esszimmer.jalousie.Tuer = True via Timer None None -- item.py:__update:369[/SIZE][/FONT]

Meine Items sehen so aus: (aktive ist ein globales Item aus der Visu bzw. KNX-Schalter

[eg]
  name = Erdgeschoss
  [[esszimmer]]
    [[[jalousie]]]
      [[[[Fenster]]]]
        type = bool
        name = Fensterjalousie
        autoblind_plugin = active
        watch_manual = eg.esszimmer.jalousie.Fenster.manual_move
        item_height = eg.esszimmer.jalousie.Fenster.hoehe
        item_active = eg.esszimmer.jalousie.Fenster.active
        item_state_id = eg.esszimmer.jalousie.Fenster.state_id
        item_state_name = eg.esszimmer.jalousie.Fenster.state_name
        sv_widget = "{{ basic.switch('item', 'item.move',icon1~'light_light.png',icon0~'light_light.png' ) }}"
        [[[[[active]]]]]
          type = bool
          knx_dpt = 1
#           knx_send =
#           knx_status =
          knx_listen = 7/0/6
          knx_init = 7/0/6
          visu_acl = rw
          cache = on
        [[[[[state_id]]]]]
          type = str
          visu_acl = r
          cache = on
        [[[[[state_name]]]]]
          type = str
          visu_acl = r
          cache = on
        [[[[[suntrack]]]]]
          type = foo
          use = autoblind.default.suntrack_east
        [[[[[Day]]]]]
          type = foo
          use = autoblind.default.day
        [[[[[night]]]]]
          type = foo
          use = autoblind.default.night
        [[[[[move]]]]]
          type = bool
          knx_dpt = 1
          knx_send = 2/2/3
          knx_listen = 2/2/3|6/1/4|6/1/6|6/1/5|6/1/7
          knx_init = 2/2/3
          enforce_updates = yes
        [[[[[manual_move]]]]]
          type = bool
          knx_dpt = 1
          enforce_updates = yes
        [[[[[stop]]]]]
          type = bool
          knx_dpt = 1
          knx_send = 2/2/1
          knx_listen = 2/2/1
          knx_init = 2/2/1
          enforce_updates = yes
        [[[[[hoehe]]]]]
          type = num
          knx_dpt = 5.001
          visu_acl = rw
          cache = on
          #enforce_updates = yes

Gruss Andreas

[mumpf]

Die Eintrage im Log sind die ganz normalen scheduler Infos. Das Aktuelle AutoBlind-Plugin läßt sich jetzt über die Standard-sh.py-Verfahren triggern, also cycle, crontab oder z.B. auch über knx-Adressen.
Versuch mal hinter

autoblind_plugin = active
[COLOR=#FF0000]cycle = 300[/COLOR]

einzufügen, vielleicht ist es das. Sonst muss doch offline helfen, ich bin ja auch nur (begeisterter) Verwender des Plugins.

Gruß, Waldemar

[McTao]

Hi,

danke.

Versuch mal hinter

autoblind_plugin = active
[COLOR=#FF0000]cycle = 300[/COLOR]

einzufügen

Jetzt startet es. Ich werde dann weiter testen.
Demnach ist cycle mandantory!!

Gruss Andreas

[mumpf]

Demnach ist cycle mandantory!!

Hi,

ja - und auch nicht. Das steht irgendwo hier im Thread. Früher hat AutoBlind die Wiederholungen bestimmt und/oder per watch_trigger auf Änderungen von anderen Items gelauscht. Dadurch war es möglich, das ein globales default_cycle (in der plugin.conf) für alle Items gelten konnte, die kein eigenes cycle gesetzt hatten.
Nun wird die Ganze "wann muss ich meine Zustände aktualisieren"-Logik mit standard sh.py Mitteln erledigt. Wann immer jetzt das Hauptobjekt (das ist das, in dem autoblind_plugin = active steht) getriggert wird, werden alle Zustände erneut ausgewertet. Und das Triggern erledigt sh.py "wie immer", also z.B. durch cycle, crontab, knx_listen, xbmc_listen, eval_trigger oder oder oder...

Aber wenn Du gar keinen Trigger hast, scheint es Dir das Plugin übel zu nehmen... und ein default_cycle geht wohl nicht mehr.

Gruß, Waldemar

[mumpf]

Hi offline,

wollte nochmal kurz feedback geben. Nach Deiner Korrektur ist alles prima. Konnte sogar einige conditions durch das neue negate_* vereinfachen - und nicht nur wegen Zeitumkehr. Ich habe einige Rolläden, die wenn sie während der Dämmerung runter gehen, dann nicht mehr hoch gehen sollen. Das konnte ich nur vernünftig ausdrücken, indem ich ein

[[[leave_hell]]]
    min_Helligkeit = 150
[[[leave_dunkel]]]
    max_Helligkeit = 10

so bleibe ich bei Dämmerung in dem Zustand. Jetzt geht es komfortabel mit

[[[leave_helldunkel]]]
    min_Helligkeit = 10
    max_Helligkeit = 150
    negate_Helligkeit = True

Macht das Ganze schon wieder ein klein bisschen übersichtlicher! Und das Beste: Ich konnte Deine Korrektur noch einspielen, bevor meine Frau vom Wochenende wiederkam, sonst weiß ich nicht, wann ich wieder zu einer so großen Umstellung gekommen wäre.

Und abschließend doch noch eine kleine Kritik (bzw. Verbesserungsvorschlag): Ich würde mir wünschen, dass das "value:" beim set_* optional (oder genauer der Default) ist. In den meisten Fällen weist man konstante Werte zu. Die dynamischen Angaben sind natürlich klasse, aber da würde es reichen, wenn diese einen Präfix haben, oder?
Ist mir nur wieder aufgefallen, weil ich das zig mal vergessen hatte...

Danke nochmal,
Waldemar

[offline]

Sag mal, arbeitest Du in einer anderen Zeitzone? Ich hatte die Meldung irgendwann gegen 1 Uhr geschrieben und nicht damit gerechnet, heute Morgen überhaupt irgendein Feedback zu haben oder vielleicht ein "Ich schau mal". Aber gleich eine Korrektur, die funktioniert?

Nein, ich bin nur Frühaufsteher und nutze die Zeit, bist der Rest der Familie aus den Federn kommt. Zumal die Korrektur hier darin bestand ein paar Coding-Blöcke an neue Positionen zu schieben ...

bin jetzt bei der Version (develop) von heute. Habe ich in der Config etwas vergessen, oder wo kann ich nachsehen, um den Fehler zu finden. (Meine Config für die Jalousien ist inzwischen 1200 Zeilen groß). Ich bekomme beim Start folgenden Fehler:

Da hat sich noch ein kleiner Fehler eingeschichen. Das Problem tritt nur auf, wenn man weder über cycle noch über crontab triggern lässt. Push mit Fix kommt gleich ...

Wann immer jetzt das Hauptobjekt (das ist das, in dem autoblind_plugin = active steht) getriggert wird, werden alle Zustände erneut ausgewertet. Und das Triggern erledigt sh.py "wie immer", also z.B. durch cycle, crontab, knx_listen, xbmc_listen, eval_trigger oder oder oder...

Genau. Man kann theoretisch auch überhaupt keinen Trigger haben und das Update in einer eigenen Logik auslösen, in dem man das Objekt-Item auf True setzt.

Aber wenn Du gar keinen Trigger hast, scheint es Dir das Plugin übel zu nehmen... und ein default_cycle geht wohl nicht mehr.

Die Exception bei fehlendem Trigger war noch ein Bug.
Das es kein "default_cycle" mehr gibt hat einen einfachen Grund: Wenn der cycle durch smarthome.py ausgewertet bekomme ich im Plugin nur mit, ob es einen cycle gibt oder nicht. Da es auch sein kann, dass es keinen cycle gibt, weil man eben keinen cycle möchte, kann ich nicht dann einfach einen cycle mit einem Defaultwert setzen.

Ich würde mir wünschen, dass das "value:" beim set_* optional (oder genauer der Default) ist. In den meisten Fällen weist man konstante Werte zu. Die dynamischen Angaben sind natürlich klasse, aber da würde es reichen, wenn diese einen Präfix haben, oder?

Eigentlich sollte als Fallback genau das passieren. Wenn kein : im Attributwert enthalten ist, wird der gesamte Attributwert als "value:" gewertet. Es steht nur nicht in der Doku ... Hat das bei dir nicht funkioniert?

Grüße
offine

[mumpf]

Eigentlich sollte als Fallback genau das passieren. Wenn kein : im Attributwert enthalten ist, wird der gesamte Attributwert als "value:" gewertet. Es steht nur nicht in der Doku ... Hat das bei dir nicht funkioniert?

Oh - cool, ich habe das gar nicht probiert. Ich hab vor ca. 3 Monaten bei sh.py den Überblick über meine config files verloren (damals waren es ca. 600 Items). Das Problem war, dass ich immer nur sh.py zum Testen nutzen kann, ob ich mich vertippt habe (Quasi syntax error im config). Wenn dann noch logische Fehler, falsche Item-Referenzen in eval_trigger, logikfehler etc dazu kommen, kann es ganz schön lange dauern, bis sh.py wieder läuft. Mein KNX ist zwar so aufgebaut, dass die Grundfunktionen auch ohne sh.py laufen, aber meine Familie hat sich an die kleinen Komfort-Funktionen gewöhnt und nutzt z.B. auch ausgiebig die SmartVisu. Wenn da länger was nicht läuft, gibt es "gemecker".
Langer Rede kurzer Sinn: Ich habe mir einen .conf-Generator geschrieben, der mir beim generieren schon einige Fehler meldet (Hauptsächlich falsche Item-Referenzen und falsch geschriebene item-Properties. Dem Generator habe ich inzwischen Deine Syntax beigebracht, der hat mich deswegen bereits vorher gewarnt, dass ich ein "value:" vergessen hatte - so dass ich das gar nicht ausprobiert habe.
Das gute ist, dass ich inzwischen ca. 2000 Items habe und wesentlich weniger Probleme, als vorher mit 600. Und Deine State-Engine hat mir bereits ca. 10 Logiken und rund 50 Hilfsitems gespart. Und das bei mehr Funktionen, als ich früher hatte! Klasse...

Gruß, Waldemar