Automatische Beschattung

[Msinn]

Trag mal in der etc/logging.yaml in der logger: Section folgendes ein:

loggers:
    plugins.autoblind:
    handlers: [file]
    level: INFO

Falls bei Dir der Handler nicht file heißt, ersetzte file durch den Namen des bei Dir zu verwendenden Handlers.

[ivande]

im SH1.5 fehlt bei mir im log die Zeile:

INFO     autoblind    Init AutoBlind items
INFO     autoblind    Using AutoBlind for 39 items

2018-07-11  23:35:28 DEBUG    Main         Plugins, section: autoblind
2018-07-11  23:35:28 DEBUG    Main         Plugins __init__: pluginname = 'autoblind', classpath 'plugins.autoblind'
2018-07-11  23:35:28 INFO     Main         Loading '/usr/local/smarthome/plugins/autoblind/plugin.yaml' to 'OrderedDict'
2018-07-11  23:35:28 WARNING  Main         YAML-file not found: /usr/local/smarthome/plugins/autoblind/plugin.yaml
2018-07-11  23:35:28 DEBUG    Main         PluginWrapper __init__: Section autoblind, classname AutoBlind, classpath plugins.autoblind
2018-07-11  23:35:28 INFO     Main         Loading '/usr/local/smarthome/plugins/autoblind/locale.yaml' to 'dict'
2018-07-11  23:35:28 INFO     Main         plugin 'autoblind': No metadata found
2018-07-11  23:35:28 INFO     Main         plugin 'autoblind' metadata contains no version number
2018-07-11  23:35:28 DEBUG    Main         Plugins: Loaded plugin 'autoblind' (class 'AutoBlind') v1.1.1: 
2018-07-11  23:35:28 INFO     Main         Initialized plugin 'autoblind' from from section 'autoblind'
2018-07-11  23:35:35 DEBUG    Main         Starting plugin 'autoblind'

[ivande]

bei mir läuft autoblind mit SH1.5 noch nicht. ich habe eval: true in der schnelle in den items in der datei jalousie_default hinzugefügt

Abenddaemmerung:
    as_use:Jalousie_default.Abenddaemmerung

jalousie_default

Abenddaemmerung:
    type: foo
    name: Abenddämmerung
[COLOR=#FF0000][B]    eval: true[/B][/COLOR]
    as_set_suspend: False

leider hatte ich noch keine Zeit für eine genauere Analyse, deswegen vorerst zurückrudern auf SH1.4.2

[Onkelandy]

Zur Info: Ich musste bei mir seit Master 1.5 in den rules-Abschnitt von allen Items "eval: true" hinzufügen.

[Onkelandy]

Angenommen ich möchte folgendes Verhalten forcieren, wie gehe ich da am besten vor?
Folgende Zustände sind in rules definiert:

                wind:
                    type: foo
                    as_use: jalousien.autoblind.default.wind_screens

                lock:
                    type: foo
                    as_use: jalousien.autoblind.default.lock

                eine Reihe weiterer Zustände

Wenn nun das Item im lock-Zustand ist und dann der Wind daher kommt, soll es natürlich in den Windzustand. Allerdings soll es NACH dem Wind wieder in den Lock-Zustand wechseln.

Beim Verlassen des Lock-Zustands wird ja lock auf False gesetzt. Ich habe daher mal einen Hilfszustand eingebaut, der nur dann eingenommen wird, wenn das Item zuvor im lock-Modus war. Dieser Zustand setzt dann beim Verlassen das lock wieder auf True. Problem ist allerdings, dass dieses Setzen von lock erst nach dem Einnehmen eines neuen Zustands passiert und nicht sofort beim Verlassen.

Wie ist das am saubersten und einfachsten umzusetzen?

[gama]

Schon richtig mit den Sekunden - und da das Visa-Widget auch mit Sekunden funktioniert, habe ich die Umrechnung (* 60) weggelassen.

Wie die Präsenz ermittelt wird, ist der Beschattung erst einmal egal. Primär geht es darum, dass es zwei Strategien gibt "Optimiert auf Lichteinlass" oder "Optimiert auf Hitzeschutz".

Off-Topic: die Präsenz kann am einfachsten über Präsenzmelder erfolgen. Ich dachte aber auch an eine Verknüpfung mit einer zentralen Haus-Sate-Machine die z.B. die eingebuchten Handys, Urlaub, etc. erkennt. Testweise habe ich das iPhone über HomeKit ein Bit setzen lassen, wenn ich mich annähere oder entferne (Radius 250m) - funktioniert schon ganz gut... aber wird in Summe nicht einfach zuverlässig UNS komfortabel den Präsenzzustand zu ermitteln - daher die Trennung in mehrere Statemachines...

Grüße
Markus

[Onkelandy]

Ja, ein Tipps+Tricks wäre sicher noch eine gute Idee. Das ist dann aber halt schon für die advanced user und die Anleitung sollte eher für Neueinsteiger dienen. Ich denke auch, dass offline eh schon viele Sachen in seinem Wiki zusammengetragen hat. Aber ist sicher ausbaufähig.

Wie meinst du das mit den Sekunden bei suspend_duration? Das sind ja ohnehin Sekunden, oder? Ich habs bei mir jedenfalls so gemacht, dass ich's in der Visu in Minuten angeben kann. Und dann wird in Sekunden umgewandelt:

as_agemax_suspend: eval:autoblind_eval.get_relative_itemvalue('..settings.suspendduration') * 60

Die Kombo mit der UZSU wäre sicher auch noch einen Hinweis wert, ja. Wenn du bezüglich Raumpräsenz was hast, kannst gerne hier posten Gehst du einfach auf die Bewegung im Raum? Ich evaluiere bei mir zB auch mittels Hilfsitems, ob innerhalb der letzten 5, 15 oder 30 Minuten Bewegung im Raum/Stock war. Das ist vermutlich das was du meinst? Fahren dann aber deine Jalousien/Lamellen tatsächlich auf heller, sobald du den Raum betrittst? Wär eigentlich gar keine blöde Idee.. der nächste Sommer kommt bestimmt

[gama]

Hi,

tolle Zusammenfassung!

Vielleicht ergänzt Du gegen Ende noch ein paar "Tipps und Tricks"?
Ich finde Deinen Ansatz z.B. mittels Prüfung

as_value_suspend_active: 'True'

den jeweiligen Status zu de-/aktivieren. So könnte auch von der Visu aus die Statemachine grob konfiguriert werden.

Weiterhin habe ich beispielsweise die Variable suspend_duration auf Sekunden umgestellt, sodass ich mit smartvisu die Dauer zwischen 1 Minute und einem Tag graphisch einstellen kann.

{{ basic.input('', gad_suspend_duration, 'duration', 60, 86400) }}

Zudem setze ich pro (Schlaf-)Raum eine "sleeping" Variable, welche mittels eine USZU steuern kann und die den Status "Nacht" zwangsführt. Die USZU hat den Vorteil, dass die Zeiten ebenfalls elegant per Visu durch jeden im Haus geändert werden können und auch das Wochenende Berücksichtigung findet (z.B. ausschlafen).

Ebenso habe ich die "Raumpräsenz" vorbereitet. Im Fall von Abwesenheit, ist der Hitzeschutz sehr konservativ und dunkelt den Raum noch stärker ab.

usw.

Nur so eine Idee

Grüße
Markus

[gama]

Kurz zur Info: mit dem branch 1.4.0 von autoblind und ein paar patches läuft es wieder. Danke.

[Onkelandy]

Issue hab ich erstellt.. Wie der Fehler so behoben wird, dass die CLI Befehle angelegt werden, ist mir leider unklar. Es wird ja gemotzt, dass das "usage" Attribut fehlt. Fügt man ein Attribut hinzu, wird gemotzt, dass man zu viele Attribute übermittelt. Blick da nicht ganz durch

[gama]

Hi,

zunächst ein gutes Neues Jahr in die Runde (bin gerade mit der Familie im Winterurlaub und habe soeben das Prinzip der "KNX-Ruhe" aufgrund des Regenwetters gebrochen
Nein, ich habe es vor Weihnachten nicht mehr weiter getrieben - aber Deine Erklärung scheint sehr plausibel.
Hast Du schon ein issue für i-am-offline aufgemacht, bzw. hast Du eine konkrete patch Idee? Ich kann es gerne (in ein paar Tagen) testen...

Grüße
Markus

[Onkelandy]

gama konntest du das Problem inzwischen lösen?

Ich bin bei mir von SmarthomeNG 1.3 auf 1.4.1 umgestiegen und da hat das mit dem manuellen Item plötzlich nicht mehr geklappt. Grund war, dass das Registrieren der CLI Commands einen Fehler brachte und dadurch das "alive" für die spezielle eval-Funktion nicht gesetzt wurde. Ich habe jetzt im File CLICommands das except noch mit einem except Exception: erweitert, damit die 2 Befehle in der run-Funktion in __init__.py ausgeführt werden.

Ansonsten schau doch einfach mal in die Datei Functions. Dort notfalls mal alive auf True setzen, ein paar log.error Einträge machen und gucken, was passiert,,?

[gama]

Trotzdem vielen Dank! Irgendwie kommt man immer ans Ziel....

[mumpf]

Hi,

sorry, aber dann müssen hier Leute drauf schauen, die sich tiefer in der Materie auskennen. Ich kann Dir leider nicht mehr helfen, ich dachte es liegt genau an diesem Eintrag...

Gruß, Waldemar

[gama]

Hallo,

das hat leider auch keinen Erfolg gebracht. Ich verstehe es nicht, da es ja schon einmal (mit der alten Version) funktioniert hat...