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
<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.
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.
ZitatIn 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)
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.
man könnte vielleicht einfach immer gleich ein BurstXmit hinterherschicken...
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.
Zitat von: rasti am 21 Februar 2016, 17:02:24
man könnte vielleicht einfach immer gleich ein BurstXmit hinterherschicken...
@rasti: Wie müsste der Befehl aussehen für BurstX?
Zitat von: zap am 20 Februar 2016, 13:37:01
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.
Zitat von: rasti am 21 Februar 2016, 17:02:24
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
ZitatEs 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:
data-valve="DEVICE:READING
Zitat von: setstate am 23 Februar 2016, 08:42:48
Man muss nur das mit Device angeben, dann wird der Wert von einem anderen Device geholt:
data-valve="DEVICE:READING
Kann man diese "DEVICE:READING" Syntax eigentlich bei allen Widget verwenden oder nur bei bestimmten?
Zitat von: setstate am 23 Februar 2016, 08:42:48
Man muss nur das mit Device angeben, dann wird der Wert von einem anderen Device geholt:
data-valve="DEVICE:READING
Kann man diese "DEVICE:READING" Syntax eigentlich bei allen Widget verwenden oder nur bei bestimmten?
Zitat von: zap am 23 Februar 2016, 08:54:23
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:
elem.addReading('valve');und im update Teil muss sowas stehen:
base.elements.filterDeviceReading('valve',dev,par)Umgestellt sind u.a. : Switch, Push, Button, Spinner, Select, PageTab, Label, Input, Range ...
Zitat von: setstate am 23 Februar 2016, 08:42:48
Man muss nur das mit Device angeben, dann wird der Wert von einem anderen Device geholt:
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
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.
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.
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
Zitat von: BasWeg am 23 Februar 2016, 11:15:30Da 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
Zitat von: skuggy am 23 Februar 2016, 07:26:02
@rasti: Wie müsste der Befehl aussehen für BurstX?
Ist es möglich den BurstX mitzusenden? Wenn ja, wie müsste das aussehen?
Danke
Zitat von: skuggy am 25 Februar 2016, 06:51:43
Ist es möglich den BurstX mitzusenden? Wenn ja, wie müsste das aussehen?
Danke
du müsstest jedesmal wenn
set HM_XXXXXX_Clima desired-temp .....
gesendet wird sofort ein
set HM_XXXXXX_Clima burstXmit
hinterhersenden. Geht mit cmdalias
Die elegante Methode ist das aber nicht, da es eigentlich unnötige Funklast erzeugt,
nur weil du zu bequem bist ein paar Minuten auf die richtige Anzeige zu warten.
Den js-Code des Widget umzuschreiben wäre da wohl besser.
Vorschlag an setstate: solange das Reading state auf "set_desired-temp ...." steht,
das Thermostat dunkler darstellen/verschatten oder irgendwie anders graphisch
drauf aufmerksam machen, dass das HM-Thermostat die Info noch nicht hat....
Gruss
Ralf
Find ich jetzt nicht so toll. Nicht jeder nutzt CUL_HM und hat in state diesen Text drin stehen.
Ich bin für eine Lösung, die unabhängig vom FHEM Device funktioniert.
Zitat von: zap am 25 Februar 2016, 11:05:04
Find ich jetzt nicht so toll. Nicht jeder nutzt CUL_HM und hat in state diesen Text drin stehen.
Ich bin für eine Lösung, die unabhängig vom FHEM Device funktioniert.
Naja, momentan funktioniert es mit HM ja auch, nur halt mit dieser etwas lästigen EInschränkung,
dass wenn man die Temperatur verstellt, die Regleranzeige das erstmal nicht widergibt..
Für einen unbedarften Benutzer ist das sehr verwirrend, aber wenn man weiss dass das Thermostat
ggf. erst ein paar Minuten später den neueingestellten Sollwert anzeigen wird, ist das OK.