Steuerung der Rollläden

Dieses Thema ist eine Fortsetzung des GitHub-Issues:

@AlexTrovato wir können hier auf Französisch darüber sprechen, denn ich habe das Gefühl, dass wir uns dort unten auf Englisch nicht verstehen :smiley:

Tatsächlich geht es darum, Informationen über die Funktionen des Rollladens zu speichern.

Stellen wir uns drei hypothetische Marken von Rollläden vor:

  • Die erste wird mit einer Fernbedienung mit drei Tasten gesteuert: Öffnen der Rollläden zu 100%, Öffnen zu 50% und Öffnen zu 0% (geschlossene Position)

  • Die zweite wird mit einer Fernbedienung mit einer Taste nach oben und einer Taste nach unten gesteuert.

  • Die dritte wird mit einer Fernbedienung mit fünf Tasten gesteuert: 0%, 25%, 50%, 75%, 100%

Frage:

Wie kann man das in Gladys modellieren?

Wenn ich „das“ sage, meine ich nicht das Endergebnis. Ja, das Endergebnis könnte eine ganze Zahl von 0 bis 100 sein, die dem Öffnungsprozentsatz des Rollladens entspricht. Ich spreche über die Information, die besagt: „Dieser Rollladen hat diese Funktion.“

Denn in der Benutzeroberfläche wird jeder Rollladen einen anderen Typ von Tasten haben, aber irgendwo in der Datenbank muss diese Information vorhanden sein.

Eine Möglichkeit, die ich sehe, ist die Lösung im Einzelfall. Wir erstellen Kategorien/Typ-Paare für jeden Typ von Rollläden. Ich denke, das ist die Lösung, die am ehesten der Philosophie von Gladys 4 entspricht :slight_smile:

Aber es gibt vielleicht andere Möglichkeiten, und vor allem müssen wir sehen, wie sich diese Frage auf andere Problemstellungen anwenden lässt.

Ich hoffe, du verstehst, was ich meine :grin: Gute Idee übrigens, sich anzusehen, wie andere es machen!

Ok, ich verstehe besser.
Als erster Entwurf würde ich sagen, eine Gerätekategorie pro „Rolladensystem“. Aber das könnte ein bisschen schwerwiegend sein.
Unter Berücksichtigung, dass dies mehrere Gerätetypen betreffen wird.
Alternativ ein „Param / Optionen“-System auf der Gerätefunktion.

Aber es ist besser, sich gut zu überlegen.

Also hätte ein Rollladen nur ein einziges Gerätemerkmal? Und dieses Gerätemerkmal hätte die Kategorie + den Typ, der seiner Verwendung entspricht, und wir würden im Zustand eine ganze Zahl von 0 bis 100 speichern, die dem Rollladenstand entspricht? Das könnte funktionieren.

Es stimmt, das ist vielleicht etwas schwergewichtig, aber ich bevorzuge diesen anfänglichen Ansatz, solange wir nicht zu viel Erfahrung mit Rollläden haben, anstatt mit dem ultra-modularen Ansatz zu beginnen, ohne zu verstehen und einfach irgendetwas zu machen :slight_smile:

Ich bevorzuge es, von ultra-spezifisch zu allgemein zu gehen, anstatt umgekehrt.

Eine Frage, die mir in den Sinn kommt, ist, wie man dann in der UI im MQTT-Service erklärt, wofür jedes Merkmal steht? Da wir nur den Namen anzeigen, muss der Name ausreichend aussagekräftig sein, um zu erklären „dann entspricht dieses Merkmal dem Rollladen bei 0, 50, 100%“ ^^ eine Idee?

UI UI…
wie kann ich eine erklärende Box (Beschreibung der Funktion) beim Auswählen (oder Hovern) in der Dropdown anzeigen lassen… ich sehe das nicht so richtig.

Wenn ich mich einmischen darf, gibt es sogar Fernbedienungen mit 3 Funktionen:

  • Hoch
  • Runter
  • Stop, um das Hoch- oder Runterfahren des Rollos zu stoppen (man weiß also nicht, wie weit das Rollo geöffnet ist)

Das macht die Sache vielleicht ein bisschen komplexer :slight_smile:

Hallo,
Ja, das ist oft so, mit einer Lernphase.
Das Problem mit diesem Prinzip ist, dass die Auf- und Abfahrtszeiten nicht unbedingt gleich sind.
Der Abstieg ist schneller als der Aufstieg, weil die Masse des VR ihn beim Abstieg mitzieht.
Allerdings ist der Unterschied nicht groß.
In Domoticz gibt es einen Parameter Motor Operation Time

Das habe ich bei mir zu Hause und das ist am weitesten verbreitet, wenn es um manuelle Schalter geht (Schaltmodelle).

Außerdem gibt es Modelle für vernetzte Schalter (4e Gen+), die den Öffnungsgrad basierend auf einer Zeitsteuerung steuern.
Die Idee ist, die Auf- und Abfahrtszeiten anzugeben und dann kann man, basierend auf diesen Zeiten und der Richtung des Befehls, den Rollladen teilweise öffnen/schließen.

In der Anwendung gibt es 2 Arten von Befehlen (hoch/stop/runter und Schieberegler):

Hallo,

ich habe eine kleine ESP8266-Schaltung entwickelt, um Rollläden mit einem 3-Positionen-Schalter oder über Gladys zu steuern. Zu Beginn initialisiere ich die Zeiten für das Öffnen und Schließen. Bei jedem Zustandswechsel des Rollladens sende ich die Position in % (bei meiner Schaltung ist es umgekehrt: 100% bedeutet geschlossen, 0% geöffnet).
Ich denke, dass es nicht Gladys’ Aufgabe ist, die Position des Rollladens zu berechnen, sondern dass der Schalter die Position zurückgeben sollte.

Beispiel:
Ich fordere über Gladys an, den Rollladen auf 25% zu öffnen, entscheide aber aufgrund der Sonneneinstrahlung mit Hilfe des Wandschalters, ihn bei 50% anzuhalten.
Ich drücke den Stopp-Knopf.
Bis Gladys die Information über den Stopp erhält, wird Gladys’ Berechnung fehlerhaft sein.
Es wird eine Abweichung zwischen der tatsächlichen Position und der von Gladys geschätzten Position geben.

Seit 9 Monaten hat sich das Thema nicht bewegt, sucht ihr immer noch nach einer Lösung?

Bei jeedom ist es einfach: Hoch/Runter/Stopp, der Prozentsatz funktioniert nicht gut, daher nicht von Grund auf integriert! Der Prozentsatz wird nämlich in Abhängigkeit von der Zeit berechnet, die der Rollladen benötigt, um von einem Punkt zum anderen zu fahren… nur dass alle Rollladen unterschiedlich sind, selbst wenn sie mit demselben Motor verwendet werden.

Vielleicht habe ich nicht verstanden, woran diese Funktion blockiert ist?

Ich denke, es ist nur eine Frage der Zeit, denn in den letzten 9 Monaten habe ich mich auf die am häufigsten geforderten Funktionen konzentriert (Multi-User, Multi-Dashboard, Szenen, Zonen, Anwesenheit, Google Home-Integration, also alles, was 2021 so entwickelt wurde :D). Da diese Funktion nur 2 Stimmen hatte, war sie natürlich weniger priorisiert :slight_smile:

Ich bin aber immer offen für Diskussionen, wenn jemand eine Überlegung/Entwicklung wieder aufgreifen möchte.

Ich habe deshalb abgestimmt, weil ich nicht weiß, wie ich meine Rollläden in Node Red in Gladys verwalten soll.

Es gibt verschiedene Arten von Jalousien:

  • solche mit Rückmeldung und damit Prozentsteuerung
  • solche ohne Rückmeldung, also 0 - 100%

Ich habe ein Mockup mit beiden erstellt, wobei wir die Prozentangabe nur für diejenigen verwenden, die sie unterstützen:

Das klingt gut! Super Mockup übrigens :slight_smile: Vielleicht könnte der quadratische, gefüllte « Stopp »-Button noch etwas verbessert werden?

@syper Hast du die Fähigkeiten, um die Entwicklung durchzuführen?

Ja, ob quadratischer Umriss …
Gibt es einen Leitfaden für die Icons? Oder eine Bibliothek?

Bei den Fähigkeiten habe ich etwas Webentwicklung, aber kein React und sehr wenig JS.

Also im Grunde bin ich Frontend mit HTML/CSS/PHP, ich habe gesehen, dass es dem Frontend von Bootstrap ähnlich ist, aber ich weiß nicht, ob ich die Zeit dafür habe …

Ich nehme an, es gibt auch Backend? Ich habe nicht gesehen, wo alles bei Gladys liegt. (Schade, dass es keine Dokumentation mit der Verzeichnisstruktur gibt).

Ja, wir verwenden feathericon!

Ich empfehle dir mehrere Videos, die ich zu diesem Thema gemacht habe:

Die technische Präsentation von Gladys 4:

Ein Live-Coding letzte Woche:

Das kann dir eine Idee vom Projekt geben :slight_smile:

Danach ist das Beste, eine Instanz lokal zu starten. Du hast das gesamte Frontend im Ordner « front » und das gesamte Backend im Ordner « server » (Es ist Node.js)

Nichts wirklich Kompliziertes, und ich bin immer da, um zu helfen, falls du Probleme hast!


Mit den richtigen Icons :smiley:

Ich werde es versuchen, sobald ich etwas Zeit habe :wink:

Für die ohne Rückmeldung sollte man in Gladys Folgendes einstellen können:

  • eine maximale Zeit für das vollständige Herunterfahren
  • eine maximale Zeit für das teilweise Herunterfahren (wenn man die Striche sieht)
  • eine maximale Zeit für das vollständige Hochfahren
  • eine Zeit bei 50% des teilweisen Hochfahrens
  • eine maximale Zeit für das teilweise Hochfahren (wenn man die Striche sieht)
  • eine Zeit bei 50% des teilweisen Herunterfahrens
    Algorithmusmäßig würde das bedeuten:
    Öffnen auf 100% = maximale Hochfahrzeit + 2s (anpassbar) dann Rücksetzen der Position auf 100%
    Schließen auf 100% = maximale Herunterfahrzeit + 2s (anpassbar) dann Rücksetzen der Position auf 0%
    Ausgehend von einer vollständigen Öffnung oder einem vollständigen Schließen hat man immer eine exakt zurückgesetzte Position
    Danach, wenn man eine Öffnung auf X% möchte, ist es die Zeit bei 50% plus oder minus (Zeit bei 50%/50) * die zu erreichende Position in % – man erhält eine ungefähre Position, die doch recht zuverlässig sein sollte, oder?

Hallo hier,
weiß jemand, ob das Thema vorankommt? Ob es von jemandem bearbeitet wird?
Ich sehe, dass sich die Nachfrage beim Dienst z2m erhöht, mit Modellen mit OPEN/STOP/CLOSE (3 Aktionen).

@AlexTrovato Soweit ich weiß, arbeitet niemand an diesem Thema.

Meiner Meinung nach verliert man nichts, wenn man mit der Entwicklung für einen Rollladen-Typ beginnt (z. B. Öffnen/Stoppen/Schließen), es ist nicht nötig, alles auf einmal zu machen. Es ist schon cool, einen Typ zu haben.

Ich stimme hier zu, denn ich habe drei Rollläden mit ihren Zigbee-Schaltern (die unter z2m gut erkannt werden) und die warten nur darauf, in Gladys zu landen! :slight_smile: