Fehlender Batteriestatus in Readings

Begonnen von PeterS, 09 März 2013, 14:39:41

Vorheriges Thema - Nächstes Thema

martinp876

Hi Arthur,

das mit dem getConfig ist warscheinlich nur ein Teil der Antwort. Moeglich dass ein Teil der Anfragen nicht beantwortet wird. Kannst du mir die logs schicken?
Immerhin sind die Register gelesen. Also muss nur ein Teil schiefgegangen sein.
Korrigieren wir erste einmal getConfig.

Der statusRequest scheint nicht zu funktionieren,den koennen wir vergessen. Schade


Danke
Martin

snoop

Hallo Martin,

ok, ich mache es etwas komplizierter - ich habe heute gegen 1500 ein Update durchgeführt.

Hier die Raw Messages: Device: E1E3145


2013.03.31 17:28:26.387 1: HMLAN_Parse: HMLANAMA V:03C1 sNo:0987654321 d:1ACA40 O:123456 m:139AF465 IDcnt:0005
2013.03.31 17:28:35.189 1: HMLAN/RAW: /E1E3145,0000,139B16C4,FF,FFC8,8B84001E314500000020002F4B45513030333037373580810101

2013.03.31 17:28:35.192 1: HMLAN_Parse: HMLANAMA S:E1E3145   stat:0000 t:139B16C4 d:FF r:FFC8 m:8B84001E314500000020002F4B45513030333037373580810101
2013.03.31 17:28:35.292 1: HMLAN_Send:  SC1107ACA,00,00000000,01,C1107ACA,33A0011234561E314500040000000000
2013.03.31 17:28:35.462 1: HMLAN/RAW: /E1E3145,0000,139B17D5,FF,FFC4,33A0101E314512345602020009010A000B000C00100114060000

2013.03.31 17:28:35.464 1: HMLAN_Parse: HMLANAMA S:E1E3145   stat:0000 t:139B17D5 d:FF r:FFC4 m:33A0101E314512345602020009010A000B000C00100114060000
2013.03.31 17:28:35.502 1: HMLAN: Skip ACK
2013.03.31 17:28:35.564 1: HMLAN_Send:  SC1107BED,00,00000000,01,C1107BED,34A0011234561E31450103
2013.03.31 17:28:35.574 1: HMLAN/RAW: /RC1107ACA,0001,139B17DA,FF,FFC4,33A0101E314512345602020009010A000B000C00100114060000

2013.03.31 17:28:35.576 1: HMLAN_Parse: HMLANAMA S:RC1107ACA stat:0001 t:139B17DA d:FF r:FFC4 m:33A0101E314512345602020009010A000B000C00100114060000
2013.03.31 17:28:35.976 1: HMLAN/RAW: /E1E3145,0000,139B19D7,FF,FFC2,34A0101E3145123456011D2AA10300000000

2013.03.31 17:28:35.979 1: HMLAN_Parse: HMLANAMA S:E1E3145   stat:0000 t:139B19D7 d:FF r:FFC2 m:34A0101E3145123456011D2AA10300000000
2013.03.31 17:28:36.004 1: HMLAN: Skip ACK
2013.03.31 17:28:36.079 1: HMLAN_Send:  SC1107DE3,00,00000000,01,C1107DE3,35A0011234561E314501040000000001
2013.03.31 17:28:36.100 1: HMLAN/RAW: /RC1107BED,0001,139B19DD,FF,FFC2,34A0101E3145123456011D2AA10300000000

2013.03.31 17:28:36.103 1: HMLAN_Parse: HMLANAMA S:RC1107BED stat:0001 t:139B19DD d:FF r:FFC2 m:34A0101E3145123456011D2AA10300000000
2013.03.31 17:28:36.500 1: HMLAN/RAW: /E1E3145,0000,139B1BE3,FF,FFC0,35A0101E314512345602080020602100226430060000

2013.03.31 17:28:36.502 1: HMLAN_Parse: HMLANAMA S:E1E3145   stat:0000 t:139B1BE3 d:FF r:FFC0 m:35A0101E314512345602080020602100226430060000
2013.03.31 17:28:36.537 1: HMLAN: Skip ACK
2013.03.31 17:28:36.603 1: HMLAN_Send:  SC1107FF9,00,00000000,01,C1107FF9,36A0011234561E314501041D2AA10304
2013.03.31 17:28:36.695 1: HMLAN/RAW: /RC1107DE3,0001,139B1BE9,FF,FFC0,35A0101E314512345602080020602100226430060000

2013.03.31 17:28:36.697 1: HMLAN_Parse: HMLANAMA S:RC1107DE3 stat:0001 t:139B1BE9 d:FF r:FFC0 m:35A0101E314512345602080020602100226430060000
2013.03.31 17:28:37.014 1: HMLAN/RAW: /E1E3145,0000,139B1DE6,FF,FFC0,36A0101E31451234560201010000

2013.03.31 17:28:37.016 1: HMLAN_Parse: HMLANAMA S:E1E3145   stat:0000 t:139B1DE6 d:FF r:FFC0 m:36A0101E31451234560201010000
2013.03.31 17:28:37.043 1: HMLAN: Skip ACK
2013.03.31 17:28:37.135 1: HMLAN/RAW: /RC1107FF9,0001,139B1DEB,FF,FFC0,36A0101E31451234560201010000


Viele Grüße
Arthur
P.S: Habe ich dann schon die 3006 drauf? Hilft es wenn ich diese einspiele?

martinp876

Hi,

updates werden von Rudi irgendwann so um 7:00 scharf geschaltet. Also eher sicht,sollte auch kein Problem sein.

Bei dieser Aktion sollte es kein NACK gegeben haben. Somit verstehe ich nicht, wie dies vorher zustande gekommen sein soll.
Koennen wir festhalten, dass es
- hier kein NACK gebeben hat
- ein getConfig mit Anlernen auch kein NACK gibt (jedenfalls meistens...)
Wenn es beim Anlernen ein NACK gibt brauch ich hier logs.

Gruss
Martin

Gast45

Ich greife das Thema nochmal auf. Ich habe mehrere HM-SEC-SCO. einmal am Tag eine Statusmeldung wäre ja total klasse. Meine melden sich etwa einmal pro Stunde als ,,alive". Zum einen ist das nervig, weil das log voll wird und die echten Meldungen untergehen. Aber viel wichtiger ist das Thema mit dem Energieverbrauch. Kann man die Sensoren irgendwie dazu bewegen seltener ein ,,alive" zu senden? Kann dieses kurze Intervall noch jemand feststellen?
Meist liegt der Fehler vor der Tastatur

Pfriemler

 Bei den optischen Fenstersensoren ist das Intervall fest eingestellt und nicht änderbar. Durch die ggü den Magnetkontakten größere Batterien ergeben sich bei regelmäßiger Nutzung dennoch längere Batterielebensdauern.

event-on-change-reading ist Dein Freund, wenn es um die Reduzierung der Datenflut geht, wenn ein Log für den Sensor nicht ohnehin entbehrlich ist.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Gast45

Danke für die Info. Schade eigentlich, aber dann brauche ich nicht weiter suchen. Ich lasse mich überraschen wie lange die Batterie hält. Es ist ja nur eine AAA drin.

Mit Einschränkung der Logs habe ich schon Erfahrung. Ich musste da schon bei Wetterdaten ordentlich abspecken :)
Meist liegt der Fehler vor der Tastatur

stromer-12

Ich habe einen im Briefkasten verbaut, die Batterie hält jetzt 2 Jahre.
Letzte Woche war mal kurz ein Batterie Low aufgetaucht.
FHEM (SVN) auf RPi1B mit HMser | ESPLink
FHEM (SVN) virtuell mit HMLAN | HMUSB | CUL