Die Werte bleiben auch 
Aber das adaptive Icon ist dann richtig herum.
Steht auch in bumaas Doku auf der GitHub Seite, dass es am Icon erkennbar ist.
Michael
Du denkst/erwartest, dass die Werte umgerechnet werden 
Das passiert aber nicht. .Reversed wird nur intern von Symcon ausgewertet. Dies passiert z.B. bei Darstellung von adaptiven Icons. Wenn du z.B. der Level Variablen das Icon „Jalousie“ zuordnest, dann siehst du den Unterschied.
Es muss halt bei der Darstellung des Icons unterschieden werden zwischen 100% = offen und 100%=geschlossen.
Dazu wird auch im Modul der Namen des Icons ausgewertet. Die Umrechnung erfolgt auch hier nur intern.
EDIT: Mann, oh mann. Michael war schon wieder schneller
Okay,
dann hab ich das wohl ein wenig völlig falsch verstanden. 
o.
Vielen Dank.
Gruß
Burkhard
Hallo bumaas,
habe erfolgreich den ersten Rollladen mit Deinem Modul konfiguriert.
Jetzt kann ich mich nur noch bedanken. Das Modul ist der Wahnsinn. Selbst die Lüftungsstellung, wenn der Rollladen unten ist und ich das Fenster kippe funktioniert auf anhieb und in Perfektion.
Also: VIELEN, HERZLICHEN DANK.
Irgendwo stand, Du solltest mal einen Spenden-Link einrichten. Gibt es den schon? Da würde ich glatt aktiv werden. Ich kann mir nur ungefähr vorstellen, was in dem Modul für Arbeit steckt.
Viele Grüße
Burkhard
Auf der ersten Seite ganz runter scrollen, dann kannst Du Spenden 
Es freut mich, dass dir/euch mein Modul gefällt. Wer möchte, kann mir auch gerne etwas zukommen lassen. Darüber freue ich mich immer
Betrachtet es aber bitte nicht als Verpflichtung! Besonders freue ich mich, wenn mir selber auch geholfen wird. Aber vielleicht kann nicht jeder helfen und somit gibt es nun (in der Beta 2.20 build 8) auch einen Spendenknopf
Daneben gibt es aber auch noch eine Erweiterung:
- in den Experteneinstellungen lässt sich eine Verzögerung für den Tag-/Nachtwechsel einstellen. Optional auch mit Zufallsanteil, falls jemand eine Abwesenheitssimulation umsetzen möchte
Burkhard
Wie ist denn die Verzögerung der Tag/Nachtumschaltung zu verstehen?
Wenn ‚es ist Tag‘ dann fahren die Rollos noch nicht hoch, da zu früh (erst nach Wochenplan). Dann dürfte ein früheres ‚es ist Tag‘ ja keinen Einfluss haben?
Bei ‚es ist Nacht‘ würde es dann funktionieren, da dieses Vorrang vor dem Wochenplan hat.
Die Zeit bezieht sich aber dann simultan auf Tag/Nacht?
Kann man auch negative Werte eintragen, also quasi nach hinten verschieben? ‚Tag‘ und ‚Nacht‘ = später?
Funktioniert mittlerweile eigentlich der Wochenplan über Mitternacht hinaus oder sie kann man für einen einzelnen Rollladen die Schliesszeit über Mitternacht ziehen?
Danke vorab!
Die Tag-/Nacht-Umschaltung beinhaltet sowohl den Wochenplan als auch die ‚Ist es Tag‘ Erkennung. Es ist der Zeitpunkt, bei dem nach Auswertung aller Regeln der Rollladen öffnet bzw. schließt.
Wenn der Zeitpunkt erreicht ist, wird bei gesetzter Verzögerungszeit ein entsprechender Timer gesetzt und dann erst bei Auslösung des Timers die Fahrt durchgeführt.
Ein negativer Wert und somit ein Vorziehen des Zeitpunktes ist nicht zulässig.
Es darf weiterhin im Wochenplan nur einen Zeitraum zum Hochfahren („Tagzeit“) geben. Das Schließen lässt sich aber über einen Kontakt verhindern.
Ich habe ein Problem mit Blindcontoll. Ich hatte schon vor Monaten mal angefragt aber es dann nicht mehr weiter verfolgt da es im Normalbetrieb gut läuft.
Bei manueller Betätigung eines Rollladen sollte die Automatik ausgeschaltet sein. Hier bewegt er sich nach der eingestellten Zeit trotzdem.
Heute konnte ich etwas beobachten.
- August 2020 20:04 - ‚SZ Fenster klein‘ wurde manuell geschlossen.
- August 2020 18:38 - ‚SZ Fenster klein‘ wurde geöffnet (Tag, 5209.0 lx)
- August 2020 18:31 - #51470(BlindLevelID): Position not reached! (Diff: -100,00).
- August 2020 15:36 - ‚SZ Fenster klein‘ wurde auf 20% gefahren (Kontakt offen)
- August 2020 09:00 - ‚SZ Fenster klein‘ wurde geöffnet (Tag, 74320.0 lx)
Um 15:36 wurde der RL(Homematic) über Kontakt offen auf Lüftungsstellung gefahren, hier 20%. Um 18:31 wurde er manuel geschlossen. In diesem Fall von einem FS20 Schalter, über ein Skript:
SetValueInteger(48063, 0); //ContactCloseLevel1
SetValueInteger(45915, 0); //ContactCloseLevel2
$InstanzID = 12091;
$VariablenID =49437;
//$level = GetValue($VariablenID);
//HM_WriteValueFloat($InstanzID, "LEVEL" , 0.0); // Rollladen schließen
RequestAction($VariablenID, 0.0); // Rollladen schließen
Hier ist der RL erst kurz nach oben gefahren (ContactCloseLevel wurde auf 0 gesetzt) dann geschlossen vom RequestAction. Nach einiger Zeit fuhr er dann wieder von alleine nach oben.
Irgendwie bei beißt sich da der Kontakt mit der manuellen Betätigung.
Hi, das mit dem Wochenplan stimmt.
Aber früher konnte man zB die Offenzeit nicht von 7.00 Uhr - 01.00 Uhr deklarieren, sondern nur bis max. 23:59 Uhr.
Alles nach 23.59 Uhr funktionierte nicht.
Ob das jetzt geht das weiß ich nicht.
Habe heute mal mit den Kontakten rumgespielt. Diese haben ja Vorrang vor der Beschattung. Das Tolle ist, das wenn der Kontakt offen ist und aktiv und während dem gesetzten Kontakt manuell gefahren wird, der Rollladen wieder auf den Kontakt getriggert wird und in die durch den Kontakt vorgegebene Position gefahren wird.
Ich muss da noch rumgrübeln, da ich hier so einen Spezialfall habe, wo ich trotz der umfangreichen Möglichkeiten noch nicht weiss wie ich es realisieren kann/soll.
Das mit dem PositionNotReached hatte ich auch schon, während ich mit den Kontakten herumgespielt hatte um etwas zu probieren und zu testen.
Generell ist es ja so, daß die Kontakte vorrangig der Beschattung bzw der Automatik ist. Wird der Kontakt geschlossen, so greift in dem Moment die reguläre Automatik. Das Rollo fährt also nach Schließen des Kontaktes in die Beschattung oder in die Tag oder Nachtposition.
Bei Dir wohl hier in die Tagposition (also auf) und kurz darauf schiebst Du aber den Schliessbefehl hinterher, was eigentlich bedeuten müsste das das Rollo erst hochfährt und danach dann zufährt.
Oder sehe ich das falsch?
Nein.
Hatte ich so geschrieben. Kurz hoch dann runter. Später wieder hoch.
Die Manuelle Betätigung sollte aber Vorrang vor allem haben.
Nein, das sehe ich anders. Die Kontakte (egal ob die Standardkontakte, als auch der Notfallkontakt) sollte vorrangig der manuellen Bedienung stehen.
Ich nenne mal folgendes Szenario. Ein Kontakt (Boolean Variable) welche über das Webfront auf true gesetzt wird zum Öffnen des Rollos.
Die Variable steht auf true, das Rollo fährt hoch. Nun fährt man das Rollo manuell zu.
Würde es zu bleiben, so hätte man paradoxe Zustände. Das Rollo wäre zu obwohl laut gesetzter Variable das Rollo auf sein müsste.
So wäre es laut Deiner These.
Also ist es schon richtig, das bei ausgelöstem Kontakt und darauffolgender manueller Fahrt der Zustand des Kontaktes erneut abgefragt wird und das Rollo erneut dem Kontakt folgt.
Das sehe ich nicht so. Egal was der Computer sagt meine manuelle Bedienung muss Vorrang haben.
Also ist es schon richtig, das bei ausgelöstem Kontakt und darauffolgender manueller Fahrt der Zustand des Kontaktes erneut abgefragt wird und das Rollo erneut dem Kontakt folgt.
Und das geschieht ja hier auch nicht. Ich stelle ja erst die Kontakte zurück und fahre dann.
Hallo Heiner,
das Modul erkennt eine Manuelle Bedienung daran, dass das Änderungsdatum der Levelvariablen sich nicht mit der letzten Aktion des Moduls deckt. In deinem Fall wird die manuelle Bewegung aber nicht erkannt. Sonst hättest du auch eine entsprechende Meldung bekommen ("… wurde manuell gefahren" oder so).
Wenn ich es richtig sehe, kommt wohl zeitgleich zur automatischen Fahrt ein „Gegenbefehl“ von dir. Danach erkennt das Modul lediglich, dass die Zielposition nicht erreicht wurde. Der Grund lässt sich aber modulseitig nicht herausfinden. Es könnte ja auch ein Funkproblem sein … Demnach wird die Fahrt bei nächster Gelegenheit erneut versucht. Manuelle Fahrten können nur erkannt werden, wenn sie nicht zeitgleich mit modulseitigen Fahrten stattfinden.
Deine Lösung mit dem Kontakt verstehe ich jedoch noch nicht ganz. Du setzt die Kontaktvariable im Skript auf „false“ und führst eine Rollladenfahrt aus. Die gleiche Variable ist aber im Modul hinterlegt und soll ebenfalls eine Fahrt auslösen.
Das beißt sich eigentlich.
Vielleicht schilderst du einmal, wie dein Anwendungsfall aussieht. Da findet sich bestimmt eine Lösung.
Ich sehe das anders… die Kontakte müssen Vorrang vor der manuellen Bedienung haben. Aber hierzu kann sich bumaas ja gerne nochmals äußern bzw. es einmal richtig erklären.
Nach meinem Verständnis:
Priorität 1 (höchste): Activated Variable
Priorität 2: Notfallkontakt
Priorität 3: Kontakte
Priorität 4: manuelle Bedienung
Priorität 5 (niedrigste) Beschattung (automatisch)
Ich nenne mal 2 Beispiele.
Für jedes Beispiel gehe ich davon aus, das die automatische Fahrt nach manueller Bedienung auf 120min gesetzt ist.
Beispiel 1:
Ich fahre um 18 Uhr meinen Rollladen herunter (manuell), der dadurch bis mindestens 20 Uhr in dieser Position verbleibt.
Nun löst um 19 Uhr die Brandmeldeanlage aus und der Notfallkontakt wird gesetzt, die Rollladen sollen sofort auffahren.
Nach Deiner Theorie würden diese aber erst um frühestens 20 Uhr auffahren, da ja die Haltezeit von 120min eingehalten wird.
Das ist so sicherlich nicht gewünscht.
Beispiel 2:
Ich habe einen Türkontakt, welcher bei ‚Tür auf‘ das Rollo auffahren soll.
Ich fahre um 18 Uhr das Rollo herunter (manuell), welcher dadurch bis mindestens 20 Uhr in dieser Position verbleibt.
Nun öffne ich um 19 Uhr die Tür, das Rollo würde aber nicht hochfahren (nach Deiner Theorie erst um frühestens 20 Uhr).
Das ist sicherlich so auch nicht gewünscht.
Angenommen das Rollo wäre durch die Türöffnung aufgefahren und ich wäre draussen. Nun würde ein Skript angestossen, was das Rollo zufährt (manuelle Fahrt). Würde BlincControl den Zustand des Kontakts nicht nochmals abfragen, so stehe ich draussen im Freien, bin ausgesperrt obwohl die Türe auf ist.Von daher muss ein Kontakt immer Vorrang vor der manuellen Bedienung haben.
Auch könnte es sein, das jemand das Rollo per Taster herunterährt, während ich draussen bin. Auch hier muss doch über den Kontakt ‚Tür auf‘ nach einer manuellen Fahrt geprüft werden, wie der Zustand des Kontaktes ist und dann bei offener Türe das Rollo wieder durch den ausgelösten Kontakt aufgefahren werden (solange die Tür auf ist).
Hallo Burkhard,
in diesem Fall (Schlafzimmer) habe ich 2 Fenster und 3(4) Schalter. Direkt an jedem Fenster einen HM-LC-Bl1-PBU-FM der den RL direkt schaltet. Am Bett einen HM-PB-6-WM55, Direktverknüpfung mit denen am Fenster. Und einen FS20 TC6 an der Zimmertür der beide RL über ein Skript ansteuert.
Nun will ich erreichen dass ich damit die Fenster öffnen oder schließen kann egal in welcher Stellung sie sich durch die Automatik gerade befinden. Die Automatik sollte für diesen Tag ausgeschaltet werden.
Bei Positionierung durch Sonnenstand klappt es auch. Wenn die ContactCloseLevel gesetzt sind muss ich sie ja irgendwie zurück setzen.
Bei der Bedienung über diese Taster sollte die manuelle Fahrt eigentlich erkannt werden und dann im manuellen Modus nach eingestellter Deaktivierungszeit verbleiben.
Dann ist das Skript also das Pendant zur Direktverknüpfung? Warum aber setzt du die Kontaktvariable hier auf 0?
Das ist eigentlich der Auslöser des Problems. Lass das mal raus.
Das machst du ja korrekt über RequestAction. Die Fahrt sollte durchgeführt werden und anschließend als manuell vom Modul erkannt werden.
Das erreichst du durch ein Setzen der Deaktivierungszeit auf 0.
Das brauchst du nicht und machst es bei den Direktverknüpfungen ja auch nicht.
Dann bräuchte man doch nur die Automatik ausschalten (dieses deaktiviert ja die Auswertung des Kontaktes) und das Rollo fahren.
Die Automatik könnte man dann ja über ein Skript zur gewünschten Zeit wieder einschalten lassen.
Bei deaktivierter Automatik geht nur der Notfallkontakt auch nicht mehr bzw andere Kontakte, die u. U. konfiguriert sind