Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[paul53]

@mariatschi0815 sagte: ein bisschen zu helfen?

Das ist nicht möglich, wenn man die Datenpunkte nicht kennt.

• Was hat es mit "Thermostat Mode" = "32" / "16" auf sich?
• "ZielTemp" ist der Sollwert des Thermostaten?
• Woher kommt "TempAbwesend"?

Zeige bitte alle Datenpunkte (inkl. Werte) des Thermostaten.

[Mariatschi0815]

@paul53 okay, das sind "Eigenheiten" des Thermostats. Die Modi kann ich nur über die bits steuern. Mit "32" schaltet sich das Thermostat aus und setzt die Zieltemperatur (Sollwert) auf 5°C, mit "16" schaltet sich das Thermostat ein und setzt die Zieltemperatur auf den zuvor programmierten Wert bspw. 20°C. TempAbwesend kommt auch vom Thermostat, diesen Wert würde es setzen, wenn man in den Abwesenheitsmodus geht, den man aber nicht schalten kann. Ich würde somit einfach nur den vorhandenen Datenpunkt nutzen.

Hier alle Datenpunkte des Thermostats:

Edit: heating_setpnt_current ist meine ZielTemp.

Die Datenpunkte die ich nutze hab ich nochmal in alias-Punkte übernommen, daher die abweichende Bezeichnung:

[paul53]

@mariatschi0815 sagte: Die Datenpunkte die ich nutze hab ich nochmal in alias-Punkte übernommen

Es fehlt der Alias "TempAnwesend" zu "heating_setpnt_occupied".

Sind die beiden Datenpunkte "occupied" / "unoccupied" read only ?

@mariatschi0815 sagte in Eine Heizung mit drei Fensterkontakten:

mit "16" schaltet sich das Thermostat ein und setzt die Zieltemperatur auf den zuvor programmierten Wert

Das muss sicherlich die Zahl 16 sein? Oder ist der Datenpunkt "spz_system_mode" vom Typ "string"?

[Mariatschi0815]

@paul53 Ich muss zugeben, dass das es hier etwas verwirrend ist. Mit den Alias. TempAnwesend ist die ZielTemp.

[paul53]

@mariatschi0815 sagte: TempAnwesend ist die ZielTemp.

TempAnwesend ist die Vorgabe für die Zieltemperatur bei Anwesenheit bzw. 6 - 8 Uhr / 14 - 22 Uhr. Die Variable TempAnwesend kann nicht mit der variablen Zieltemperatur initialisiert werden, da dann das Problem mit zu niedrigem Sollwert entsteht.

[Mariatschi0815]

@paul53 said in Eine Heizung mit drei Fensterkontakten:

@mariatschi0815 sagte: Die Datenpunkte die ich nutze hab ich nochmal in alias-Punkte übernommen

Es fehlt der Alias "TempAnwesend" zu "heating_setpnt_occupied".

Sind die beiden Datenpunkte "occupied" / "unoccupied" read only ?

@mariatschi0815 sagte in Eine Heizung mit drei Fensterkontakten:

mit "16" schaltet sich das Thermostat ein und setzt die Zieltemperatur auf den zuvor programmierten Wert

Das muss sicherlich die Zahl 16 sein? Oder ist der Datenpunkt "spz_system_mode" vom Typ "string"?

Jetzt hat es erst click gemacht, was du hier gemeint hast. Problem ist das die Datenpunkte ..._current und …_occupied sich sozusagen gegenseitig aktualisieren. Ändere ich current wird occupied auf den selben Wert geschrieben und umgekehrt. Somit müsste ich also mein Problem beheben indem ich eine zusätzliche Variable zur Übergabe einfüge?

Edit: Die Datenpunkte sind beide schreibbar.

Und der Wert ist eine Zahl genau, also sollte ich das noch ändern.

[paul53]

@mariatschi0815 sagte: Ändere ich current wird occupied auf den selben Wert geschrieben und umgekehrt

Wirklich? Das kann ich mir nicht vorstellen.

@mariatschi0815 sagte in Eine Heizung mit drei Fensterkontakten:

Die Datenpunkte sind beide schreibbar.

Dann ist die Rolle "value.temperature" falsch.

[Asgothian]

@paul53 sagte in Eine Heizung mit drei Fensterkontakten:

@mariatschi0815 sagte: Ändere ich current wird occupied auf den selben Wert geschrieben und umgekehrt

Wirklich? Das kann ich mir nicht vorstellen.

Das ist so. Der Thermostat unterstützt einen Attribut im Hersteller spezifischen Cluster (current_heating_setpoint). Damit er aber auch von “Standard” Koordinatoren angesteuert werden kann nimmt er auch Werte auf den im Standard definierten Attribut “occupied_heating_setpoint” aus dem HVAC Cluster.

A.

[Mariatschi0815]

@paul53 said in Eine Heizung mit drei Fensterkontakten:

Dann ist die Rolle "value.temperature" falsch.

Die Rolle wird vom Adapter so vorgegeben, da hab ich keine Handhabe drüber. Würdest du mir trotzdem erklären was die Rolle aussagt und was dann theoretisch die richtige Rolle wäre?

[paul53]

@mariatschi0815 sagte: was die Rolle aussagt

Siehe Doku

@mariatschi0815 sagte in Eine Heizung mit drei Fensterkontakten:

was dann theoretisch die richtige Rolle wäre?

"level.temperature"

Wenn die Rolle im Adapter falsch ist, kann man sie aber im Alias korrigieren.

[paul53]

@mariatschi0815 sagte: eine zusätzliche Variable zur Übergabe einfüge?

Ja, erstelle einen eigenen Datenpunkt für "TempAnwesend" unter "0_userdata.0".

[paul53]

@asgothian
Normalerweise sind “occupied_heating_setpoint” und “unoccupied_heating_setpoint” die Sollwerte, zwischen denen das interne Wochenzeitprogramm umschaltet.

[Mariatschi0815]

@paul53 Ich hab jetzt mal probiert das ganze über eine Variable zu lösen. An den CRONs hab ich erstmal nichts geändert. Um die Variable zu schreiben hab ich einen neuen Trigger eingefügt und eine Abfrage. Jetzt wäre es ja aber so, jedes mal wenn das Fenster auf und zu gemacht wird, wird mein Trigger ausgelöst (was ja nicht nötig wäre) kann ich das noch umgehen? Oder ist der Trigger hier generell überflüssig?

[paul53]

@mariatschi0815 sagte: kann ich das noch umgehen?

Nein, denn der Sollwert bei Anwesenheit kann erhöht und verringert werden, muss aber größer sein, als der Abwesenheits-Sollwert.

[Mariatschi0815]

@paul53 Achso, mein Gedankengang war jetzt der, dass mein Anwesenheitssollwert nur größer sein muss als die 5°C (was einem "Heizung aus" entspricht). Okay, also lässt sich der Trigger nicht umgehen.

Edit: Wenn ich jetzt meine Zeitpläne außerhalb vom Script anpassen möchte, also z.B. Uhrzeiten ändern. Wie könnte ich das umsetzen? Also außerhalb der vis. Da muss ich mich später auch erst noch einarbeiten. Da hab ich auch noch keine Ahnung.
Das würde aber auch nach sich ziehen, dass ich das Script nochmal umbauen muss. Sodass quasi mein CRON-Job neu angestoßen wird, richtig?

[paul53]

@mariatschi0815 sagte: Das würde aber auch nach sich ziehen, dass ich das Script nochmal umbauen muss. Sodass quasi mein CRON-Job neu angestoßen wird, richtig?

Ja. Prinzip

[Mariatschi0815]

Soweit jetzt erstmal mein "Roh-Entwurf".

Jetzt kann ich das ganze doch aber bestimmt noch kompakter gestalten oder? Wegen dem Datenpunkt der mir Zeiten liefert um den Plan fernzusteuern bin ich noch am recherchieren, darum kann ich den Trigger auch noch nicht genau definieren.

[paul53]

@mariatschi0815 sagte: Trigger auch noch nicht genau definieren.

Du benötigst 8 Trigger und Funktionen:

• Uhrzeit ein/aus WT morgens
• Uhrzeit ein/aus WT abends
• Uhrzeit ein/aus WE morgens
• Uhrzeit ein/aus WE abends

[Mariatschi0815]

@paul53 Das brauche ich, um mit einzelnen DP die jeweiligen an/aus Zeiten belgen zu können, oder? An dem Trigger wo gerade nur eine ID hängt müsste ich dann also auch 8 "Trigger-IDs" haben.

Die Stunden in den CRONs muss ich dann durch die entsprechenden IDs ändern.

[paul53]

@mariatschi0815: An dem Trigger wo gerade nur eine ID hängt müsste ich dann also auch 8 "Trigger-IDs" haben.

Nein, erstelle 8 Trigger mit jeweils einer ID. Stoppe nur den zugehörigen Zeitplan und rufe die zugehörige Funktion auf. Alle 8 Funktionen müssen auch bei Skriptstart aufgerufen werden, damit die Zeitpläne nicht erst nach Zeitänderung aktiv sind.

Bei den Minuten ersetze den * gegen eine 0 (oder eine andere Zahl bis 59), da sonst innerhalb der vorgegeben Stunde jede Minute getriggert wird.