HM-CC-TC schneller auf "set desired-temp" reagieren lassen

[ThorstenH]

Hallo,

sobald bei mir ein Fenster geöffnet wird (SC) macht FHEM ein "set TC desired-temp 6.0", was beim nächsten wakeup verarbeitet wird. Ich würde den TC jetzt am liebsten etwas schneller reagieren lassen. Dazu habe ich schon an allen möglichen Stellen etwas über den burst Modus gelesen. Allerdings war dort auch immer die Rede von Warnungen wegen Overload und erhöhtem Batterieverbrauch.

Dazu hätte ich ein paar Fragen:

• Ist es richtig, dass alle Geräte im System mit "R-burstRx on" bei jedem Burst zusätzlich Strom verbrauchen?
• Ist es richtig, dass alle Geräte im System mit "R-burstRx on" konstant zusätzlich Strom verbrauchen?
• Gibt es bezifferbare Erfahrungswerte bezgl. des erhöhten Stromverbrauchs?

Ich beabsichtige folgende Einstellungen zu tätigen:

Code Auswählen Erweitern

set TC regSet burstRx on

In meiner Routine, in der ich dem TC die desired-temp von 6.0 schicke:

Code Auswählen Erweitern

...
    fhem("set ".$tc_climate." desired-temp ".$temp);
    fhem("set ".$tc." burstXmit");
...


Reicht das, um die desired-temp sofort am TC aktiv werden zu lassen? Muss man die VDs auch noch auf burst einstellen, geht das überhaupt?

Viele Grüße
Thorsten

[Samsi]

Hallo Thorsten,

1. Ist m.E. vernachlässigbar, weil wenn Du wartest bis er aufwacht und dann sendest wird er genauso viel strom verbrauchen, vielleicht etwas weniger, aber das wird nichts ausmachen.
2. Das ist Richtig, weil er ab und zu horschen muss ob ein burst Signall kommt
3. Ich hab bei mir burt auf on und auch so da jedes mal wenn ich ein Set-Temp mache sofort ein Burst gesendet wird. Bisher hatte ich keine Probleme. Ich habe seit 2 Monaten NiMh Akkus drin. Am Anfang zeigte er mit 2.7V an, jetzt sind es 2.6  der default LowBatt Alarm ist irgendwo bei 2.1. Wie er bei 2x 1.2V Akku auf 2.7V gekommen ist, ist mir allerdings auch ein Rätsel.

Da es entgegen der Bedienungsanleitung mit Akkus gut funktioniert ist mir der Zusätzlich Verbrauch Schnuppe. Sobald zu wenig Saft drauf ist kommen halt neue Akkus rein.

Ich denke das was Du da machst wird reichen, aber wie gesagt ich habe einfach bei den Thermostaten so eingestellt, das immer ein Burst gesendet wird, wenn ich im Frontend etwas ändere. Ich will gleich wissen ob die Einstellung übernommen wurde und nicht x Minuten später. So oft ändre ich die Temperatur eh nicht. Mit overload hatte ich bei meinen 2 Thermostaten noch keine Probleme (außer als ich mal bei beiden das komplette Wochenprogramm geändert hatte, war es etwas knapp, kommt aber noch seltener vor), wenn Du noch mehr hast, die du gleichzeitig änderst, könnte das anders aussehen.

Grüße

[LuckyDay]

Sorry ich verstehe mal wieder die Frage nicht 

du hast doch eh schon Fenstersensoren an den TC angelernt, also ändert sich doch nichts bei dir im TC, es wacht eh schon bei jedem neuen Fenstersignal auf
und zwar von allen deinen Fenstern.

warum möchtest du auch noch am VD etwas ändern? , bei dem kann Fhem eh nur zuhören in der Regelphase

[ThorstenH]

Erst mal Danke für die Antworten.

@Samsi:
zu 1): bei der Frage stand eigentlich "alle" im Vordergrund. Wenn also ein Fensterkontakt in der Küche "open" meldet, verbraucht dann jeder TC im Haus zusätzlich Strom (auch im Wohnzimmer, Schlafzimmer, ...). Mit jedem neuen Fensterkontakt irgendwo im Haus würde der TC dann *jeweils* mehr Strom verbrauchen. Irgendwann wäre das dann nicht mehr vernachlässigbar, oder?

zu 2): die Frage ist so zu verstehen: verbraucht ein burst-enabled device konstant mehr Strom oder nur wenn ein burst von FHEM gesendet wird? (oder beides?).

zu 3): wahrscheinlich ist dannn dabei auch noch wichtig, wieviele Sensoren mit burst du in Gebrauch hast (auch wenn er logisch nichts mit dem TC zu tun hat). Oder?

@ fhem-hm-knecht:
Kein Problem . Ich habe keine Fenstersensoren an den TC angelernt (soll auch so sein). Ohne die VDs zu ändern, gäbe es immer noch eine Latenz, bis der VD aufwacht, um vom TC den neuen Sollwert für die Ventilöffnung zu bekommen. Mit burst wäre das (evtl.) nicht der Fall. Die Frage ist, ob der VD überhaupt burst unterstützt oder man diese Latenz hinnehmen muss. Jetzt verstanden?

[Samsi]

Hallo Thorsten,

Das Thermostat verbraucht konstant mehr Strom weil er ja die ganze zeit lauschen muss ob ein Burst kommt. Selbst wenn jetzt tatsächlich 100 Bursts über den Tag verteilt kommen die er dann noch überprüfen muss ob Sie an Ihn adressiert sind, wird diese Zusätzlich Überprüfung im Verhältnis zu den ohnehin 24 Stunden Empfangsbereitschaft nicht mehr viel ausmachen. Das Thermostat sendet schließlich ohnehin alle 3 Minuten, also 480 mal am Tag und das senden kostet sicherlich mehr Strom als die zusätzlich Burst-Überprüfung.

Ich würde mir darüber nicht so viele Gedanken machen und es einfach probieren. Deine Batterien werden deshalb nicht nach 2 Wochen leer sein.

[ThorstenH]

Habe ich mir auch gedacht. Probieren geht hier wohl über studieren. Schlimmstenfalls muss ich neue Batterien kaufen 

Ich habe das jetzt so gelöst, dass das erste Öffnen eines Fensters in einem Raum die Temperatur per burst runtersetzt, die nachfolgenden Fenster dann ohne Burst (sicherheitshalber). Erst mal positiv getestet, jetzt noch der Praxistest über ein paar Tage hinweg...

Code Auswählen Erweitern


sub OnWindowOpenTurnOffDesiredTemp($$)
{
    my ($device,$event) = @_;
    my ($tc_climate) = "";
    my ($tc) = "";
    my ($temp) = "6.0";
   
    $tc = &GetTCByWindowContact($device);
   
    if ($tc eq "")
    {
        Log(1,"*** OnWindowOpenTurnOffDesiredTemp: ".$device." [IGNORED]");
        return;
    }
   
    $tc_climate = $tc."_climate";
    #Log(1,"*** OnWindowOpenTurnOffDesiredTemp: ".$device." ==> tc: ".$tc."; tc_climate: ".$tc_climate);

    # Burst nur verwenden, falls sich die Temperatur (höchstwahrscheinlich) unterscheidet
    my ($currTemp) = ReadingsVal($tc_climate, "desired-temp", $temp);
    my ($useBurst) = ($currTemp ne $temp);
   
    fhem("set ".$tc_climate." desired-temp ".$temp);
   
    # Burst verwenden?
    if ($useBurst)
    {
        fhem("set ".$tc." burstXmit");
        Log (1, "*** OnWindowOpenTurnOffDesiredTemp: set ".$tc_climate." desired-temp ".$temp." with burstXmit (device: ".$device."; event: ".$event.")");
    }
    else
    {
        Log (1, "*** OnWindowOpenTurnOffDesiredTemp: set ".$tc_climate." desired-temp ".$temp." without burstXmit (device: ".$device."; event: ".$event.")");
    }
}


[Samsi]

Hallo,

das sehe ich bei den Bursts eher das Problem, das wenn Du das von den Fensterkontakten über FHEM machst, das denn der HMLAN eher einen overload bekommt, wenn viele Fenster schnell auf oder zu gemacht werden. Aber zum Glück hast Du ja da die nachfolgenden Fenster ohne burst gemacht.

Das ist halt der Vorteil, wenn Du die Fensterkontakte direkt mit dem Thermostat peerst: Das Sendekontingent vom HMLAN wird nicht so belastet.

die nachfolgenden Fenster dann ohne Burst (sicherheitshalber).

Wäre es da nicht sinnvoller einfach zu prüfen, ob die Temperatur schon abgesenkt ist , und wenndann  musst Du ja keine neues 'Desired Temp' mehr schicken?

[betateilchen]

Das Thermostat verbraucht konstant mehr Strom weil er ja die ganze zeit lauschen muss ob ein Burst kommt.

Vernachlässigbar. (wer es nicht glaubt, soll einfach nachmessen!)

[ThorstenH]

Ok, ich hole weiter aus.

Ich habe jetzt schon fast 2 Jahre schlechte Erfahrungen mit den Thermostatkomponenten von Homematic gemacht. Insbesondere mit gepeerten SCs. Ich wollte den TC am Drehrad, per Komfortemperaturtaste und per Webinterface über fhem steuern können, ohne Wochenprogramm. Aber das lässt die TC Firmware einfach nicht zu.

Stattdessen wird z.B. sporadisch im Manu Modus die desired-temp verändert, ohne dass fhem davon etwas mitkriegt und ohne dass jemand irgendwo dran dreht, z.B. mitten im Winter 2:00 Uhr Nachts im Kinderzimmer, so dass meine Tochter morgens als Eiszapfen aufwacht (ist gar nicht so lustig). Dabei geht *nichts* auffälliges über das Netz (weder über TC -mit Wireshark untersucht-, noch über Funk, wenn man dem HMLAN trauen darf).   

Die Tage habe ich jetzt einen Schlussstrich gezogen und das ganze mittels fhem so nachprogrammiert, dass es genau das macht, was ich verlange (s.o.), im Cent Modus. Ist wesentlich stressfreier und zuverlässiger als dem TC alles zu überlassen. Die Fensterkontakte sind die letzten Features, die noch fehlten, wobei ich auf das "Hochsetzen" der Temperatur nach Schliessen der Fenster bewusst verzichtet habe.

Inzwischen habe ich hier zuhause wieder einen ziemlich hohen WAF, geregelte Temperaturen in allen Zimmern und endlich meine Ruhe. Was will man mehr? 

[betateilchen]

Stattdessen wird z.B. sporadisch im Manu Modus die desired-temp verändert, ohne dass fhem davon etwas mitkriegt und ohne dass jemand irgendwo dran dreht, z.B. mitten im Winter 2:00 Uhr Nachts im Kinderzimmer, so dass meine Tochter morgens als Eiszapfen aufwacht (ist gar nicht so lustig). Dabei geht *nichts* auffälliges über das Netz (weder über TC -mit Wireshark untersucht-, noch über Funk, wenn man dem HMLAN trauen darf).

Danke.

Endlich mal jemand, der die von mir schon identisch beschriebenen kranken Verhaltensweisen dieser Komponenten bestätigt.
Genau aus diesem Grund habe ich bei mir alle TC/VD/SC Kombinationen durch RT-DN/SC ersetzt. Bis auf eine Kleinigkeit ist seither alles, wie es sein soll.