Native Heizungssteuerung

Bestellungen geliefert
,
21

Ok, es bleibt noch eine technische Abwägung zu treffen, dann ist es gut.

Wir möchten also einen Ein-Aus-Schalter zusätzlich dazu, dass es thermostatisch ist, außer dass der Kopf keinen Schalter hat, also muss es ein falscher Schalter sein, der einen Standardwert setzt (z. B. 5 Grad) und wenn man den Schalter wieder aktiviert, setzt man den alten Wert zurück, den der Kopf hatte, oder potenziell einen neuen, der für die Szenen gepusht wurde.

Das erfordert eine Art Speicher, das ist nicht verrückt.

Ansonsten schlage ich folgende Funktionsweise vor:

  • Numerische Variable der gewünschten Temperatur
  • Wenn diese Variable geändert wird, wird überprüft, ob die Heizung an ist, um sie zu veröffentlichen
  • Wenn die Heizung aus ist, wird nur der Wert innerhalb von Gladys geändert
  • Wenn die Heizung an ist, wird der Wert gepusht, der in Gladys ist
  • Wenn die Heizung ausgeschaltet wird, wird ein Standardwert gepusht, der definiert wurde.

Ich denke, ich habe alle Fälle abgedeckt, ich weiß nicht, ob das sehr klar ist!
Ich würde gerne die Meinung eines Experten (@pierre-gilles?) hören, wie du dieses Problem technisch lösen würdest?

22

Will man das wirklich so haben? Ich finde das kompliziert, und vor allem führt es zu einem „falschen Verhalten“, das der Nutzer nicht verstehen wird.

Ich denke, Gladys sollte einfach das nachahmen, was im echten Leben passiert, damit es für den Nutzer klar ist.

Wenn der Thermostatkopf kein Ein/Aus verwaltet, sollte man meiner Meinung nach auch kein Ein/Aus in Gladys einbauen.

Wenn der Nutzer 5°C einstellen möchte, um seinen Thermostatkopf „auszuschalten“, kann er das in Gladys tun, aber ich denke, es ist nicht Gladys‘ Aufgabe, magische Verhaltensweisen mit festen Werten zu erzeugen, oder?

23

Ja, ich bin da ganz deiner Meinung.
Wenn du keine Heizung möchtest, senkst du die Temperatur auf ein Minimum. Das ist ein logisches Verhalten.

24

Da ist etwas, das mir wichtig erscheint und das noch nicht angesprochen wurde: die Regulierung.

25

Wie so oft muss man das in der U ausführlich erklären

Ich mag es, wenn es nicht extrem gemacht ist, Buttons (an/aus in unserem Fall) zu haben, die „deaktiviert“ sind, mit einer Nachricht (z. B. Tooltip), die erklärt, dass es von meinem vernetzten Kopf nicht unterstützt wird.

26

In diesem Fall wäre es nicht einfacher für den Nutzer selbst mit einem Fake-Device und einer Szene umsetzbar? Das wäre realistischer… dafür müsste die Werteinstellung aber gleichzeitig in den Szenen erfolgen. Und in der Dokumentation könnten konkrete Umsetzungsbeispiele gegeben werden (die Anforderung für die Sortierung der Szenen in Ordner wäre idealerweise ebenfalls ^^)

27

Genau @VonOx ^^
Aber soweit ich die Unterhaltung verstanden habe, ging es darum, das Projekt mit dem Einfachsten zu starten und die Regulierung in einem zukünftigen PR hinzuzufügen, oder?

28

Hallo zusammen,

Theoretisch ja, ich bin der Meinung, dass das nicht ideal ist, es ist ein bisschen redundant usw…
In der Praxis gibt es aber viele Szenarien, in denen es unverzichtbar ist. Alles, was mit der Unterbrechung der Heizung / Wiederaufnahme der Heizung zu tun hat, muss den alten Zustand wiederherstellen können, der sehr wahrscheinlich je nach Fall unterschiedlich ist…

Ja, wie @Terdious sagt, die Idee wäre, das in einem zweiten Schritt zu machen, aber wenn es Entwickler gibt, die motiviert sind, alles direkt zu machen, warum nicht gleich integrieren!
@VonOx, legst du Wert auf diese Funktion schon im ersten Feature-Lot?

29

Hallo zusammen,

Ich habe meinen Heizung noch nicht in Gladys integriert, aber ich fange gerade erst mit Gladys an und habe noch nicht alle Elemente, die ich für die Integration meiner gesamten Hausautomation benötige. Gleichzeitig ist es nicht einfach, ein bestehendes System, das funktioniert, für eine andere Lösung zu ändern, aber ich mache langsam Fortschritte.
In der Zwischenzeit kann ich Ihnen zeigen, wie ich es in meinem aktuellen System Domoticz gemacht habe, falls das Ideen gibt.

Zuerst habe ich einen virtuellen Schalter (Fake-Gerät) für den Heizungsmodus (WINTER / SOMMER)

image
image428×150 6.78 KB

Wenn der Sommer-Modus aktiviert ist, wird die Heizung ausgeschaltet
Wenn der Winter-Modus aktiviert ist, schalte ich die Heizung ein

Dann habe ich einen NetAtmo-Thermostat, dessen Relais direkt mit meinem Pellet-Ofen verbunden ist.
In Domoticz erhalte ich 4 Informationen:

  • Betriebsmodus => ermöglicht die Steuerung der Heizung meines gesamten Hauses (Pellet-Ofen und elektrische Heizung) gemäß einem Zeitplan, einem Abwesenheitsmodus und einem Frostschutzmodus

    image
    image426×148 6.39 KB

  • Zustand des Relais => ermöglicht zu überprüfen, ob das Thermostat-Relais aktiv ist oder nicht (man kann Szenen ausführen, je nach Zustand)

    image
    image422×143 6.57 KB

  • Temperatur, die vom Thermostat gelesen wird

    image
    image426×153 5.03 KB

  • Solltemperatur

    image
    image424×157 5.48 KB

Ich habe ein Python-Skript geschrieben, das die NetAtmo-API abfragt und die Daten in Gladys anzeigt, falls das jemanden interessiert. Mir fehlt nur die Anzeige des Modus, da es kein MQTT-Fake-Gerät gibt, das Text anzeigen kann, oder ich habe nicht herausgefunden, wie man das macht.

Die Heizung meines Ofens wird also direkt vom NetAtmo-Thermostat gesteuert und ich lese nur die Daten in Domoticz.

Dann habe ich in jedem Raum eine elektrische Heizung mit einem Vorläuferkabel (gesteuert mit einem QUBINO-Modul in ZWAVE)

Für jeden Raum habe ich mehrere Fake-Geräte erstellt:

  • Betriebsmodus => manuell oder automatisch

    image
    image420×148 7.07 KB

    Im manuellen Modus gibt es ein weiteres Fake-Gerät, mit dem der Heizkörper gesteuert werden kann
    Im automatischen Modus gibt es eine Szene, die den Zustand meines allgemeinen Thermostats überprüft. Wenn ich beispielsweise im Zeitplanmodus bin und die Solltemperatur über einem bestimmten Wert liegt, erlaube ich die individuelle Heizung jedes Raumes

  • Art der Regelung => Hysterese oder PID

    image
    image422×152 7.18 KB

    Hysterese => Dies ist eine Ein-Aus-Regelung mit einem Wert zum Einschalten und einem anderen zum Ausschalten. Zum Beispiel schalte ich die Heizung bei 18°C ein und schalte sie bei 20°C aus
    PID => Dies ist eine etwas komplexere Regelung (proportional, integral, derivativ), um es zusammenzufassen, ist es ein geschlossener Regelkreis, der darauf abzielt, die Temperatur (oder was auch immer man steuern möchte) zu glätten
    image
    image212×165 9.61 KB

  • Manuelle Steuerung => Wenn der Modus auf manuell eingestellt ist, kann ich den Betriebsmodus des Heizkörpers des Raumes (AUS, Frostschutz, Eco, Komfort…) auswählen

    image
    image455×258 13 KB

  • Thermostat => der die Solltemperatur des Raumes festlegt

    image
    image431×272 15.7 KB

  • Temperatursensor

    image
    image422×154 4.39 KB

    Hier verwende ich einen Xiaomi-Aqara-Zigbee-Sensor, um die Raumtemperatur zu lesen und mit dem Wert des virtuellen Thermostats zu vergleichen.

Wenn also der Sollwert höher ist als die aktuelle Temperatur und auch in Abhängigkeit vom allgemeinen Thermostat und dem manuellen oder automatischen Betriebsmodus, steuere ich den Heizkörper im Komfortmodus, andernfalls im Eco-Modus.

Für mich fehlt Gladys für eine Heizungsfunktion ein Fake-Thermostat-Gerät, ein Fake-Gerät vom Typ Mehrwegschalter, nicht nur EIN/AUS, mit der Möglichkeit, einen Text für jede Schalterposition zu definieren.
Danach kann meiner Meinung nach alles andere durch Szenen verwaltet werden, außer die PID-Regelung, die recht komplex ist.
Für den allgemeinen Thermostat verwende ich einen NetAtmo-Thermostat, da ich ihn remote steuern kann und wenn mein Hausautomationssystem ausfällt, kann ich ihn immer noch physisch steuern, aber für die Integration in Gladys könnte man sich ein Fake-Thermostat-Gerät vorstellen, das es ermöglicht, einen Sollwert einzustellen. Anschließend kann mit dem Kalender und einer Szene der Thermostat automatisch in Abhängigkeit von dem, was definiert wurde, gesteuert werden.

30

Hallo zusammen,
deshalb komme ich nochmal auf das Thema zurück, nachdem Gladys 4.9 veröffentlicht wurde

Aus dem, was ich aus unseren Diskussionen verstanden habe, gibt es nur noch einen Punkt, auf dem wir uns einigen müssen, nämlich wie wir das im Dashboard darstellen möchten?
Möchten wir einen Schieberegler wie für die Helligkeit?
Oder lieber ein Thermostat, das in 0,5-Grad-Schritten ansteigt?

Entwicklungsseitig zur Unterstützung der Geräte

  • Zigbee2MQTT müssen die Topics occupied_heating_setpoint oder current_heating_setpoint der Geräte unterstützt werden
  • Immer noch keine Idee für Z-Wave (und ich unterstütze das Thema der Z-Wave-Migration)

Zum Aktivieren/Deaktivieren der Heizung Sommer/Winter → Aktivieren/Deaktivieren von Szenen oder Einstellen auf 5 Grad Temperatur
Zum Aktivieren/Deaktivieren aller Heizungen in einem Raum → Fake-Switch-Szene, die einen festen Wert an die Heizkörper des Raums sendet (Man könnte diesen Punkt in der Zukunft potenziell verbessern, indem man ein allgemeines Thermostat für den Raum hinzufügt)
Heizung per Kalender steuern → Machbar mit Szenen
Steuerung einer On-Off-Heizung mit Raumtemperatur → Bereits machbar mit Szenen, einem Fake-Gerät und einem Temperatursensor im Raum

Habe ich Anwendungsfälle vergessen, über die wir uns noch nicht geeinigt haben?

31

@jgcb00 Könntest du bitte einen Designvorschlag auf whimsical (https://whimsical.com/) für eine Zusammenfassung aller zu entwickelnden Punkte erstellen? (Sowohl das Dashboard als auch die Szenen)

Du machst einen Vorschlag, und dann können wir daran iterieren :slight_smile:

32

Okay, welche Funktion nutzt du dafür?

image
image876×112 7.48 KB

33

Drahtgittermodell!

34

Hättest du eine Vorlagendatei für die Boxen des Dashboards?
Mit der Höhe des « Boxname »-Teils

35

Man muss nicht pixelperfekt sein (das ist nicht die Idee hinter whimsical, das ist nicht Figma), die Idee ist einfach, ein funktionales Mockup / eine funktionale Spezifikation zu erstellen :slight_smile:

36

maquette_chauffage@2x
maquette_chauffage@2x2116×912 89.6 KB

Das ist, was ich im Moment sehe
Linker Teil in den Szenen, rechter Teil im Dashboard

37

Wenn es so einfach ist, umso besser!

Genau, will man dann ein „Gerät für Gerät“ machen (was vielleicht ein guter Anfang für den ersten Schritt sein könnte), oder will man lieber Befehle pro Raum anbieten? (was in einer separaten Box in einem zweiten Schritt kommen könnte)

Jedenfalls bin ich eher für eine einfache Verwaltung zum Start, und das, was du vorschlägst, ist wirklich nicht schlecht!

38

Ja, ich hatte denselben Gedanken, aber für mich ist das ein anderes Thema, oder? Man könnte eine Gruppe von Objekten mit der Steckdose der Lampe und der Deckenlampe erstellen, um sie immer zusammen einzuschalten. Will man das also nur auf die Heizung beschränken?

Ich denke, der beste Kompromiss wäre, eine Gruppe von Objekten in einer Szene super einfach zu erstellen, so wie hier:

groupe_device@2x
groupe_device@2x2524×3378 635 KB

oder jede Änderung eines Werttyps kann auf ein anderes Objekt desselben Typs übertragen werden.
Was denkst du? Und das ist ein großes Kernfeature von Gladys.

39

Man kann auch alles in einem einzigen Block in den Szenen machen, was es ermöglicht, nur die kompatiblen Geräte anzuzeigen.

40

Mal sehen, man muss nicht immer generisch arbeiten, manchmal ist etwas Custom für einen Gerätetyp auch gut!

Typischerweise hat Home Assistant so etwas (das rechte für die Heizung):

Screenshot 2022-06-24 at 13.21.04
Screenshot 2022-06-24 at 13.21.04552×354 54.7 KB

Das könnte eine Custom-Box in Gladys sein, oder man könnte eine Liste von Geräten vom Typ Heizung auswählen, um diese Geräte in einer Box zu steuern, ohne dass es zwangsläufig eine Objektgruppenverwaltung sein muss.

Aber in jedem Fall ist der erste Schritt die beiden Komponenten, die du vorschlägst, @jgcb00. Solche Komponenten sind ein Baustein darüber, um eine möglichst praktische UX für den täglichen Gebrauch zu haben :slight_smile: