Hallo, nach der Integration des Thermostats in Gladys erstelle ich dieses Thema, um die Integration dieser Funktion mit Zigbee2MQTT zu validieren.
@lmilcent wir machen hier weiter 
Ich habe bereits kurz geschaut und kann bereits ein Testimage bereitstellen: atrovato/gladys:z2m-thermostat.
Zur Erinnerung: Es ist ratsam, ein Backup der Datenbank zu erstellen oder mit einer neuen Installation zu beginnen, bevor man ein „Beta“-Image testet.
Vielen Dank im Voraus für euer Feedback.
Danke für den Anfang, entschuldige, dass ich erst jetzt zurückkomme, ich hatte deine Nachricht nicht gesehen.
Container gestartet, Heizkörpergerät in der Z2M-Integration aktualisiert:
Ich sehe, dass der Homekit-Service vorhanden ist, daraus schließe ich, dass dieses Bild auf der neuesten Version mit den Fixes von @pierre-gilles basiert. Aber man sieht auf dem Screenshot, dass die Thermostate im Dashboard abgeschnitten sind (FullHD-Bildschirm und Chrome 107).
Weitere Rückmeldung:
Ich füge hinzu, dass die Temperaturkontrolle in der Oberfläche gut funktioniert und dies wird in der Z2M-Oberfläche widergespiegelt.
Ja, ich habe mich auf eine Version mit HomeKit gestützt, aber ich bin mir nicht sicher, ob es die neueste ist.
Super!
Ich nehme an, das ist nicht themenbezogen zum Thermostat? Wenn es mit dem Thermostat zusammenhängt, werde ich sehen, was ich tun kann. Andernfalls würde ich mich über weitere Erklärungen in einem eigenen Thema freuen.
Danke, dass du dir die Zeit genommen hast 
Tatsächlich ist dies eher mit dem Modell des verbundenen Kopfes als mit dem des Thermostats verbunden, aber es beeinflusst dessen Steuerung, da der „Eco“-Modus bewirkt, dass die Solltemperatur nicht mehr verwendet wird, sondern die „Eco“-Temperatur.
Beispiel: 16°C bei der Eco-Temperatur und 21°C bei der Solltemperatur => der Heizkörper wird auf 16°C heizen.
Was den Thermostat betrifft, ist für mich alles in Ordnung, außer dem angesprochenen Punkt:
Übermittlung der lokalen Temperatur Senden eines HeizwertsSind diese berühmten Modi standardmäßig? Haben alle Thermostate, die Modi wie „Eco“ usw. verwalten, mehr oder weniger dieselben Modi?
Es muss ein neuer Typ in der Thermostat-Kategorie für diese Steuerung erstellt werden, in diesem Fall hat das tatsächlich nicht viel mit dem Zigbee-Teil zu tun
Zur Information, der eco_mode (binär) ist nur auf einem einzigen Zigbee-Gerät verfügbar:
Ansonsten spricht man auch von:
system_mode (enum): 'off', 'heat', 'cool', 'auto', 'dry', 'fan_only', 'sleep', 'emergency_heating'away_mode (binär): Was passiert, wenn ich abwesend bin?regulator_mode (binär): Regler vs. ThermostatIch spreche nur über das, was ich in den zigbee2mqtt-Dokumentationen gefunden habe.
Aber ich denke, wir werden schnell blockiert sein, wenn wir den Begriff ‹ verfügbare Werte › nicht zu den Features hinzufügen, denn nicht alle system_mode sind auf allen Geräten verfügbar, und wenn wir das von der Dashboard aus verwalten wollen, müssen wir nur die auf den Aktuatoren verfügbaren Modi kennen.
Sollen wir mit einem Eco-/Normalmodus starten und dann nach und nach mehr hinzufügen?
Ich bin einverstanden, wir müssen an diesem Thema auf der Core-Seite arbeiten!
In der Zwischenzeit, @pierre-gilles, was hältst du von diesem Vorschlag?
Wobei ich keine anderen Geräte mit dieser Funktion gefunden habe (ich habe nur in der Liste der z2m-Geräte gesucht).
Ich sehe nicht, warum es komplizierter sein soll, alles einzubeziehen, statt nur eco/normal?
ah! Also ist das wirklich 100%ige Custom-Entwicklung, gibt es da nichts Generisches in diesem Verhalten?
Bei eco/normal handelt es sich einfach um einen benutzerdefinierten „Binärwert“.
In den anderen Fällen handelt es sich um eine Weiterentwicklung des Feature-Modells, um die verfügbaren Werte zu kennen, wobei diese Weiterentwicklung auch den benutzerdefinierten Binärwert einschließen kann.
Ich fürchte ja… zumindest beim benutzerdefinierten Binärwert.
Ist diese Weiterentwicklung so kompliziert? Ich finde, es ist eine recht häufige Anforderung, die viele Probleme lösen würde. Mir kommt es sogar so vor, als könnten auch die « Klick-Button »-Geschichten mit Übersetzungen von dieser Änderung profitieren.
Der benutzerdefinierte Binärwert ist ein bisschen ein Hack, ich denke, es lohnt sich, es sauber zu machen
Kompliziert nein, aber etwas aufwendig. Sobald es den Kern, das Modell und die Datenbank betrifft, gehen wir Risiken ein. Aber dafür sind wir ja da.
Ich kann mich nicht zur Übernahme der Entwicklung verpflichten, ich bin mir nicht sicher, ob ich in den kommenden Tagen Zeit habe.
Auf jeden Fall! Es gibt vor allem die ganze Überlegung, wie man es macht ^^
Kein Problem! Vielleicht kannst du ein Thema im Forum erstellen, um eine Spur zu hinterlassen und vielleicht eine erste Implementierungsspezifikation zu starten?
Erstellt!
Man kann jetzt auf der anderen Seite mit dem Auflisten unserer Ideen beginnen
Hallo,
In Bezug auf die Betriebsmodi der Heizungen, diese müssen auf dem Pilotdraht basieren:
In Z-Wave gibt es Geräte vom Typ Pilotdraht mit 4 Befehlen.
Könnte man diese Liste nicht im Feld „params“ der Gladys-Geräte hinterlegen und nur diese anbieten?
Ich bin eher dafür, zu statischen Lösungen zu gehen, wenn es sich um ein Verhalten handelt, das wir zusammenfassen können
Zur Information habe ich gerade die PR von @AlexTrovato gemerged 
Danke an alle, die getestet haben!
Das wird in der nächsten Gladys-Release enthalten sein
