Automatische Beschattung

[arnix]

Hallo zusammen,

ich habe mir die Logik von offline auch eingebaut und es ist jetzt bei dem Sonnenschein schon eine schöne Sache. Ich habe rund um die Uhr immer irgendeinen Zustand, der von der Logik hergenommen werden kann.

Mein einziges Problem ist, wenn man morgens die Rollladen früher oben haben möchte, sie natürlich innerhalb kurzer Zeit wieder runterfahren, denn die Logik checkt alle 10 Minuten, was gemacht werden soll. Ich bräuchte also dringend so was...

Ich hab die Manuell-Situation so bei mir gelöst, dass die Logik zuerst mal checkt, von wem die Jalousie als Letztes aktualisiert worden ist. Wenn das nicht durch die Logik geschehen ist, dann wohl durch die Visu oder KNX Taster. Dann soll bis zur Dunkelheit (theoretisch auch nach Ablauf von einer gewissen Zeit) die Jalousie unangetastet bleiben. Das spart letztlich, für jede einzelne Jalousie ein Aktiv-Item anzulegen und abzufragen.

Ich scheitere aber daran, in der getriggerten Logik zu unterscheiden, von woher de Impuls für den Rollladen kam. Überwacht wird zuzeit die Rollladenposition, das Fahren und das Stoppen. Ich habe schon Versuche mit trigger['by'], trigger['source'] und changed_by() gemacht. Am erfolgversprechendsten finde ich noch changed_by().
Allerdings bekomme ich schon beim Start von smarthome.py durch das Setzen der Werte Probleme. Changed_by sagt dann mal "Cache" und mal "Init". Es kommt beim Start aber auch manchmal "knx", was ja eigentlich sonst nur bei Tasterdruck kommt. Es liegt wohl daran, dass sich nach dem Initiieren der Werte die Position mit irgendwelchen Statuswerten meldet.
Beim Tasterdruck kommt mehrheitlich "knx", aber bei manchen Ereignissen auch "Init".
Beim Triggern durch die Logic kommt mehrheitlich "Logic", dass würde ja helfen, aber in der Folge kommen dann auch wieder "knx"-Meldungen.
Lediglich ein Ereignis von der Visu kann ich klar indentifizieren.Bei dem Ansatz von JanT schein ja nur die Visu eine Rolle zu spielen, aber die nutzen wir fast nie.

Ich weiss, dass ich für eine detaillierte Analyse die Logs etc mitschicken müsste. Ich wollte aber vorab mal fragen, ob es vielleicht einen ganz anderen Ansatz gibt, um herauszufinden, woher der initiale Befehl kommt. Ideal wäre auch, wenn die Logik durch eine Rollladenbewegung mehrfach getriggert würde (Fahren, Stopp, Position)

Vielen Dank

Arne

[JanT]

Hallo Arne,

Versuch mal bitte folgendes: Ich gehe davon aus, dass die Taster separate KNX Gruppenadressen haben. Binde die in SmartHome als Items mit enforce_updates und knx_listen (NICHT knx_cache). Diese Items werden dann bei ein Tastendruck – und nur bei Tastendruck, auch nicht bei eine SmartHome Neustart – „getriggert“.

Viele Grüße,

Jan

[arnix]

Hi Jan,

hatte ich schon versucht, ich versuche es aber nochmal. Welchen Typ bekommt das Item? Oder bleibt es ohne Typ?

Grüße

[arnix]

ich nochmal:

Meine Taster haben zurzeit keine Gruppenadressen, sondern nur physikalische Adressen. Daher wurde wohl auch nicht getriggert. Kann man jedem Taster eine Gruppenadresse zuweisen? Ich habe bisher keine Möglichkeit gefunden. Es sind die MDT-Glastaster.

Grüße

Arne

[callidomus]

Hallo Arne,

Anmerkung: wenn Deine Taster keine Gruppenadressen (zugewiesen) haben, dann kannst Du Sie auch der Installation entfernen.

Allgemeine Fragen zu den MDT-Glastastern sind aber besser im Hauptforum aufgehoben. Also bitte dort weiter...

Bis bald

Marcus

[arnix]

Hi Marcus,

naja, meinen Tasten sind schon Gruppenadressen zugewiesen, sonst machen Sie ja keinen Sinn. Es handelt sich bspw. um die Gruppenadresse für Rollladen.Wohnzimmer.Fahren usw.
Nur ist diese Gruppenadresse auch an anderen Tastern, und auch an der Visu etc. zugewiesen. Somit ist unklar, woher der Befehl für Rollladen.Wohnzimmer.Fahren kommt. Und darum geht es, dass für meien Logik klar sein muss, dass der Befehl vom Taster kommt und nicht vom Scheduler.

Jan meinte, wenn ich ihn richtig verstanden habe, dass der Taster eine eigene Gruppenadresse zugewiesen bekommen soll, die nur mit dem Taster verknüpft ist. Um dann mittles eines enstprechenden Items eine Logic triggern zu können, wenn der Taster bedient wird. Vielleicht habe ich das auch falsch verstanden. Aber darum geht es und die Frage, ob das (auch) ein MDT-Taster kann, ist eher Nebenkriegsschauplatz.

Grüße

Arne

[mumpf]

Hallo Jan,

auch wenn es leicht off-topic ist: Mit diesem Satz

... Items mit enforce_updates und knx_listen (NICHT knx_cache). Diese Items werden dann bei ein Tastendruck – und nur bei Tastendruck, auch nicht bei eine SmartHome Neustart – „getriggert“.

hast Du mein Wochenende gerettet! Ich hatte sporadisch beim Neustart von sh.py Rolläden, die runterfuhren und war dabei, die Ursache rauszufinden bzw. mich nach Alternativen umzusehen (deswegen auch diesen Thread gelesen). Und da kam Dein Satz, der einfach nur den (mir eigentlich bekannten) Unterschied zwischen knx_listen und knx_cache nochmal explizit im Zusammenhang mit einem Neustart formulierte - da ist bei mir der (gedankliche) Knoten geplatzt und ich weiß die Lösung.

Ich wollte mich hiermit bedanken,
Gruß, Waldemar

[JanT]

Hallo Arne,

Jan meinte, wenn ich ihn richtig verstanden habe, dass der Taster eine eigene Gruppenadresse zugewiesen bekommen soll, die nur mit dem Taster verknüpft ist. Um dann mittles eines enstprechenden Items eine Logic triggern zu können, wenn der Taster bedient wird. Vielleicht habe ich das auch falsch verstanden.

Das hast Du schon richtig verstanden. Jeden Taster kann das, Du änderst nur die vorhandene sendende Adresse in eine neue eindeutige. Die Begrenzung (die Du wahrscheinlich auch nicht erreicht) liegt an die Anzahl hörenden Adressen im Aktor - da Du die neue eindeutige Adresse hier hinzufügen muss. Den Typ des Items ist abhängig von Dein Aktor. Ich tippe auf bool/knx_dpt=1 für Fahren/Stop und num/knx_dpt = 5 für Position (0-255) oder num/knx_dpt = 5001 (0-100).

Viele Grüße,

Jan

[arnix]

Hallo Jan,

erst jetzt habe ich dich richtig verstanden. Bisher habe ich geglaubt, ich benötige eine zusätzliche Gruppenadresse, die zu den bestehenden am Taster hinzugefügt wird, nur um den Taster zu identifizieren.
Du meinst aber, ich soll bei der Vergabe der Gruppenadresse differenzieren, von welchem Gerät es kommt. D.h. der Taster im Wohnzimmer hat eine andere Gruppenadresse für das Fahren des Wohnzimmerrolllos als die Visu.
Mit den Kapazitäten am Aktor käme ich hin. Aber es bedeuted natürlich auch, dass ich 2 verschiedene Items für ein und diesselbe Aktion habe. Das wird nicht gerade zur Übersichtlichkeit beitragen.

Ich schaue mal, wie ich weitermache. Du hast bei dir die Manuel-Funktion auf die Visu beschränkt??

Danke für die Antworten,

Arne

[offline]

Hallo zusammen,

ich habe das Plugin für die Verschattung nun soweit fertig, dass man es auf die Allgemeinheit loslassen kann. Die Grundarbeitsweise entspricht der der Raffstore-Logik: Verschiedene Zustände werden abgeprüft, der erste Zustand, bei dem alle Bedingungen passen, wird angesteuert.
In der Datei autoblind.zip habe ich das Coding angehängt. Außerdem hängt noch eine Doku als PDF an.

Es gibt noch ein paar Vorschläge aus diesem Thread, die ich interessant finde, jedoch noch keinen Eingang in das Plugin gefunden haben. (z. B. Automatik deaktivieren, wenn Verschattung manuell angesteuert wurde, generische item_*, min_*, max_* Bedingungen). Bevor ich das jedoch auch noch einbaue, hier zunächst einmal der aktuelle Stand des Plugins.

Grüße
offline

Edit: Irgendwie klappt das mit dem Anhängen von Dateien nicht ...

Edit2:

autoblind.zip: https://www.dropbox.com/s/738i9tz1m5...blind.zip?dl=0
docu.pdf: https://www.dropbox.com/s/69q21yc8w41d2ga/docu.pdf?dl=0

[Onkelandy]

Vielen Dank offline für das Bereitstellen. Werde ich mir demnächst mal im Detail ansehen.
Der Vollständigkeit halber noch der Ansatz bezüglich Automatik an/abschalten.
In der Logik wird abgefragt, ob die letzte Änderung durch einen Taster oder die VISU durchgeführt wurde. Nur, wenn nicht, dann soll die Automatik greifen:

    if not (jalousie.changed_by().startswith('KNX') or jalousie.changed_by().startswith('Visu')):

Dann gibt's nen generellen Automatikschalter für alle Jalousien, der auch immer bei Sonnenauf- und untergang getriggert wird. Man hört dann natürlich das kurze Fahren der Jalousien... Ich habe bei allen Jalousieitems ein zusätzliches Attribut namens "Beschattung" - unten stehender Code läuft also durch all diese Items

if sh.jalousien.automatik() == 1:
   logger.warning("Jalousienautomatik aktiv")
   for jalousie in sh.find_items('beschattung'):
       fahren = jalousie()
       # Dies bewirkt, dass die letzte Aenderung fuer die Jalousie von der Logik kommt und nicht mehr vom KNX-Taster oder der Visualisierung. Alles wird wieder nach Sonnenstand gesteuert.
       jalousie(fahren+1)
       logger.debug("Fahre Jalousie {0} auf Wert {1} zu.".format(jalousie,fahren))

Das Item sieht dann so aus:

    [['j5_wohnen']]
    type = foo
        [[['hoehe']]]
            knx_send = 3/1/16
            knx_dpt = 5
            visu_acl = rw
            type = num
            knx_init =3/1/32
            cache = True
            sqlite = init
            enforce_updates  = yes
            beschattung = 75 | 130 | 20 | 254 | 23 | 1 | 450 | 255
            # azimut-start | azimut-stop | min altitude | jalousienhoehe | temperatur (Wunderground) | UV Wert (Wunderground) | Solarwert (Wunderground) | Nachtwert

[offline]

edit: gelöscht, neuer Post kommt gleich

[arnix]

Hallo offline,

vielen Dank für das Bereitstellen. Ich bin auch sehr interessiert daran, habe aber gerade erst (heute) meine automatische Steuerung auf Grundlage der Logik fertiggestellt bzw. die letzten Fehler ausgemerzt. Ich habe zusätzlich das Problem, dass ich keine Raffstores habe sondern Rollladen und daher wieder etwas Code ändern müsste. Vermutlich würde das bei jedem Update deines Plugins ein Problem. Kann man da vielleicht eine Option einbauen, ob Raffstores oder Rollladen gesteuert werden sollen? Im Prinzip muss bei den Rollladen ja nur etwas weggelassen werden.

@ JanT:
Ich habe es jetzt so gemacht, wie Du vorgeschlagen hast, also mit eigenen GAD für die Taster. Somit werden beim Start von SH diese GAD nicht mehr initialisiert und damit wird auch nicht die Logik falsch ausgelöst. Funktioniert aber nur beim Überwachen der Items "Fahren" und "Stopp". Bei "Position" gibt wohl auch der Aktor nach jedem Start von SH eine Meldung über die Position, so dass die Logik getriggert würde, als wenn jemand die Position verändert hätte. Schade eigentlich, weil das Überwachen der Position für Szenen relevant ist, d.h. wenn ich eine Szene schalte würde die Logik ausgelöst und die automatische Steuerung gestoppt. Jetzt muss ich mir noch etwas einfallen lassen, um das trotzdem zu realisieren und auch um bei Zentralbefehlen die Logik zu triggern, also z.B. bei "alle Rollladen auf".

Danke jedenfalls für deinen Tipp, ich musste nur unzählige Stunden alle Kommunikationsobjekte mit neuen GAD belegen und schon hat es funktioniert

[offline]

Hallo zusammen,

die Bastelwut hat zugeschlagen: Die generischen Items und die zeitgesteuerte Deaktivierung sind fertig. Coding und Doku liegen unter https://www.dropbox.com/sh/pcqcse9ba...qNo9kycNa?dl=0

@onkelandy: Danke für dein Coding. Ich habe es aber etwas anders gelöst. Ich setzte direkt im Plugin trigger auf die zu überwachenden Items, so bekommt die Logik direkt mit, wenn sich etwas ändert. Wenn das der Fall ist, setzte ich das Aktivierungs-Item "active" auf "aus" und gleichzeitig einen Timer, um es wieder einzuschalten. Zusätzlich wird natürlich noch das Item "active" selbst überwacht, um im Fall einer manuellen Aktivierung/Deaktivierung einen ggf. gesetzten Timer wieder zu löschen.

@arnix: Bei der Ansteuerung von Rolladen hast du nur eine Höhe und keine Lamelle. Probiere mal ein Dummy-Item für die Lamelle einzubauen. Den Lamellenwert bei der Positionsangabe kannst du dann durchgehend auf 0 setzen. Ich habe das zwar nicht ausprobiert, aber eigentlich sollte es so funktionieren

Grüße
offline

[hhhc]

Edit2:

autoblind.zip: https://www.dropbox.com/s/738i9tz1m5...blind.zip?dl=0
docu.pdf: https://www.dropbox.com/s/69q21yc8w41d2ga/docu.pdf?dl=0

hallo,

konnte die beiden dateien (auf dem iPhone) nicht laden und bekomme einen 404 von Dropbox...

bin das we unterwegs würde das plugin aber gerne nächste Woche testen...

gruss
hhhc

EDIT: Guten morgen offline. jetzt geht's. da hatten sich dein update und meine ungeduld überschnitten