Automatische Beschattung

[offline]

btw gibts sowas auch für Beschattung mit Rolläden??

siehe Post 29

[Bonze]

sieht gut aus ;p
btw gibts sowas auch für Beschattung mit Rolläden??

[offline]

@hhhc: Die Dateien aus Post #25 sind gelöscht, weil überarbeitet. Der neue Link steht in Post #29.

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

[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

[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]

edit: gelöscht, neuer Post kommt gleich

[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]

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

[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

[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

[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

[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

[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]

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