Thermostat ON/OFF & Heating/Cooling/Auto mode group addresses missing

[matthafner]

Is there a plan to add

• ON/OFF
• Heating/Cooling/Auto
• Heating & cooling thresholds

to the web interface so you can use it with KNX group addresses (this is pretty important if you work with a thermostat).

I was wondering because the Homekit device already seem to supports the heating/cooling and off/auto function...

And to make it complete, it would be nice to add the humidity reading too, so it is displayed in Homekit ;)

I'm on hkknx Version 2.0.0.

[brutella]

Wenn man Heizen/Kühlen gar nicht schreiben kann, braucht es dann überhaupt eine Schreiben-Gruppenadresse?

[pfeifix]

Für den MDT-Aktor nicht. Für andere Aktoren kann ich nicht sagen, ob die evt. ein Objekt für Heizen/Kühlen haben. Würde aber gefühlsmäßig eher sagen nein, auch weil der HVAC Mode das ja nicht anbietet. Die Aktoren werden nach Soll- und Istwertvergleich selbst entscheiden, ob geheizt oder gekühlt werden soll.

[willf8]

Das ist richtig, aber in manchen Fällen, wo man z.B. ein separates Kühl/Heizsystem hat, das man separat ansteuern möchte ist es auf jeden Fall sinnvoll.

On 7 Sep 2023, at 15:32, pfeifix @.***> wrote:

Für den MDT-Aktor nicht. Für andere Aktoren kann ich nicht sagen, ob die evt. ein Objekt für Heizen/Kühlen haben. Würde aber gefühlsmäßig eher sagen nein, auch weil der HVAC Mode das ja nicht anbietet. Die Aktoren werden nach Soll- und Istwertvergleich selbst entscheiden, ob geheizt oder gekühlt werden soll.

— Reply to this email directly, view it on GitHub https://github.com/brutella/hkknx-public/issues/135#issuecomment-1710159801, or unsubscribe https://github.com/notifications/unsubscribe-auth/BBQWIPEARDUCOVWOI2R23ELXZHEFHANCNFSM5EISCKRA. You are receiving this because you were mentioned.

[pfeifix]

Der MDT-Aktor kann auch ein separiertes Heiz-/Kühlsystem (4-Rohr) ansteuern. In dem Fall wird ein zusätzlicher Kanal benötigt, dann entscheidet der Aktor auch selbst, ob im einen System geheizt oder im anderen gekühlt wird. Für diesen Fall gibt es bspw. die Einstellung einer "Totzone", das ist ein Übergangsbereich zwischen Heizen und Kühlen, der bewirkt, dass nicht ständig zwischen Heizen und Kühlen hin- und hergeschaltet wird.

Hat jemand einen Heizungsaktor eines anderen Herstellers und kann mal nachschauen, ob sich dort Heizen und Kühlen per Objekt schalten lässt? Es wäre interessant zu wissen, was der Aktor dann mit dieser Info anstellt , weil er eigentlich immer nach Soll- und Istwert selbst entscheiden kann, wie er welche Stellantriebe ansteuert..

[willf8]

Ja genau, das hatte ich auch im Kopf…

Sorry kann gerade nicht nachschauen.

Aber ich denke konkret an die Situation wenn man z.B. Klimaanlage über Zennio/Intesis KLICs ansteuert, und quasi die Klima “force” an machen will.

On 7 Sep 2023, at 15:43, pfeifix @.***> wrote:

Der MDT-Aktor kann auch ein separiertes Heiz-/Kühlsystem (4-Rohr) ansteuern. In dem Fall wird ein zusätzlicher Kanal benötigt, dann entscheidet der Aktor auch selbst, ob im einen System geheizt oder im anderen gekühlt wird. Für diesen Fall gibt es bspw. die Einstellung einer "Totzone", das ist ein Übergangsbereich zwischen Heizen und Kühlen, der bewirkt, dass nicht ständig zwischen Heizen und Kühlen hin- und hergeschaltet wird.

Hat jemand einen Heizungsaktor eines anderen Herstellers und kann mal nachschauen, ob sich dort Heizen und Kühlen per Objekt schalten lässt? Es wäre interessant zu wissen, was der Aktor dann mit dieser Info anstellt , weil er eigentlich immer nach Soll- und Istwert selbst entscheiden kann, wie er welche Stellantriebe ansteuert..

— Reply to this email directly, view it on GitHub https://github.com/brutella/hkknx-public/issues/135#issuecomment-1710178777, or unsubscribe https://github.com/notifications/unsubscribe-auth/BBQWIPH3CZE3TJQBP5VHTRTXZHFRTANCNFSM5EISCKRA. You are receiving this because you were mentioned.

[pfeifix]

@brutella: Was macht die hkknx-Implementierung, wenn "Aus"=1 ist und gleichzeitig bspw. "Heizen"=1. Wenn ich das Sperrobjekt des Aktorkanals mit meinem Fensterkontakt verbinden würde, würde das bspw. so. zustandekommen (der Aktor setzt alle Stellwerte auf 0% für die Zeit, wo die Sperre am Kanal aktive ist). Was würde die Homekit-GUI anzeigen? Würde die immer zwischen "Heizen" und "Aus" toggeln? Oder überschreibt der Aus-Zustand einen gleichzeitigen Heizen- oder Kühlen-Status solange, bis Aus wieder auf 0 zurückgesetzt wird?

[brutella]

@pfeifix Es kommt auf die Reihenfolge der empfangenen Telegramme an. Wird Aus=1 empfangen, dann wird das Thermostat auf Aus gestellt. Wird danach Heizen=1 empfangen, wird das Thermostat wieder auf Heizen gestellt. Es wechselt also zwischen Aus und Heizen.

Wie ich befürchtet habe gibt es zwischen HomeKit und KNX einen konzeptionellen Unterschied. HomeKit erlaubt das Verändern des Status auf Aus, Heizen, Kühlen, und Automatisch. In KNX entscheidet das immer der Heizungsaktor – korrigiert mich, wenn das falsch ist. Gibt es überhaupt den Bedarf den Status in HomeKit zu verändern?

[pfeifix]

Ich denke Heizen/Kühlen eignet sich nur zur Visualisierung in HomeKit, da dafür die KNX-Schreibobjekte fehlen. Würde es denn gehen, die Auswahl Aus/Heizen/Kühlen/Auto ganz zu unterbinden also dass nur der gelesene Status angezeigt wird, der aber nicht änderbar ist?

Alternativ könnte man im hkknx einfach die Betriebsmodi (über HVAC Mode) wieder variabel für die Heizen/Kühlen/Aus/Standby-Auswahl zuweisbar machen (wie in einer früheren Version schon mal implementiert). Und das dann am besten so, dass man die Lesewerte trotzdem auf die Heizen/Kühlen-Rückmeldung über den HVAC State mappen kann. Dann wäre es für mich stimmig.

(Die bisher vorgesehenen Einzelschalter für die Betriebsmodi Comfort, Economy, Standby, Building Protection würde ich trotzdem bestehen lassen)

[willf8]

Bitte korrigiert mich falls ich mich irre, aber kann man beim Gira Heizungsaktor z.B. über das Objekt Heizen/Kühlenumschalten das nicht vorgeben?

[pfeifix]

Habe gerade mal ins GIRA-Handbuch geschaut und ja, es gibt ein Objekt für die manuelle Umschaltung Heizen/Kühlen, schreibend wie lesend.

Bitobjekte machen also auf jeden Fall Sinn.

Aus MDT-Sicht wäre m. E. aber zusätzlich ein Mapping der Betriebsart (s. o., HVAC Mode) auf jeweils Schreiben Heizen/Kühlen/Auto sinnvoll. (Lesen/Initialisieren so wie in der aktuellen Beta über den HVAC State). Bei „Aus“ würde ich mir eine Kombi aus einem Bitobjekt für Schreiben und dem HVAC State für Lesen/Initialisieren wünschen.

Beispiel:

— Heizen — Schreiben: HVAC Mode Comfort - GA a/b/c, Lesen: HVAC State - GA d/e/f, Initialisieren: HVAC State - GA g/h/i

— Aus — Schreiben: Bitobjekt „Sperre“ (1=Aus, 0=Ein) - GA j/k/l, Lesen: HVAC State - GA d/e/f, Initialisieren: HVAC State - GA g/h/i

[brutella]

@willf8 Liefert der Gira Heizungsaktor den aktuellen Status (Heizen, Kühlen) dann auch über ein 1-Bit-Objekt?

[pfeifix]

Kann ich stellvertretend beantworten.

Laut GIRA-Handbuch https://partner.gira.de/data3/21293210.pdf Seite 42 tut er dies.

[willf8]

@pfeifix Danke!

Bin nur mit Handy unterwegs und da tu ich mich mit den Handbüchern ohne ETS etwas schwer :)

[brutella]

@pfeifix Die Idee mit den unterschiedlichen Datentypen für Schreiben und Lesen würde das Ganze verkomplizieren. Falls ein gesendeter HVAC Status nicht vom MDT Aktor interpretiert wird, dann würde ich einen Workaround über ein Skript vorschlagen. Das Skript würde das Schreiben eines HVAC States auswerten und an andere Gruppenadressen weiterleiten.

Heizen Schreiben: HVAC State - GA a/b/c

Im Skript würde man auf das Telegram an die a/b/c warten, und das Flag Heizen (1) und Kühlen (0) auswerten. Falls 1 (Heizen) gesetzt ist, dann den HVAC Mode Comfort an x/y/z senden.

Wie würdest du den Aus-Status auf ein HVAC State mappen? Es gibt zwar bei dem Datentyp ein Flag Controller Active (laut KNX Spezifikation), aber dieser wird laut MDT Handbuch nicht verwendet.

[pfeifix]

@brutella: Ja, es würde (in den Drop-Down-Listen der hkknx-GUI) etwas komplizierter mit den unterschiedlichen Objekttypen für Schreiben vs. Lesen/Initialisieren. Die Skript-Ausweichlösung geht natürlich immer, das hatte ich mir auch schon überlegt. Einfacher bzw. zuverlässiger wird es natürlich dadurch auch nicht.

Etwas widersprüchlich ist es schon, dass ein HVAC State Objekt überhaupt zum Schreiben angeboten werden soll, da es ja (wie der Name schon sagt) eigentlich nur als Status-Objekt zur Visualisierung gedacht ist (siehe bspw. https://www.knx.org/wAssets/docs/downloads/Marketing/Flyers/HVAC-Use-Cases/HVAC-Use-Cases_de.pdf). Zum Setzen der Betriebsmodi gibt es ja den HVAC Mode (der aber keine Heizen/Kühlen-Vorgabe zulässt, die braucht man aber im Automatikmodus eines Aktors auch nicht, da er das Wissen hat, dies selbst zu entscheiden). Deshalb auch mein Vorschlag, den HVAC Mode (Schreiben) mit dem HVAC State (Lesen/Initialisieren) zu kombinieren.

Die "Aus"-Stellung hätte ich wie erwähnt über ein Bitobjekt realisiert, das beim MDT-Aktorkanal die Sperre setzt (1=Aus, 0=Ein). Bei gesetzter Sperre wird der Stellwert auf 0% gesetzt und es werden keine Telegramme mehr ausgewertet, bis die Sperre wieder aufgehoben wird. Verbindet man das Sperrobjekt mit bspw. einem Fensterkontakt, dann kann man den Wert auch abfragen. Finde das eigentlich eine passende Lösung, soll der Aktor ja für den Fall, dass Fenster im Raum geöffnet sind, nicht heizen. Die "Aus"-Vorgabe über das "Controller Active"-Flag des HVAC State könnte man trotzdem mit anbieten, für Aktoren, die dieses Flag - lesend - unterstützen.

[brutella]

Wenn du den Aus-Zustand über ein 1-Bit-Objekt löst, dann braucht es dazu aber nicht den Datentyp HVAC Status. Aus dem HVAC Status kannst du beim MDT Aktor den Aus-Zustand nicht entnehmen, oder verstehe ich da was falsch. 🤔

[pfeifix]

Korrekt, beim MDT-Aktor geht das wohl nicht. Das mit dem HVAC State habe ich nur geschrieben, um der Einheitlichkeit Rechnung zu tragen, wenn man die HVAC-State-Mappings bei "Heizen", "Kühlen" und "Automatisch" eh anbietet (aus meiner Sicht am Besten in Kombination mit dem HVAC Mode beim Schreiben, da HVAC State ja per Definition nur zum Lesen da ist).

Mein Vorschlag für jeweis Heizen/Kühlen/Auto/Aus, ich würde beide Optionen in den Drop-Downs anbieten:

• Jeweils Bitobjekte für Schreiben/Lesen/Initialisieren
• HVAC Mode für Schreiben, HVAC State für Lesen/Initialisieren

[brutella]

Ist die aktuelle Implementierung in 2.7.0-rc1 soweit in Ordnung, dass ich die Version 2.7.0 veröffentlichen kann?

[brutella]

Da es seit einiger Zeit keine Problemmeldungen bzgl. Thermostate in Version 2.7.0 gibt, nehme ich an, dass alles soweit passt. Version 2.7.0 ist somit offiziell verfügbar.