Ich muss zurückrudern. Ich hatte da noch nie etwas hinterlegt sondern das über ein eigenes php skript realisiert. Ich werde wohl mal die Variable vom Türgriff loggen müssen, ob die ggf. nicht immer gesetzt wird.
Sorry für die Verwirrung.
1 „Gefällt mir“
Hi @bumaas ,
Danke Dir für das tolle Modul und Deine immense Arbeit und Zeit die da reinsteckst 
Ich habe seit einem der letzen (Beta)Modul Updates ein Problem mit meinen beiden Dachfenstern (schräg, nicht 90 Grad). Die Beschattung (nach Sonnenstand, genaue Version) startet beim Richtung Osten gerichteten Fenster korrekt am Morgen, wenn die Sonne aber im Laufe des Tages über dem Dach aus Richtung Westen scheint und somit das Ost Fenster nicht mehr bescheint, öffnet sich dieses trotzdem nicht mehr und bleibt voll beschattet… Das war vor dem besagten Update (ich weiss nicht mehr welches genau) nicht so, da wurde die Beschattung schrittweise zurückgefahren und sobald die Sonne gar nicht mehr ins Fenster schien, wieder ganz geöffnet. Seit dem Update öffnet sich die Beschattung erst, wenn die eingestellte Altitude unterschritten wird (aktuell spät am Abend, statt vom Sonnenstand her eigentlich am frühen Nachmittag)…
Kannst Du Dir das erklären, resp. bei Dir nachstellen? Ich kann Dir sonst auch mal ein Debug schicken, wenn Du es bei Dir nicht selber nachvollziehen kannst…
Hallo Boobele,
um es eingrenzen und nachstellen zu können, bräuchte ich von dir bitte:
-
Ein Debug-Log über einen kompletten Nachmittag, an dem das Ostfenster fälschlich beschattet bleibt – idealerweise inklusive des Moments, an dem es eigentlich wieder öffnen müsste. Am einfachsten über „An Datei schicken“ im Debug Fenster.
-
Deine Konfiguration des betroffenen Fensters („Zeige Konfiguration“)
Könntest du es hier ablegen oder mit schicken?
Hi Bumaas,
die Debug Daten sind ‘in Arbeit’ ich hänge Sie Dir dann am Abend an. Die Config der Instanz habe ich schonmal hinzugefügt…
Besten Dank fürs Anschauen
Config Rollo.pdf (22,4 KB)
Update für @bumaas:
Tja, was soll ich sagen, nachdem ich gestern noch das Gateway dass die Rollos steuert neu gebootet habe und ich die Konfiguration der Instanz nochmal angeschaut und etwa korrigiert habe, läuft die Beschattung heute wieder ganz normal… 
Es muss eine ‘Eine Verkettung unglücklicher Umstände’ (wie man so schön sagt 
) gewesen sein, dass der Rollo in den letzten Wochen erst spät Abends wieder geöffnet wurde. Ich vermutete da wohl zu unrecht eines der letzten Beta Updates als Ursache…
Was ich gemacht habe, eben neben des Reboot des Gateway (Velux), ist das löschen der Temperatur ID (da gibt es widersprüchliche Aussagen in der Doku, siehe unten) und das korrigieren der Dachschräglage vom Fenster.
Ich bin davon ausgegangen, weil in der Doku steht, 90 Grad = Fassadenfenster (senkrecht), dass ich von diesen 90 Grad ausgehen musste und das Dachfenster von unten nach oben in die korrekte Schräge daraus berechnen muss, das wären dann 55 Grad, was ich auch seit jeher eingetragen hatte. Beim andern Dachfenster konnte ich aber heute eindeutlig nachvollziehen, das ich wohl von der horizontalen ausgehen hätte sollen und somit 35 Grad (90 - 55 Grad) eintragen hätte sollen. Ist ein bisschen verwirrend geschrieben finde ich, einerseits als Referenz die senkrechte (90 Grad), aber der Winkel muss anscheinend aus der horizontalen nach unten abgeleitet werden…
Betreffen Temperatur ID, ist es eben auch ein bisschen verwirrend in der Doku, in der Funktionsbeschreibung (Text) steht:
Zusätzlich kann eine Temperaturvariable angegeben werden, um bei erhöhten Außentemperaturen eine höhere Beschattung zu erreichen, d.h., der Rollladen wird bei höheren Temperaturen weiter heruntergefahren. Dies erfolgt in zwei Stufen: Wenn die Temperatur 27 °C übersteigt, wird der Rollladen um weitere 15 % heruntergefahren, wenn die Temperatur 30 °C übersteigt, dann wird der Rollladen auf einen Schließungsgrad (Behanghöhe) von 90% heruntergefahren)
Also dass je wärmer es ist, desto weiter herunter fährt das Rollo… In der Konfiguration Beschreibung der ID steht aber:
Indikatorvariable die einen Temperatursensor (Außentemperatur) wiedergibt. Bei Temperaturen über 24 °C wird der Helligkeitsschwellwert verringert, um eine frühere Beschattung zu erreichen (10% Schwellwertverringerung je Grad Temperaturdifferenz zu 24 °C). Bei Temperaturen unter 10 °C wird der Helligkleitsschwellwert heraufgesetzt, um die Sonne erst später 'auszusperren' (10% Schwellwerterhöhung je Grad Temperaturdifferenz zu 10 °C).
Also bei fixen Werten (10, 24 Grad) wird die Beschattung früher oder später gestartet, nicht aber die Behanghöhe verändert… Was stimmt nun, was bewirkt die Temp ID genau?
Ich denke eher das erst genannte, das führte dann vermutlich bei mir, jetzt mit den extrem heissen Temperaturen (> 30 Grad) dazu, dass das Rollo trotz Sonne die nicht mehr durchs Fenster schien, auf 90 Prozent Beschattung blieb…
Was es jetzt genau war (Reboot, Temp löschen oder Dachneigung korrigieren, ist schwer zu sagen, ich vermute aber in meinem Fall war es die Temp ID…
Wie auch immer, im Moment läuft wieder alles wie früher (wo es nicht so heiss war und somit die Temp ID einen Kleien Einfluss hatte), somit ist der ‘Fall’ erledigt
Danke Dir nochmal für das supertolle Modul 
Hallo
Ich möchte mich auch für das Modul bedanken, mittlerweile betreibe ich das glaube ich seit 8 Jahren. Weiß nicht genau. Hat immer gemacht was es sollte. Im Moment habe ich aber ein Problem. Nachdem ich einige Fenster umgebaut habe von Eaton auf HmIP und natürlich die Modul Update gemacht habe ist jetzt irgendwie eine Verzögerung von ca. 1 - 2 Minuten (hab die Zeit nicht gemessen) beim reagieren des Rollo bei Öffnen, Schliessen, Kippen. Es war sonst so das wenn ich die Terassentür geöffnet habe fuhr sofort das Rollo hoch, wenn ich ein Fenster auf Kipp gestellt habe fuhr das Rollo auf Lüften. Das geht zwar immer noch, aber stark verzögert.
Ist in dem Bereich irgendwas geändert worden?
Gruß
Kalle
Wenn ich es richtig einordne, dann hast du die Kontakte ausgetauscht, korrekt?
Eine Verzögerung von 1-2 Minuten klingt danach, als ob die Events der Kontakte nicht verarbeitet würden und erst beim regelmäßigen Kontrolllauf der geänderte Kontaktwert festgestellt wird.
Wenn du mal ins Debug schaust während du ein Fenster kippst, sollte man es sehen, das sofort reagiert wird.
Vielleicht hilft dir zur Analyse auch der neue Testbutton in der Instanz weiter. Der ist in der Beta Version des Moduls neu.
Hallo Boobele,
freut mich, dass wieder alles rundläuft! Deine beiden Beobachtungen haben zwei Doku-Ungenauigkeiten aufgedeckt, die ich gerade bereinigt habe – danke dafür.
Zur Temperatur-ID: Beide Doku-Stellen waren jeweils richtig, aber unvollständig. Der Temperatursensor wirkt tatsächlich zweifach:
- Beschattungsbeginn (Helligkeitsschwellwert): über 24 °C wird der Schwellwert gesenkt (10 % je Grad → frühere Beschattung), unter 10 °C angehoben (spätere Beschattung).
- Behanghöhe (Hitzeschutz): über 27 °C zusätzlich 15 % weiter herunter, über 30 °C fest auf 90 % Schließungsgrad.
Deine Vermutung war also richtig: Bei den >30 °C der letzten Tage hat der Hitzeschutz gegriffen und den Behang bewusst auf 90 % gehalten – und zwar solange die Beschattung nach Sonnenstand insgesamt aktiv ist (Helligkeit über Schwellwert sowie Azimut und Sonnenhöhe im eingestellten Bereich)
Das ist so gewollt (Hitzeschutz), war aber nicht dokumentiert. Durch deinen sehr weiten Azimutbereich blieb das Gatter lange offen, daher der späte Effekt.
Zur Fensterneigung: Der Winkel wird gegen die Horizontale gemessen – senkrechte Fassade = 90°, flach liegendes Dachfenster = 0°. Für ein Dachfenster trägst du also die Dachneigung ein (z. B. 35°-Dach → 35°). Ich habe die Beschreibung entsprechend eindeutiger formuliert.
Beides fließt in den nächsten Build ein. Danke dir für die ausführliche Schilderung!
Burkhard
ich habe die Aktore für die Rollos gewechselt.
Vielen Dank bumaas für die Klarstellung des Temperatur Verhaltens und der Einstellung der Dachschräge
Neuerungen in der aktuellen Beta
In den letzten Builds hat sich beim Blind Control-Modul einiges getan – hier die wichtigsten Erweiterungen:
- Kontakte mit Wertegruppen (Öffnen & Schließen)
Kontakte zum Öffnen und zum Schließen können jetzt pro Kontakt bis zu drei verschiedene Positionen anfahren – abhängig vom Rohwert der zugewiesenen Variable. Unterstützt werden Boolean, Integer, Float und String. Bleiben die Wertefelder leer, verhält sich der Kontakt wie bisher als einfacher Ein/Aus-Kontakt. Zusätzlich lässt sich je Kontakt eine eigene Entprellung (Verzögerung) einstellen, sodass bei schnell wechselnden Werten nur der zuletzt gemeldete ausgewertet wird. - Nachvollziehbare Entscheidungen (Ablaufprotokoll)
Die optionale HTML-Statusvariable DECISION_TRACE und der Probelauf „Entscheidung erklären" zeigen den kompletten Entscheidungsweg eines Steuerungslaufs Schritt für Schritt – inkl. Tag/Nacht, Beschattung, Temperatur-Einfluss, Wochenplan-Zeiten und Einfluss der Kontakte. - Korrektur
Sind mehrere Schließen-Kontakte gleichzeitig offen, wird nun die am weitesten geschlossene Position angefahren (restriktivste Anforderung gewinnt). - Hinweis
Das Modul setzt jetzt Symcon ≥ 8.1 voraus.
Viel Spaß damit – Feedback willkommen!
PS: vielen Dank an @Burki24 für seine Ideen und seine Unterstützung
1 „Gefällt mir“
Lieben Dank Burkhard,
damit sind jetzt auch die Werte verschiedenster Fenstergriffe wie SODA, Homematic, etc. einbezogen. Diese liefern ja unter Umstanden int (0, 1,2, 3, 4) oder string (up, down, left, right, etc.) alles ist dadurch möglich zu nutzen.
LG
Burkhard
Hallo Burkhard’s
das sind ja mal sinnvolle Änderungen am Modul. Vielen Danke.
Was aber bei den Auswertungen nun immer noch zu kurz kommt, sind die sinnvollen Benennungen der Kontakte. Wenn da mehrere konfiguriert sind, steht in der Auswertung auch nur “Kontakt offen” o.ä. Welcher das nun ist, muss ich dann auch erst über die Konfiguration suchen.
Wenn ihr hier vielleicht noch die Kontaktfunktion mit ausgeben könntet? (offen/geschlossen/Notfall und die entsprechende Zahl des Kontakts 1 oder 2)
Damit währen Aktion und Ursache der Bewegung noch eindeutiger und leichter zu identifizieren.
Danke
Gruß Rainer
Hallo @erpe (Rainer),
bitte beachten: Das Modul wird von @bumaas betreut, ich hatte nur ein paar Ideen. Also richte Deine Wünsche bitte direkt an @bumaas.
Denke aber mal, dass sich das schnell ergänzen lässt.
Lieben Dank und LG
Burkhard
ja, ich weiß @bumaas und @Burki24
aber ihr heißt nun mal beide Burkhard - daher auch meine Anrede:
Aber schön, wenn sich einer von euch darum kümmert. 
Vielen lieben Dank
Gruß Rainer
Moin @bumaas ,
seit dem letzten Update erhalte ich viele dieser Meldungen
An der Konfiguration habe ich nichts geändert.
Was mag das sein?
Gruß,
Loerdy
Hallo Rainer,
danke für den guten Vorschlag — das ist nun umgesetzt und in der Beta (2.50 Build 102) verfügbar.
Die Auswertungen benennen jetzt den auslösenden Kontakt mit Funktion, Nummer und Zustand.
Magst du kurz testen, ob die Ausgaben bei dir jetzt eindeutig sind?
Burkhard
Die sollten auch wieder verschwunden sein
Vielen Dank!!!
Sieht wieder gut aus.
Loerdy
Hallo @bumaas
Danke für die sehr schnelle Umsetzung. Jetzt sind die Aussagen schon eindeutig einem Kontakt zuzuordnen.
Da ihr nun die Möglichkeiten auch Integer-Variablen für die Kontakte zu nehmen geschaffen habt, muss ich mal schauen, wie ich da meine “Hilfsvariablen” ablösen und die realen Kontakte bzw. Zustandswerte der Fenster nutzen kann. z.B. Dachfenster: geschlossen, zu, gekippt (offen), schwing
Vielleicht macht es dann sogar Sinn, den Namen und den Anzeigewert der benutzen Variablen hierfür zur Anzeige im Protokoll zu nehmen. ich teste mal, wie das mit der aktuellen Version und Integer Variablen aussieht. Boolean bringt hier ja nur zwei Möglichkeiten.
Gruß Rainer
Der Anzeigewert sollte schon jetzt dabei sein.
Der Name (z.B. ‚Status’) hilft meistens nicht.
stimmt. Das hatte ich beim ersten schnellen Test wohl übersehen.
da gebe ich dir Recht. Meine Variable für den Öffnen-Kontakt heißt “Fenster offen…”, aber die integer Variable vom Fensterstatus auch nur “Status” bzw. “Priorität” (habe für jedes Fenster ein Dummy mit den Variablen).
Eine sinnvolle Beschriftung liegt da in der Verantwortung des Benutzers…
Belassen wir es erstmal so. Die möglichen Kontakte (2) zur Auslösung sind ja überschaubar.
1 „Gefällt mir“