Funktionsbeschreibung
Nach dem Kauf meines Smart-Home-Systems stelle ich fest, dass Gladys noch keine native Heizungssteuerung unterstützt:
Stimmt jetzt alle dafür, damit das noch vor Ende des Winters umgesetzt wird 
Soweit ich verstanden habe, werden die Stimmen nichts ändern, solange entweder niemand verfügbar ist oder kein Entwickler ausgestattet ist — und das trotz der Anzahl der Wähler.
Siehe:
https://community.gladysassistant.com/t/ajout-enceinte-sonos/5504/5?u=spenceur
Vielleicht können wir das an einem anderen Ort besprechen, aber wenn die Abstimmungen ein großes Interesse haben: Das gibt der Community eine Indikation darüber, was gefordert wird/nicht gefordert wird.
Persönlich, wenn ich eine neue Funktion entwickle, nehme ich die Liste der Funktionen, die mit dem Kern verbunden sind, ordne sie nach Abstimmung und entwickle die am meisten geforderte. Das ist keine goldene Regel, natürlich entwickle ich manchmal auch wenig geforderte Funktionen, die ich nach meinem Urteil für wichtig halte.
Jedenfalls historisch in den letzten Jahren habe ich die 30 Funktionen entwickelt, die am meisten gefordert wurden (siehe Archiv: Demandes livrées - Gladys Assistant community)
Im Fall der Integrationen habe ich dir bereits @spenceur in einem anderen Thema geantwortet.
Übrigens, vielleicht ist die Grenze zwischen Core-Entwicklung und Integrationsentwicklung dünn, aber dieses Issue (native Heizungssteuerung) ist eindeutig eine Core-Entwicklung, keine Integration!
Für diese Feature-Anfrage ist keine Hardware erforderlich.
Ansonsten, @lmilcent, wenn du möchtest, dass dieses Issue vorankommt, sind hier 90% der Arbeit funktionale Spezifikationen.
Ich glaube, du hast Erfahrung damit, ich mache das bei jedem Funktionswunsch, aber es wird notwendig sein:
- Untersuchung der verschiedenen Heizungslösungen (wir werden eine Entwicklung machen, die unabhängig von den Integrationen ist, nicht nur Zigbee)
- Funktionale Spezifikationen: Was wollen wir?
- Mockups: Wie wird es aussehen?
- Schließlich die Entwicklung
Kurz gesagt, das Schreiben von Code wird die letzten 10% sein.
Wenn du dich nicht in der Lage siehst, all das zu tun, es sei denn, jemand anderes kümmert sich darum, persönlich habe ich Dutzende anderer Anfragen, die mehr Stimmen haben als diese, daher könnte es eine Weile dauern, bis ich zu diesem Feature komme 
(Mehrere Jahre? 
)
Edit: Beispiel für Spec/Mockups: Multi-utilisateurs - #6 par pierre-gilles
Vor etwa 2 Jahren habe ich zwei Enocean-Thermostatköpfe gekauft, einer schlummert in einer Schublade, der andere ist montiert, aber im abgetrennten Modus genutzt. Ich habe immer noch die Idee, ein vollständiges Heizungsmanagementsystem unter Gladys zu haben.
Es würde mich nicht stören, mich damit zu beschäftigen, aber die Spezifikationen, die ich im Kopf habe, sind recht umfangreich/komplex. Da ich im Moment große Schwierigkeiten habe, (viel) Zeit zu finden, habe ich Angst, einen weiteren Winter mit meinem alten System zu verbringen ^^
Ich bin, wie @pierre-gilles sagt, bereit, über diese Spezifikationen zu diskutieren.
Für mich, grob gesagt, sah ich bereits ein System zur „Deklaration der Heizung“.
-
Das heißt, eine Verbindung zwischen den thermostatischen Geräten, den Heizkörperventilen oder dem zentralen Ventil (ich denke an meinen Fall) mit Temperatursensoren.
-
Jedes Ventil ist mit seinem/ihren Sensor(en) gekoppelt.
-
Ein Sollwertsystem für jedes Ventil-Sensor-Paar.
-
Eine Überschreitung des Schwellenwerts an einem mit einem Ventil verbundenen Sensor würde die Anforderung an das Ventil auslösen oder es stoppen.
-
Natürlich auch die visuelle Verwaltung eines Zeitplans.
-
Nicht zu vergessen eine mögliche Kopplung der Ventile mit den Fenstersensoren, wenn man eine Tür/Fenster im Raum öffnet, in dem sich ein Ventil befindet, wird es gestoppt, um nicht umsonst zu heizen.
-
Auf ähnliche Weise, wenn das Haus leer ist, kann man entscheiden, die Heizung auszuschalten, mit einer Verzögerung… … zu sehen… oder sie aus der Ferne zu starten, wenn ein Benutzer ankommt oder es entscheidet…
Danke für eure Antworten. Wie @Jean-Philippe habe ich im Moment auch immer Schwierigkeiten, mir Zeit zum Nachdenken zu nehmen, aber das hindert mich nicht daran, etwas zu beginnen. Gemeinsam werden wir es schaffen, eine vollständige Version zu erstellen, um die Entwicklung zu erleichtern.
Stimmt, mir war nicht bewusst, dass es sich hauptsächlich um Spezifikationen handelt, aber das erleichtert anschließend die Entwicklung!
In der Zwischenzeit gibt es, glaube ich, node-red, mit dem man herumexperimentieren kann, bis es unterstützt wird. Ich habe es noch nicht ausprobiert, ich kann also nicht sagen, ob es funktioniert 
Also, wir bleiben dran, ich beginne eine Arbeitsversion, sobald ich kann. Zögert nicht, alle, auch Informationen vorzuschlagen, zu ergänzen, zu korrigieren, eure Szenarien beizutragen usw.
Funktionale Spezifikation
Als Gladys-Nutzer möchte ich meine Heizung steuern können. Dafür sehe ich einige Möglichkeiten:
- Über einen Kalender oder statische Programmierung
- Über einen Kalender mit Priorität für Sensoren
- Manuell über eine Art Thermostat oder zentrale Steuerung
- Automatisch mit Hilfe anderer Sensoren
1. Über einen Kalender
Eine Kalender-ähnliche Oberfläche für eine Woche ermöglicht es, festzulegen, zu welcher Uhrzeit die Heizung ein- oder ausgeschaltet wird, zusätzlich mit einer Heizungsvorgabe.
Beispiel:
- Montag: 21°C von 7 bis 9 Uhr, aus von 9 bis 17 Uhr, 19°C von 17 bis 21 Uhr, 17°C von 21 bis 7 Uhr.
- Dienstag: usw. bis Sonntag
2. Über einen Kalender mit Priorität für Sensoren
Die Kalender-Oberfläche ist immer aktiv, aber wenn eine Szene die Solltemperaturen ändert, hat diese Vorrang. Sobald diese Solltemperatur entfernt wird oder die Heizung ausgeschaltet ist, übernimmt der Kalender wieder die Kontrolle.
Beispiel:
- Der Kalender heizt täglich zwischen 6 und 9 Uhr sowie zwischen 16 und 21 Uhr. Tagsüber ist die Heizung ausgeschaltet.
- Eine Szene erkennt meine Anwesenheit um 9 Uhr (#Homeoffice) und schaltet die Heizung ein, indem sie die Solltemperatur erhöht. Trotz der im Kalender geplanten Deaktivierung hat die Szene die Kontrolle über die Heizung.
- Um 17 Uhr deaktiviert die Szene die Heizung und sendet ein Signal an Gladys, um die Kontrolle zurückzugeben und den Kalender seinen Gang gehen zu lassen.
3. Manuell
Ein Thermostat im Dashboard ermöglicht die Steuerung der Raumtemperatur. Hier gibt es keine Automatisierung, der Nutzer entscheidet über Gladys, wie er die verschiedenen Räume heizen möchte.
Falls ein physisches Thermostat zu Gladys hinzugefügt wird, kann es mit oder anstelle des im Dashboard angezeigten Thermostats verwendet werden. Das physische Thermostat hat immer Vorrang.
Falls der Heizungskalender aktiv ist, aber der Nutzer das Thermostat über das Dashboard ändert, hat er die Kontrolle. Eine kleine Warnmeldung (im Infomodus) kann daran erinnern, dass der Kalender (oder eine Szene) die Solltemperatur steuert.
4. Automatisch (WIP)
Was ist die beste Lösung, um Außensensoren praktisch und nicht über 25.000 Szenen, etwas Kalender usw. zu nutzen?
TODO
Eine Verbindung zwischen den thermostatischen Geräten, den Heizkörperventilen oder dem zentralen Ventil (ich denke an meinen Fall) mit Temperatursensoren.
Jedes Ventil ist mit seinem/ihren Sensor(en) gekoppelt.
Ein System von Vorgaben für jedes Ventil/Sensor-Paar.
Eine Überschreitung des Schwellwerts an einem mit einem Ventil verbundenen Sensor würde die Anforderung an das Ventil auslösen oder es stoppen.
Und natürlich die visuelle Verwaltung eines Zeitplans.
Nicht zu vergessen, eine mögliche Kopplung der Ventile mit den Fenstersensoren, wenn man eine Tür/Fenster in dem Raum öffnet, in dem sich ein Ventil befindet, wird es gestoppt, um nicht umsonst zu heizen.
Auf ähnliche Weise kann man entscheiden, die Heizung auszuschalten, wenn das Haus leer ist, mit einer Verzögerung … … zu sehen … oder sie aus der Ferne zu starten, wenn ein Nutzer ankommt oder es entscheidet …
Exzellente Beschreibung!
Falls ich mir die Bemerkung erlauben darf, ich würde gerne zusätzlich die Möglichkeit haben, die Programmierung für längere Zeit auszusetzen (nicht heizen im Sommer, selbst wenn man mal friert) und eine programmierbare Reaktivierung (ich bin die ganze Woche unterwegs/im Urlaub, aber aktiviere die Heizungsprogrammierung am Freitag um 15 Uhr).
… Und eine praktische Funktion wäre auch „X Stunden länger heizen“ und umgekehrt „X Stunden nicht heizen“, denn „ich habe Gäste, die bleiben werden, aber ich könnte vergessen, die Heizung auszuschalten, wenn ich ins Bett gehe“ (oder ich weiß nicht mehr, wie man das macht) und „Nachmittag Shopping, keine Notwendigkeit zu heizen für 2 Stunden“ (tatsächliche, gefühlte 8 Uhr).
Hallo @lmilcent,
Das ist sehr interessant, aber wie @pierre-gilles sagt, muss es unabhängig von der Integration funktionieren.
Ich habe Z-wave Qubino ZMNHJD1 Module für die Fußbodenheizung, den Handtuchheizkörper und andere, noch nicht installierte Module für Konvektoren. Ich habe auch programmierbare Inertheizkörper, die in Gladys integriert werden, wenn Z-wave funktioniert.
Alles, was verwendet wird, funktioniert seit mehreren Jahren mit Domoticz.
Der Grund, warum ich nicht zu Gladys Plus wechsle, ist, dass ich die Heizung nicht steuern kann…
Danke für dein Feedback @gaetanb76, tatsächlich gibt es noch viel zu tun, um diese Beschreibung zu vervollständigen und die meisten Anwendungsfälle zu berücksichtigen.
Ich habe mir inzwischen Zigbee-verbundene Köpfe gekauft, die ich mit Zigbee2MQTT und Node-Red steuere. Ich bin auf viele Schwierigkeiten gestoßen und habe viel Zeit damit verbracht, ich werde meine Hauptnachricht aktualisieren, um sie später basierend auf meiner Erfahrung zu ändern
Ich habe gerade begonnen, meine Ventile https://ubiwizz.com/l-offre-produits-ubiwizz/9636-vanne-thermostatique-enocean.html in meine enOcean-Integration zu integrieren (noch nicht mit Gladys gemerged).
Und in meinem Fall können sie nativ mit Fensteröffnungssensoren und einem externen Temperatursensor verbunden werden, wenn man den internen Sensor nicht verwenden möchte.
Grundsätzlich kann eine native Heizungssteuerung, die alle Fälle ohne Fehler verwaltet, wie @gaetanb76 angibt, sehr komplex zu schreiben sein, aber ich denke, dass dies tatsächlich ein Adoptionsfaktor für Gladys sein könnte, da die Heizung in einem Haus einer der wichtigsten Hebel für die Hausautomatisierung ist.
Ich denke, sobald ich meine Ventile steuern kann, werde ich statisch arbeiten und mein Gerät die Sollwerte verwalten lassen, bis ich es auch automatisiere, aber keine Eile also 
Genial, ich wollte mich mal bei EnOcean für meine Smart-Home-Lösung umschauen, vor allem wegen ihrer batterielosen Schalter!
Aber angesichts des Giganten Zigbee war ich auf den überall unterstützten Standard gegangen.
Ich freue mich auf deine Version 1 in Gladys 
Hallo, ich erlaube mir, noch einmal nachzuhaken, weil es tatsächlich eine super Integration wäre. Es geht darum, eine funktionale Spezifikation zu definieren.
Für mich sollte die Idee des Heizens bereits auf einen Raum beschränkt sein.
Es gibt zwei Arten von Heizungen:
- Einfache Ein/Aus-Schaltungen
- Thermostatische Köpfe
Thermostatische Köpfe
Im Fall der thermostatischen Köpfe haben diese einen Temperatursensor und kümmern sich selbst darum, diese Raumtemperatur zu erreichen. Es reicht, ihnen einfach diesen Wert zu übermitteln.
Ich denke, das ist der einfachste Anwendungsfall und einer, der bereits 80% der Bedürfnisse aller Benutzer abdeckt, denke ich.
Die Integration aus einem Kalender kann mit Szenen ab der Version 4.8 erfolgen
Man kann je nach anwesenden Personen im Haus usw. steuern… Kurz gesagt, es gibt bereits viele Möglichkeiten.
Für die thermostatischen Köpfe bleibt es, den Temperaturwert vom Dashboard aus ändern zu können. Dafür sah ich ein Design, das so aussieht:
Ein/Aus-Heizung
Die Frage der Ein/Aus-Heizung ist komplexer.
Idealerweise sollte man eine Verbindung zwischen einem Temperatursensor und dem Schalter mit automatischer Einschaltung und automatischer Abschaltung um den Zielwert herum herstellen können.
Ich denke, dass allein die Tatsache, einen Zielwert zu haben, die Funktionsanforderung in Gladys erfüllt, virtuelle Variablen zu haben. Denn klar, das wäre der Fall für diesen Wert.
Dadurch könnte jede Ein/Aus-Heizung in einen thermostatischen Kopf umgewandelt und somit auf die gleiche Weise gesteuert werden.
Weiter gehen
- Eine Prioritätsidee bei Änderungen einführen,
- Allgemeiner Ein/Aus-Schalter für das ganze Haus, für bestimmte Räume usw… (die Verwendung virtueller Variablen, mit denen man in Szenen interagiert).
- In einer Szene kann man das Heizung dieses Raumes ausschalten, anstatt jede Heizung einzeln zu deklarieren (wieder eine virtuelle Variable).
Das ist es, habe ich die gewünschten Funktionen richtig zusammengefasst?
Das scheint mir keine riesige Arbeit für die Core-Integration der thermostatischen Köpfe zu sein, es wird etwas Arbeit auf der Seite von Zigbee2Mqtt und den anderen Integrationen geben, denke ich.
Aber die Integration der Ein/Aus-Schaltungen scheint mir komplizierter zu sein, insbesondere wenn man zu einem bestimmten Zeitpunkt die Information des Temperatursensors nicht zurückmelden kann und der Raum überhitzt…
Zögern Sie nicht, wenn Sie Anmerkungen oder Überlegungen haben.
Danke, das ist sehr gut zusammengefasst. Nach meiner Erfahrung in diesem Winter bestätige ich deine Überlegung zu den Thermostatköpfen und der Möglichkeit, diese mit einem externen Temperatursensor zu koppeln. Das war eine der Ideen, die ich mit NodeRed aufgegeben habe.
Man muss daran denken, den Wert für die Aktualisierungsrate (oder Temperaturprüfung) einstellen zu können, denn das sollte nicht alle 10 Sekunden, sondern eher alle 10 Minuten erfolgen, aufgrund der Trägheit.
Ein weiterer Punkt ist die Möglichkeit einer manuellen Vorgabe am Thermostatkopf oder in Gladys, die Vorrang vor der Programmierung hat.
Das ist die Funktionsweise unserer Moes-Köpfe, genannt „temporary manual“. Es übernimmt deine neue Temperaturbedingung bis zum nächsten Programmzyklus.
Beispiel: 18°C sind zwischen 20:00 und 6:00 Uhr programmiert. Wenn ich um 21:00 Uhr den verbundenen Kopf oder Gladys über das Dashboard (oder Telegram) anweise, auf 21°C zu gehen, wird das bis 6:00 Uhr angewendet.
Ja, ich denke, wir sollten eine Liste der Funktionen erstellen, von der wichtigsten bis zur unwichtigsten, und wir wären schon zufrieden, wenn wir die grundlegenden Dinge davon umsetzen könnten. Aber lass uns auch die fortgeschritteneren Funktionen angehen.
Also gibt es die Funktion, die du gerade beschrieben hast, und dann gibt es noch die Möglichkeit, den Heizung einfach ein- und auszuschalten, weil ich an einen Fall gedacht habe.
Wenn ich das Fenster öffne, schalte ich die Heizung aus. In solchen Fällen sind wir daran interessiert, den gewünschten Temperaturwert nicht zu ändern, um leicht zum normalen Modus zurückzukehren.
Okay, dann lass uns vorankommen, da es scheint, als gäbe es nicht allzu viele Bedenken.
Erster Bedarf: Thermostatköpfe
Integrationen:
- Bei Zigbee2Mqtt entspricht dies den Topics:
occupied_heating_setpointodercurrent_heating_setpointder Geräte - Hat jemand einen Z-Wave-Thermostatkopf, damit wir verstehen können, wie man ihn integriert?
Danach:
- Jeder Raum kann einen Heizungszustand „Heizung Ein“ oder „Heizung Aus“ haben, um zu verhindern, dass die Temperatur geändert wird und die Temperatur verloren geht, die in einer der Szenen festgelegt wurde.
(z. B.: Jeden Morgen von 8 bis 10 Uhr auf 20 Grad heizen. Wenn ein Fenster geöffnet wird, schaltet die Heizung ab. Wenn es geschlossen wird, wird die alte Temperatur wiederhergestellt (d. h., die Heizung wird wieder eingeschaltet)).
Was sich in den Szenen wie folgt übersetzt:
- Eine Aktion, um die Heiztemperatur eines Raumes festzulegen, und dies wirkt sich auf die verschiedenen Heizungen des Raumes aus
- Eine Aktion, um die Heizung eines Raumes ein- oder auszuschalten
- Eine Bedingung: Wenn die Heizung eines Raumes nicht eingeschaltet ist
Auf dem Dashboard:
- Ein Schalter für die Raumheizung
- Ein Zähler, um die gewünschte Temperatur im Raum festzulegen.
Ich denke, das sind die fünf grundlegendsten Bedürfnisse, und ab da können wir beginnen, etwas immer Interessanteres aufzubauen. Meinungen?
@lmilcent kleine Frage, der Fall, in dem du manuell ein oder zwei Grad an deinem Heizkörper hinzufügst, ist dir das oft passiert?
In Gladys denke ich, dass dies natürlich durch „Temperatur auf 18 Grad setzen“ verwaltet wird, ein Benutzer ändert direkt am Ventil, beim nächsten Mal, wenn eine Temperatur in den Szenen definiert ist, hoppla, es setzt den Wert zurück, der in der Szene definiert ist. Würde das als Betriebsmodus funktionieren?
Ja, in fast allen meinen Räumen!
Bis jetzt habe ich nichts zu beanstanden!
@pierre-gilles, reicht dir dieses Maß an Details für die funktionale Spezifikation? Möchtest du mehr Details?
@jgcb00 dein letzter Beitrag ist sehr gut, aber ich denke, sobald ihr euch über alles einig seid, wäre es cool, eine Art „Zusammenfassungs“-Nachricht mit der gesamten Spezifikation in einer Nachricht von angemessener Größe zu haben, mit der gleichen Organisation, die du gemacht hast, das ist sehr gut:
Dashboard
…
Szenen
…
Integrationen
…
Bitte kümmert euch darum, es ist zwar simpel, aber das, was ihr macht, ist der größte Teil der Entwicklung Das Codieren ist nur der letzte Meter, es ist reine Technik, ganz einfach.