Probleme mit Batterielebensdauer CUL_HM_HM_SEC_SC

Begonnen von fidel, 01 November 2013, 20:24:00

Vorheriges Thema - Nächstes Thema

fidel

Hallo Martin,

ich habe mir vor ca. 2 Wochen Stellmotor Thermostat und Magnetkontakt von Homematic zugelegt. Alles wurde per Autocreate angelegt und ich habe auch nach einiger Zeit das peeren kapiert...
Nach ca einer Woche kam dann eine Batteriestörung des Magnetkontaktes... In der Hoffnung das die mitgelieferten Batterien vielleicht einfach nur bescheiden oder entladen waren habe ich sie getauscht.
Nach einer weiteren Woche sind nun wieder die Batterien des CUL_HM_HM_SEC_SC platt.

Was mir noch aufgefallen ist, ist das der HM Lan Adapter seit den neuen Komponenten hin und wieder auf overoad geht.

Woran kann das liegen?

Anbei mal der Log des CUL_HM_HM_SEC_SC

Grüße
Steven


Fhem 5.6 auf Cubietruck,CUL,CUL_TCM97001,FritzBox7390,HMLAN,CUL_HM_HM_OU-16LED,CUL_HM_HM_SEC_SC,CUL_HM_HM_LC_SW4,CUL_HM_HM_RT_DN,HUEBridge,HUEDevice,Panstick,Panstamp (binouts,rgddriver mit dht22),PHTV,Yamaha-AVR,Withings,ELV-IPS, etc...

hobbyprovider

ich habe auch so Einen hier.
Gemessener Stromverbrauch permanent 21mA.
scheit ein Fehler zu sein, der öfter vorkommt
mein System:
2 vernetzte FHEM auf RPi
1.: mit Cul 868 und 433
2.: mit 1Wire-Adapter DS9490R

Rohan

Hmmm....

da der Thread ja wieder aus dem Keller geholt wurde ....

... habe mir gerade mal das Log angesehen...

- Da sind sehr viele open/closed-Vorgänge am Tag, wenn auch nur stundenweise und kurzzeitig
- der SC ist mit einem TC gepeert

Dazu erlaube ich mir einige Anmerkungen:

Der SC dürfte an einer Haus-/Wohnungstüre installiert sein.
Solch kleine Batterien wie die LR44 sind mM nicht für lange Haltbarkeit bei so häufig abzusetzenden Funktelegrammen geeignet.
Die Erfahrung meinerseits mit den LR44, die den SCs beiliegen ist eher negativ statt positiv, deshalb messe ich die (wenn auch ohne Last) erst einmal durch, bevor die zum Einsatz kommen. Aber selbst bei neu dazu gekauften LR44 habe ich schon Krücken gehabt. Markenware schneidet dabei deutlich besser ab, ist aber auch teurer.
Das Peeren dieses SC mit einem TC ist mM kontraproduktiv, auch für den TC, denn wenn der jedesmal die Ventile schließen lässt, dann wird der (oder die) VDs bzw. deren Batterien auch nicht lange mitmachen. Ich weiß jetzt aber nicht, nach welcher Zeitspanne der TC den VDs den Schließbefehl bei SC-Offen-Kennung sendet.

Zu dem Overload kann ich jetzt nichts beitragen.

Gruß
Thomas
Fhem auf Mini-ITX mit Celeron 2-Core, HMLAN (> 55 Devices), CUL (FS20 und EM), RFXtrx 433E, Arduino (einige DS18B20), RPi mit 1-Wire (DS2423 für S0-Signale, DS18B20+), RPi/Arduino mit MQ-5 und MQ-9 (CO- und CNG/LPG-Sensor), CO-20 IAQ Sensor

martinp876

Auch noch ein paar Anmerkungen - allgemein:

der SC muss einen "burst" schicken, um dem TC aufzuwecken.
-> einen Overload des HMLAN wird es nicht geben.
-> ein Overload dieses SC kann es geben, wenn 100 burst in eine Stunde (50 mal auf/zu) kommen oder 30 mal wenn der TC nicht antworten sollte (der SC sollte wiederholen). Der Overload sollte auf dem SC beschränkt bleiben, also eher unkritisch

=>mit jedem burst werden alle burst-empfangenden Devices aufgeweckt! Das kostet in allen burst-enableden devices Batterie, auch wenn sie nicht gepeert sind. Das Device erkennt erst nach aufwachen, wer gemeint ist.
Dieser SC in der Form reduziert also die Batterielaufzeit aller burst-enabled devices.
Die Batterielaufzeit des VDs wird durch das Ventil-stellen erheblich reduziert. Für den Motor muss es auch nicht förderlich sein.

Gruss Martn