Hallo zusammen
Erst mal vielen Dank an @simatec, dass er meine Erweiterungen mit in den Master aufgenommen hat!
Es stimmt, Dokumentiert sind diese Erweiterungen von meiner Seite her noch nicht wirklich, aber so wie es aussieht wurden diese schon mehrheitlich korrekt erraten

Hier noch eine kleine Zusammenfassung:

• Added buttons for Sunprotect Living and Sunprotect Sleep:
  
  Dies sind zusätzliche Buttons um die Bereiche Living und Sleep separat manuell in den Sonnenschutz zu bringen.

• KeepSunprotect added:
  
  Diese Option gibt's neu in den Sonnenschutzeinstellungen und bewirkt, dass der Rollladen nach Auslösen des Sonnenschutzes im Sonnenschutz verbleibt, bis das Down-Signal kommt. Damit wird ein häufiges Auf/Ab vermieden. Sie kann aber auch benutzt werden, um im Jalousiebetrieb (je ein Objekt für Höhe und Lamellenwinkel) die Jalousie unten zu halten und nur noch die Lamellen auf und zu gehen zu lassen.

• Drive after close added:
  
  Zu finden in den Haupteinstellungen.
  Wie der Name es sagt, kann damit das Nachholen der zuletzt angeforderten Aktion nach dem Schliessen des Fensters/Türe verlangt werden. (zb. Wenn Türe offen steht und SunProtect eigentlich schliessen will, bleibt der Rollladen auf offen, bis das Fenster geschlossen wird. Wenn das Fenster dann geschlossen wird, fährt der Rollladen auf Position Sunprotect. Das gleiche gilt für zb. Down am Abend. Wenn der Rollladen bei offenem Fenster manuell bewegt wird, merkt sich die Funktion die neue Position ebenfalls und fährt nach dem Schliessen nicht zurück, ausser wenn nach dem manuellen Fahren wiederum eine neue Anforderung kam.
  Wichtig hier ist das korrekte setzen von AutoDrive - also der Funktion für den Aussperrschutz. Steht dieser auf "Aus" ist die "Drive after close" Funktion wirkungslos. In den aller meisten Fällen macht hier wohl die Kombination aus Trigger (öffnen/schliessen) und Aussperrschutz (öffnen) und anhaken von "Fahren, nachdem Fenster geschlossen wurde" Sinn.

• Included Living-Auto and Sleep-Auto in Buttons for Open/Close Sleep and Living:
  Wie @coyote es schon richtig interpretiert hat, habe ich in die bestehenden Buttons für Open/Close Living und Sleep die Option der Living-Auto und Sleep-Auto mit reingenommen, so dass zb. mit dem Open Living alle Rollläden, welche mit Living oder Living-Auto konfiguriert sind, hoch gefahren werden. Das gleiche gilt für Close.
  Wenn ein Rollladen mit diesen Buttons nicht aus oder eingefahren werden soll dann steht neu zusätzlich die Option "Nur manueller Betrieb" zur Verfügung
  
  Dies ist insbesondere für Markisen sehr hilfreich, dass diese am Morgen beim manuellen öffnen nicht auch ausgefahren wird. (zb. bei Regen )

• Extend status handling
  Um einige dieser Funktionen realisieren zu können, musste ich das Status Handling von Shuttercontrol ziemlich heftig anfassen. U.a. habe ich da den status "triggered" eingeführt, damit man sehen kann ob der Fensterkontakt angesprochen hat. Weiter wird der Status auch geupdatet, wenn der Rollladen schon die geforderte Position hat. Damit wird sichergestellt, dass nachfolgende Aktionen korrekt ablaufen können. Es ist aber weiterhin kein externes Steuern über den Status möglich. Dieser ist weiterhin nur read-only.

Ich hoffe, ihr habt auch so viel Spass mit diesen neuen Funktionen wie ich

@negalein said in Test Adapter shuttercontrol v1.1.x:
@StefanW

Das kann sicher @FoxRo beantworten.

Das war jetzt eine Fangfrage - musste also kurz in den Code schauen um sicher zu gehen.
Also in allen Sonnenschutzarten, in denen ein Lichtsensor in der Auswahl drin steht, ist dieser jeweils optional, die anderen Parameter in der jeweiligen Auswahl sind "MUSS" Parameter und müssen somit konfiguriert werden. Wenn der optionale Lichtsensor konfiguriert ist, dann wird er mit berücksichtig, sonst logischerweise nicht.
Alle Parameter sind "UND" Verknüpft um die Sonnenschutzanforderung auszulösen. Es reicht somit, wenn einer der Parameter unterschritten wird, um die Sonnenschutzanforderung wieder aufzuheben.
Hoffe, habe es genug kompliziert geschrieben
Viel Erfolg!

@Qlink , das funktioniert bei meinen Jalousien nur, weil der KNX Aktor für Position (Höhe) und Lamellenstellung (Winkel) eigene Objekte anbietet. Mein Jalousie-Aktor kennt das genaue Timing jeder Jalousie. Die beiden Objekte habe ich dann als zwei Rolladen mit gleichen Settings erfasst. Das funktioniert grundsätzlich seit dem KNX unterstützt wird, auch wenn ich aktuell noch Mühe mit der Beschattungsfunktion habe. Da bei uns immer wieder mal manuell gefahren wird, schmeisst es die Beschattungsfunktion "raus" (z.b werden Lamellen manuell gefahren, die Position allerdings nicht, was den Beschattungsmodus manchal total aus dem Tritt bringt). An dieser Stelle fehlt mir evtl ein Hacken, mit welchem ich die manuelle Änderung wieder mit der Beschattungsfunktion übersteuern kann, damit er wieder "Tritt fassen" kann.
Wann eine offizielle Unterstützung für Jalousien kommt, weiss ich nicht.
Viele Grüsse

@simatec
Kann ich gerne tun.
Frage, wie wurden die .md Files erstellt? mit dem Pandao Editor von Github? Willst dies wiederum via Pull Request?

Hallo @simatec und Helfer
Coole Sache! Da ist in meiner "Abwesenheit" ja einiges gelaufen und es gibt wieder coole neue Funktionen. Danke allen fürs Weiterentwickeln!
Ich habe mir zum besseren Verständnis deshalb die neuste Version von @simatec "geforked" und den Code ein wenig angeschaut.
Vor allem die Zwischenposition hat es mir sehr angetan
Beim Durchgehen des Codes sind mir allerdings ein paar Dinge aufgefallen, welche uns mit fortschreitendem Sonnenstand evtl auf die Füsse fallen könnten, weshalb ich hier mal "Fahne" hoch halte.

1. Status: Mit den neuen Modi für X-Mas und Zwischenposition sind zwei neue Zustände eingeführt worden, welche aber unter dem Shutter-Status "down" geführt werden. Dies ist aus meiner (begrenzten) Sicht falsch, da es mit nachfolgenden Funktionen zu Problemen kommen kann. ZB. Wenn im Sommer zur Mittagszeit auf eine Zwischenposition gefahren wird, wird damit die Sunprotect Funktion ausgehebelt, da diese mit Status "down" nicht fahren darf. Für X-Mas ist dies, denke ich, weniger schlimm und kommt in der Praxis wohl kaum vor. Ich würde vorschlagen, dass die neuen Shutter-Stati "X-Mas" und "Middle" korrekt eingeführt werden, damit nachfolgende Funktionen weiterhin korrekt ablaufen/übernehmen können.
2. Die Zwischenposition funktioniert, nach dem wie ich es aus dem Code bis jetzt verstanden habe, nur solange korrekt, als dass die Schliessen Zeit(zb. Sonnenuntergang) vor der Zwischenpos. schliessen-Zeit liegt. Wenn sich dies aufgrund des Sonnenstandes irgendwann im Frühling bei mir umkehren wird, dann wird der Rollladen durch CompleteDown geschlossen, bevor er auf die Zwischenpos. fährt. (soweit noch so gut). Wenn nun aber mit dem Sunset das "down" kommt, wird der Rollladen auf die Zwischenposition gefahren (er öffnet sich also wieder). An dieser Stelle wäre es (zumindest für mich) wünschenswert, wenn der Rollladen mit der CompleteDown nur geschlossen wird, wenn dieser vorgängig auf die Zwischenpos. (Status = "Middle") gefahren wurde. Und im Downxxx wird nur auf die Zwischenposition gefahren, wenn die aktuelle Zeit vor der Zwischenpos. schliessen Zeit liegt. Wenn die aktuelle Zeit später als die Zwischenpos. schliessen Zeit liegt, soll mit der Downxxx (zb. Sonnenuntergang) der Rollladen direkt ganz geschlossen werden. Somit bleibt der Rollladen zusammen mit den anderen automatisch länger offen, und es werden alle wie heute gleichzeitig geschlossen.
   Wie gesagt, so würde es bei mir stimmen. Wäre schön, wenn sich der Eine oder Andere hier melden würde, wie es bei ihm mit der Zwischenpos. ablaufen sollte.
   Eigentlich möchte ich hier nicht im Code der neuen Funktionen "rum pfuschen". Deshalb möchte ich dies den jeweiligen Entwicklern überlassen. Wenn es aber gewünscht ist, biete ich gerne meine Unterstützung an.
   Wünsche allen einen guten Rutsch ins 2021, Danke für die tolle Arbeit und bleibt gesund!!
   Roli

@roadrunner said in Test Adapter KNX v1.0.x:

Bin mir nicht sicher, ob ich Deine Fragen richtig verstehe..

... Da ich kein ETS habe, habe ich die xml und Objektliste nach freien Adressen durchforstet, jedoch alles ohne Erfolg.
..Die physikalische Adresse ist laut Webinterface des ControlTouch 1.1.255:

Du musst hier im KNX Adapter eine FREIE unbenutzte KNX Adresse eingeben! Wenn also im ControlTouch für den IP Router die Adresse 1.1.255 definiert ist, dann darfst Du diese nicht verwenden! Um da sicher zu gehen, musst Du die KNX GA Struktur und Definition kennen.

Nun zum Problem: Obwohl der Adapter grün ist, kann ich nichts vom ioBroker aus steuern. (Jedoch kann ich die aktuellen Werte auslesen)

"Grün" bedeutet an dieser Stelle nur, dass sich der KNX Adapter korrekt mit dem IP Router verbinden konnte - mehr aber auch nicht.
Wie hast Du die Datenpunkt Objekte im IoBroker KNX Adapter angelegt? Manuell oder hast Du vom Installateur die KNX Projektdatei zum Import bekommen?
Du hast kein ETS - Ohne genaue Kenntnisse der KNX GA Struktur wird dieses Unterfangen zu einem "Suchen der Nadel im Heuhaufen".
.. Und wenn Du einzelne Datenpunkt Werte bereits reinbekommen hast (Read), wie sind diese konfiguriert? Sprich, wie sind die Flags für Read und Write gesetzt. Sind diese gemäss KNX Adapter Doku? GA für Schalten und Status?
Viel Erfolg!
Viele Grüsse, Roli

@cuth said in Test Adapter shuttercontrol v1.1.x:

@simatec danke.
Kannst du mir bitte die Elevation in der Astroeinstellung und je Shutter nochmal erklären.

Ich blicke da nicht durch. Ich will das jedes Fenster ab gewisser Sonnenhöhe gefahren wird.

Innen und Außentemperatur wäre natürlich schön da einzubinden. Aber ich verstehe es eben nicht

Ich stimme @simatec zu.
Deine Konfig ist so, dass er aus dem "Down" wohl direkt in den Sunprotect geht und da verbleibt bis die "Direction" (154+20) überschritten wird oder die Temp unter 23,75° (25° -5%) fällt.
Da Du die Sunprotect auf ganz geschlossen (0) gestellt hast, kannst Du den "Übergang" nach sunprotect nicht sehen.
Wie in der Doku geschrieben, Stelle die Temp für aussen und innen so ein, dass diese auch nur bei Sonne erreicht werden, ansonsten der Shuttercontrol zusammen mit der Direction immer gleich in den Sunprotect geht und da verbleibt, bis eines der Kriterien nicht mehr erfüllt ist.
Viel Erfolg!

Edit:
.. sorry hab ich erst jetzt gesehen, Du fährst den Sonnenschutz aktuell nur auf die Direction, also auf die Fensterausrichtung. ("type": "only direction",)
Die "sunProtEndElevation": "10", führt dazu, dass der Sonnenschutz erst beendet wird, wenn die Sonne von oben kommend die 10° unterschreitet oder, wie bei Dir, die Sonne aus dem Fenster geht.
Stelle den Sonnenschutz mal auf 50%, so kannst du sehen was wann passiert
Viel Erfolg!

@m-m said in Test Adapter shuttercontrol v1.1.x:

Offensichtlich wurde der Rollladen nicht bewegt, weil shuttercontrol denkt, dass Fenster sei geöffnet.

Die Meldung betr. Trigger und Manuell gefahren kommt immer, nachdem der Rollo manuell gefahren wurde. Egal ob Fenster offen oder zu.
Damit wird sichergestellt, dass der interne Zustand der für den Trigger benötigten Variablen in jedem Fall korrekt ist.
Dies ist also nicht der Grund, warum er bei Dir nicht fährt.

Die drei Rollläden werden wie vorgegeben 1 Sekunde versetzt angesprochen. Aber mir scheint, es wird 2 mal der gleiche Rollladen angesprochen (2x shutterDownLiving #3), oder nicht?

Das sieht mir aber etwas "komisch" aus.
Exportiere mal Deine Shuttercontrol Config und lade sie hier hoch - dann werfe ich mal einen Blick drauf. Vielleicht kann ich Dir so einen Tipp geben.
Bitte gebe zusätzlich an, welche Objekte korrekt laufen, und wie das Objekt heisst, welches nicht korrekt tut.
... danach sehen wir weiter.

@m-m said in Test Adapter shuttercontrol v1.1.x:

Heute morgen sind dann übrigens alle 3 gefahren. autoState.Position war heute morgen "down" bevor der Trigger sie um 09:30 Uhr geöffnet hat.

Das klingt doch schon mal gut!!

Wie Du siehst, heißt es aber immer "shutterUpLiving #3".

Da bin ich jetzt selbst kurz "reingefallen" deshalb kurz in den Code geschaut.
das #3 ist nicht die Shutternummer sondern die Nummer, um den Log eindeutig identifizieren zu können. (für die Entwickler sehr hilfreich )Er geht also bei #20 in den ShutterDownLiving und zwar wird hier zusätzlich die Türöffnung geprüft. Bei #21 wird dies nicht berücksichtigt, da es keinen Trigger für das Fenster gibt.
Leider heissen Deine Shutters alle xxx.Position, was nun dazu führt, dass im Log immer nur "Position" als Shutter angegeben wird - das macht das Debugging schwierig. Kannst Du diese umbenennen, so dass diese eindeutig werden?
Grundsätzlich scheinen aber alle 3 neuen Positionen am Abend auf down "gesetzt" zu werden und der Rollo müsste eigentlich fahren.
Kannst bitte mal prüfen, ob in den "Schaltern" für "autoDown" (Shuttercontrol - shutters-autoDown) beim entsprechenden Rollo auch ein "true" drinne steht? wenn nein, bitte dieses auf "true" stellen.
.. wenn auch das ok ist, bitte mal prüfen, ob Du wirklich das richtige Objekt gewählt hast und wenn da im Pfad shelly.0.SHSW-25#483FDA8DCA84#1.Shutter.Position mal die Position von Hand eingibst, ob dann der Rollo auch wirklich fährt.
Bin gespannt ob es so lösen kannst.
Viel Erfolg!

Edit:
Was ich noch gesehen habe. Du hast "LateDown": true, und somit wurde er am Abend um 22:15 auf "down" gesetzt. Deshalb auch das "down" im Status am Morgen.
Stelle bitte sicher, das zum Zeitpunkt wo der Zeittrigger kommt, das Objekt shuttercontrol.0.control.autoLiving= true ist. Du verwendest "Living-Auto" für up und down.

@m-m said in Test Adapter shuttercontrol v1.1.x:

Vorweg: Heute Abend sind in Abwesenheit auch wieder alle Rollläden richtig gefahren. Zuerst für das Fenster ohne Kontakt, dann Terrasse links und dann Terrasse rechts:

Sehr gut! Somit stimmt ja fast alles.

Ja, in autoDown steht true drin. Ich habe aber nur ein Objekt, wahrscheinlich weil ich alle shutter auf autoLiving gestellt habe (für Öffnen und Schließen).

Nicht ganz, dass Du hier nur ein Objekt hast liegt daran, dass alle Deine Rollos "Position" heissen. Ansonsten würde für jeden Rollo weitere Steuer- und ein Statusobjekt angelegt, welches Du dann von "aussen" beeinflussen kannst.

Bezüglich des Namens: Das Objekt bzw. die Objekt-ID heißt ja:

shelly.0.SHSW-25#483FDA8DCA84#1.Shutter.Position

Wäre es nicht besser, den Objektnamen dann direkt hinter dem Adapter auszulesen? Das wäre dann

SHSW-25#483FDA8DCA84#1

und damit sehr eindeutig. Ich weiß nicht was passiert, wenn ich "Position" umbenenne. Aufgrund des Startzeitpunkt weiß ich aber, wann welcher Rollladen getriggert wurde da die Reihenfolge in der Konfiguration ja festgelegt ist.

Das ist anscheinend nur beim Shelly so. Ich habe KNX und da sieht die Struktur ganz anders aus. Der Shuttercontrol Programmierer kann sich also nicht darauf verlassen, dass andere Adapter auf höherer Ebene eine Eindeutigkeit erzeugen. Also halten sich alle an die Konvention, dass die Eindeutigkeit zum einen über den ganzen Pfad gegeben ist und Adapter intern, dass der letzte Ausdruck nach dem "." im Pfad ebenfalls eindeutig ist. (ist ja im Filesystem auch so - in einem Ordner kann ein Filename nur einmal existieren, sonst wirds überschrieben). Das ist auch der Grund, warum es bei dir überhaupt läuft.
Ich denke es gibt hier einige, welche die Shelly nutzen und dir evtl einen Tipp geben können, wie die Objekte korrekt benannt und verwendet werden sollen.
Ich empfehle Dir, die Objekte ".Position" umzubenennen und der Klarheithalber irgendwie nach dem Fenster zu benennen. Damit hälst du Dir allfälligen "Ärger" mit Konflikten vom Hals.
Viel Erfolg!

@simatec
@Homoran
Danke euch zweien für eure wertvolle und tolle Arbeit.
Auch ich habe das gleiche Problem mit dem GoogleDrive Zugriff, nachdem ich Backitup nach längerem wieder mal auf den neusten Stand gebracht habe.
Ich weiss nicht genau, was euch Google da aktuell erzählt aber aus einem völlig anderen Bereich habe ich folgende Info aufgeschnappt:

Google Drive:
Achtung: Bei der Verwendung von Google Drive wird aktuell der Hinweise App blockiert angezeigt. Das liegt daran, dass die App das Limit von 100 Usern bei Google Drive erreicht. Jetzt können keine weitere Anwender hinzugefügt werden bis Google die App verifiziert hat.

Offenbar muss der Entwickler nun eine erneute Verifizierung bei Google beantragen und den gesamten Prozess nochmals durchlaufen.
Evtl hilft das euch weiter bei der Diskussion mit Google.
Ich persönlich habe den Eindruck, dass mit der Einführung/Umstrukturierung von Googles App-Zentrale in den Google Workspace mit der dazugehörigen App Verwaltung, bei Google so einiges übelst schief gelaufen ist.
Wünsche euch viel Erfolg mit Google.
Bis auf weiteres schreibt BackitUp bei mir halt an einen anderen Ort.
Danke euch für eure Unterstützung!

@lackylacky
Ja richtig, Shuttercontrol werkelt fast perfekt für mich.
Habe soeben das Handbuch Deines Aktors angeschaut und der tickt in der Tat anders. Offensichtlich habe ich Jalousien mit ‚Arbeitspunkt‘ während Dein Aktor für Jalousien ohne ‚Arbeitspunkt‘ ist. Deshalb auch das Nachführen der Höhe was bei solchen Jalousien auch korrekt ist.
Was ich aber gelesen habe ist, dass der Aktor das Lamellenobjekt nicht neu sendet, wenn es gleich bleibt. Das gäbe dir die Möglichkeit, als momentanen Workaround, zuerst die Lamellenpos. Und dann die die Höhe durch SC schreiben zu lassen. Versuche mal die Reihenfolge in der Liste zu tauschen und wähle eine Verzögerung der Fahrten damit die Lamellen fertig positioniert werden bevor die Höhe gesendet wird. Dann sollte die Pos von deinem Aktor nicht 2mal gesendet werden. 100% sicher bin ich aber nicht, ob SC das immer entlang der Liste abarbeitet, wenn gleichzeitig mehrere Objekte angesteuert werden.
Dieses Verhalten ist aber ein wichtiger Punkt für eine zukünftige Jalousie Unterstützung

@lackylacky
Interessant, benutzte auch KNX Aktoren, aber von ABB. Die senden nur einen Status an dem Objekt zurück, wobes auch eine Änderung gegeben hat. Wenn ich also nur die Lamellen bewege, dann wird auch nur das Lamellen Objekt geupdatet. Das Höhen Objekt bleibt ohne Update.
Bei meinen Jalousien passt das auch, da beim verstellen der Lamellen an den Bändern für die Höhe nicht gezogen wird, die Lamellen bleiben im Drehpunkt also gleich hoch.
Sag mal, um wieviel ändert bei Dir die Höhe, wenn die Lamellen von Zu auf waagerecht stellst?
Ich fürchte, da hab ich noch ein paar Denksport Aufgaben vor mir

@lackylacky
Wenn ich dich richtig verstehe, hast Du einen Jalousie Aktor mit zwei Objekten, wobei aber das Höhen-Objekt von der Position der Lamellen abhängt? Sprich, die Höhe verändert sich, wenn die Lamelle bewegt wird. Korrekt?
Dies kann Shuttercontrol aktuell nicht unterstützen. Shuttercontrol erwartet nach der Zeit zur Überprüfung der Position, dass am Ende der Rollo oder die Jalousie diejenige Position zurückmeldet, wo er sie "hin beordert" hat. Also zb. auf die konfigurierte DOWN Position.

Nachdem @simatec mit den vergangenen Releases diverse Umbauten am Fundament von Shuttercontrol gemacht hat (Danke vielmals @simatec für die Vorarbeit!!), habe ich es für mich nun mal gewagt, die Erweiterung für Jalousieen für Shuttercontrol in Angriff zu nehmen.
Deshalb bin ich aktuell auf der Suche nach verschiedenen Jalousie Aktor Typen und versuche dann deren Verhalten zu verstehen, um die Anforderungen an Shuttercontrol besser beschreiben zu können. Meine Aktoren sind da sehr simpel - 2 getrennte Objekte für Höhe und Lamelle, Werte je 0-255. Der Rest erledigt er Aktor selbst.
Um möglichst viele Aktoren unterstützen zu können, bräuchte ich den genauen Aktor Typ den Du im Einsatz hast, sowie eine gute Beschreibung (Datenblatt, Handbuch oder von Dir erklärt) wie dieser Aktor genau tickt und wie sich dessen Objekte in welchen Fällen Verhalten.
Super wäre, wenn wir die Detailanforderungen gleich im dazu erstellten Issue https://github.com/simatec/ioBroker.shuttercontrol/issues/56 dokumentieren können.
Wärst Du dabei mich zu unterstützen?

RoFrie created this issue in simatec/ioBroker.shuttercontrol

closed Jalousien #56

@xbit
Wie gesagt,
Wenn der Rollo zu ist und dann der Frostalarm kommt, fährt Shuttercontol aktiv auf den Frost Level.
Wenn Frostalarm aktiv ist und dann automatisch geschlossen wird, fährt er nur bis zum Frostlevel.
Beachte auch, dass beim Auswerten der Temperatur genügend Hysterese gibst, damit er bei 0,1C „Flattern“ nicht dauernd auf und zu fährt.
Der Frostalarm verhindert das Fahren vom Rollo nicht!

@xbit
Oh, ich vermute da gibt’s ein Missverständnis.
Der Frostalarm ist nicht so konzipiert wie du ihn anwendest. Er verhindert das Fahren nicht, sondern ist dazu gedacht, dass bei Frostgefahr nicht ganz geschlossen wird, um ein Festfrieren der Rollos unten am Fensterbrett zu verhindern. Er fährt aber am Morgen normal hoch.
In deinem Fall würde ich eher empfehlen mittels script den AutoUP Datenpunkt bei Frost auf false zu setzen. Damit verhinderst, dass Shuttercontol am Morgen den Rollo überhaupt automatisch bewegt.

@xbit
Hi, in deinem Screenshot oben hast du alle anderen Alarme auf 100 - also auf Offen. Der Frost ist aber auf 0 - also wenn ich dich jetzt richtig verstanden habe auf Zu. Besser wäre aber doch, wenn sie nicht ganz zu fahren, also zb. 90% zu was dann bei dir auf 10 wäre.
Hast da mal mit Werten geprüft, welche nicht Endanschlag sind?

@xbit
Hi, ich nutze den Windalarm2, welchen ich auch manuell auslösen kann. Soeben getestet und tut bei mir einwandfrei.
Fürchte, dass bei deiner Config oder an den vom Aktor zurück gemeldeten Höhen evtl was nicht korrekt ist.
Stelle sonst mal die Config als exporiertes File und ein debug log hier rein, dann kann Dir sicher jemand helfen.

@homoran
Interessant!
der Logtext mit "save current height after State Check:" wird im ganzen Shuttercontrol Code nur an einer einzigen Stelle geschmissen - und das ist nach dem Überprüfen der Rollo Position...
Wenn Deine Theorie mit dem Trigger für das gekippte Fenster stimmt, dann müsste dies im Log auch ersichtlich sein. Es ist so, dass an dieser Stelle, wenn dieses Signal wirklich rein kommt, der Shuttercontrol die aktuell gesetzte Höhe ( EDIT: Es wird die aktuell gemeldete Position genommen) wiederum in den Trigger speichert und dann auf die gekippt Position fahren will. Kurz danach müsste dann das Geschlossen kommen, womit er den im Trigger gespeicherten Wert wieder holt und dahin (in Deinem Fall Down oder eben nicht Down) fährt.

@homoran
Ich vermute aufgrund vom Log, dass nach dem Positions-Check wieder ein (alter) Wert vom Aktor gesendet wird und deshalb Shuttercontrol interpretiert, dass der Rollo bewegt wurde

Kannst da mal prüfen, was für eine Position da effektiv zu dem Zeitpunkt vom Aktor zurück gemeldet wird?
EDIT:
Der vermutete Bug im Trigger war ein "Sturm im Wasserglas".
Es gibt aber dev. einen Bug im Alarmhandling im Zusammenhang mit dem Manu_Mode gefunden. Werde da für einen Fix an @simatec senden.