HM-CC-RT-DN bei leeren Akkus auf 31° geheizt

Begonnen von JoeALLb, 02 Februar 2015, 09:36:25

Vorheriges Thema - Nächstes Thema

JoeALLb

Hallo,

Wir waren letzte Woche auf Urlaub und als ich wieder nach Hause kam, hatten wir im Wohnzimmer 31°.
Es stellte sich heraus, dass bei einem HM-CC-RT-DN die Akkus leer waren.

Nun stellt sich die Frage, warum das Ventil zu 100% geöffnet wurde? Gibt es einen Wert, den ich
als Ventilöffnung für diesen Fall vorgeben kann? "valveErrPos" hat damit wohl nichts zu tun?

Danke, beste Grüße
Joe
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

Mr. P

Hej Joe,

also eigentlich hat genau dieser Wert damit zu tun.
Bevor die Steuerung auszufallen droht, stellt sich der RT auf diesen Wert.
Das selbe hatte ich bei mir auch schon einmal. Reguläre Befehle hat der Thermostat nicht mehr entgegen genommen - reagiert allerdings noch auf das Ändern des valveErrPos-Wertes.
Greetz,
   Mr. P

strauch

Nunja die Frage ist ja an welcher Stelle der Akku leer gegangen ist und ob der DN überhaupt Zeit hatte zu reagieren. Vielleicht ist er beim Heizen auch ausgegangen und das Ventil stand weiter offen. Dafür müsste man mal die Daten sehen.
Normalerweise sieht man ja auch die Volt Zahl, wenn das Ding auf 2,2V steht würde ich da vielleicht vor meinem Urlaub neue Akkus einlegen.
FHEM 5.6 VMware mit Debian. 1 CUL für FS20 und HMLAN für Homematic, HM-CC-RT-DN, HM-LC_Sw1PBU-FM, HM-LC-Bl1PBU-FM,  HM-SEC-SC, HM-SEC-SC-2, HM-LC-Sw1-Pl2, HM-Sec-RHS, ASH2200, FHT80B, S20KSE, Sonos, XBMC, FB_Callmonitor, SMLUSB, Arduino Firmata, uvm.

hermannk

#3
Hallo Joe,

In der "Bau- und Bedienungsanleitung" (Best.-Nr,: 132639, Version 1.0, Stand: April 2014) heißt es dazu auf Seite 3:

ZitatFällt die Batteriespannung auf einen Wert unterhalb 2,1 V, wird im Display das Batterie-Symbol eingeblendet. Sollte das Batterie-Symbol über einen längeren Zeitraum nicht bemerkt werden, fährt der Heizkörperthermostat die Ventilstörposition an, sobald die Batteriespannung unter 2,0 V sinkt. Dadurch wird verhindert, dass das Gerät wegen zu geringer Batterieleistung an einer undefinierten Ventilposition verharrt und der Raum zu stark auskühlt. Werksseitig ist die Ventilposition auf 15 % voreingestellt.

Was das in der Praxis bedeutet, hängt von der Vorlauftemperatur ab. Bei mir würden 15 % Ventilöffnung etwa 10 bis 15 Grad ergeben. Ich halte den Wert (15 %) für sinnvoll und würde den nicht
ändern.

Angeregt durch deine Frage habe ich mir mal die Batteriespannungen aus den Logs angesehen. Einerseits ist es betrüblich, wie die Spannungen unaufhaltsam dahinsiechen. Anderseits scheint mir die
Vorwarnzeit auch nicht allzu knapp bemessen. Ich habe mal den Plot und das Script angehängt. Ließe sich so etwas nicht Perl-mäßig in FHEM integrieren oder wäre das zu verspielt?

strauch

So ein Plot, kannst du mit FHEM Boardmitteln auch machen. Aber wozu plotten, ich hab ne Funktion die einfach bei 2,2V warnt und gut ist.
FHEM 5.6 VMware mit Debian. 1 CUL für FS20 und HMLAN für Homematic, HM-CC-RT-DN, HM-LC_Sw1PBU-FM, HM-LC-Bl1PBU-FM,  HM-SEC-SC, HM-SEC-SC-2, HM-LC-Sw1-Pl2, HM-Sec-RHS, ASH2200, FHT80B, S20KSE, Sonos, XBMC, FB_Callmonitor, SMLUSB, Arduino Firmata, uvm.

hermannk

#5
ZitatSo ein Plot, kannst du mit FHEM Boardmitteln auch machen.

Und wie? Ich habe noch keine Methode gefunden, die Logs verschiedener Geräte in einem Plot zusammenzufassen (z.B. Plot der Innen- gegen die Außentemperatur).

ZitatAber wozu plotten, ich hab ne Funktion die einfach bei 2,2V warnt und gut ist.

Zum einen mag ich Bildchen. Wie heißt es so schön? Ein Bild sagt mehr... Hier kann ich z.B. ablesen, dass die Vorwarnzeit im Bereich von Monaten liegt.

Aber mal konkret. Wie wird die Warnung mitgeteilt? Per E-Mail?

peterchen89

Du kannst als plotfunction verschiedene Geräte und Readings angeben und dann in den gplot-Files entsprechend als <SPEC1>, <SPEC2> usw. nutzen.
FHEM 5.5 auf HP ProLiant MicroServer G7 N54L 8 GB Ubuntu 14.04 LTS.
1x HM-CFG-LAN, 1x HM-CFG-USB, 7x HM-CC-RT-DN, 5x HM-SEC-SC-2, 1x HM-SEC-SCo, 2x HM-TC-IT-WM-W-EU, 2x HM-LC-Sw1-Pl, 2x HM-ES-PMSw1-Pl, 4x HM-PB-2-WM55-2, 1x HM-PB-6-WM55, 1x HM-WDS10-TH-O, 1x CUL433, 6x Pollin Funksteckdose

strauch

#7
Zitat von: hermannk am 02 Februar 2015, 11:45:23
Und wie? Ich habe noch keine Methode gefunden, die Logs verschiedener Geräte in einem Plot zusammenzufassen (z.B. Plot der Innen- gegen die Außentemperatur).Aber mal konkret. Wie wird die Warnung mitgeteilt? Per E-Mail?

für so einen Fall würde ich mir einen extra log machen:
define FileLog_Batterylevel Filelog ./log/batterylevel-%Y.log .*:batteryLevel.*

Ansonsten sollte das auch mit logproxy gehen, das habe ich mir aber noch nicht angeschaut, oder wie peterchen schrieb. Wenn du dann noch bei allen Device event-on-change-reading hast dürfte das auch kein großes logfile werden.

Und bei der SVG Datei muss ein
attr fixedrange year

Damit das ganze Jahr angezeigt wird....

Zitat von: hermannk am 02 Februar 2015, 11:45:23
Aber mal konkret. Wie wird die Warnung mitgeteilt? Per E-Mail?

Ja wird per E-Mail mitgeteilt. Im Fhemwiki steht wie es geht.
FHEM 5.6 VMware mit Debian. 1 CUL für FS20 und HMLAN für Homematic, HM-CC-RT-DN, HM-LC_Sw1PBU-FM, HM-LC-Bl1PBU-FM,  HM-SEC-SC, HM-SEC-SC-2, HM-LC-Sw1-Pl2, HM-Sec-RHS, ASH2200, FHT80B, S20KSE, Sonos, XBMC, FB_Callmonitor, SMLUSB, Arduino Firmata, uvm.

frank

hallo,

ich glaube ihr solltet mal öfter ein update machen.  ;)

im svg editor werden bereits seit einiger zeit alle vorhandenen plotquellen (filelog, dblog, logproxy, fhem.log) parallel genutzt. einfach mal reinschauen und jedes x-beliebige reading aus jedem x-beliebigen filelog miteinander plotten. einfach nur zusammenklicken und fertig.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

strauch

Update mach ich oft genug, das Problem ist aufzuarbeiten, was so alles neues schönes Programmiert wurde ;-). Aber ich logge mein Batterylevel auch nirgends mit.
FHEM 5.6 VMware mit Debian. 1 CUL für FS20 und HMLAN für Homematic, HM-CC-RT-DN, HM-LC_Sw1PBU-FM, HM-LC-Bl1PBU-FM,  HM-SEC-SC, HM-SEC-SC-2, HM-LC-Sw1-Pl2, HM-Sec-RHS, ASH2200, FHT80B, S20KSE, Sonos, XBMC, FB_Callmonitor, SMLUSB, Arduino Firmata, uvm.

reibuehl

Im FHEM Wiki ist die Batterieüberwachung von HomeMatic Geräten eigentlich ganz gut erklärt: http://www.fhemwiki.de/wiki/Batterie%C3%BCberwachung.
Reiner.

JoeALLb

Danke für die ganzen Antworten.

Laut Log sendete mein HM-CC-RT-DN noch 2.2V bis zuletzt!
Laut Log war aber auch der Acutatot nur bei 15% Dennoch hatte ich eine measureed-temp von 39,7° üner mehrere Tage.
Ärgerlich! Werde diesen Wert wohl deutlich niedriger setzen müssen.

Das Logging in einen Plot habe ich geschafft, jedoch schaue ich diesen nicht täglich an!

Der Wiki-Eintrag war mit eigentlich bekannt, jedoch war ich mir nicht sicher, ob "valveErrPos" der korrekte Wert ist.


Danke!
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

Mr. P

Hej Joe,

2,2V ist die magische Untergrenze. Kleinere Werte wären mir im Log noch nicht aufgefallen. ;-)
Aber ich hatte einmal ein ähnliches Problem wie du und seither ist bei mir die Error-Position auf 0% gesetzt.
Bei einem Haus, wo etwas Einfrieren könnte, würde ich freilich etwas aufgedreht lassen - in den meisten Wohnungen sollte sowas aber nicht passieren können und im schlimmsten Fall ein kühler Abend bevor stehen.
Greetz,
   Mr. P

strauch

#13
Was hast du denn für eine Vorlauftemperatur. Ich würde bei mir selbst mit 100% Öffnung keine Raumtemperatur von 39°C schaffen. (Vorlauf soll ca. 41°C). Beim alten Thermostat wurde oft auch Unsinn geschickt wenn die Batterien den Geist aufgaben. Hast du denn Akkus oder Batterien im Antrieb?
Batterien haben einen linearen Spannungsverlust. Akkus (gerade Eneloop) ( http://www.eneloop.eu/uploads/pics/capacity_icon4_01.gif ) haben zu Anfang einen starken Abfall bleiben dann lange stabil und fallen zum Schluss rapide ab, vielleicht geht das für den DN zu schnell am Ende der Laufzeit?

Dann wäre es vielleicht Sinnvoll für Akkus die Warnung von 2.1 auf vielleicht 2.2 oder 2.3 rauszusetzten. Vielleicht sollte ich wirklich mal die Laufzeit mitplotten und parallel in welche Batterien und Akkus reinpacken. Hab eh gerade Bausätze und 2 kommen in den gleichen Raum, da kann ich das gut vergleichen.
FHEM 5.6 VMware mit Debian. 1 CUL für FS20 und HMLAN für Homematic, HM-CC-RT-DN, HM-LC_Sw1PBU-FM, HM-LC-Bl1PBU-FM,  HM-SEC-SC, HM-SEC-SC-2, HM-LC-Sw1-Pl2, HM-Sec-RHS, ASH2200, FHT80B, S20KSE, Sonos, XBMC, FB_Callmonitor, SMLUSB, Arduino Firmata, uvm.

JoeALLb

Ich hatte Akkus drinn, aber in diesem keine Enveloops. Diese sind jetzt drinnen.
Werde auch mal die Logs von Enveloops prüfen, vielleicht heute Abend.

Die Volt waren 11 Tage auf 2,2V, danach die Störposition.
davor war nur 9 Tage 2.3V
davor war 20 Tage 2.4V.

Ging also irgendwie relativ schnell.
Meine Vorlauftemperatur ist nicht soo hoch, wenn ich die Heizung auf 100% manuell drehe, bekomme ich nie solch eine Hitze zusammen ;-)
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270