IPX800-v5 in Gladys steuern

[cce66]

Ok also:

gladys/device/mqtt:commutateur/feature/mqtt:commutateur/state

wenn gladys veröffentlicht, ist das Topic auf Mosquitto gladys und es gibt Schlüssel
device/commutateur/feature
device/commutateur/state

gladys/master/device/mqtt:commutateur/feature/mqtt:commutateur/state

wenn gladys empfängt, ist das Topic auf Mosquitto immer noch gladys und es gibt Schlüssel
master/commutateur/feature
master/commutateur/state

@Shiftmaj

Im ersten Fall veröffentlicht Gladys es auf Gladys/device (für das Gerät). Im zweiten Fall ist es das Gerät, das auf Gladys/master veröffentlicht (diesmal für Gladys), um z. B. einen Status zurückzugeben.

Tatsächlich ist es die device/master-Seite (da wir keine Angabe zur Richtung der Datenübertragung haben), die verwirrt , slave/master (nicht ideal) oder publish/suscribe (kohärenter, da dies die Richtung der Datenübertragung implizit angibt, da „device“ und „master“ sowohl Master als auch Slave im Verhalten sind!)

@Shiftmaj

Die Position des Schalters auf dieser Seite ändert nichts an der Funktionsweise der beiden Adressen, es ist nur ein visuelles Element.

In diesem Fall denke ich, dass sich alle einig sind, dass die beiden Adressen standardmäßig angezeigt werden sollten und dass, wenn man „Ist dies ein Sensor?“ ankreuzt, nur die entsprechende Zeile angezeigt wird!
Tatsächlich muss man bei der Implementierung in Node-RED darauf achten, die richtige Zeile in die MQTT-Objekte einzutragen!

[Shiftmaj]

@cce66

Tatsächlich ist es die Device/Master-Seite (da es keine Angabe zur Datenübertragungsrichtung gibt), die verwirrt , Slave/Master (nicht ideal) oder Publish/Subscribe (kohärenter, da dies die Übertragungsrichtung der Daten implizit angibt, da das „Device“ wie „Master“ sowohl Master als auch Slave im Verhalten ist!)

Grundsätzlich stimme ich deiner Analyse zu.
Allerdings können wir in unserem Fall mit Gladys davon ausgehen, dass unser zentraler Punkt (die Smart-Home-Box) den Rest steuert und die gesamte logische/Steuerungsfunktion verwaltet. In diesem Kontext ist es durchaus logisch, diesen Hauptknoten „Master“ zu nennen.
Ich möchte mich nicht zu weit aus dem Fenster lehnen, aber ich denke, das ist die Logik, die zur Wahl dieser Bezeichnungen geführt hat.

@cce66

In diesem Fall denke ich, dass sich alle einig sind, dass beide Adressen standardmäßig angezeigt werden sollten und dass, wenn man „Ist dies ein Sensor?“ ankreuzt, nur die entsprechende Zeile angezeigt wird!

Ich unterstütze diesen Teil, mir scheint, dass dieser Button regelmäßig für Missverständnisse im Forum sorgt. Vielleicht sollten wir ein anderes Thema erstellen, um darüber zu diskutieren?

[cce66]

@Shiftmaj

Allerdings können wir in unserem Fall mit Gladys annehmen, dass unser zentraler Punkt (Smart-Home-Box) den Rest steuert und die gesamte Logik/Reihenfolge verwaltet. In diesem Kontext ist es durchaus logisch, diesen Hauptknoten „Master“ zu nennen.

Ja, wenn Gladys und Mosquitto tatsächlich auf derselben Maschine gehostet werden, kann man es als zentralen Punkt betrachten, aber der Mosquitto-Server, der von Gladys auf der Maschine bereitgestellt wird, auf der er läuft, dient auch als Server für andere Clients, die nicht über Gladys laufen, und wenn Gladys einen anderen Mosquitto-Server verwendet (was möglich ist, da er konfigurierbar ist, z. B. habe ich bei mir einen anderen NUC, auf dem Home-Assistant gehostet wird, auf dem Mosquitto läuft). Und wenn der Hauptknoten „Master“ ist, hätte die Logik verlangt, dass die Geräte …Slave sind!

@Shiftmaj

Ich unterstütze diesen Teil, mir scheint, dass dieser Knopf regelmäßig eine Quelle von Missverständnissen im Forum ist.

Ich bestätige, dass ich eine Weile gebraucht habe, um diesen Punkt zu verstehen, obwohl ich ohne Probleme einen Flow von Node-Red auf Home-Assistant bereitgestellt habe, der mit meinem IPX800V5-Domotik-Modul interagiert (dieses Modul integriert MQTT-Objekte „subscribe“ und „publish“).

[pierre-gilles]

@cce66

In diesem Fall denke ich, dass sich alle einig sind, dass die beiden Adressen standardmäßig angezeigt werden sollten und dass, wenn man „Ist dies ein Sensor?“ ankreuzt, nur die entsprechende Zeile angezeigt wird!

Ja, 100% einverstanden, das ist ein UX-Problem Es gibt bereits eine GitHub-Issue, die erstellt wurde =>

MQTT: Add the publication Topic sensor if the option "Is it a sensor?" is disabled

[cce66]

Also gut, gute Nachricht, fast (jetzt habe ich keine Haare mehr! )
Ich habe es endlich geschafft, die Funktion in beide Richtungen (Relais IPX800V5 <=> Gladys) zu nutzen, indem ich « Schalter » verwendet habe (es wäre gut, wenn man das Relais hinzufügen könnte, denn für mich bedeutet Schalter=Schalter )

et genauso auf der Seite von IPX800V5

Die MQTT-Abonnenten auf der Seite von IPX800V5

Die MQTT-Veröffentlichungen auf der Seite von IPX800V5

der grafische Fluss

et die Debugging-Reihenfolge:
Relais 1 « An » vom IPX800V5

Relais 1 « Aus » vom IPX800V5

Relais 1 « An » von Gladys

Relais 1 « Aus » von Gladys

Und der Fluss im JSON-Format

 [{"id":"cf6dc2aae7c8ab92","type":"tab","label":"Flow 3","disabled":false,"info":"","env":[]},{"id":"91ee9c360eac6d43","type":"mqtt out","z":"cf6dc2aae7c8ab92","name":"IPX800_V5-1","topic":"IPX800_V5-1","qos":"1","retain":"false","respTopic":"","contentType":"","userProps":"","correl":"","expiry":"","broker":"291914c5c9c68f02","x":1230,"y":100,"wires":[]},{"id":"c2659b7b2ff21d6e","type":"function","z":"cf6dc2aae7c8ab92","name":"selon payload \"[IPX]Relay state x\" true/false => 0/1","func":"var msg1,msg2;\n\nswitch (msg.payload) {\n    \n  case \"{\\\"[IPX]Relay state 1\\\":true}\":\n    msg1 = {payload:\"1\" };\n    break;\n  case \"{\\\"[IPX]Relay state 1\\\":false}\":\n    msg1 = {payload:\"0\" };\n    break;\n    \n  case \"{\\\"[IPX]Relay state 2\\\":true}\":\n    msg2 = {payload:\"1\" };\n    break;\n  case \"{\\\"[IPX]Relay state 2\\\":false}\":\n    msg2 = {payload:\"0\" };\n    break;  \n    \n  default:\n    break;\n}\n\nreturn[msg1,msg2];\n","outputs":2,"noerr":0,"initialize":"","finalize":"","libs":[],"x":450,"y":220,"wires":[["d7e02d71312aa03e"],["6ea07d03df94f62e"]]},{"id":"d9a7d3602448c88a","type":"mqtt in","z":"cf6dc2aae7c8ab92","name":"IPX800_V5-1","topic":"IPX800_V5-1","qos":"1","datatype":"auto","broker":"291914c5c9c68f02","nl":false,"rap":true,"rh":0,"inputs":0,"x":150,"y":220,"wires":[["c2659b7b2ff21d6e"]]},{"id":"d7e02d71312aa03e","type":"mqtt out","z":"cf6dc2aae7c8ab92","name":"gladys/master/device/mqtt:IPX800_5-1_Relais1/feature/mqtt:IPX800_5-1_Relais1/state","topic":"gladys/master/device/mqtt:IPX800_5-1_Relais1/feature/mqtt:IPX800_5-1_Relais1/state","qos":"1","retain":"false","respTopic":"","contentType":"","userProps":"","correl":"","expiry":"","broker":"291914c5c9c68f02","x":1000,"y":180,"wires":[]},{"id":"6ea07d03df94f62e","type":"mqtt out","z":"cf6dc2aae7c8ab92","name":"gladys/master/device/mqtt:IPX800_5-1_Relais2/feature/mqtt:IPX800_5-1_Relais2/state","topic":"gladys/master/device/mqtt:IPX800_5-1_Relais2/feature/mqtt:IPX800_5-1_Relais2/state","qos":"1","retain":"false","respTopic":"","contentType":"","userProps":"","correl":"","expiry":"","broker":"291914c5c9c68f02","x":1000,"y":260,"wires":[]},{"id":"4dc3520e0af08d51","type":"mqtt in","z":"cf6dc2aae7c8ab92","name":"gladys/device/mqtt:IPX800_5-1_Relais1/feature/mqtt:IPX800_5-1_Relais1/state      .","topic":"gladys/device/mqtt:IPX800_5-1_Relais1/feature/mqtt:IPX800_5-1_Relais1/state","qos":"1","datatype":"auto","broker":"291914c5c9c68f02","nl":false,"rap":true,"rh":0,"inputs":0,"x":350,"y":80,"wires":[["1bedbf53cbd0b7c2"]]},{"id":"e51228ced7b818c2","type":"mqtt in","z":"cf6dc2aae7c8ab92","name":"gladys/device/mqtt:IPX800_5-1_Relais2/feature/mqtt:IPX800_5-1_Relais2/state","topic":"gladys/device/mqtt:IPX800_5-1_Relais2/feature/mqtt:IPX800_5-1_Relais2/state","qos":"1","datatype":"auto","broker":"291914c5c9c68f02","nl":false,"rap":true,"rh":0,"inputs":0,"x":360,"y":140,"wires":[["1bedbf53cbd0b7c2"]]},{"id":"658e6d08a9bfa70c","type":"mqtt in","z":"cf6dc2aae7c8ab92","name":"#","topic":"#","qos":"2","datatype":"auto","broker":"291914c5c9c68f02","nl":false,"rap":true,"rh":0,"inputs":0,"x":130,"y":300,"wires":[["0b066345aae7ddb9"]]},{"id":"0b066345aae7ddb9","type":"debug","z":"cf6dc2aae7c8ab92","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":340,"y":300,"wires":[]},{"id":"1bedbf53cbd0b7c2","type":"function","z":"cf6dc2aae7c8ab92","name":"selon topic => [IPX]Relay cmd x : true/false","func":"var msg1,msg2;\n\nswitch (msg.topic) {\n  case \"gladys/device/mqtt:IPX800_5-1_Relais1/feature/mqtt:IPX800_5-1_Relais1/state\":\n    \n    switch (msg.payload) {\n      case \"0\":\n        msg1 = {payload:\"{\\\"[IPX]Relay cmd 1\\\":false}\" };\n        break;\n      case \"1\":\n        msg1 = {payload:\"{\\\"[IPX]Relay cmd 1\\\":true}\" };\n        break;\n      default:\n        break;\n    }\n    break;\n    \n  case \"gladys/device/mqtt:IPX800_5-1_Relais2/feature/mqtt:IPX800_5-1_Relais2/state\":\n\n    switch (msg.payload) {\n      case \"0\":\n        msg1 = {payload:\"{\\\"[IPX]Relay cmd 2\\\":false}\" };\n        break;\n      case \"1\":\n        msg1 = {payload:\"{\\\"[IPX]Relay cmd 2\\\":true}\" };\n        break;\n      default:\n        break;\n    }\n    break;\n    \n  default:\n    break;\n}\n\nreturn[msg1,msg2];","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":860,"y":100,"wires":[["91ee9c360eac6d43"]]},{"id":"291914c5c9c68f02","type":"mqtt-broker","name":"mqtt://localhost","broker":"mqtt://localhost","port":"1883","clientid":"","autoConnect":true,"usetls":false,"protocolVersion":"4","keepalive":"60","cleansession":true,"birthTopic":"","birthQos":"0","birthPayload":"","birthMsg":{},"closeTopic":"","closeQos":"0","closePayload":"","closeMsg":{},"willTopic":"","willQos":"0","willPayload":"","willMsg":{},"sessionExpiry":""}]

Ich habe Latenzen oder sogar keine Berücksichtigung, wenn die Befehle zu schnell ausgeführt werden, aber wenn man wartet, funktioniert es sehr gut. Allerdings von einem Node Red in Home Assistant aus, also Home Assistant <=> IPX800V5, gibt es keine Latenz!
Aber von Gladys aus werden 4 Nachrichten im Debug generiert, anstatt 2, wenn es vom IPX800V5 kommt

[cce66]

@pierre-gilles
Okay, ich werde ein Tutorial erstellen und es auf der Gladys-Website und auf der GCE-Website veröffentlichen, um zu zeigen, wie man eine Schnittstelle über Node-RED zwischen Gladys und der IPX800V5 einrichtet (direkte Verbindung funktioniert nicht in der IPX800V5, die MQTT-Kette ist zu lang). Ansonsten kennst du ja https://www.youtube.com/watch?v=jTeJxQFD8Ak, gemacht von einem Mitglied des MQTT-Spezifikationskomitees. Aber für die Rosbif-Fans ist es nicht untertitelt

[pierre-gilles]

@cce66

Ich habe Latenzen oder sogar keine Berücksichtigung, wenn die Befehle zu schnell ausgeführt werden, aber wenn man wartet, funktioniert es sehr gut. Allerdings von einem Node Red in Home Assistant aus, also Home Assistant <=> IPX800V5 keine Latenz!

Sehr seltsam! Du bestätigst, dass die Bedingungen dieselben sind (Home Assistant/Node-Red/Gladys sind auf derselben Maschine?), Gladys hat nichts Besonderes gemacht?

@cce66

Okay, ich werde einen Tutorial erstellen und auf der Gladys-Website und auf der GCE-Website, um zu zeigen, wie man eine Schnittstelle über Node-Red zwischen Gladys und der IPX800V5 erstellt

Top, danke @cce66!

[cce66]

@pierre-gilles

Ich denke, es wäre auch einfacher, den Teil « mqtt: » der « Externe ID der Funktion » nicht im Topic zu verwenden. Für mich ergibt das keinen Sinn und verlängert das Topic, und auf dem IPX800V5 wird es zu lang! (Ich habe nicht herausgefunden, ob es eine Grenze für das Topic gibt)
Zum Beispiel, wenn man IPX800V5-1 in IPX800V5 umbenennt

gladys/device/mqtt:IPX800V5_Relais1/feature/mqtt:IPX800V5_Relais1/state

würde zu

gladys/device/IPX800V5_Relais1/feature/IPX800V5_Relais1/state

oder (laut MQTT-Standard)

gladys/device/IPX800V5_Relais1/state

Ebenso

gladys/master/device/mqtt:IPX800V5_Relais1/feature/mqtt:IPX800V5_Relais1/state

würde zu

gladys/master/device/IPX800V5_Relais1/state

Finde ich das nicht klarer?

Und wie die Duponts und Duponts würde ich sogar sagen:

IPX800V5 abonniert « Gladys\Schalter\state » (Payload 0 oder 1 / an oder aus / true oder false)
Gladys veröffentlicht « Gladys\Schalter\state » (Payload 0 oder 1 / an oder aus / true oder false)
Wenn ich in einer Szene oder im Chat zu Gladys sage « Schalte das Relais ein », schaltet Gladys den Schalter ein
und veröffentlicht den Zustand des Schalters, der IPX800V5 wird informiert und schaltet sein Relais um und das Lycée de Versailles!

Gladys abonniert « IPX800V5\Relais1\state » (Payload 0 oder 1 / an oder aus / true oder false)
IPX800V5 veröffentlicht « IPX800V5\Relais1\state » (Payload 0 oder 1 / an oder aus / true oder false)
Wenn das Relais des IPX800V5 durch Programmierung im IPX800V5 geschaltet wird, veröffentlicht dieser den Zustand seines Relais, Gladys wird informiert und schaltet ihren Schalter um
Alles mit QOS 1, um Schleifen zu vermeiden

Also in Gladys haben wir

• ein Abonnement auf den Zustand des Relais1 des IPX800V5 (« IPX800V5\Relais1\state »)
• eine Veröffentlichung des Zustands des Gladys-Schalters (« Gladys\Schalter\state »)

Und im IPX800V5 haben wir

• ein Abonnement auf den Zustand des Gladys-Schalters (« Gladys\Schalter\state »)
• eine Veröffentlichung des Zustands des Relais1 des IPX800V5 (« IPX800V5\Relais1\state »)

Man versteht das besser, wenn man bedenkt, dass der Mosquitto-Broker nur dazu dient, Nachrichten zu speichern und zu übertragen, die Clients (Publisher) an andere Clients (Subscriber) senden, und dass die Clients daher indifferent sowohl Publisher als auch Subscriber sein können, aber man muss immer die ID des Client-Publishers und die ID des Client-Subscribers (Gladys und IPX800V5) klar angeben

All das gilt nur, wenn es keinen objektiven Grund gibt, es anders zu machen!
Also, selbst wenn Gladys eine ‹ Master ›-Rolle spielt und die ‹ Slave ›-Geräte steuert, die ihm aus MQTT-Sicht zugeordnet sind, bleibt es ein Client von Mosquitto wie die anderen Geräte!

[pierre-gilles]

@cce66

Ich denke, es wäre auch einfacher, den Teil „mqtt:” der „Externe ID der Funktionalität” nicht im Topic zu haben, das hat für mich keinen Sinn und verlängert das Topic, und auf der ipx800v5 wird es zu lang! (Ich habe nicht gefunden, ob es eine Grenze für das Topic gibt)

In Wirklichkeit möchtest du das obligatorische Präfix « mqtt: » von der externen ID entfernen, es ist mehr eine Frage der externen ID als des MQTT-Topics.

Grundsätzlich haben wir dieses Präfix hinzugefügt, weil diese externe ID in der Datenbank für alle Geräte in ganz Gladys einzigartig ist, und wir wollen nicht, dass mehrere Integrationen kollidieren können, da die MQTT-Integration die einzige Integration ist, bei der der Benutzer diese externe ID auswählt.

Danach stimme ich zu, dass es in Bezug auf die Lesbarkeit weniger sauber ist, und es gibt Probleme mit zu langen Topics. Das muss mit dem Team diskutiert werden. @AlexTrovato Was denkst du? (Entfernen des obligatorischen Präfixes « mqtt: » für neue MQTT-Geräte)

@cce66

Die Clients können indifferent sowohl Publisher als auch Subscriber sein

Genau das ist es

@cce66

Also selbst wenn Gladys eine Rolle als „Master” spielt

In Wirklichkeit bedeutet die Idee von „Master” nicht, dass Gladys „Master” ist, ich denke, du hast dieses Konzept der API falsch verstanden, weil du nicht die gesamte Geschichte der Konzeption kennst: eine der zukünftigen Entwicklungen der v4 (gut, das ist sehr langfristig), war die Idee einer „Master”-Instanz und „Pod”-Instanzen

Die Idee war, theoretisch „Mini-Gladys” zu haben, die auf anderen Maschinen laufen können, um entfernte Geräte steuern zu können.

Dadurch wäre Gladys nicht nur eine Instanz, sondern ein Netzwerk mehrerer Instanzen, darunter 1 Master und X Pods.

Wir haben die API so konzipiert, dass man angeben kann, ob man mit Gladys „Master” spricht:

gladys/master/**

Oder mit einer Pod-Instanz:

gladys/pod/ID_DU_POD/**

Allerdings, da dieses Konzept nicht entwickelt wurde, habe ich dir nichts davon erzählt, um dich nicht zu verwirren

Aber ich versichere dir, dass diese gesamte API Monate der Überlegung und Arbeit ist, nichts ist zufällig! Ich lade dich ein, die Diskussionen auf dem Konzeptionsforum noch einmal zu lesen, alles ist öffentlich.

[cce66]

@pierre-gilles

Pflichtiges Präfix „mqtt:” für neue MQTT-Geräte entfernen

Ich habe in der MQTT-Dokumentation diese Pflicht nicht gefunden? Ist das in der Version 5? Jedenfalls funktioniert es perfekt ohne in dem oben genannten Beispiel zwischen IPX800 und NodeRed!

@pierre-gilles

ein Master und X Pods.

Das ist okay, das macht Sinn: „gladys\master”, „gladys\pods” und „gladys\device” mit anschließend Eigenschaften und Methoden! Wir sind wirklich im Internet der Dinge!
Übrigens, wenn man darüber nachdenkt angesichts dieser Informationen… die IPX800V5 ist irgendwie… ein Mini-Pod!

[cce66]

Hallo @pierre-gilles

Nach viel Schweiß habe ich es endlich geschafft, die IPX800V5 von Gladys aus zu steuern, hier ist das Tutorial!

Mini-Tutorial - Gladys-Interaktion - IPX800V5 über Node-RED

Das Ziel dieses Tutorials ist es, zu zeigen, wie man Relais der IPX800V5-Domotic-Plattform von GCE mit Gladys steuert Gehen Sie zum Tab „System“ [image] Klicken Sie auf „MQTT“ [image] Konfigurieren Sie wie folgt, wobei für „Server: " die IP des Mosquitto-Brokers (IP des Raspberry oder des NUC, auf dem Gladys installiert ist) und für „Client-ID" der gewünschte Name (hier habe ich IPX800V5 eingetragen, das ist wichtig für die Konfiguration der Topics in Node-Red) [image] Dann gehen wir z…

Und dasselbe im GCE-Forum, damit Gladys den Besitzern der IPX800V5 bekannt wird, ich denke, der Teil Gladys Plus könnte sie wirklich interessieren!

Mini tuto Gladys Nore-red IPX800V5

Ich hoffe, ich habe es am richtigen Ort veröffentlicht.
Aber auf der Seite der Spracherkennung habe ich das gesehen, es ist neu und sieht leistungsfähig aus

alphacep/kaldi-vosk-server - Docker Image

alphacep/kaldi-fr - Docker Image

Créer sa propre reconnaissance vocale. Librairie python : vosk

Es wäre interessant, die Frage zu untersuchen, es in Gladys zu deployen! Ich werde versuchen, es auf meinem NUC zu deployen und zu sehen, wie man damit « spielen » kann. Es stimmt, dass es im Vergleich zu Version 3 fehlt!

[pierre-gilles]

@cce66

Ich hoffe, ich habe es am richtigen Ort veröffentlicht.

Ich habe das Tutorial in die Kategorie „Tutorials“ des Forums verschoben

Gut gemacht mit dem Tutorial, es ist super!

[cce66]

Wenn das den Schmilblick voranbringen kann und die IPX-Seite mit Zigbee über Gladys komplementär ist (fehlt nur noch die Spracherkennung… )
Ich werde noch einen weiteren machen, denn in Node-RED gibt es ein Modul namens sun-calc, mit dem man die Position der Sonne berechnen kann und in Kombination mit den Temperatursensoren kann man interessante Szenarien mit dem Rollladenmodul von GCE erstellen https://www.gce-electronics.com/fr/carte-relais-ethernet-module-rail-din/1097-ipx800-v4-extension-4-volets-roulants-x-4vr-3760309690094.html das über MQTT via IPX800V5 steuerbar ist!

[cce66]

Aber @pierre-gilles, gibt es vielleicht Knöpfe, die für die Rollläden funktionieren könnten?

[pierre-gilles]

Nein! Es gibt zwei Feature-Anfragen in diese Richtung:

Druckknopf am Armaturenbrett

Ich schlage vor, einen Taster in die Gerätefunktionen hinzuzufügen. Zum Beispiel ist eines der ersten Geräte, die wir steuern möchten, der oder die elektrischen Rollläden. Eine Möglichkeit besteht darin, die hier vorgeschlagenen Funktionen zu verwenden: Gestion des volets roulants - #13 par syper Eine andere Möglichkeit besteht darin, nur einen Taster (immer dieselbe Nachricht) zu verwenden, der es ermöglicht, den Rollladen zu öffnen, zu stoppen oder zu schließen. Natürlich muss die Steuerung…

Und umfassender:

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 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% (geschloss…

[cce66]

@cce66

mit dem Rollladenmodul von GCE Rollladensteuerung - X4VR

deshalb habe ich meine Rollläden mit meinem IPX automatisiert, da ich Statusrückmeldungen habe, die ich über MQTT verwalten und in Gladys nutzen kann!

Und mit Node-RED gibt es auch dieses Modul, das viele Möglichkeiten zur Steuerung der Rollläden bietet. Letztlich ist die Integration von Node-RED mit Gladys

flows.nodered.org

node-red-contrib-blindcontroller-v2

Eine Sammlung von Node-Red-Knoten, die die Steuerung von Rollläden im Haushalt basierend auf der aktuellen Sonnenposition automatisiert

Und die Position der Sonne an den Rollläden kann hier überprüft werden: Calcul de la position du soleil dans le ciel pour chaque localisation à importe quel moment

Es fehlt nur noch der passende Button in Gladys!

Wie man so schön sagt, Gladys fehlt nur noch die Sprache… und die Spracherkennung!

[Fabic]

Um die Jalousien und Motoren zu steuern, gibt es auch Tasmota: Shutters and Blinds - Tasmota

In diesem Fall ist die Integration in Gladys automatisch, aber um perfekt zu sein, fehlt entweder der Impulsbutton oder die Buttons „Hoch und Runter“, wie von @syper in diesem Integrationsantrag vorgeschlagen: Gestion des volets roulants - #16 par pierre-gilles

Der einzige Nachteil für mich im Modus 1 von Tasmota ist, dass die Umschaltzeit zwischen „Hoch“ und „Runter“ im Code auf 50 ms fest eingestellt ist. Ein bisschen knapp für Relais und in bestimmten Schaltungen mit Triac und sogar MOSFET.

[cce66]

Ich kenne tasmota nicht, gibt es ein VR-Modul? Denn ich bevorzuge eine Lösung, die im Problemfall (Brand) okay ist, weil die Versicherungen in diesem Fall immer versuchen, dich zu vernebeln und sagen, dass du gebastelt hast!

[pierre-gilles]

@cce66

In diesem Fall denke ich, dass sich alle einig sind, dass die beiden Adressen standardmäßig angezeigt werden sollten und dass, wenn man „Ist dies ein Sensor?“ aktiviert, nur die entsprechende Zeile angezeigt wird!

Ich bestätige, dass ich gerade die Benutzerfreundlichkeit der MQTT-Ansicht verbessert habe, indem ich die beiden Topics anzeige, wenn die Option deaktiviert ist

Aktor:

Sensor:

Bisher ist es in einem Pull Request, es wird im nächsten Update von Gladys veröffentlicht.

Fix #1401 : Improve MQTT integration UX by adding listen & publish topics to non read-only devices (#1449)

[pierre-gilles]

Ich bestätige, dass die UX-Verbesserung in Gladys Assistant 4.8 verfügbar ist:

Gladys Assistant 4.8 ist verfügbar und ermöglicht die Nutzung von Kalendern in Szenen!

Hello à tous, Suite au live, je suis heureux de lancer Gladys Assistant 4.8 officiellement Vous trouverez toutes les nouveautés dans un article récapitulatif sur le blog : Le replay du live est dans l’article Merci à tous ceux qui étaient là, et tous ceux qui ont contribués à cette nouvelle version !