UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Homoran]

@christoph1337 sagte in Test Adapter shuttercontrol v1.2.x:

Warum ist due Außentemperatur nicht teil meiner Beschattung?

siehe @tobitobsta s Antwort und in deinem pulldown in der obersten Zeile

@christoph1337 sagte in Test Adapter shuttercontrol v1.2.x:

Die Gradzahl hab ich mit dem Handy ermittelt.

dann ist das falsch!
0/360 Grad ist Norden, 90 Osten, 180 Süden und 270 Westen.
SW wäre dann etwa 225°

ggf. auch die 241, die dein Handyscreenshot zeigt.
Aber du hast 335° in der Konfiguration eingegeben

[Christoph1337]

@homoran

AAhhh! Ich hab das Dropdown oben garnicht als Dropdown identifiziert gehabt. Dann ist auch klar, warum das nicht ging^^

Und danke für die Gradzahl. Ich werde damit mal testen!

[Homoran]

@christoph1337 sagte in Test Adapter shuttercontrol v1.2.x:

Dann ist auch klar, warum das nicht ging

[FoxRo]

@strago said in Test Adapter shuttercontrol v1.2.x:

@foxro

Das gleiche Problem habe ich leider auch feststellen müssen.

Wenn der angefahrene Sollwert nicht dem entspricht was vom Shuttercontrol vorgegeben wird, ist der Status der Rolladen/Raffstore Manu_Mode.
Leider greift die Einstellung:

nicht im Beschattungsmodus.

--> Bei den Raffstore verstelle ich den Winkel, und habe somit immer einen leicht abweichenden Sollwert als jenen der vom Shuttercontrol vorgegeben wird. Dadurch immer Manu_Mode im Status.

Bei den Rolladen ist der Sollwert gleich der Vorgabe und der Status bleibt Sun_Protect

Shuttercontrol unterstützt nur Raffstore, welche mit einem Aktor betrieben werden, welcher zwei Objekte (Höhe, Lamellenwinkel) besitzen. Wenn da von "Aussen" gesteuert zurück fährst um die Lamelle zu öffnen, dann stimmt logischerweise der Soll nicht mehr mit dem Ist- Wert, wodurch Shuttercontrol davon ausgeht, dass manuell eingegriffen wurde. Ich denke nicht, dass da die Extra Einstellung zum Zeitverzögerten aktualisieren alleine was hilft.
Das Problem ist dies, dass er auf Manu_Mode geht, sobald ein Statusupdate auf dem Positionsobjekt kommt, welches nicht der ursprünglichen Höhe, aber auch nicht der anzufahrenden Sollposition entspricht.
Wenn Du dem also entgegenwirken willst, hast evtl eine Chance, indem mit deinem Script die Position nicht gleich weitermeldest, sondern vorher auswertest, wohin er muss. zb. Wenn SunProtect Pos. angefordert wird, dass nicht die Position geschlossen und danach die neue Position Lamelle offen zurückmeldest, sondern erst am Schluss den Wert der zurückgefahrenen End Position zurück meldest. Hier stellst du dann die nötige Verzögerung in den Extraeinstellungen ein, damit er den nicht ganz erreichten Sollwert nach Ablauf der Zeit intern korrigiert.
Bin nicht sicher ob das wirklich funktioniert - eine gewisse Chance gibts aber.
Viel Erfolg!

[FoxRo]

@negalein said in Test Adapter shuttercontrol v1.2.x:

@foxro sagte in Test Adapter shuttercontrol v1.2.x:

Genau

Hi

Konntest du im Debog-Log was erkennen?

Hi
Sorry, hab grad recht viel um die Ohren, Privat wie auch Beruflich.
Habe mir dies mal angesehen und es sieht ja verdächtig danach aus, dass Dir der Rollo einen Streich spielt.
Wenn man das log Ansieht steht beim eintreten in SunProtect für Wohnzimmer folgendes:

Hier überprüft er ob er beschatten muss...

2021-06-12 12:25:35.574 - debug: shuttercontrol.0 (24894) Rollo Wohnzimmer: Check basis for sunprotect. Height:100 > HeightDownSun: 50 AND Height:100 == currentHeight:100 AND currentHeight:100 == heightUp:100
2021-06-12 12:25:35.574 - debug: shuttercontrol.0 (24894) Sunprotect for Rollo Wohnzimmer is active
2021-06-12 12:25:35.575 - debug: shuttercontrol.0 (24894) Temperature outside: 25.11 > 25 AND Light: undefined > 15

Hier wird dem Rollo der Auftrag erteilt, nach 50% zu fahren...

2021-06-12 12:25:35.575 - info: shuttercontrol.0 (24894) Set ID: Rollo Wohnzimmer value: 50%
2021-06-12 12:25:35.576 - debug: shuttercontrol.0 (24894) Sunprotect Rollo Wohnzimmer old height: 100% new height: 50%

Hier kommt vom Aktor die Rückmeldung, dass er bei 96% steht.

2021-06-12 12:25:37.421 - debug: shuttercontrol.0 (24894) Shutter state changed: Rollo Wohnzimmer old value = 100 new value = 96

Worauf Shuttercontrol damit reagiert, dass der Rollo offensichtlich manuell gestoppt wurde und setzt deshalb gleich den Manu_Mode...

2021-06-12 12:25:37.422 - debug: shuttercontrol.0 (24894) Rollo Wohnzimmer drived manually to 96. Old value = 100. New value = 96
2021-06-12 12:25:37.426 - debug: shuttercontrol.0 (24894) Rollo Wohnzimmer Updated trigger action to Manu_Mode to prevent moving after window close

Das hast Du auch sauber im Statuslog mit geloggt:

Manu_Mode true history.0 2021-06-12 12:40:37.434
Manu_Mode true shuttercontrol.0 2021-06-12 12:25:37.427
sunProtect true shuttercontrol.0 2021-06-12 12:25:35.644

Kurz darauf meldet ein weiteres Positionsupdate vom Aktor, dass der Rollo nun bei 50% angekommen ist...

2021-06-12 12:25:51.704 - debug: shuttercontrol.0 (24894) Shutter state changed: Rollo Wohnzimmer old value = 100 new value = 50
2021-06-12 12:25:51.704 - debug: shuttercontrol.0 (24894) Rollo Wohnzimmer Old value = 100. New value = 50. automatic is active

Warum hier gemeldet wird, dass die Automatik noch aktiv sei verstehe ich im Moment noch nicht, sie ist es nämlich nicht mehr, da während des Runterfahrens ein, aus Sicht von Shuttercontrol, manueller Zwischenstopp eingelegt wurde.

Die Extra-Einstellung zum überprüfen des Rollo Status kann so nicht ziehen, da immer nach dem Fahrauftrag auf die letzte Rückmeldung gewartet wird und dann aktualisiert wird. Wenn die letzte Rückmeldung nicht ganz mit dem Soll-Wert übereinstimmt, wird an dieser Stelle dann korrigiert. Wenn aber während es Fahrens ein Wert aus dem "nichts" als Update daher kommt, dann geht Shuttercontrol davon aus, dass der Rollo nun da steht.

Weisst Du, warum der Aktor hier einen solchen (sorry) "Fantasie Wert" während dem Fahren liefert?

Sorry, aber mir fällt es schwer, dir an dieser Stelle noch viel weiter helfen zu können.
Bei Fragen zum Shuttercontrol und sein (inneres) Verhalten kann ich Dir aber gerne weiterhelfen wenns nochmals nötig wird.
Viel Erfolg!

[Negalein]

@foxro sagte in Test Adapter shuttercontrol v1.2.x:

Weisst Du, warum der Aktor hier einen solchen (sorry) "Fantasie Wert" während dem Fahren liefert?

Danke für deine ausführliche Antwort.

Ja, das mit den Werten ist mir in Vis schon aufgefallen, wenn ein Rollo gefahren wird (zB von 100 auf 70), wird immer ein zusätzlicher Wert solange angezeigt, bis er auf der gewünschten Position angekommen ist (zB Ist 100, Soll 70; in der Vis bleibt dann zB 97 solange stehen, bis er auf 70 angekommen ist; erst dann stehen die 70 dort).

Ich werde mal @foxriver76 fragen. Er ist am Homematic-Adapter beteiligt.

[Negalein]

@foxro sagte in Test Adapter shuttercontrol v1.2.x:

Sorry, aber mir fällt es schwer, dir an dieser Stelle noch viel weiter helfen zu können.

Hallo

Hab gleich Antwort von @foxriver76 erhalten.

CCU meldet den Wert so und glaube der DP Working wird auf true gesetzt so lange er fährt. Ich denke über den Working Dp sollte man sagen können, dass es gerade ne aktive Fahrt ist und kein endzustand. Ich denke der Hauptgrund dass gesendet wird von CCU ist auch dieser dp aber der Rollo ist halt schon losgefahren und daher so ein krummer Wert

Eventuell kann @simatec dies als Kontrolle in den Adapter einbauen.
Sind ja sicher einige mit Homematic Komponenten.

Bei den Extra-Einstellungen bin ich schon auf 120. Das half auch nicht.

[FoxRo]

@negalein said in Test Adapter shuttercontrol v1.2.x:

Eventuell kann @simatec dies als Kontrolle in den Adapter einbauen.
Sind ja sicher einige mit Homematic Komponenten.

Möchte hier keinen Streit vom Zaun brechen - ist eher ein wenig "Religion", muss aber anfügen, so wie ich das iOBroker Konzept bis jetzt verstehe, und wie andere Adapter ihre Endgeräte Spezifika in iOBroker integrieren, dann müsste dies der HM Adapter übernehmen und nicht jeder Adapter, welcher möglicherweise HM Geräte steuert.
Da hält sich zb. der KNX Adapter penibel daran, keine KNX spezifischen Verhaltensweisen in iOBroker rein zu bringen.
Aus meiner Sicht müsste also der HM Adapter dafür sorgen, dass es auf dem Positions DP kein Update gibt, solange der Working DP true ist. Denn wie @foxriver76 selbst schreibt, sind die Werte am Positions DP während dem Fahren ungültig. Ich meinte hier schon Logs gesehen zu haben, wo es während dem Fahren fortlaufend zu Updates kam.

Wie geschrieben, die Extra-Einstellung wird an dieser Stelle ausgehebelt, da der DP für die Höhe von Shuttercontrol sogenannt "abonniert" wird und deshalb Änderungen da drauf direkt und ohne Delay in die Logik mit einbezogen werden. Wenn man diese Änderungen durch die Extra-Settings ganz ausblenden würde, dann wäre Shuttercontrol auf dem DP während dieser Extra-Einstellungen Zeit bei jeder Fahrt komplett blind und würde da nichts mit bekommen, egal was passiert. Dh. die Extra-Einstellungen würden wohl plötzlich zu einem kritischen "Fine-Tune" Element. Gute Ideen wären also gefragt, wenn der HM Adapter dies nicht übernimmt

Projektleiter von Shuttercontrol ist und bleibt @simatec und deshalb überlasse ich es ihm, ob und wie er zu diesem Verhalten eine Lösung anbieten will.

[Negalein]

@foxro sagte in Test Adapter shuttercontrol v1.2.x:

muss aber anfügen, so wie ich das iOBroker Konzept bis jetzt verstehe, und wie andere Adapter ihre Endgeräte Spezifika in iOBroker integrieren, dann müsste dies der HM Adapter übernehmen und nicht jeder Adapter, welcher möglicherweise HM Geräte steuert.

Aus meiner Sicht müsste also der HM Adapter dafür sorgen, dass es auf dem Positions DP kein Update gibt, solange der Working DP true ist.

Da bin ich voll deiner Meinung.
Wenn es beim KNX-Adapter geht, kann es @foxriver76 vielleicht doch im HM-Adapter irgendwie bewerkstelligen.
Es betrifft bestimmt noch andere Adapter oder in Zukunft welche, die mit dem Problem zu kämpfen haben.

Ich bin kein Entwickler, kenne mich also 0 aus ob das möglich ist.
Muss oder kann nur @foxriver76 entscheiden.

[Kuddel]

Hallo zusammen,

aktuell habe ich meine Rollo-Steuerung per Blockly realisiert und wollte mir jetzt mal diesen Adaopter anschauen.

Bevor ich anfange zu testen, habe ich direkt mal eine Frage:

Kann man Fenstersensoren integrieren, damit die ROllos nur auf z.B. 25% fahren, wenn ein Fenster gekippt ist?

[bishop]

@kuddel
ja, ist möglich!

[da_Woody]

@kuddel die frage ist eher umgekehrt, können deine rollos alles das, was shuttercontrol kann!

[Muchul]

@da_woody
Welches Rollo kann das denn?
Grinsduckundwech

[tobitobsta]

nochmal eine Frage zu den Shuttercontrol States:

soll es denn eigentlich so sein, dass jedes manuelle Hochfahren auf das Level 100%, den Status auf "none" ziehen soll und somit Sunprotect funktionieren sollte?

Bei mir ist das am Tag nur der Fall, wenn morgens das erste manuelle "hoch" gesetzt wird. Wenn im laufe des Tages einmal manuell runter und dann wieder manuell hoch (auf 100%) dann bleibt der State "ManuMode" (und SunProtect geht nicht mehr)
Soll das so? Oder mache ich was falsch? Ist das ein Bug?

[Kuddel]

@bishop okay, habe die Einstellung gefunden.

Problem ist nur, dass ich teilweise pro Rollo zwei Fenster und zwei Densoren habe.

Kann man auch zwei Sensoren pro Rollo-Aktor hinterlegen?

[da_Woody]

@tobitobsta sagte in Test Adapter shuttercontrol v1.2.x:

"ManuMode"

an dem problem wird im moment rumgerätselt, wie man in diversen postings lesen kann...

[da_Woody]

@kuddel sagte in Test Adapter shuttercontrol v1.2.x:

Kann man auch zwei Sensoren pro Rollo-Aktor hinterlegen?

grundsätzlich mal nicht. wird ohne trixxen nicht lösbar sein. (blockly für beide sensoren, die einen DP füllen.)

[IT-Veteran]

@negalein Hallo zusammen,

ich werde das Gefühl nicht los, dass die Ursache (mal wieder) an der Implementierung der Homematic Aktoren liegt. Ich hatte das hier schon mal thematisiert.

Die HmIP-Aktoren BROLL und FROLL benutzen den Kanal 3, um den IST-Zustand darzustellen. Die Kanäle 4, 5 und 6 werden benutzt, um SOLL zu setzen. Da Shuttercontrol nur einen Kanal verwenden kann, muss dies logischerweise 4, 5 oder 6 sein (ich verwende im Folgenden mal Kanal 4). Und genau da fängt das Problem an, denn Kanal 4 und Kanal 3 werden in der CCU nicht synchronisiert. Der richtige Wert nach dem Stopp des Rolladens steht deshalb ausschließlich in Kanal 3. In Kanal 4 steht der Sollwert, auch, wenn die Fahrt aus beliebigem Grund vorher gestoppt wurde. Hinzu kommt, dass nach dem Losfahren die Werte in Kanal 3 zufällig wechseln können. Nachdem der Rolladen angehalten hat, dauert es einige Zeit, bis in Kanal 3 der IST-Wert eingetragen wird.

Ich habe mal versucht, das durch ein kleines Skript in den Griff zu bekommen, das einfach den Status des Rolladens überprüft und, sobald dieser angehalten hat, mit einer Verzögerung von einigen Sekunden den Wert aus Kanal 3 in den Kanal 4 schreibt. Das hat jedoch aus nicht nachvollziehbaren Gründen nur teilweise funktioniert, weshalb ich es wieder aufgegeben habe.

Wollte man das Thema zuverlässig lösen, so müssten m.E. in Shuttercontrol zwei Kanäle (IST=3, SOLL=4 oder 5 oder 6) verwendet werden. Wie aufwändig diese Änderung wäre, kann ich natürlich nicht einmal ahnen.

[Muchul]

@it-veteran
Müsste sich das nicht durch Alias'e umgehen lassen?

[simatec]

@muchul
Genau durch Alias wurde das Thema hier schon einige male beschrieben. Für den Aktor einen Alias anlegen, indem IST und SOLL Werte des Aktors verknüpft werden und es läuft in shuttercontrol.
Im Prinzip wurde Alias genau für solche Anwendungen geschaffen