Thermostat Widget setzt Desired Temp automatisch zurück

[zap]

Seltsamer Effekt bei einem Thermostat Widget: Ich stelle die Zieltemperatur 1. Ich sehe links unten eingeblendet den Set-Befehl Richtung FHEM. In FHEM wird die neue Zieltemperatur gesetzt.
Tja, und nach einiger Zeit springt die Zieltemperatur im Widget auf den alten Wert zurück und auch in FHEM wird wieder der alte Wert eingestellt.

Code

Code Auswählen Erweitern

<div data-type="thermostat" data-device="HM_KL_AZ_HZ"
  data-get="KL-AZ-HZ.4.SET_TEMPERATURE"
  data-set="datapoint 4.SET_TEMPERATURE"
  data-valve="KL-AZ-HZ.4.VALVE_STATE"
  data-unit="%B0"
  data-mincolor="#ff0000"
  data-maxcolor="#ff0000"
  data-fgcolor="#ff8000"
  class="large">
</div>


UPDATE: oh, interessanter Effekt. Ich habe ein Homematic Wandthermostat mit einem Heizkörperthermostat gekoppelt. Das Widget greift auf das Heizörperthermostat zu. Wenn ich also die Zieltemperatur des Heizkörperthermostaten direkt ändere, scheint diese vom Wandthermostaten nach kurzer Zeit überschrieben bzw. zurück gesetzt zu werden. Sieht also so aus, als müsste ich beim Thermostat-Widget das Device des Wandthermostaten hinterlegen. Leider hat der keinen Datenpunkt für die Ventilöffnung. Lässt sich aber verschmerzen.

[setstate]

Kenne ich. Beim HM bleibt die desired-temp eine ganze Weile beim alten Wert. In der Zwischenzeit steht aber STATUS auf  set_desired-temp 25. Erst wenn der Wert auch beim Device angekommen und geändert ist, ist das Reading auch aktuell. Wenn dazwischen ein neues Versenden der Daten erfolgte, steht dann im FTUI wieder der alte Wert. Aber nach einiger Zeit kommt dann auch der neue.

In einer der vorherigen Versionen vom Thermostat habe ich STATUS "set_desired-temp xx" ausgewertet und zur Anzeige herangezogen. Jetzt passiert das nicht mehr. Es irritiere mich auch schon 2-3 mal und ich werde das wieder verbessern.

[kvo1]

In einer der vorherigen Versionen vom Thermostat habe ich STATUS "set_desired-temp xx" ausgewertet und zur Anzeige herangezogen. Jetzt passiert das nicht mehr. Es irritiere mich auch schon 2-3 mal und ich werde das wieder verbessern.

Danke ! (habe auch HM)

[setstate]

Das geht doch nicht zu optimieren. Wenn der Thermostat zyklisch seine Werte übermittelt, ist auch das set_desired-temp xx nicht mehr verfügbar. Man bekommt also nirgends mit, ob ein Wert geändert wurde.
Erst wenn die Änderung beim Device angekommen ist, erscheint beim nächsten Datenübermitteln der neue Wert.

[rasti]

man könnte vielleicht einfach immer gleich ein BurstXmit hinterherschicken...

[zap]

Ich glaube in meinem Fall ist das Problem anders gelagert. Ich nutze ja eine CCU mit FHEM Anbindung, d.h. die Thermostate werden über die CCU gesteuert. Hier gibt es nun 2 Dinge zu beachten:

1. Per Default setze ich Werte in CCU Devices per Value(). Daher werden Änderungen erst mit einiger Verzögerung an das Thermostat weiter gegeben. Das habe ich nun auf State() geändert, das die Werte direkt an das Thermostat übermittelt.

2. Ich habe in der CCU ein virtuelles Device (Gruppe mit Thermostat, Wandthermostat und Fensterkontakten) angelegt. Wenn man nun trotzdem die Desired Temp in einem der Thermostate direkt ändert, scheint das (in manchen Fällen) von dem virtuellen Device überschrieben zu werden (scheint eine Art Master zu sein). Das werde ich lösen, indem ich die virtuellen CCU Devices in meiner FHEM-CCU Schnittstelle besser berücksichtigen werde, sodass man dann im Thermostat-Widget direkt das virtuelle Device ansprechen kann. Im Prinzip ist das in der CCU Doku auch so beschrieben: Wenn eine Gruppe angelegt wurde, soll man die darin enthaltenen Geräte nur noch über die Gruppe steuern.

Mit diesen Anpassungen in einer schnell hingefrickelten Testversion ist bei mir der beschriebene Effekt nicht mehr aufgetreten.

Wie sich das bei Einsatz von CUL_HM lösen lässt, weiß ich allerdings nicht, da ich das nicht nutze.

[skuggy]

man könnte vielleicht einfach immer gleich ein BurstXmit hinterherschicken...

@rasti: Wie müsste der Befehl aussehen für BurstX?

[Thorsten Pferdekaemper]

UPDATE: oh, interessanter Effekt. Ich habe ein Homematic Wandthermostat mit einem Heizkörperthermostat gekoppelt. Das Widget greift auf das Heizörperthermostat zu. Wenn ich also die Zieltemperatur des Heizkörperthermostaten direkt ändere, scheint diese vom Wandthermostaten nach kurzer Zeit überschrieben bzw. zurück gesetzt zu werden. Sieht also so aus, als müsste ich beim Thermostat-Widget das Device des Wandthermostaten hinterlegen. Leider hat der keinen Datenpunkt für die Ventilöffnung. Lässt sich aber verschmerzen.

Hi,
klar, wenn man Heizungs- und Wandthermostat peert, dann hat nur noch der Wandthermostat das sagen. Er setzt alle paar Minuten die desired-temp der gepeerten Heizungsthermostate wieder auf "seinen" Wert. Ich finde das auch richtig so.
Die Ventilöffnung wird immer vom Heizungsthermostat selbst berechnet. Es wäre ganz nett, wenn das Thermostat-Widget  die Möglichkeit hätte, auch etwas wie ein  data-valve_device anzubieten.

man könnte vielleicht einfach immer gleich ein BurstXmit hinterherschicken...

Das dann aber bitte nur, wenn es konfigurierbar ist. Bei mir funktioniert das momentan wunderbar auch so und ich will keine unnötigen Bursts haben.

Gruß,
   Thorsten

[setstate]

Es wäre ganz nett, wenn das Thermostat-Widget  die Möglichkeit hätte, auch etwas wie ein  data-valve_device anzubieten.

Man muss nur das mit Device angeben, dann wird der Wert von einem anderen Device geholt:

Code Auswählen Erweitern

data-valve="DEVICE:READING

[zap]

Man muss nur das mit Device angeben, dann wird der Wert von einem anderen Device geholt:

Code Auswählen Erweitern

data-valve="DEVICE:READING

Kann man diese "DEVICE:READING" Syntax eigentlich bei allen Widget verwenden oder nur bei bestimmten?

[zap]

Man muss nur das mit Device angeben, dann wird der Wert von einem anderen Device geholt:

Code Auswählen Erweitern

data-valve="DEVICE:READING

Kann man diese "DEVICE:READING" Syntax eigentlich bei allen Widget verwenden oder nur bei bestimmten?

[setstate]

Kann man diese "DEVICE:READING" Syntax eigentlich bei allen Widget verwenden oder nur bei bestimmten?

Nur bei denen, die ich schon darauf umgestellt habe. 
Zu erkennen:
im init Teil sowas:

Code Auswählen Erweitern

elem.addReading('valve');

und im update Teil muss sowas stehen:

Code Auswählen Erweitern

base.elements.filterDeviceReading('valve',dev,par)

Umgestellt sind u.a. : Switch, Push, Button, Spinner, Select, PageTab, Label, Input, Range ...

[Thorsten Pferdekaemper]

Man muss nur das mit Device angeben, dann wird der Wert von einem anderen Device geholt:

Code Auswählen Erweitern

data-valve="DEVICE:READING

Cool, das gibt's also schon.
...jetzt fehlt mir noch eine Lösung für Wandthermostate, die mit mehreren (bei mir bisher 2) Heizungsthermostaten gepeert sind. Vielleicht ist das aber auch nicht wirklich wichtig.
Gruß,
   Thorsten

[BasWeg]

Hi,

ich hatte das bei mir so gelöst, dass ich für das Wandthermostat ein UserReading "ValvePosition" definiert hatte in welchem der Wert des Heizkörperthermostat landet.

Code Auswählen Erweitern

attr BAD.Wandthermostat_Climate userReadings ValvePosition {ReadingsVal("BAD.Heizung_Clima","ValvePosition",0)}

Da bei uns Wohn- und Esszimmer sich ein Wandthermostat teilen schreibe ich dort den "Durchschnittswert" der beiden Heizkörperthermostate rein.

Code Auswählen Erweitern

attr EZ.Wandthermostat_Climate userReadings ValvePosition {(ReadingsVal("EZ.Heizung_Clima","ValvePosition",0)+ReadingsVal("WZ.Heizung_Clima","ValvePosition",0))/2.0}

Somit kann ich desired_temp, measured_temp und ValvePosition direkt vom Wandthermostat abgreifen und brauche die oben genannte Brücke mit "DEVICE:READING" nicht.

Viele Grüße
Bastian

[Thorsten Pferdekaemper]

Da bei uns Wohn- und Esszimmer sich ein Wandthermostat teilen schreibe ich dort den "Durchschnittswert" der beiden Heizkörperthermostate rein.

Hi,
Danke für die Anregung. Das ist zumindest besser als nichts.
Gruß,
   Thorsten