Automatikbeschattung fährt seit 15.0 nicht mehr ganz zu nach Beschattungsposition

[Labmaster]

Ich befürchte, daß mittlerweile die Firmware des Minserver so aufgeblasen und dadurch nicht mehr Echtzeitfähig ist, daß so spezielle Anforderungen wie Zeitmessungen und Ansteuerungen im Sub Millisekunden Bereich (und das ist leider bei Raffstores teils notwendig) einfach nicht mehr zuverlässig möglich sind.
Die ursprünglichen Entwickler haben damals (vermutlich eher aus der Hardwareentwicklung kommend) auf solchen Dinge noch achten können, bei einem größer werdenden Projekt und Projektteam kann so etwas aber echt ein Problem werden, vor allem wenn so etwas nicht ganzheitlich bedacht wir.
Ich kennen solche Probleme im Embeddedbereich leider nur zu gut.
Mal sehen ob hier die Kuh wirklich von Eis gebracht werden kann oder ob es bei Symptombekämpfung bleibt.

[rage302]

Hi Leute,
da jetzt die Config 15.3 released ist und im Changelog einiges zum Thema Shading steht, wollte ich fragen ob damit schon jemand eine Verbesserung unsers Problems erkennen konnte? ->


Der "Rdd" Workaround könnte zwar schon helfen, aber es ist trotzdem nur ein Workaround.

greetings rage

[frankenhooker]

Die 15.3 habe ich seit Freitag und seitdem schließen die Jalousien jeden Abend wie erwartet.

[Gerrit]

frankenhooker ohne Aktivierung von Rdd?

[frankenhooker]

Rdd wird temporär Abends vor Schließen per Logik eingeschaltet, nach 70s wieder aus.

[Benjamin G.]

Hallo zusammen,

da es hier offensichtlich zu Unklarheiten kam, liefere ich euch gerne ein paar Hintergrundinfos zu den vergangenen Updates.

Mit Version 15.0 haben wir einen Fehler behoben, der dafür sorgte, dass die Beschattung beim Schließen aus der Beschattungsposition doppelt so lange nach unten gefahren sind, wie beim Beschatten nach oben. Wenn die Beschattung dementsprechend nie geöffnet wurde, sondern lediglich von der geschlossenen in die Beschattungs-Position und wieder zurück gefahren wurden, „wanderte“ die Beschattung mit der Zeit nach unten. Die Totzeiten haben wir angeglichen, um das zu verhindern.

Da geht es nicht darum, dass der Miniserver zu aufgeblasen oder unser Projektteam zu klein wäre – es wurde einfach ein Fehler behoben. Diesen Fehler werden wir jetzt nicht wieder einführen. Der Parameter „Rdd“ ist dementsprechend kein Workaround, sondern eine Lösung, wodurch bestehende Beschattungen wieder möglichst einfach wie gewünscht fahren.

Ich hoffe die Erklärung hilft euch, unsere Beweggründe und Entscheidungen besser nachvollziehen zu können. 🙂

Liebe Grüße,
Benjamin

[Thomas M.]

Damals wurde das Aus der Referenzfahrt nach unten ja begründet, dass bei irgendjemanden (?) der Endschalter nicht funktionierte (falsch eingestellt oder gab es keinen?) und sich die Beschattung verkehrt herum aufgerollt hat und dabei die Aufhängung zerstört wurde.

So quasi Loxone sei schuld daran, dass jetzt die Aufhängung defekt ist.
Das fand ich ziemlich merkwürdig.

Ich bin jedenfalls sehr froh über Rdd, denn dadurch habe ich meinen workaround an jeder einzelnen Beschattung aus dem Projekt entfernen können.
Ich habe einige Fenster, bei denen ich von ganz geschlossen auf Bescahttung und wieder auf geschlossen fuhr.

Oder nach Stromausfall, ... glaubte der MS die Position war zu, in Wirklichkeit waren sie halb offen. Die Beschattung war nicht mehr runterzubekommen.
Ich musste den Baustein wegen dem "Mist" bügeln, also Taster "runter" 1:1 auf Relaisausgang "runter".

[rage302]

Danke Benjamin für die Erklärung. Es freut mich, dass sich hier Loxonauten einschalten.
Ich aktivere den "Rdd" Parameter und wenn ich das richtig verstanden habe, wird sich damit das Problem lösen.

greetings rage

[frankenhooker]

Endlich mal ne Erklärung wo es genau herkam. Bei uns war das genau das Thema, dass die Lamellen von zu auf waagerecht fahren und nur selten mal ganz hoch gefahren werden.

[Gerrit]

Benjamin G.
danke für die Infos, dann stochert man nicht im Dunklen!
Warum wurde nicht ein weiterer Zeitparameter verwendet, wenn als Ursache unterschiedliche Totzeiten diagnostiziert wurde? Weil für Kunden, die Fälle wie die beschriebenen haben ("Raffstor an einer bestimmten Position fix öffnen + schließen ohne zu wandern"), kommen am Ende ja nur Lösungen mit genauen Zeitangaben in Frage? Oder sollen solche Kunden dann spezielle Motoren verwenden, die identische Totzeiten haben? Mir scheint diese Kundengruppe auch eher die Ausnahme und nicht unbedingt der berechtigte Standard, nach denen die anderen Funktionen ausgerichtet werden sollten?

[Benjamin G.]

Weil wir Loxone so einfach wie möglich halten wollen und weil es so, wie es jetzt ist, funktioniert.

[Gerrit]

joa...sagen wir so, die hier tw. dargestellte Lösung der User den Parameter vor und nach der Aktion ein / auszuschalten finde ich nicht sehr smart. Also kommt ja immer drauf an was die Kunden mit einem Feature machen, das wird nicht automatisch die erhoffte einfache Lösung.
Und die Einstellmöglichkeiten die es sonst gibt an dem Baustein sprechen jetzt auch nicht unbedingt für "so einfach wie möglich", da wäre für mich als mögliche Lösung eher die gemeinsame Linie der anderen Parameter maßgebend. Und manchmal wäre Understament bei Aussagen auch eher angebracht...