Hallo,
mit Hilfe des Forums konnte ich erfolgreich FHEM in einer Ferienwohnung installieren.
Konkret läuft dort FHEM auf einem Raspberry (mit HM-MOD-RPI-PCB) worüber ein Homematic Funkthermostat HM-CC-RT-DN angesteuert wird. Die Temperatur wird mit einem DS18B20 am Raspberry gemessen und an das Thermostat gekoppelt.
Allerdings brauche ich eure Hilfe beim Batterieverbrauch.
Die ersten Batterien haben nur ca. 3 Monate gehalten. Die zweiten Batterien habe ich Anfang Oktober eingesetzt und bis jetzt war das System eigentlich im Winterschlaf, d.h. nur regeln auf 8 Grad. Laut Plot den ich per Telegrambot auslese, hat das etwa zu zwei Regelungen pro Tag geführt.
Was kann die Ursache sein, dass die Batterie nur so kurz hält, trotz geringer Beanspruchung? In einem Forumsbeitrag habe ich gefunden, dass das Funkmodul am Thermostat defekt sein könnte. Leider finde ich den Thread nicht mehr.
Könnte es noch andere Ursachen geben?
Danke
Tobias
edit: HM-MOD-RPI-PCB ergänzt
Da du nicht schreibst, welches IO mit welcher firmware du nutzt:
Würde eher auf einen CUL (ohne TS-CUL-firmware) tippen, der den RT zu oft aus dem Schlaf holt...
Angesprochen wird der RT über den HM-MOD-RPI-PCB. Das Firmwareupdate wie in https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi (https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi) habe ich im Dezember 17 gemacht.
Moin
Wieder einmal duerfen wir vieles raten!
Vermutlich hast du den onewire Temperatursensor virtuell mit dem RT gepeert!? Das geht leider massiv auf die Batterie. Ich habe das bei einer fremden Installation auch schon gesehen, zwar mit einem anderen Thermometer, aber das Prinzip bleibt ja gleich.
Ob das an Verbindungsabbruechen oder aehnlichem liegt hat sich mir noch nicht erschlossen!
Habe ich die Tage nicht irgendwo so kleine Temperaturgnuggis gesehen, die man mit HM peeren konnte?
Gruss Christoph
Ja, der OneWire ist ja nach dem Vorgehen im Forum über den Weather Channel virtuell mit dem RT gepairt.
Wie könnte ich denn anders eine externe Temperatur nehmen um nicht immer die Temperatur direkt an der Heizung zu messen?
Hmmm, soweit erkennbar, kann man dem "originalen" IO nicht so einfach beibringen, sich an das Timing eines Batterie-Geräts anzugleichen (kannst ja mal bei dem virtuellen Device schauen, ob man da burst abschalten kann?). Das kann scheinbar nur ein CUL mit der timing-optimierten firmware.
Wenn das mit Burst abschalten nicht geht, würde ich vorläufig empfehlen, das bei der internen Regelung zu belassen; kannst ja mal nachprüfen, ob der RT halbweg sinnvolle Ergebnisse liefert, da ist intern irgendeine Art Korrektur vorgesehen.
Ansonsten hilft nur, einen HM-WT zu kaufen (Bausatz ist günstiger); da sollten die Batterien >1 Jahr jeweils halten.
Ok, vielen Dank für den Hinweis. Dann teste ich das über die Weihnachtsferien.
Hallo Tobias,
am RT musst Du das Register burstRx auf off setzen, um den geringsten Batterieverbrauch zu erreichen.
burstRx on wird nur benötigt, wenn man einen Fensterkontakt oder eine Fernsteuerung peert oder man komfortabel schnell Register am RT ändern möchte, auf Kosten der Batterielebensdauer.
Siehe wiki https://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat#Burst-Modus (https://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat#Burst-Modus).
ZitatHmmm, soweit erkennbar, kann man dem "originalen" IO nicht so einfach beibringen, sich an das Timing eines Batterie-Geräts anzugleichen
Die Nachamung des variierenden Sendeintervals machen nicht die IOs sondern das virtuelle Temperatur Device im CUL_HM Code.
Der RT muss sich dann erst mal auf den Temperatursensor aufsynchronisieren, den also empfangen um dann rechtzeitig zum nächsten Sendezeitpunkt des Temperatursensors aufzuwachen.
Und FHEM muss auch pünktlich senden, was nicht immer gegeben ist.
Damit braucht der Betrieb des RT mit gepeertem Temperatursensor ebenfalls etwas mehr Batterie, als ein Standalone-Betrieb des RT.
Ein HM-Temperatursensor hat nicht die FHEM Sendezeitvarationen und dürfte daher zuverlässiger vom RT empfangen werden können und damit effektiv weniger RT Batteriebelastung erzeugen.
Für möglichst lange Batterielebensdauer in Abwesenheit müsstest Du also den virtuellen Temperatursensor unpeeren und burstRx auf off stellen.
Gruß, Ansgar.
Hallo,
ich konnte es mir jetzt im Urlaub anschauen.
Der aktuelle "Ausfall" des Thermostats lag nicht an der Batterie, sondern das Thermostat war aus "Ins" gegangen und hat deshalb nicht mehr reagiert. Mit meinem beschränkten Fernzugriff konnte ich das nicht erkennen.
Die Stromspareinstellungen gehe ich aber trotzdem an.