Thermostat reagiert extrem langsam

[Laire]

Das Thermostat habe ich auch Manuell stehe, da ich keine Zeitabhängige Steuerung nutze.
Wenn ich die Temperatur am Thermostat verändere, dann ändert sich auch der desired Wert im FHEM Interface.
Aber wenn ich im FHEM Interface bei desired-temp eine andere Temperatur auswähle, z.B.: 20, dann steht dort plötzlich set_desired-temp 20.0 (kein desired-temp mehr).
Vorhin hat er 5 min. gebraucht, bis er an der Heizung den Wert übernommen hat.

Woher kommen diese Verzögerungen?


Achja ich habe in der Liste, wo ich die Temperatur regel noch die Werte on und off. Sind das dann sozudagen 100% und 0% ?

[Laire]

Ok hat sich gerade erledigt, jedenfalls das mit der Verögerung. Habe gelesen, dass nur all 2,5 Minuten die Befehle abgeglichen werden.

Jetzt suche ich nur noch den Befehl, wie ich den Boost auslösen kann und die Bedeutung der on / off Werte

[Waldgeist78]

Hallo,

klingt nach Homematic Thermostaten, wenn es sich um diese handelt dann einfach den Befehl z.Bsp. "set HZ_Schlafzimmer_Clima burstXmit" hinterherschicken.
Dann werden die Werte sofort geschickt...

Viele Grüße

[Laire]

Danke für den Tipp mit dem burst.
Den Befehl für den Boost habe ich jetzt auch raus bekommen:

Code Auswählen Erweitern

set WZ.Heizung1.Regler controlMode boost

[Cruiser79]

Hallo,

klingt nach Homematic Thermostaten, wenn es sich um diese handelt dann einfach den Befehl z.Bsp. "set HZ_Schlafzimmer_Clima burstXmit" hinterherschicken.
Dann werden die Werte sofort geschickt...

Viele Grüße

Ich habe den Burstmodus so verstanden, das er nur bei aktivierten Geräten funktioniert http://www.fhemwiki.de/wiki/HM-CC-RT-DN_Funk-Heizkörperthermostat#Burst-Modus
Da bei Thermostaten per default der Burst Modus aus ist, würde diese ein set burstXmit doch gar nicht erreichen!?

[stromer-12]

Dieser Burstmodus hat mit dem Befehl burstXmit nichts zu tun. Der burstXmit sorgt dafür das das HM Device aufwacht und einen Befehl entgegennimmt und sich dann wieder schlafen legt.

[Cruiser79]

Dieser Burstmodus hat mit dem Befehl burstXmit nichts zu tun. Der burstXmit sorgt dafür das das HM Device aufwacht und einen Befehl entgegennimmt und sich dann wieder schlafen legt.

Um bei einem burstXmit aufzuwachen, muss das Gerät doch aber dauerhaft lauschen, heisst Receiver ist dauerhaft an. Wie soll er sonst das Kommando mitbekommen. Und das geht doch nur mit aktiviertem Burst-Modus, wie hier steht.

Das ist der Vorteil des eingeschalteten Burst-Modus.
Nachteil: Der RT muss den Receiver wach halten. Der RT und alle anderen Burst-Devices erwachen bei jedem Burst (egal für wen) und legen sich dann wieder schlafen.
jeder Burst-trigger kostet Batterie für alle Burst-Geräte im System
wenn Burst enabled ist kostet es dem RT Batteriekapazität

Die andere Variante ist doch nur das 2,5 minütliche Aufwachen und nach neuen Befehlen fragen, heisst Receiver ist nur alle 2,5 Minuten an.

Der RT erwacht alle 2,5 Minuten und dann überträgt die Zentrale die Kommanods.

Und dieses "Receiver dauerhaft an" hatte ich als "eingeschalteten Burst-Modus" verstanden. Ist das so nicht korrekt?

[frank]

Und dieses "Receiver dauerhaft an" hatte ich als "eingeschalteten Burst-Modus" verstanden. Ist das so nicht korrekt?

so sehe ich das auch, => R-burstRx=on.

[strauch]

Spätesten wenn ein Fensterkontakt da ist, muss er aber für Burst aufwachen. Sonst würde er ja den Fensterkontakt nicht mitbekommen. Die Frage ist, wo ist der Unterschied zwischen Burst und normalen Empfang?!

[frank]

Spätesten wenn ein Fensterkontakt da ist, muss er aber für Burst aufwachen. Sonst würde er ja den Fensterkontakt nicht mitbekommen. Die Frage ist, wo ist der Unterschied zwischen Burst und normalen Empfang?!

muss er nicht. kannst du auch unterbinden. auch wenn es keinen wirklichen sinn macht.

wenn burstRx=on, dann schläftt er nicht wirklich. dann lauscht er auf ein burst-signal und wacht bei einem burst-signal auf, um zuschauen, ob die folgenden messages für ihn sind. danach geht er wieder in den "halbschlaf".

[Cruiser79]

Spätesten wenn ein Fensterkontakt da ist, muss er aber für Burst aufwachen. Sonst würde er ja den Fensterkontakt nicht mitbekommen. Die Frage ist, wo ist der Unterschied zwischen Burst und normalen Empfang?!

Genau, wenn ein Fensterkontakt z.B. mit einem TC gekoppelt wird, muss auch burstRx auf on gesetzt werden.

Ein TC oder RT hingegen hat diese Funktion abschaltbar. 'Per default ist dies ausgeschaltet um Batterie zu sparen'. Wenn ein VD gesteuert wird ist der TC ja selbst wach. Wird er aber mit einem Fensterkontakt gekoppelt muss es eingeschaltet werden – sonst verpasst er die message.

Ob das beim koppeln automatisch eingeschaltet wird, weiss ich nicht.

Was meinst du mit "Unterschied zwischen Burst und normalen Empfang"?

Burst bedeutet: Dauerhaft ist der Receiver an und lauscht, z.B. auf burstXmit Befehle.
Normal bedeutet: Alle 2,5 Minuten wird der Receiver eingeschaltet und holt neue Befehle ab.

[martinp876]

burst: eine besondere Sequenz weckt ALLE burst-fähigen devices auf. Der Reciever ist semi-aktiv, wird dann aktiv geschaltet. dann wird auf die Addresse gelauscht und ggf reagiert oder wieder geschlafen.
Burst: kostet Batterie in ALLEN burst devices - unweigerlich.
- ermöglicht schnelle kommunikation

Normal: wenn das device etwas sendet bleibt es hernach kurz auf - die Zentrale hat die chance, kommandos zu senden. Andere Devices sind nicht beeinträchtigt.

Also weitestgehend wie von dir beschrieben.

Bei RTs z.B. ist burst einschaltbar. Wenn der RT auf einen SC reagieren soll (o.ä.) dann muss burst aktiv sein. FHEM versucht, burst beim Peeren einzuschalten. HMInfo versucht beim Prüfen zu kontrollieren, dass es ggf. eingeschaltet ist.
Beides muss nicht zu 100% funktionieren - falls die Konfiguration unterbochen wird kann ein Teil (z.B. einschalten von burst) fehlen.