FHEM Forum

FHEM - Hausautomations-Systeme => Homematic => Thema gestartet von: PeterS am 09 März 2013, 14:39:41

Titel: Fehlender Batteriestatus in Readings
Beitrag von: PeterS am 09 März 2013, 14:39:41
Hallo Zusammen

Meine Homematic-Sensoren liefern keinen Status der Batterien über die Readings.
Beim Öffnen der Sensoren wird dieser einmalig übermittelt.

Muss man hierzu noch ein zusätzliches Attribut pflegen ?

Gruss Peter
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: Rohan am 11 März 2013, 16:36:26
Hallo Peter,

was für Sensoren? Klingt nach Tür/Fenster (HM-Sec-SC)?

Mit CUL gibt es bei letzteren Probleme (wie bei den meisten "Sec"-Geräten), z.Zt. mW nur lösbar durch Einsatz eines HMLAN-Adapters.

Gruß
Thomas
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: justme1968 am 11 März 2013, 16:54:29
das stimmt so nicht!

die HM-SEC-RHS und auch die HM-SEC-MDIR funktionieren problemlos mit einem cul. trotz des sec im namen. beide liefern auch problemlos den batterie stand. beim HM-SEC-MDIR muss man es aber über das register cyclicInfoMsg erst aktivieren.

gruss
  andre
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: PeterS am 11 März 2013, 19:36:48
Hallo Zusammen

Konfiguriert ist folgendes:
attr Fenster_WC subType threeStateSensor
regSet Fenster_WC cyclicInfoMsg on

Trotzdem kommt das Battery-Reading nur beim Öffnen des Sensors und nicht beim Schaltvorgang bzw. innerhalb von 24 Stunden.

Gruss Peter
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: martinp876 am 11 März 2013, 20:29:51
Hallo Peter,

vielleicht kannst du die messages einmal aufnehmen, in denen der Batteriestand fehlt.
Ausserdem ein get Fenster_WC reg all

In der einfachen Aktionsmessage ist der Status nicht enthalten.

Dein device ist doch mit der Zentrale gepairt? Wenn nicht gibt es auch niemanden, dem er den Stand melden sollte.

Gruss
Martin
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: Rohan am 11 März 2013, 20:34:21
Zitat von: justme1968 schrieb am Mo, 11 März 2013 16:54das stimmt so nicht!

Zitat von: Rohan schrieb am Mo, 11 März 2013 16:36... (wie bei den meisten "Sec"-Geräten) ...

Hmmm... egal ...

Zitat von: PeterS schrieb am Mo, 11 März 2013 19:36Konfiguriert ist folgendes: ...

Das war zwar nicht meine Frage, aber ich gehe nun davon aus, dass es sich wohl wirklich um einen "HM-Sec-SC" handelt. Und genau bei dem gab es hier im Forum schon genau diesen Effekt in Zusammenhang mit einem CUL.

Aber was soll's... dann eben nicht.

Gruß
und weg
Thomas
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: justme1968 am 11 März 2013, 20:57:01
beim der fenstergriff sensor kann man die register nur beschreiben nach dem der knopf im batteriefach gedrückt wurde.

also um das register zu setzen muss du get Fenster_WC reg all
set Fenster_WC regSet cyclicInfoMsg on
eingeben. danach siehst du beim device das mindestens ein kommando pendig ist und in den readings das das cyclicInfoMsg register geschrieben werden soll. danach fhem in den pairing modus versetzten und den Knopf unter dem batteriefach drücken. danach noch mal  get Fenster_WC reg all jetzt sollten keine pendig commands mehr zu sehen sein und in den readings genau R-cyclicInfoMsg on stehen. danach bekommst du regelmäßig eine batterie meldung wenn der griff etwa 24 stunden lang nicht betätigt wurde.

gruss
  andre
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: martinp876 am 12 März 2013, 08:22:42
Hi Thomas,

CUL hat Probleme mit allen Burst devices. diese sind
"HM-SEC-KEY"       rxt=>'b'  
"HM-SEC-KEY-S"     rxt=>'b'  
"HM-SEC-KEY-O"     rxt=>'b'  
"HM-SEC-WIN"       rxt=>'b'  
"HM-SEC-SD"        rxt=>'b'  
"HM-LC-SW4-WM"     rxt=>'b'  
"HM-LC-SW1-BA-PCB" rxt=>'b'  
"HM-Dis-TD-T"      rxt=>'b'

die RC19 hat auch burst mode,aber auch config. Eine RC19 mit Display macht hinter einer CUL aber keinen Sinn
"HM-RC-19"         rxt=>'c:b'
"HM-RC-19-B"       rxt=>'c:b'
"HM-RC-19-SW"      rxt=>'c:b'

Ansonsten hat Andre alles geklaert
Gruss
Martin
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: Rohan am 12 März 2013, 11:08:42
Ich muss jetzt nochmal nachfragen, bevor ich etwas falsches oder an der falschen Stelle im Wiki reinschreibe...

Die Abläufe von Andre beziehen sich auf einen "Fenstergriffsensor". Das dürfte der HM-Sec-RHS sein? Gelten diese Ausführungen auch für einen HM-Sec-SC, auf den ich mich bezog?

Gruß
Thomas
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: martinp876 am 12 März 2013, 12:32:06
Thomas,

Batterie wird gerne. und bei ALLEN threestate Sensoren (mit Batterie) ausschliesslich in der Info message gesendet.
Batterie-status kommt nicht in 'trigger' messages, also wenn das Fenster aufgeht.

Man kann (oft) einstellen, dass das device eine Zyklische Info-message sendet.
Mit einem statusRequest sollte es auch abfragbar sein - aber nicht hilfreich bei devices die nur wakeup und Config unterstuetzen.
Eine INFO-message wird meines wissens NICHT nach einem trigger (fensteraction) gesendet. Evtl kann dies jemand mit einem sauber gepairten device bestaetigen (bei ungepairten devices sicher keine auto-info)  

Langer Rede kurzer Sinn
- Device immer pairen
- wenn Batterie-status regelmaessig gewuenscht immer CyclicInfo einschalten
- Ohne Cyclic Info auch kein korrekter ActionDetector support
- Nachteil ist ein erhoeter Batterie-verbrauch - keine Ahnung wieviel.

Gruss
Martin

Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: Rohan am 12 März 2013, 12:49:04
Hallo Martin,

ok, dann ist ein entsprechender Hinweis auf diesen Umstand beim Wiki-Eintrag für den HM-Sec-SC nicht verkehrt, aber besser wäre eine separate Abhandlung für alle "threestate Sensoren". Jetzt habe ich aber ein Problem (mangels großer Auswahl an HM-Geräten), welches du an Hand der dir vorliegenden Unterlagen leichter lösen können wirst:

Was sind alles threestate Sensoren?

Dann kann ich deren Typbezeichnung in dem entsprechenden Wiki-Beitrag benutzen, damit auch jeder Wiki-Leser weiß, für welche Devices das Geschriebene gilt. Solche Informationen sind m.M. im Wiki besser aufgehoben als hier in einem Thread, der durch Zeitablauf in die Versenkung verschwindet.

Wenig Sinn dürfte aber (gerade für Einsteiger/Anfänger, der ich auch noch bin) eine Erklärung haben a la "Wenn Sie einen threestate Sensor haben, müssen Sie folgendes beachten ...".

Gruß
Thomas

Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: martinp876 am 12 März 2013, 16:16:10
Hallo Thomas,

FHEM user koennen den aktuellen Stand auslesen, wenn sie HMinfo nutzen und ein
set <name> models
machen. Da erhalten sie eine komplette und aktuelle Liste aller devices die FHEM unterstuetzt.

ok- HMinfo ist (noch) kein offizieller Bestandteil von fhem, habe es aber mal - genau aus solchen Gruenden - gebaut.
Wiki ist sicher gut, aber eine 'incode' info ist immer aktueller.
Ich wuerde nur auf die Mechanismen hinweisen und die Liste immer frisch auslesen lassen.

Wenn du die Liste in Wiki pflegen willst habe ich damit natuerlich auch kein Problem. Du findest sie im File
http://fhem.svn.sourceforge.net/viewvc/fhem/trunk/fhem/FHEM/HMConfig.pm?revision=2876 (//fhem.svn.sourceforge.net/viewvc/fhem/trunk/fhem/FHEM/HMConfig.pm?revision=2876)
etwa Line 50 bis 200, alles was st=>'threeStateSensor' heisst.

Gruss
Martin
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: Rohan am 12 März 2013, 16:21:04
Danke.

Gruß
Thomas
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: snoop am 14 März 2013, 18:30:56
Hallo Martin,

ZitatEine INFO-message wird meines wissens NICHT nach einem trigger (fensteraction) gesendet. Evtl kann dies jemand mit einem sauber gepairten device bestaetigen (bei ungepairten devices sicher keine auto-info)

Als Rückmeldung: korrekt (soeben verifiziert) auf/zu ändert den Bat-Status nicht nur das Gehäuse "HM-Sec-SCs" auf/zu schickt den Bat-Status. Soviel dazu....

Wenn wir schon dabei sind, weißt du (jemand) was genau passiert wenn ich das Register cyclicInfoMsg auf on stelle?
Schickt dann der HM-Sec-SC die Daten in bestimmten Zeitintervallen (24H?) an die Zentrale/Fhem (Push) oder ist der Sensor immer aktiv und wird über den ActionDetector abgefragt (Pull)?

Viele Grüße
Arthur
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: justme1968 am 14 März 2013, 18:47:20
ich kann es dir nur für die HM-SEC-RHS fenstergriff sensoren sagen. die senden die daten wenn etwa 24 stunden seit der letzten gesendeten nachricht vergangen ist. wenn man das fenster also täglich von hand auf und zu macht kommt nie eine batterie nachricht sonst maximal alle 24 stunden.

der actiondetector macht kein pull sondern schaut nur in allen readings nach und checkt jeweils das datum dort.

gruss
  andre
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: snoop am 14 März 2013, 19:16:59
Hallo Andre,

danke, eine Sache ist mir aber noch unklar.

Zitatwenn man das fenster also täglich von hand auf und zu macht kommt nie eine batterie nachricht sonst maximal alle 24 stunden.

Bei dem HM-Sec-SC scheint ja ein "täglich von hand auf und zu" nicht zu helfen, da die entsprechende message nicht beim "auf/zu" gesendet wird.

Ich versuche die Frage anders zu stellen, befindet sich der Sensor mit dem Register: "cyclicInfoMsg on" in wakeup Modus und sendet den Status nach min/spätestens 24h (weckt sich - also merkt sich wann er den letzten Status geschickt hat?!) *klar ein Schlafmodus wird unterbrochen wenn ich ein Fenster auf und zu schließe - der Sensor legt sich dann nach einer ungewissen Zeit(?) wieder schlafen*

Viele Grüße
Arthur
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: snoop am 14 März 2013, 19:28:30
also nach drei mal lesen..... versuche ich es anders zu kombinieren - vielleicht einfacher.

Ist es so, dass der Sensor mit dem Register "cyclicInfoMsg on" den Bat-Status bei jedem auf/zu und spätestens nach 24h verschickt?

Viele Grüße
Arthur
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: justme1968 am 14 März 2013, 20:46:32
das ist beim HM-SEC-RHS genau so. da kommt die batterie nachricht auch nicht bei der auf/zu/gekippt nachricht mit. nur wenn der deckel aufgemacht wird.

mit 'cyclicInfoMsg on' wird der batterie status immer genau dann automatisch versendet wenn seit 24 stunden keine nachricht gesendet wurde. d.h. wenn der griff mindestens ein mal pro tag betätigt wird kommt nie eine batterie ok meldung.

ich weiss nicht wie es mit batterie low meldungen ist.

gruss
  andre
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: snoop am 14 März 2013, 21:41:20
Hallo Andre,

ok, ich halte fest (deine negierten Antworten verwirren mich ein wenig - sorry :o) ):

mit 'cyclicInfoMsg "off"' (default Sensor Einstellung)
'________________________________________________________
- beim auf/zu Event wir kein Batterie Status gesendet/übertragen: check
- beim öffnen des Gehäuses wir der Batterie Status gesendet/übertragen und in FHEM aktualisiert: check

mit 'cyclicInfoMsg "on"'
'________________________________________________________
- nach spätestens 24h sendet der Sensor sein Bat-Status

Offene Frage:
Unklar, ob mit cyclicInfoMsg "on" der Sensor beim auf/zu Event den Batterie Status mit sendet/überträgt UND
viel wichtiger aber schwieriger zu beantworten ist, aus meiner Sicht, was machte der Sensor mit Register: cyclicInfoMsg "on" in der Zeit zwischen "00:00:00" und "23:59:59" sendet er frühlich irgend ein Status (Fragt z.B. habe ich den Bat-Status schon geschickt und das evtl. in 10 Min Tackt) und verbraucht dabei fleißig die Batterie. (Ich habes es bei mir ab heute aktiv mal schauen was die Logs sagen - wenn das überhaupt Protokolliert wird?)

Was mich interessiert ist, hält dan die Baterrie nach einschalten des Resgisters, statt ca. 2 Jahre? (Abgesehen der Frequenz der auf/zu Aktivitäten?)? nur noch ein 1/2 Jahr (Ergebnis: Bin nur noch am wechseln? - Abgesehen von den Kosten - ehe der "nervig/lästig Faktor" -> hier das Motto je weniger desto "besser"!)

Hoffe es ist verständlich....

Viele Grüße
Arthur
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: justme1968 am 14 März 2013, 22:08:13
die negierte antwort macht es aber gerade richtig und eindeutig :)

Zitatmit 'cyclicInfoMsg "off"' (default Sensor Einstellung)
- beim auf/zu Event wir kein Batterie Status gesendet/übertragen: check
- beim öffnen des Gehäuses wir der Batterie Status gesendet/übertragen und in FHEM aktualisiert: check
ja.

Zitatmit 'cyclicInfoMsg "on"'
- nach spätestens 24h sendet der Sensor sein Bat-Status
nein. genau eben nicht. wenn 24 stunden lang nichts gesendet wurde kommt ein mal der status. sonst nicht.
wenn gelmäßig ein auf oder zu kommt mit weniger als 24 stunden abstand wird nie ein batterie status gesendet. zumindest nicht ein batterie ok. der 24 stunden zähler fängt bei jeder gesendeten nachricht wieder bei null an und es wird nur dann genau eine batterie nachricht gesendet wenn der zähler bei etwa 24 stunden angekommen ist.

die cyclicInfoMsg ist also eher ein 'ich hab jetzt 24 stunden nix gesagt ich melde mich mal kurz damit niemand denkt ich bin tod'

ZitatOffene Frage:
Unklar, ob mit cyclicInfoMsg "on" der Sensor beim auf/zu Event den Batterie Status mit sendet/überträgt
nein.

ZitatUND
viel wichtiger aber schwieriger zu beantworten ist, aus meiner Sicht, was machte der Sensor mit Register: cyclicInfoMsg "on" in der Zeit zwischen "00:00:00" und "23:59:59" sendet er frühlich irgend ein Status (Fragt z.B. habe ich den Bat-Status schon geschickt und das evtl. in 10 Min Tackt) und verbraucht dabei fleißig die Batterie. (Ich habes es bei mir ab heute aktiv mal schauen was die Logs sagen - wenn das überhaupt Protokolliert wird?)
das verstehe ich jetzt gerade nicht :)

ZitatWas mich interessiert ist, hält dan die Baterrie nach einschalten des Resgisters, statt ca. 2 Jahre? (Abgesehen der Frequenz der auf/zu Aktivitäten?)? nur noch ein 1/2 Jahr (Ergebnis: Bin nur noch am wechseln? - Abgesehen von den Kosten - ehe der "nervig/lästig Faktor" -> hier das Motto je weniger desto "besser"!)
wie lange die batterie hält weiss ich nicht. ich hab meine erst zwei monate :) bei einem fenster das nie bedient wird macht es sicher einen unterschied. bei einem fenster das täglich sowieso bedient wird macht es keinen.

gruss
  andre
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: snoop am 14 März 2013, 22:20:45
Hallo Andre,

ich ergänze (grade ein wenig getestet "Nachwuchs inkl. Frau schläft grade..."):

mit 'cyclicInfoMsg "off"' (default Sensor Einstellung)
'________________________________________________________
- beim auf/zu Event wir kein Batterie Status gesendet/übertragen: check
- beim öffnen des Gehäuses wir der Batterie Status gesendet/übertragen und in FHEM aktualisiert: check

mit 'cyclicInfoMsg "on"'
'________________________________________________________
- nach spätestens 24h sendet der Sensor sein Bat-Status: nicht verifiziert?
- beim auf/zu Event wir kein Batterie Status gesendet/übertragen: check
- beim öffnen des Gehäuses wir der Batterie Status gesendet/übertragen und in FHEM aktualisiert: check

Offene Frage:
Unklar, ob mit cyclicInfoMsg "on" der Sensor beim auf/zu Event den Batterie Status mit sendet/überträgt
#######
#Verifiziert: dies ist nicht der Fall.
#######
UND
viel wichtiger aber schwieriger zu beantworten ist, aus meiner Sicht, was machte der Sensor mit Register: cyclicInfoMsg "on" in der Zeit zwischen "00:00:00" und "23:59:59" sendet er frühlich irgend ein Status (Fragt z.B. habe ich den Bat-Status schon geschickt und das evtl. in 10 Min Tackt) und verbraucht dabei fleißig die Batterie. (Ich habes es bei mir ab heute aktiv mal schauen was die Logs sagen - wenn das überhaupt Protokolliert wird?)
#######
# Durchsuche mal die Logs am Wochenende (Ersten 30 Min Log Files -> keine Hinweise auf hoch frequentierten Messages)
#######

Was mich interessiert ist, hält dan die Baterrie nach einschalten des Resgisters, statt ca. 2 Jahre? (Abgesehen der Frequenz der auf/zu Aktivitäten?)? nur noch ein 1/2 Jahr (Ergebnis: Bin nur noch am wechseln? - Abgesehen von den Kosten - ehe der "nervig/lästig Faktor" -> hier das Motto je weniger desto "besser"!)

Viele Grüße
Arthur
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: snoop am 14 März 2013, 22:53:02
Hallo Andre,

okkkk, danke für die Rückantwort, die Nachrichten haben sich ein wenig überschnitten aber ich versuche den aktuellen Status zusammen zu fassen:

mit 'cyclicInfoMsg "off"' (default Sensor Einstellung)
'________________________________________________________
- beim auf/zu Event wird kein Batterie Status gesendet/übertragen: check
- beim öffnen des Gehäuses wird der Batterie Status gesendet/übertragen und in FHEM aktualisiert: check

mit 'cyclicInfoMsg "on"'
'________________________________________________________
- nach spätestens 24h sendet der Sensor sein Bat-Status: offen!(siehe weiter unten)
- beim auf/zu Event wird kein Batterie Status gesendet/übertragen: check
- beim öffnen des Gehäuses wird der Batterie Status gesendet/übertragen und in FHEM aktualisiert: check

Offene Frage:
nach spätestens 24h sendet der Sensor sein Bat-Status: offen!(siehe weiter unten)


ZitatZitat:

   
Zitatmit 'cyclicInfoMsg "on"'
    - nach spätestens 24h sendet der Sensor sein Bat-Status

nein. genau eben nicht. wenn 24 stunden lang nichts gesendet wurde kommt ein mal der status. sonst nicht.
wenn gelmäßig ein auf oder zu kommt mit weniger als 24 stunden abstand wird nie ein batterie status gesendet. zumindest nicht ein batterie ok. der 24 stunden zähler fängt bei jeder gesendeten nachricht wieder bei null an und es wird nur dann genau eine batterie nachricht gesendet wenn der zähler bei etwa 24 stunden angekommen ist.

die cyclicInfoMsg ist also eher ein 'ich hab jetzt 24 stunden nix gesagt ich melde mich mal kurz damit niemand denkt ich bin tod'

OK: FHEM notify ".*:genial.*" :o) so damit halten wir fest:

Wenn meine Haustür ein mal am Tag aufgeht bekomme ich "nie" die Meldung, dass die Baterrie leer ist - Richtig?

Ferner ist das Thema noch offen (vermutlich können Erfahrungswerte hier etwas dazu beitragen?):

Zitatviel wichtiger aber schwieriger zu beantworten ist, aus meiner Sicht, was machte der Sensor mit Register: cyclicInfoMsg "on" in der Zeit zwischen "00:00:00" und "23:59:59" sendet er frühlich irgend einen Status (Fragt z.B. habe ich den Bat-Status schon geschickt und das evtl. in 10 Min Tackt) und verbraucht dabei fleißig die Batterie. (Ich habes es bei mir ab heute aktiv mal schauen was die Logs sagen - wenn das überhaupt Protokolliert wird?)
#######
# Durchsuche mal die Logs am Wochenende (Ersten 30 Min Log Files -> keine Hinweise auf hoch frequentierten Messages)
#######

Was mich interessiert ist, hält dan die Baterrie nach einschalten des Resgisters, statt ca. 2 Jahre? (Abgesehen von der der auf/zu Aktivitäten/Frequenz?)? nur noch ein 1/2 Jahr (Ergebnis: Bin nur noch am wechseln? - Abgesehen von den Kosten - ehe der "nervige/lästige Faktor" -> hier das Motto je weniger desto "besser"!)

so muss abbrechen..... sorry

Viele Grüße
Arthur

Edit: Wenn meine Haustür ein mal am Tag aufgeht bekomme ich "nie" die Meldung, dass die Baterrie leer ist - Richtig?
Neu: Wenn meine Haustür ein mal am Tag aufgeht bekomme ich "nie" die Meldung, über den aktuellen Batterie Status? - Richtig?
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: snoop am 14 März 2013, 23:01:01
Hallo zusammen,
Ach, ja damit habe ich den Sinn der Funktion von "cyclicInfoMsg" nicht verstanden - zumindest nicht ganz!
Viele Grüße
Arthur
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: justme1968 am 14 März 2013, 23:14:25
wenn die tür regelmäßig mindestens ein mal alle 24 stunden auf geht bekommst du nie die meldung batterie voll. wozu auch. du bekommst ja die meldung das die tür aufgegangen ist. das wäre ja mit leerer  batterie nicht gegangen.

wenn die tür 24 stunden lang nicht auf gegangen ist bekommst du ein mal alle 24 stunden die meldung batterie voll. du weisst also alles ist ok.

beides zusammen sorgt dafür das du spätestens nach 24 stunden weißt das die batterie nicht leer ist ohne das dauernd etwas gesendet wird.

wann und ob eine batterie low nachricht gesendet wird weiss ich noch nicht. ich würde mal tippen im prinzip schon. aber es kann ja passieren das die batterie so schnell und plötzlich leer ist das die nachricht nicht mehr gesendet werden kann.

das ist genau die sache mit der negierten antwort: du kannst niemals 100% zuverlässig senden das die batterie jetzt (gleich) leer ist.
aber so lange eine nachricht kommt kannst du sicher sein das sie zu dem zeit punkt 100%ig nicht leer war :)

und genau so funktioniert auch der AktionDetector. der trigger das etwas nicht stimmt ist nicht das eine bestimmte nachricht ankommt sondern das alle nachrichten ausbleiben. schon wieder negiert :)
 
  andre
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: snoop am 14 März 2013, 23:51:29
Hallo Andre,

ok, dann nutze ich die Zeit,

Mein Ansatz ist folgender:

Zitatwenn die tür regelmäßig mindestens ein mal alle 24 stunden auf geht bekommst du nie die meldung batterie voll. wozu auch. du bekommst ja die meldung das die tür aufgegangen ist. das wäre ja mit leerer batterie nicht gegangen.

Praxis: Ich gehe jeden Tag zur Arbeit (oft auch am WE), nun nehmen wir an - heute ist mein letzter Arbeitstag und Morgen geht es in meinen wohl verdienten Urlaub. Ich packe meine Sachen und fahre mit meiner Familie los. Nach 24 Stunden - bekomme ich ein notify "E-Mail" -> Herzlichen glückwunsch Sie haben von 1/2 Jahr ihre Fenster und Tür Sensoren gekauft und nun sind die Batterien leer - ich wünsch ihnen einen angenehmen 2-3 Wöchigen Urlaubsaufenthalt (Ein Tipp: 2-3 Wochen werden die Batterien wohl nicht mehr halten!).

Ok, etwas übetrieben, ja und wenn ich sowas vermeiden möchte dann setzt man vielleicht nicht aus solch ein System - dennoch damit versuche ich, für mich, die technischen grenzen abzustecken -> mehr nicht.
Zitatwann und ob eine batterie low nachricht gesendet wird weiss ich noch nicht. ich würde mal tippen im prinzip schon. aber es kann ja passieren das die batterie so schnell und plötzlich leer ist das die nachricht nicht mehr gesendet werden kann.

Ja, verstanden da hat Martin auch schon mal was geschrieben.

Zitatdas ist genau die sache mit der negierten antwort: du kannst niemals 100% zuverlässig senden das die batterie jetzt (gleich) leer ist.
aber so lange eine nachricht kommt kannst du sicher sein das sie zu dem zeit punkt 100%ig nicht leer war :)
und genau so funktioniert auch der AktionDetector. der trigger das etwas nicht stimmt ist nicht das eine bestimmte nachricht ankommt sondern das alle nachrichten ausbleiben. schon wieder negiert :)

Wie bereits geschrieben, absolut korrekt, ich möchte für mich nur die technischen Restriktionen ausloten. ;o)

Dann muss ich schlußfolgern, dass "cyclicInfoMsg" nicht die Lösung für mein Problem ist? Zumindest mir nicht die Sicherheit gibt die ich mir wünsche - aber mir die Diskussion die Eisnchränkung deutlich gemacht hat! Danke.

Viele Grüße
Arthur

Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: justme1968 am 15 März 2013, 09:57:15
es ein teil der lösung.

der andere teil, also die meldung battery low, gibt es vermitlich ich habe es aber noch nirgends dokumentiert gesehen. probier es doch einfach mal mit ein paar alten batterien aus. aber ich denke selbst wenn die nachricht kommt kannst du dich nicht auf mehrere wochen vorlaufzeit verlassen. das kann dann ganz schnell gehen.

also um sicher zu sein vor dem urlaub alle batterien austauschen :)

ansonsten kommt es halt auf den anwendungsfall an. ich benutze die fenstergriff sensoren um beim weggehen auf einen blick zu sehen das alles zu ist. nicht um festzustellen das in meiner abwesenheit unerlaubt auf gemacht wird. das würde dann eh mit grosser wahrscheinlichkeit durch eine scheibe passieren und das müßte ich ganz anders abfangen und sehr warscheinlich nicht funk verwenden.

gruss
  andre
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: martinp876 am 15 März 2013, 10:09:28
Hi Arthur,

Wie hoch dein Sicherheitsbedürfniss ist kann ich nicht einschätzen. Ein gewisses Vertrauen in Technik muss man schon mitbringen wenn man home-automation macht. Die Wichtigkeit einzelner Elemente muss man selbst abwaegen: arbeits-sicherheit, einbruch, ausfall... und deren Folgen. Da ist jedes Element einzeln zu betrachten - und es ist Personen und Bedürfniss abhaengig.

Batterie-betreibene Devices leben immer damit, dass die Batterie irgendwann leer ist. HM devices haben eine Vorwarnung, bat low. Ausserdem haben wir den Action detector, der Batterie-leer (oder aehnlich) signalisiert.
Manche habe noch einen weiteren Level, Batterie critical.

So weit sollte alles passen, viel mehr kann man auch nicht machen - ausser einen "Analogen" Batterie-level. Ist aber bei Kunden-Alkalie-batterien schwer zu realisieren. So etwas kenne ich nur von sehr spezifischen Lithium Akkus - alles andere ist immer ein gewisser 'rate/glücks-level'

Dass ein Fensterkontakt nur einmal am Tag einen statusport liefert ist somit sinnvoll. Das device wird in der Regel selten aktiviert... haeufigere Meldungen wuerden die Batterie einfach leeren.

Was mir nicht klar ist: was mehr stellst du dir vor? Eine TimeToLife Anzeigen schliesst sich schon durch die gewaehlten Batterietypen aus, die ist zu unspezifisch, dafür Billiger....
Wenn alle im Urlaub sind ist ein Fenster-kontakt auch nicht kritisch - es sei denn du rechnest mit Einbrechern. Das ist dann ein andres Thema - und die koennen auch kein Fenster von innen öffnen...

Gruss
Martin
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: snoop am 15 März 2013, 10:17:18
Hallo Andre,

Zitates ein teil der lösung.

der andere teil, also die meldung battery low, gibt es vermitlich ich habe es aber noch nirgends dokumentiert gesehen. probier es doch einfach mal mit ein paar alten batterien aus. aber ich denke selbst wenn die nachricht kommt kannst du dich nicht auf mehrere wochen vorlaufzeit verlassen. das kann dann ganz schnell gehen.

Absolut.

Zitatalso um sicher zu sein vor dem urlaub alle batterien austauschen :)

ja, ne ist klar... ;o) *

Zitatansonsten kommt es halt auf den anwendungsfall an. ich benutze die fenstergriff sensoren um beim weggehen auf einen blick zu sehen das alles zu ist. nicht um festzustellen das in meiner abwesenheit unerlaubt auf gemacht wird. das würde dann eh mit grosser wahrscheinlichkeit durch eine scheibe passieren und das müßte ich ganz anders abfangen und sehr warscheinlich nicht funk verwenden.

Ich habe ja noch die Bewegungsmelder da - die schicken ja Ihre Bat-Status regelmässig (meine bei jedem motion detection?) - damit kombiniert kann ich das ganze etwas kompensieren.

Viele Grüße
Arthur
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: snoop am 15 März 2013, 11:22:01
Hallo Martin,

ZitatDass ein Fensterkontakt nur einmal am Tag einen statusport liefert ist somit sinnvoll. Das device wird in der Regel selten aktiviert... haeufigere Meldungen wuerden die Batterie einfach leeren.
Da bin ich ja bei dir. Der Status eben nur unter bestimmten Voraussetzungen geschickt wird - keine auf/zu Aktion in den letzten 24h - daher auch "selten" nur 1-2x (auf/zu) am Tag.
Weißt du was da genau passiert? Der Sensor scheint sich die letzte "auf/zu" Aktion oder letzten "habe den Bat-Status geschickt am/um..." Status zu merken legt sich schlafen und weckt sich wenn die 24h vorbei sind? Dauernd an ist er mit cyclicInfoMsg=on nicht - habe ich das richtig verstanden?
ZitatWas mir nicht klar ist: was mehr stellst du dir vor? Eine TimeToLife Anzeigen schliesst sich schon durch die gewaehlten Batterietypen aus, die ist zu unspezifisch, dafür Billiger....
Eine geschätzte Lebenszeit/dauer wäre super aber eben nicht wirklich aussagekräftig (vorgetäuschte Sicherheit). Mir würde auch einfach reichen wenn der Sensor sein Bat-Stat bei der auf/zu Aktion mitsenden würde, so funktioniert das aber leider(warum auch immer - der Sensor ist in dem Moment wach und könnte diese Information ja mitschicken) nicht.
ZitatWenn alle im Urlaub sind ist ein Fenster-kontakt auch nicht kritisch - es sei denn du rechnest mit Einbrechern.
Ja.
ZitatDas ist dann ein andres Thema - und die koennen auch kein Fenster von innen öffnen...
;o) Gut in meinem Fall reden wir hier von SC und nicht RHS (habe keine).
Wie gesagt mir war es wichtig zu verstehen was da passiert.

Viele Grüße
Arthur
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: Rohan am 18 März 2013, 21:29:43
Hmmm...

in einer "ruhigen Minute" fiel mir ein, dass ich ja bei einem neuen HM-Sec-SC bereits ca. 6 Wochen nach der Inbetriebnahme Probleme mit diesem hatte. Im Anhang die Log-Auszüge mit den Battery-Low-Meldungen vom 06.01.2013, die verschwanden, als ich am 07.01.2013 neue LR44er eingebaut habe.

Hinweis: Der HM-Sec-SC war "damals" noch nicht sauber gepairt/gepeert ;) Die Log-Daten davor sind leider nicht mehr vorhanden.

Vlt. trägt dies ja etwas zur Klärung bei.

Gruß
Thomas
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: martinp876 am 19 März 2013, 07:28:52
Hi,

das log ist nicht sehr lang.
Eine Ack-Info und eine status meldung kann man bei diesem aktor nicht unterscheiden(anhand der Events). Eine AckStatus kommt aber nach einer trigger-message... also sehe ich 2 status-messages die 'cyclic' gekommen sein sollten:

07ter 17:37:43
08ter 17:47:12

Gruss
Martin
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: snoop am 19 März 2013, 09:42:29
Hallo Martin,

seltsam/interessant:

Zitat07ter 17:37:43
Der letzte cover: closed war am 2013-01-06_10:20:04 = viel länger als 24h.
Zwischendurch wurde mal die Tuer geöffnet (Das ist das interessante!).

Zitat08ter 17:47:12
Der letzte "contact: closed" war am 2013-01-07_17:56:04,
dann einige "Activity:unknown"s
Interessant hier ist aber (meine ich) das Zeitgleich das cover zugemacht wurde - kann sein, dass hier die Reihenfolge der Aktionen nicht stimmt (da zeitgleich)?

Eigentlich wäre (nach bisherigen Erkenntnissen - cover auf/zu triggert Bat-Status):
cover zu
batterie ok
contact closed
usw.

Ich teste(wollte noch :o( - bin noch nicht dazu gekommen) das Verhalten derzeit zu Hause auch - mal schauen.

Viele Grüße
Arthur
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: martinp876 am 19 März 2013, 10:20:35
Hi Artur,

vor dem 1.7. war das device nicht gepairt. Da kommen evtl keine cyclic messages...

Aktivity unknown  kommt eigentlich bei neustart von FHEM. Dass es so oft kommt... hm  ... ist event-on-change eingestellt? Wieviele neustarts hat es gegeben?

So gesehen lasse ich Activity einmal aussen vor, da es vom ActinDetector getrieben ist.
Es gibt 2 events: den trigger und die infos(status und ack)
Bei trigger kommt kein batterie und kein cover

Die Meldungen 'cover' am 6. kommen immer nach einem trigger.
Die Meldungen am 7. 17:37 kommt quasi direkt nach dem Batteriewechsel (denke ich... cover noch offen).

Anzumekren ist, dass vor dem 6. 10:20 mit jedem trigger auch eine info gekommen ist.
Was hat sich also hier getan?
Moegliche Parameter sind:
cyclic info message eingeschaltet?
mit der Zentrale gepairt?

denkbar: wenn cyclic info message dann keine info-message mehr bei triggern.

Gruss
Martin
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: Rohan am 19 März 2013, 12:03:34
Zitat von: martinp876 schrieb am Di, 19 März 2013 10:20... Aktivity unknown  kommt eigentlich bei neustart von FHEM. Dass es so oft kommt... hm  ... ist event-on-change eingestellt? Wieviele neustarts hat es gegeben?

Ich werde heute Abend nochmals nach den Logs vorher schauen. Logs danach sind kein Problem, die hatte ich nur abgeschnitten, weil ich nicht wusste, dass die auch von Interesse sein können. Zahl der Neustarts kann ich im fhem.log nachschauen. Zum "event-on-change": keine Ahnung, ich habe zumindest nichts derartiges bewusst eingestellt gehabt.

Was ich noch weiß ist, dass ich am 6.1. ziemlich oft den Anlernknopf gedrückt habe, weil ich (HM-Sec-SC war ja erst ein paar Wochen in Betrieb gewesen) die Batterien erst zuletzt als Grund für die Störungen in Erwägung gezogen habe (seitdem messe ich auch alle mitgelieferten Batterien erst einmal nach).

Nachdem ich neue LR44 eingepflanzt habe (am 7.1.), habe ich den Sec-SC mit dem HM-CC-TC gepairt, hat aber iirc auch einige Versuche gebraucht (incl. Reset auf Werkseinstellung des HM-CC-TC).

ZitatWas hat sich also hier getan?
Moegliche Parameter sind:
cyclic info message eingeschaltet?

"Damals" wusste ich noch gar nichts von "cyclic info message".

Zitatmit der Zentrale gepairt?

hmmm... mal in den Notizen / Logs nachsehen.

Gruß
Thomas

P.S. beim nächsten Mal werde ich etwas methodischer vorgehen.
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: snoop am 19 März 2013, 12:33:08
Hallo Thomas,

Zitat"Damals" wusste ich noch gar nichts von "cyclic info message".

Interesant wäre noch folgendes: Ist bei deinen (dem o.g. SC) die option "cyclic info message" on (default ist off - man muss es also aktiv ändern)?
Danke.

@Martin:
Wäre es denkbar, dass cyclic info message eingeschaltet wird wenn ich es mit dem TC pairt?

Viele Grüße
Arthur
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: martinp876 am 19 März 2013, 13:03:41
Hi Arthur,

nach XML ist cyclicInfo default off.
Kannst du aber nachsehen wenn du ein getConfig machst.
R_cyclicInfoMsg steht auch immer sichtbar in den Readings.

ZitatWäre es denkbar, dass cyclic info message eingeschaltet wird wenn ich es mit dem TC pairt?
wie meinst du das?
- FHEM soll CyclicInfo einschalten wenn man mit TC peert-> ist nicht so/wird nicht so
- HM schaltet cyclic info ein wenn SC gepeert wird-> kann ich mir nicht vorstellen, warum auch. Macht keinen Sinn.

Ich empfehle hier einen autoRegRead 3 einzustellen. Dann werden die Daten aktuell gehalten. Tests mit wakeup siehe unten!

Cyclic info message heisst, dass Zyklisch eine Message kommt. Es heisst nicht, dass dies die einzige info message ist!

Welche Punkte sind eigentlich offen:
- cyclic info message erzeugt eine info message alle 88200sec oder 24,5h. Dies ist unabhaengig von Schalter-aktionen.
- cyclic-info message kommt, ob gepairt ist (Zentrale) oder nicht (alle 24h) richtig/falsch
- wann kommt eine ACK_Info.
  a) wenn device       gepairt, nicht gepeert, kontakt betaetigt
  b) wenn device       gepairt,       gepeert, kontakt betaetigt
  c) wenn device nicht gepairt, nicht gepeert, kontakt betaetigt
  d) wenn device nicht gepairt,       gepeert, kontakt betaetigt

- der SC ist ein wakeup-device. Man kann also Nachrichten schicken, wenn es aufwacht. Das haben wir ncicht im Griff und bedarf voraussichtlich einiger testreihen. Hier ein paar tests - wer will:
+ messages im rohformat loggen
+ nachricht absetzen, z.B. statusRequest
+ anlernen druecken -> nachricht sollte verarbeitet werden (sanity-test)
+ nachricht absetzen, z.B. statusRequest
+ Kontakt betaetigen => wird der commandStack  gesendet?
Logs schicken.


Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: snoop am 19 März 2013, 13:30:59
Hallo Martin,

Zitatwie meinst du das?
- FHEM soll CyclicInfo einschalten wenn man mit TC peert-> ist nicht so/wird nicht so
- HM schaltet cyclic info ein wenn SC gepeert wird-> kann ich mir nicht vorstellen, warum auch. Macht keinen Sinn.

zu P.1) Nein, das meine ich nicht
zu P.2) Ja das meinte ich, im nachhinein aber auch eher unsinn, da der TC ja nichts mit der Info(s) anfangen kann!?!

Viele Grüße
Arthur

P.S:Tests folgen, leider (vermutlich) nicht vor WE.
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: snoop am 19 März 2013, 18:14:06
 Hallo Martin,

Test 1:
####################
Zitat- der SC ist ein wakeup-device. Man kann also Nachrichten schicken, wenn es aufwacht. Das haben wir ncicht im Griff und bedarf voraussichtlich einiger testreihen. Hier ein paar tests - wer will:
+ messages im rohformat loggen
+ nachricht absetzen, z.B. statusRequest
+ Kontakt betaetigen => wird der commandStack gesendet?
Rahmenparameter:
- SC gepairt mit HMLAN
- CyclicInfo = on

SC Log:
2013-03-19_17:39:36 WZ_TerassenSensor Activity:: alive
2013-03-19_17:51:49 WZ_TerassenSensor auf
2013-03-19_17:51:49 WZ_TerassenSensor contact: auf (to HMLANAMA)
2013-03-19_17:52:15 WZ_TerassenSensor zu
2013-03-19_17:52:15 WZ_TerassenSensor contact: zu (to HMLANAMA)

Sonst siehe HMLAN Log.

Antwort: NEIN

Viele Grüße
Arthur

P.S:Reicht das? Habe das gefühl es fehlt was!

Edit: Ach, ja Status in FHEM: protCmdPend = 1 CMDs_pending | protState = CMDs_pending
So darf jetzt babysitten. ;o)
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: martinp876 am 19 März 2013, 18:55:07
Hi Arthur

was war um 2013-03-19_17:39:36 WZ_TerassenSensor Activity:: alive
?

da kam irgend eine andere message.
der statusrequest haengt also noch in der Queue -logisch.
Wir koennen versuchen uns an den wakeup zu haengen oder an den trigger.
Ich werden eine test-version bauen, mal sehen ob wir es schaffen. Dauert noch etwas

Gruss
Martin

Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: snoop am 19 März 2013, 19:26:42
Hallo Martin,

vorher hat der SC geschlafen und das mehr als 24 Stunden.
Kurz vor 2013-03-19_17:39:36 habe ich log File angelegt mit

define FileLog_WZ_TerassenSensor FileLog ./log/WZ_TerassenSensor-%Y.log WZ_TerassenSensor
attr FileLog_WZ_TerassenSensor logtype text
attr FileLog_WZ_TerassenSensor room Server


und Fhem neugestartet.

"2013-03-19_17:39:36 WZ_TerassenSensor Activity:: alive" hat wohl der ActionDetector angelegt - kann das sein?

Viele Grüße
Arthur

Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: snoop am 19 März 2013, 19:39:58
Hallo Martin,

anbei der Beweis ;o)

Gruß
Arthur

Edit:
Zitatvorher hat der SC geschlafen und das mehr als 24 Stunden.
Gut gelogen.... aber aus meiner Sicht nicht relevant und daher zu vernachlässigen.
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: Rohan am 19 März 2013, 20:55:04
Hallo Arthur,

so... sorry, aber mit weiteren Logs kann ich nicht mehr dienen. Und ja, am 6./7.1.13 waren einige FHEM-Restarts, weil ich neue Geräte in Betrieb genommen habe.

Zitat von: snoop schrieb am Di, 19 März 2013 12:33... Interesant wäre noch folgendes: Ist bei deinen (dem o.g. SC) die option "cyclic info message" on (default ist off - man muss es also aktiv ändern)?

Nein:

'list EG.WZ.Tuerkontakt'

Internals:
   DEF        1CFBB0
   IODev      HMLAN1
   NAME       EG.WZ.Tuerkontakt
   NR         119
   STATE      closed
   TYPE       CUL_HM
   Readings:
     2013-03-19 19:47:35   Activity:       alive
     2013-03-19 08:57:38   alive           yes
     2013-03-19 08:57:38   battery         ok
     2013-03-19 14:49:31   contact         closed (to EG.WZ.Heizung)
     2013-03-19 08:57:38   cover           closed
     2013-03-19 14:49:31   state           closed
   Helper:
     mId        002F
     rxType     12
Attributes:
   actCycle   028:00
   actStatus  alive
   expert     2_full
   firmware   2.0
   fp_GrundrissEG 465,1077,1,Terrassentüre
   model      HM-SEC-SC
   peerIDs
   room       EG.WohnZ
   serialNr   JEQ0248383
   subType    threeStateSensor


 
nach set ... getConfig und Anlernknopf kurz drücken erneut

'list EG.WZ.Tuerkontakt'

Internals:
   DEF        1CFBB0
   EVENTS     3
   HMLAN1_MSGCNT 3
   HMLAN1_RAWMSG E1CFBB0,0000,7C6EB0B2,FF,FFC1,B184001CFBB000000020002F4A45513032343833383380810101
   HMLAN1_RSSI -63
   HMLAN1_TIME 2013-03-19 20:37:33
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     3
   NAME       EG.WZ.Tuerkontakt
   NR         119
   STATE      MISSING ACK
   TYPE       CUL_HM
   lastMsg    No:B1 - t:00 s:1CFBB0 d:000000 20002F4A45513032343833383380810101
   protCmdDel 3
   protLastRcv 2013-03-19 20:37:33
   protResnd  2 last_at:2013-03-19 20:37:33
   protResndFail 1 last_at:2013-03-19 20:37:36
   protState  CMDs_done_events:3
   rssi_at_HMLAN1 avg:-67.33 min:-77 max:-62 lst:-63 cnt:3
   Readings:
     2013-03-19 20:37:33   Activity:       alive
     2013-03-19 20:37:23   alive           yes
     2013-03-19 20:37:23   battery         ok
     2013-03-19 20:37:24   contact         open (to EG.WZ.Heizung)
     2013-03-19 20:37:23   cover           open
     2013-03-19 20:37:36   state           MISSING ACK
   Helper:
     burstEvtCnt 3
     getCfgList all
     getCfgListNo 4
     mId        002F
     rxType     12
     Rssi:
       At_hmlan1:
         avg        -67.3333333333333
         cnt        3
         lst        -63
         max        -62
         min        -77
Attributes:
   actCycle   028:00
   actStatus  alive
   expert     2_full
   firmware   2.0
   fp_GrundrissEG 465,1077,1,Terrassentüre
   model      HM-SEC-SC
   peerIDs
   room       EG.WohnZ
   serialNr   JEQ0248383
   subType    threeStateSensor


Nun ein:

'set EG.WZ.Tuerkontakt regSet cyclicInfoMsg on' => 3 CMDs pending
'set EG.WZ.Tuerkontakt getConfig' => X CMDs pending

Anlernknopf kurz gedrückt, Browser refresh, alle CMDs abgearbeitet

ein 'list EG.WZ.Tuerkontakt' bringt:

Internals:
   CHANGED
   DEF        1CFBB0
   EVENTS     11
   HMLAN1_MSGCNT 15
   HMLAN1_RAWMSG R842D4EED,0001,7C73E9F4,FF,FFC1,9FA0101CFBB0123ABC0201010000
   HMLAN1_RSSI -63
   HMLAN1_TIME 2013-03-19 20:43:14
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     15
   NAME       EG.WZ.Tuerkontakt
   NR         119
   STATE      MISSING ACK
   TYPE       CUL_HM
   lastMsg    No:9F - t:10 s:1CFBB0 d:123ABC 0201010000
   protCmdDel 3
   protLastRcv 2013-03-19 20:43:14
   protResnd  2 last_at:2013-03-19 20:37:33
   protResndFail 1 last_at:2013-03-19 20:37:36
   protSnd    7 last_at:2013-03-19 20:43:14
   protState  CMDs_done
   rssi_at_HMLAN1 avg:-58.66 min:-77 max:-50 lst:-63 cnt:15
   Readings:
     2013-03-19 20:43:11   Activity:       alive
     2013-03-19 20:43:12   CommandAccepted yes
     2013-03-19 20:43:13   PairedTo        0x0
     2013-03-19 20:43:14   R-EG.WZ.Heizung_WindowRec-expectAES off
     2013-03-19 20:43:14   R-EG.WZ.Heizung_WindowRec-peerNeedsBurst on
     2013-03-19 20:43:13   R-cyclicInfoMsg on
     2013-03-19 20:43:14   R-eventDlyTime  0 s
     2013-03-19 20:43:13   R-intKeyVisib   invisib
     2013-03-19 20:43:14   R-ledOnTime     0.5 s
     2013-03-19 20:43:14   R-msgScPosA     closed
     2013-03-19 20:43:14   R-msgScPosB     open
     2013-03-19 20:43:13   R-pairCentral   0x0
     2013-03-19 20:43:13   R-sabotageMsg   on
     2013-03-19 20:43:13   R-transmDevTryMax 6
     2013-03-19 20:43:14   R-transmitTryMax 6
     2013-03-19 20:43:13   RegL_00:          02:00 09:01 0A:00 0B:00 0C:00 10:01 14:06 00:00
     2013-03-19 20:43:14   RegL_01:          08:00 20:60 21:00 22:64 30:06 00:00
     2013-03-19 20:43:14   RegL_04:EG.WZ.Heizung_WindowRec   01:01 00:00
     2013-03-19 20:37:23   alive           yes
     2013-03-19 20:37:23   battery         ok
     2013-03-19 20:37:24   contact         open (to EG.WZ.Heizung)
     2013-03-19 20:37:23   cover           open
     2013-03-19 20:43:13   peerList        EG.WZ.Heizung_WindowRec,
     2013-03-19 20:37:36   state           MISSING ACK
   Helper:
     mId        002F
     peerIDsRaw ,1AD94103,00000000
     rxType     12
     Rssi:
       At_hmlan1:
         avg        -58.6666666666667
         cnt        15
         lst        -63
         max        -50
         min        -77
     Shadowreg:
Attributes:
   actCycle   028:00
   actStatus  alive
   expert     2_full
   firmware   2.0
   fp_GrundrissEG 465,1077,1,Terrassentüre
   model      HM-SEC-SC
   peerIDs    00000000,1AD94103,
   room       EG.WohnZ
   serialNr   JEQ0248383
   subType    threeStateSensor


Jetzt aber ;)

Und nicht wundern, der HM-Sec-SC liegt gerade offen neben der Tastatur.

Gruß
Thomas
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: snoop am 19 März 2013, 21:38:55
Hallo Thomas,

ohjee, ok.... wo soll ich anfangen? ;o)

Ich intepretiere es so - die HM Untiefen sind eher an Martin gerichtet und nicht an mich. ;o)
Mein Anliegen ist auf "high level" Ebene zu verstehen was da (technisch) passiert.
Dies nur zu klärung der Ausgangssituation nun aber zu deinen Infos:

Zitat'list EG.WZ.Tuerkontakt'
Aus der Information kann ich folgendes entnehmen:
- Infos sind unvollständig (da vorher kein getConfig erfolgt ist...)
- Heute um 08:57:38 hast du das Gehäuse geöffnet, was dazu geführt hat, dass
- Um 2013-03-19 08:57:38 ein Status der Batterie übermittelt wurde - also: battery:ok

Ergebnis: Eigentlich keine verwertbaren Informationen ausser das hiermit wieder bestättigt ist, dass bei öffnen des Gehäuses der Batterie Status übermittelt wird!

ok weiter....

Zitatnach set ... getConfig und Anlernknopf kurz drücken erneut

'list EG.WZ.Tuerkontakt'
Aus der Information kann ich folgendes entnehmen:
- es ist das Ergebinis das ich erwartet habe..... also Readings werden aufgelistet etc.
- zugleich macht mir der Status: "2013-03-19 20:37:36 state MISSING ACK" sorgen -> dies ist aber eher ein Thema für Martin. Ich vermute das es mit seinen (angeforderten Tests) bzw. mit den nachvolgenden Tests behoben wird. Ich vermute, dass es was damit zu tun hat, dass du dein SC auch mit dem TC gepairt(hmm also, devicepairt -> also gepeert) hast.

Sonst kann ich keine, für mich verwertaberen Information entnehmen.

so weiter....

ZitatNun ein:

'set EG.WZ.Tuerkontakt regSet cyclicInfoMsg on' => 3 CMDs pending
'set EG.WZ.Tuerkontakt getConfig' => X CMDs pending

Anlernknopf kurz gedrückt, Browser refresh, alle CMDs abgearbeitet

ein 'list EG.WZ.Tuerkontakt' bringt:
Aus der Information kann ich folgendes entnehmen:
- "regSet" hat wie erwartet funktioniert
- bei deinen Sensor ist nun "R-cyclicInfoMsg on"
- "2013-03-19 20:37:36 state MISSING ACK" macht mir weiterhin sorgen (siehe Punkt zuvor -> da muss Martin ran.)

Sorry Martin ;o)

ZitatUnd nicht wundern, der HM-Sec-SC liegt gerade offen neben der Tastatur.
Ja, das sieht man "2013-03-19 20:37:23 cover open"
KANNST DIE TÜR RUHIG WIEDER ZUMACHEN ES WIRD SONST KALT ;o) UUUND DANKE.

Viele Grüße
Arthur
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: Rohan am 19 März 2013, 21:49:31
Hallo Arthur,

Zitat von: snoop schrieb am Di, 19 März 2013 21:38... Ich vermute, dass es was damit zu tun hat, dass du dein SC auch mit dem TC gepairt(?) hast.

Der VD war bis gerade nur mit dem TC gepeert, jetzt ist er auch mit dem HMLAN gepairt (die anderen kommen dann noch).

ZitatSonst kann ich keine, für mich verwertaberen Information entnehmen.

Da geht es dir wie mir! ;) Ich bin halt (in Sachen FHEM) Anwender, also in der Regel erst einmal Layer 8 *gg

Und der VD ist wieder closed. Bis jetzt war mir nur die Temperatursteuerung (Absenkung bei Tür offen) wichtig und das funktioniert(e). Der Rest (bezüglich evtl. Alarmfunktion) hat Nachrang bei mir. Dafür kommt demnächst die Zeit. Jetzt weiß ich ja, wie es geht.

Danke für diesen Thread.

Gruß
Thomas
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: martinp876 am 20 März 2013, 08:22:49
Hi,

Zum Protokol:
nach dem ersten getConfig sind 3 messages nicht verarbeitet worden
 
ZitatprotCmdDel 3
   protLastRcv 2013-03-19 20:37:33
   protResnd  2 last_at:2013-03-19 20:37:33
   protResndFail 1 last_at:2013-03-19 20:37:36
   protState  CMDs_done_events:3

Wichtig fuer den User ist nicht die 3 sondern das etwas nicht korrekt gelaufen ist.
Da kommt auch das missing-ack her.

Immer, wenn der Stack leer ist und neue Nachrichten gesendet werden sollen beginnt die Zaehlung neu
Es kam ein regSet und ein getConfig. Da es sein 'config' device ist werden also alle kommandos im Stack angehaeufelt bis das Device Empfangsbereitschaft signalisiert
=>
ZitatX CMDs pending
soll heisen Kommandos vom User abgesetzt aber nicht verarbeitet.

Dann Anlernen, als der Trigger, los gehts

Danach:
ZitatprotState  CMDs_done
=> alle Kommandos dieser Sequenz korrekt ausgefuehrt

Die Fehlerzaehler sind immer noch vorhanden. Die zaehlen ewig, erleben aber keinen Restart.

ZitatprotCmdDel 3
   protResnd  2 last_at:2013-03-19 20:37:33
   protResndFail 1 last_at:2013-03-19 20:37:36

Geaendert haben sich diese Zaehler, dies sind aber keine Fehler
 
ZitatprotLastRcv 2013-03-19 20:43:14
   protSnd    7 last_at:2013-03-19 20:43:14

Wenn man hier aufraeumen will kann man ein set name clear msgEvents ausfuehren. Das bereinigt das Protokoll, Zaehler und den command-stack

Fehler haben immer ein Fail am Ende. Ein "resend" ist noch kein Fehler, koennte ja noch klappen.

Und schliesslich das 'MISSING ACK' - unschoen. Es wird erst ueberschrieben, wenn ein neues Ereigniss eintritt. Da 'state' nicht dediziert dem protokoll gehoert schreiben ich auch kein 'send successful' rein - das waere dann quasi immer drin. In state stehen also immer die wichtigen device-zustaende (on,off,...) und eben auch ein missing ack.
der state bereinigt sich erst mit dem naechsten tuer-oeffnen oder einem statusRequest.

Gruss
Martin

Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: snoop am 28 März 2013, 00:20:48
Hallo Martin,
ZitatIch werden eine test-version bauen, mal sehen ob wir es schaffen. Dauert noch etwas
Kann ich bei dem Thema unterstützen - oder ist eher low prio bzw. uninteressant?
Gruß
Arthur

Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: martinp876 am 28 März 2013, 11:07:08
Hi Arthur,

kannst du die messages loggen/schicken, die
a) bei Aktion
b) zyklisch
gesendet werden? daran muss ich es festmachen

Danke
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: snoop am 28 März 2013, 12:07:48
Hallo Martin,

ich habe einige Logs hier liegen - ich suche was raus.

Viele Grüße
Arthur
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: snoop am 28 März 2013, 21:56:27
Hallo Martin,

anbei ein paar Messages.

a) bei Aktion


[code]
##########################################
## Aktor/sensor Log
##########################################
2013-03-28_21:02:36 Test4Martin contact: closed (to broadcast)
2013-03-28_21:34:39 Test4Martin open
2013-03-28_21:34:39 Test4Martin contact: open (to FL_Thermostat)
2013-03-28_21:34:43 Test4Martin closed
2013-03-28_21:34:43 Test4Martin contact: closed (to FL_Thermostat)
2013-03-28_21:34:51 Test4Martin open
2013-03-28_21:34:51 Test4Martin contact: open (to FL_Thermostat)
2013-03-28_21:35:02 Test4Martin closed
2013-03-28_21:35:02 Test4Martin contact: closed (to FL_Thermostat)
##########################################
##########################################
## FHEM Log
##########################################
2013.03.28 21:02:35 5: HMLAN/RAW: /E1E3145,0000,05226B4B,FF,FFB8,5E96101E314500000006010000

2013.03.28 21:02:35 5: HMLAN_Parse: HMLANAMA S:E1E3145   stat:0000 t:05226B4B d:FF r:FFB8 m:5E96101E314500000006010000
2013.03.28 21:02:35 5: HMLANAMA dispatch A0D5E96101E314500000006010000::-72:HMLANAMA
2013.03.28 21:02:35 5: Triggering Test4Martin (5 changes)
2013.03.28 21:02:35 5: Notify loop for Test4Martin alive: yes
...
2013.03.28 21:34:39 5: HMLAN/RAW: /E1E3145,0000,053FC7A2,FF,FFB9,5FB4411E31451D2AA1013FC8

2013.03.28 21:34:39 5: HMLAN_Parse: HMLANAMA S:E1E3145   stat:0000 t:053FC7A2 d:FF r:FFB9 m:5FB4411E31451D2AA1013FC8
2013.03.28 21:34:39 5: HMLANAMA dispatch A0C5FB4411E31451D2AA1013FC8::-71:HMLANAMA
2013.03.28 21:34:39 5: Triggering Test4Martin (2 changes)
2013.03.28 21:34:39 5: Notify loop for Test4Martin open
2013.03.28 21:34:40 5: HMLAN/RAW: /E1D2AA1,0000,053FC822,FF,FFBC,5F80021D2AA11E314500

2013.03.28 21:34:40 5: HMLAN_Parse: HMLANAMA S:E1D2AA1   stat:0000 t:053FC822 d:FF r:FFBC m:5F80021D2AA11E314500
2013.03.28 21:34:40 5: HMLANAMA dispatch A0A5F80021D2AA11E314500::-68:HMLANAMA
2013.03.28 21:34:43 5: HMLAN/RAW: /E1E3145,0000,053FD456,FF,FFB2,60B4411E31451D2AA1014000

2013.03.28 21:34:43 5: HMLAN_Parse: HMLANAMA S:E1E3145   stat:0000 t:053FD456 d:FF r:FFB2 m:60B4411E31451D2AA1014000
2013.03.28 21:34:43 5: HMLANAMA dispatch A0C60B4411E31451D2AA1014000::-78:HMLANAMA
2013.03.28 21:34:43 5: Triggering Test4Martin (2 changes)
2013.03.28 21:34:43 5: Notify loop for Test4Martin closed
2013.03.28 21:34:43 5: HMLAN/RAW: /E1D2AA1,0000,053FD4D7,FF,FFBD,6080021D2AA11E314500

2013.03.28 21:34:43 5: HMLAN_Parse: HMLANAMA S:E1D2AA1   stat:0000 t:053FD4D7 d:FF r:FFBD m:6080021D2AA11E314500
2013.03.28 21:34:43 5: HMLANAMA dispatch A0A6080021D2AA11E314500::-67:HMLANAMA
.....

2013.03.28 21:34:51 5: HMLAN/RAW: /E1E3145,0000,053FF684,FF,FFBE,61B4411E31451D2AA10141C8

2013.03.28 21:34:51 5: HMLAN_Parse: HMLANAMA S:E1E3145   stat:0000 t:053FF684 d:FF r:FFBE m:61B4411E31451D2AA10141C8
2013.03.28 21:34:51 5: HMLANAMA dispatch A0C61B4411E31451D2AA10141C8::-66:HMLANAMA
2013.03.28 21:34:51 5: Triggering Test4Martin (2 changes)
2013.03.28 21:34:51 5: Notify loop for Test4Martin open
2013.03.28 21:34:52 5: HMLAN/RAW: /E1D2AA1,0000,053FF705,FF,FFBB,6180021D2AA11E314500

2013.03.28 21:34:52 5: HMLAN_Parse: HMLANAMA S:E1D2AA1   stat:0000 t:053FF705 d:FF r:FFBB m:6180021D2AA11E314500
2013.03.28 21:34:52 5: HMLANAMA dispatch A0A6180021D2AA11E314500::-69:HMLANAMA
2013.03.28 21:35:00 5: HMLAN_Send:  K
2013.03.28 21:35:00 5: HMLAN/RAW: /HHM-LAN-IF,03C1,0123456789,1ACA40,D496B0,05401850,000B

2013.03.28 21:35:00 5: HMLAN_Parse: HMLANAMA V:03C1 sNo:0123456789 d:1ACA40 O:D496B0 m:05401850 IDcnt:000B
2013.03.28 21:35:02 5: HMLAN/RAW: /E1E3145,0000,05401E92,FF,FFBE,62B4411E31451D2AA1014200

2013.03.28 21:35:02 5: HMLAN_Parse: HMLANAMA S:E1E3145   stat:0000 t:05401E92 d:FF r:FFBE m:62B4411E31451D2AA1014200
2013.03.28 21:35:02 5: HMLANAMA dispatch A0C62B4411E31451D2AA1014200::-66:HMLANAMA
2013.03.28 21:35:02 5: Triggering Test4Martin (2 changes)
2013.03.28 21:35:02 5: Notify loop for Test4Martin closed
2013.03.28 21:35:02 5: HMLAN/RAW: /E1D2AA1,0000,05401F13,FF,FFBD,6280021D2AA11E314500

2013.03.28 21:35:02 5: HMLAN_Parse: HMLANAMA S:E1D2AA1   stat:0000 t:05401F13 d:FF r:FFBD m:6280021D2AA11E314500
2013.03.28 21:35:02 5: HMLANAMA dispatch A0A6280021D2AA11E314500::-67:HMLANAMA
2013.03.28 21:35:13 5: HMLAN/RAW: /E1D2AA1,0000,05404C2D,FF,FFBC,E886701D2AA100000000D830

2013.03.28 21:35:13 5: HMLAN_Parse: HMLANAMA S:E1D2AA1   stat:0000 t:05404C2D d:FF r:FFBC m:E886701D2AA100000000D830
2013.03.28 21:35:13 5: HMLANAMA dispatch A0CE886701D2AA100000000D830::-68:HMLANAMA
[/code]
b) zyklisch (cyclicInfoMsg "on")

[code]
##########################################
## Aktor/sensor Log
##########################################
2013-03-20_22:16:49 Test4Martin alive: yes
2013-03-20_22:16:49 Test4Martin battery: ok
2013-03-20_22:16:49 Test4Martin cover: closed
2013-03-20_22:16:49 Test4Martin closed
2013-03-20_22:16:49 Test4Martin contact: closed (to broadcast)
##########################################
##########################################
## FHEM Log
##########################################
2013.03.20 22:16:49 1: HMLAN/RAW: /E1E3145,0000,17677BBE,FF,FFBA,5696101E314500000006010000
2013.03.20 22:16:49 1: HMLAN_Parse: HMLANAMA S:E1E3145   stat:0000 t:17677BBE d:FF r:FFBA m:5696101E314500000006010000
2013.03.20 22:16:49 5: HMLANAMA dispatch A0D5696101E314500000006010000::-70:HMLANAMA
2013.03.20 22:16:49 1: RCV L:0D N:56 F:96 CMD:10 SRC:1E3145 DST:broadcast 06010000 (INFO_ACTUATOR_STATUS) (,WAKEMEUP,CFG,BURST,RPTEN)
2013.03.20 22:16:49 5: Triggering Test4Martin (5 changes)
2013.03.20 22:16:49 5: Notify loop for Test4Martin alive: yes

##########################################
## Aktor/sensor Log
##########################################
2013-03-21_22:07:26 Test4Martin alive: yes
2013-03-21_22:07:26 Test4Martin battery: ok
2013-03-21_22:07:26 Test4Martin cover: closed
2013-03-21_22:07:26 Test4Martin closed
2013-03-21_22:07:26 Test4Martin contact: closed (to broadcast)
##########################################
## FHEM Log
##########################################
2013.03.21 22:07:26 1: HMLAN/RAW: /E1E3145,0000,1C8569B9,FF,FFBF,5796101E314500000006010000
2013.03.21 22:07:26 1: HMLAN_Parse: HMLANAMA S:E1E3145   stat:0000 t:1C8569B9 d:FF r:FFBF m:5796101E314500000006010000
2013.03.21 22:07:26 5: HMLANAMA dispatch A0D5796101E314500000006010000::-65:HMLANAMA
2013.03.21 22:07:26 1: RCV L:0D N:57 F:96 CMD:10 SRC:1E3145 DST:broadcast 06010000 (INFO_ACTUATOR_STATUS) (,WAKEMEUP,CFG,BURST,RPTEN)
2013.03.21 22:07:26 5: Triggering Test4Martin (5 changes)
2013.03.21 22:07:26 5: Notify loop for Test4Martin alive: yes

##########################################
## Aktor/sensor Log
##########################################
2013-03-22_21:57:50 Test4Martin alive: yes
2013-03-22_21:57:50 Test4Martin battery: ok
2013-03-22_21:57:50 Test4Martin cover: closed
2013-03-22_21:57:50 Test4Martin closed
2013-03-22_21:57:50 Test4Martin contact: closed (to broadcast)
##########################################
## FHEM Log
##########################################
2013.03.22 21:57:50 5: HMLAN/RAW: /E1E3145,0000,21A31D75,FF,FFBF,5896101E314500000006010000
2013.03.22 21:57:50 5: HMLAN_Parse: HMLANAMA S:E1E3145   stat:0000 t:21A31D75 d:FF r:FFBF m:5896101E314500000006010000
2013.03.22 21:57:50 5: HMLANAMA dispatch A0D5896101E314500000006010000::-65:HMLANAMA
2013.03.22 21:57:50 5: Triggering Test4Martin (5 changes)
2013.03.22 21:57:50 5: Notify loop for Test4Martin alive: yes
[/code]

Vielleicht auch interessant - die zyklischen Messages kommen nach ca. 23:50h

2013-03-20_22:16:49 Test4Martin alive: yes
2013-03-20_22:16:49 Test4Martin battery: ok
2013-03-20_22:16:49 Test4Martin cover: closed
2013-03-20_22:16:49 Test4Martin closed
2013-03-20_22:16:49 Test4Martin contact: closed (to broadcast)
2013-03-21_22:07:26 Test4Martin alive: yes
2013-03-21_22:07:26 Test4Martin battery: ok
2013-03-21_22:07:26 Test4Martin cover: closed
2013-03-21_22:07:26 Test4Martin closed
2013-03-21_22:07:26 Test4Martin contact: closed (to broadcast)
2013-03-22_21:57:50 Test4Martin alive: yes
2013-03-22_21:57:50 Test4Martin battery: ok
2013-03-22_21:57:50 Test4Martin cover: closed
2013-03-22_21:57:50 Test4Martin closed
2013-03-22_21:57:50 Test4Martin contact: closed (to broadcast)
2013-03-23_21:48:56 Test4Martin alive: yes
2013-03-23_21:48:56 Test4Martin battery: ok
2013-03-23_21:48:56 Test4Martin cover: closed
2013-03-23_21:48:56 Test4Martin closed
2013-03-23_21:48:56 Test4Martin contact: closed (to broadcast)
2013-03-24_21:39:49 Test4Martin alive: yes
2013-03-24_21:39:49 Test4Martin battery: ok
2013-03-24_21:39:49 Test4Martin cover: closed
2013-03-24_21:39:49 Test4Martin closed
2013-03-24_21:39:49 Test4Martin contact: closed (to broadcast)
2013-03-25_21:30:29 Test4Martin alive: yes
2013-03-25_21:30:29 Test4Martin battery: ok
2013-03-25_21:30:29 Test4Martin cover: closed
2013-03-25_21:30:29 Test4Martin closed
2013-03-25_21:30:29 Test4Martin contact: closed (to broadcast)
2013-03-26_21:21:05 Test4Martin alive: yes
2013-03-26_21:21:05 Test4Martin battery: ok
2013-03-26_21:21:05 Test4Martin cover: closed
2013-03-26_21:21:05 Test4Martin closed
2013-03-26_21:21:05 Test4Martin contact: closed (to broadcast)
2013-03-27_21:11:28 Test4Martin alive: yes
2013-03-27_21:11:28 Test4Martin battery: ok
2013-03-27_21:11:28 Test4Martin cover: closed
2013-03-27_21:11:28 Test4Martin closed
2013-03-27_21:11:28 Test4Martin contact: closed (to broadcast)
2013-03-28_21:02:36 Test4Martin alive: yes
2013-03-28_21:02:36 Test4Martin battery: ok
2013-03-28_21:02:36 Test4Martin cover: closed
2013-03-28_21:02:36 Test4Martin closed
2013-03-28_21:02:36 Test4Martin contact: closed (to broadcast)
2013-03-28_21:34:39 Test4Martin open
2013-03-28_21:34:39 Test4Martin contact: open (to FL_Thermostat)
2013-03-28_21:34:43 Test4Martin closed
2013-03-28_21:34:43 Test4Martin contact: closed (to FL_Thermostat)
2013-03-28_21:34:51 Test4Martin open
2013-03-28_21:34:51 Test4Martin contact: open (to FL_Thermostat)
2013-03-28_21:35:02 Test4Martin closed
2013-03-28_21:35:02 Test4Martin contact: closed (to FL_Thermostat)


Weiterhin anzumerken ist, dass der HM-Sec-SC mit HM-CC-TC gepairt ist.

Ich hoffe es hilft bei der Aufklärung.

Viele Grüße
Arthur
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: martinp876 am 29 März 2013, 10:18:24
Hallo Arthur,

die Kommandos sollten mit dem wakeup ausgefuehrt werden, und der kommt einmal am Tag, soweit waren wir klar.
Probiert hast du schon, ein Kommando anzusetzen und dann 'einen Tag warten'. Kannst du dies einmal loggen?

Moegliches Problem ist, dass die Message des TC nicht verstanden wird.
2. Versuch ist dann, diese Message wegzulassen. Wenn du keinen TC hast kannst du Zeile 1291 auskommentieren
ZitatCUL_HM_SndCmd($shash, '++A112'.CUL_HM_IOid($shash).$src);
dann wieder ein Kommando absetzen und loggen (wieder einen Tag).

In beiden faellen sollte protState erst auf pending stehen und dann irgendwann auf 'done'

Ich werde noch einmal mit den TC testen.

Gruss
Martin
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: snoop am 29 März 2013, 12:40:31
Hallo Martin,

Zitatdie Kommandos sollten mit dem wakeup ausgefuehrt werden, und der kommt einmal am Tag, soweit waren wir klar.
Ja, mit CyclicInfo "on" kommt jeden Tag (in ca. 23:50h Abständen) der Bat-Status mit. "Aber" nur wenn die ca. 24h nicht unterbrochen wurde, durch offnen und schließen.

ZitatProbiert hast du schon, ein Kommando anzusetzen und dann 'einen Tag warten'. Kannst du dies einmal loggen?
Steige hier aus wofür das gut sein soll? Klar, ob commands nach ca. 24h mit CyclicInfo "on" abgearbeitet werden.
Tests laufen: 1x mit SC gepairt an TC und 1x gepairt nur mit HMLAN/FHEM. (Status Request angefordert - prostate steht bei beiden auf "CMDs_pending").

Ich habe die Zeile erst mal noch drin. Ist das ok oder bringt dann der test nichts?
CUL_HM_SndCmd($shash, '++A112'.CUL_HM_IOid($shash).$src);
Viele Grüße
Arthur
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: martinp876 am 29 März 2013, 13:03:26
Hi Artur,

das bring schon etwas. Einfach einmal loggen.
Einfach aufwecken wird schwierig werden. So steht es nicht in der Doku, oder ich habe sie falsch verstanden.
Ist dein Device eigentlich gepairt mit der Zentrale?

Gruss
Martin
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: snoop am 29 März 2013, 14:55:15
Hallo Martin,

der TC ist mit der Zentrale gepairt - zumindest bekomme ich diverse (Grad und Luftfeuchtigkeit) Messages.
Der SC ist mit TC gepairt - ich sehe es auf dem TC und ich sehe es in FHEM.
(wie ist das kann der SC mit TC und FHEM gepairt sein?). Also ich habe den SC zuerst mit dem TC gepairt und dann mit der Zentrale.
Viele Grüße
Arthur
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: martinp876 am 29 März 2013, 17:52:00
Hallo Arthur,

Zitatder TC ist mit der Zentrale gepairt - zumindest bekomme ich diverse (Grad und Luftfeuchtigkeit) Messages.
das hat erst einmal wenig zu sagen. FHEM hoert immer mit,egal wer der Empfaenger ist.

ZitatDer SC ist mit TC gepairt - ich sehe es auf dem TC und ich sehe es in FHEM.
(wie ist das kann der SC mit TC und FHEM gepairt sein?).
Ich rede hier von peer und pair.
Jedes "Device" kann mit EINER Zentrale "gepairt" werden. Alles was pair heisst bertifft device<->Zentrale.
"Channels" konnen mit anderen/mehreren Channels "gepeert" werden. Peer ist immer ein Sensor(Button ist auch ein Sensor) mit einem Aktor.

ZitatAlso ich habe den SC zuerst mit dem TC gepairt und dann mit der Zentrale.
Peeren kann man channels ohne FHEM/Zentrale. Das geht aber nur, solange die das Device noch "selbstaendig" ist, also nicht mit einer Zentrale "gepairt".
Wenn es gepairt ist hat die Zentrale die'kontrolle' ueber die Konfiguration, also kannst du mit "peerChan" channels peeren

Also Device pairen mit Zentrale
sensor-channels mit aktor-channels peeren

Nach erfolgreichem getConfig ist alles einsehbar im web-frontend

Gruss
Martin
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: snoop am 29 März 2013, 22:22:11
Hallo Martin,

so jetzt mal ein paar Details zum Test.

SC ist gepeert mit TC jedoch nicht mit der Zentrale
TC bin ich mir leider nicht mehr sicher - ich habe auf dem TC ein getConfig ausgeführt, weil ich in de Readings kein "PairedTo" sehen konnte, danach stand in R-pairCentral" set_0x123456, nach erneuten getConfig stand da PairedTo 0x123456 - also etwas seltsam vom Verhalten.

hier Logauszug aus dem Sensor: der interessante Teil: 2013-03-29_21:25:54 Test4Martin alive: yes
[code]
2013-03-28_21:34:39 Test4Martin open
2013-03-28_21:34:39 Test4Martin contact: open (to FL_Thermostat)
2013-03-28_21:34:43 Test4Martin closed
2013-03-28_21:34:43 Test4Martin contact: closed (to FL_Thermostat)
2013-03-28_21:34:51 Test4Martin open
2013-03-28_21:34:51 Test4Martin contact: open (to FL_Thermostat)
2013-03-28_21:35:02 Test4Martin closed
2013-03-28_21:35:02 Test4Martin contact: closed (to FL_Thermostat)
2013-03-29_21:25:54 Test4Martin alive: yes
2013-03-29_21:25:54 Test4Martin battery: ok
2013-03-29_21:25:54 Test4Martin cover: closed
2013-03-29_21:25:54 Test4Martin closed
2013-03-29_21:25:54 Test4Martin contact: closed (to broadcast)

[/code]

hier die raw Logs:

[code]2013.03.29 21:25:54 5: HMLAN/RAW: /E1E3145,0000,0A5E4912,FF,FFB7,6396101E314500000006010000
2013.03.29 21:25:54 5: HMLAN_Parse: HMLANAMA S:E1E3145   stat:0000 t:0A5E4912 d:FF r:FFB7 m:6396101E314500000006010000
2013.03.29 21:25:54 5: HMLANAMA dispatch A0D6396101E314500000006010000::-73:HMLANAMA
2013.03.29 21:25:54 5: Triggering Test4Martin (5 changes)
2013.03.29 21:25:54 5: Notify loop for Test4Martin alive: yes
2013.03.29 21:25:54 5: Triggering EMail_Batteriewarnung

[/code]

Der statusRequest wurde abgearbeitet zumindest, stand kein "CMDs pending" in protState. Allerdings kann ich dazu keine Einträge in den Logs sehen?!

Alles in allem etwas undurchsichtig :o(

Ich werde jetzt folgendes machen:
Ich peere noch ein mal den SC mit dem TC und den TC mit der Zetrale und kontrolliere alles.
Ergebnisse folgen.

Parallel habe ich noch ein SEC laufen der direkt an HMLAN gepairt ist (zu erkennen das er an HMLAN sendet und nicht broadcastet?).

[code]     2013-03-29 12:02:50   alive           yes
     2013-03-29 12:02:50   battery         ok
     2013-03-29 12:02:50   contact         closed (to HMLANAMA)
     2013-03-29 12:02:50   cover           closed
     2013-03-29 12:02:50   state           closed

[/code]
Viele Grüße
Arthur
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: martinp876 am 30 März 2013, 19:20:30
Hallo Arthur

Zitatweil ich in de Readings kein "PairedTo" sehen konnte[\quote]
=> kein getConfig gelaufen, jedenfalls nicht Erfolgreich
Zitatdanach stand in R-pairCentral" set_0x123456[\quote]
=> Schreiben des Registers wurde ausgelöst, evtl schon ausgeführt. Jedenfalls wurde nach dem schreiben die Register nicht mehr gelesen.
Zitatnach erneuten getConfig stand da PairedTo 0x123456[\quote]
=> "set_" bei registern wird zurückgenommen, wenn die register gelesen wurden. Ein Ack nach dem schreiben genügt mir nicht, da es zu kompliziert ist...

Du kannst mit autoReadReg das ganze steuern, die Register automatisch zu lesen. Ich empfehle level "3", nach schreiben sollte automatisch gelesen werden - zeitverzögert.

ZitatDer statusRequest wurde abgearbeitet zumindest, stand kein "CMDs pending" in protState. Allerdings kann ich dazu keine Einträge in den Logs sehen?![\quote]
das ist seltsam. Wie ist der Status? "CMDs_done"?  Das senden sollte zu sehen sein. Die wartenden Kommandos auch.
Kommandos(commandstack) gehen verloren, wenn es einen Restart gibt. Ist das de Fall?

Gruss
Martin
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: snoop am 30 März 2013, 21:30:24
Hallo Martin,

Zitat
Zitatweil ich in de Readings kein "PairedTo" sehen konnte
=> kein getConfig gelaufen, jedenfalls nicht Erfolgreich
Das mit den Readings habe ich noch nicht begriffen: navie Frage kann man das nicht cachen? Ich war mir sicher, dass ich vorher ein getConfig gemacht habe - mache ich immer - ja ich weiß das sagen alle ;o) - leider verschwinden diese irgendwann? (nach einen Neustart?) Fände es gut wenn diese gespeichert würden, grade bei den SC bzw. bei den Sensoren/Remotes bei denen man die Anlerntaste drücken muss.
Zitat
Zitatdanach stand in R-pairCentral" set_0x123456
=> Schreiben des Registers wurde ausgelöst, evtl schon ausgeführt. Jedenfalls wurde nach dem schreiben die Register nicht mehr gelesen.
Wie gesagt bin mir eigentlich sicher, dass ich es gemacht habe - wetten würde ich aber nicht.
Zitat
Zitatnach erneuten getConfig stand da PairedTo 0x123456
=> "set_" bei registern wird zurückgenommen, wenn die register gelesen wurden. Ein Ack nach dem schreiben genügt mir nicht, da es zu kompliziert ist...
Ja, ich weiß - Zitat: "paranoid" oder so. "erst wenn ich es ausgelesen habe glaube ich es... " - habs verstanden.

ZitatDu kannst mit autoReadReg das ganze steuern, die Register automatisch zu lesen. Ich empfehle level "3", nach schreiben sollte automatisch gelesen werden - zeitverzögert.
Ok, das "autoReadReg" ist schon in unseren Diskussionen öfters gefallen - kannst du dazu ein paar Details geben - was passiert da? Wird ein getConfig in regelmässsigen Abständen ausgeführt. Für welche Devices gilt das bzw. bei welchen funktioniert das? Hintergrund: wird vermutlich bei remotes und Sensoren nicht funktionieren hmmm :o( Soweit ich das auch heute sehen konnte muss man die "OK" auch bei dem TC bei einem getConfig drücken *grrrrr *HMnerv

Zitat
ZitatDer statusRequest wurde abgearbeitet zumindest, stand kein "CMDs pending" in protState. Allerdings kann ich dazu keine Einträge in den Logs sehen?!
das ist seltsam. Wie ist der Status? "CMDs_done"? Das senden sollte zu sehen sein. Die wartenden Kommandos auch.
Kommandos(commandstack) gehen verloren, wenn es einen Restart gibt. Ist das de Fall?
Das kann sein - ich habe aber auch auf deine Nachfrage noch ein getConfig abgefeuert und war mir nicht mehr sicher wieviele CMDs in der Queue standen bzw. stehen müssten. Was ich weiß ist: vorher stand 1 CDMs pending -> kann sein, dass dann ein restart erfolgt ist - habe gestern ein wenig getestet. Meines Wissens hätte da 4 CMDs (bei getConfig steht immer 3 CMDs + 1 statusRequest = 4) stehen müssen daher gehe ich davon aus, dass der 1 CMD abgearbeitet wurde.
Leider alles Spekulationen, ich habe daraufhin folgendes gemacht:
- SC mit dem TC sauber gepeert
- TC sauber mit der Zentrale gepairt.
- alles inkl. getConfig => überpfüft, ob alles sauber eingerichtet ist.
- gut heute habe ich FHEM ein paar mal durchgestartet und grade noch ein "statusRequest" an "Test4Martin (SEC-SC)" abgefeuert.
Status aktuell:
protoEvents done:
    name                :protState              |protCmdPend            |protSnd                |protLastRcv            |protResndFail          
    Test4Martin         : CMDs_pending         |1 CMDs_pending       |-                   |-                   |-              

Status wird gegen 22:xx Uhr erwartet.

Viele Grüße
Arthur
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: snoop am 30 März 2013, 23:26:12
Hallo Martin,

hier die Ergebnisse:

protoEvents done:
    name                :protState              |protCmdPend            |protSnd                |protLastRcv            |protResndFail          
    Test4Martin         : CMDs_done_events:1   |-                   |1:2013-03-30 21:55:21 |2013-03-30 21:55:21


List Test4Martin (HM-SEC-SC)

Internals:
   DEF        1E3145
   EVENTS     2
   HMLANAMA_MSGCNT 2
   HMLANAMA_RAWMSG RBD154A78,0001,0F9FC7F3,FF,FFBE,4880021E314512345680
   HMLANAMA_RSSI -66
   HMLANAMA_TIME 2013-03-30 21:55:21
   IODev      HMLANAMA
   LASTInputDev HMLANAMA
   MSGCNT     2
   NAME       Test4Martin
   NR         670
   STATE      NACK
   TYPE       CUL_HM
   lastMsg    No:48 - t:02 s:1E3145 d:123456 80
   protCmdDel 0
   protLastRcv 2013-03-30 21:55:21
   protNack   1 last_at:2013-03-30 21:55:21
   protSnd    1 last_at:2013-03-30 21:55:21
   protState  CMDs_done_events:1
   rssi_at_HMLANAMA avg:-66 min:-66 max:-66 lst:-66 cnt:2
   Readings:
     2013-03-19 22:23:28   3SSunknownMsg   03051E31450103
     2013-03-29 22:04:21   Activity:       alive
     2013-03-30 21:55:21   CommandAccepted no
     2013-03-29 22:04:21   PairedTo        0x0
     2013-03-29 22:04:23   R-FL_Thermostat_WindowRec-expectAES off
     2013-03-29 22:04:23   R-FL_Thermostat_WindowRec-peerNeedsBurst on
     2013-03-29 22:04:21   R-cyclicInfoMsg on
     2013-03-29 22:04:22   R-eventDlyTime  0 s
     2013-03-29 22:04:21   R-intKeyVisib   invisib
     2013-03-29 22:04:22   R-ledOnTime     0.5 s
     2013-03-29 22:04:22   R-msgScPosA     closed
     2013-03-29 22:04:22   R-msgScPosB     open
     2013-03-29 22:04:21   R-pairCentral   0x0
     2013-03-29 22:04:21   R-sabotageMsg   on
     2013-03-29 22:04:21   R-transmDevTryMax 6
     2013-03-29 22:04:22   R-transmitTryMax 6
     2013-03-29 22:04:21   RegL_00:        02:00 09:01 0A:00 0B:00 0C:00 10:01 14:06 00:00
     2013-03-29 22:04:22   RegL_01:        08:00 20:60 21:00 22:64 30:06 00:00
     2013-03-29 22:04:23   RegL_04:FL_Thermostat_WindowRec 01:01 00:00
     2013-03-30 21:55:21   alive           yes
     2013-03-30 21:55:21   battery         ok
     2013-03-30 21:55:21   contact         closed (to broadcast)
     2013-03-30 21:55:21   cover           closed
     2013-03-30 21:55:21   state           NACK
   Helper:
     burstEvtCnt 1
     mId        002F
     rxType     12
     Role:
       chn        1
       dev        1
     Rssi:
       At_hmlanama:
         avg        -66
         cnt        2
         lst        -66
         max        -66
         min        -66
Attributes:
   expert     2_full
   firmware   2.0
   model      HM-SEC-SC
   peerIDs    
   serialNr   1234567890
   subType    threeStateSensor

List TC

Internals:
   DEF        1D2AA1
   EVENTS     86
   HMLANAMA_MSGCNT 86
   HMLANAMA_RAWMSG E1D2AA1,0000,0FE3B7AE,FF,FFB8,7D86701D2AA100000000E232
   HMLANAMA_RSSI -72
   HMLANAMA_TIME 2013-03-30 23:09:33
   IODev      HMLANAMA
   LASTInputDev HMLANAMA
   MSGCNT     86
   NAME       FL_Thermostat
   NR         700
   STATE      T: 21.6 H: 50
   TYPE       CUL_HM
   channel_01 FL_Thermostat_Weather
   channel_02 FL_Thermostat_Climate
   channel_03 FL_Thermostat_WindowRec
   lastMsg    No:7D - t:70 s:1D2AA1 d:000000 00E232
   protLastRcv 2013-03-30 23:09:33
   rssi_at_HMLANAMA avg:-71.7 min:-76 max:-67 lst:-72 cnt:86
   Readings:
     2013-03-29 23:49:25   Activity:       alive
     2013-03-29 22:04:58   CommandAccepted yes
     2013-03-29 21:33:40   PairedTo        0x123456
     2013-03-29 21:33:40   R-backlOnMode   2
     2013-03-29 21:33:40   R-backlOnTime   2 s
     2013-03-29 21:33:40   R-btnLock       unlock
     2013-03-29 21:33:40   R-intKeyVisib   invisib
     2013-03-29 21:33:40   R-pairCentral   0x123456
     2013-03-29 21:33:40   RegL_00:        01:01 02:01 05:82 0A:D4 0B:96 0C:B0 0F:00 00:00
     2013-03-30 21:55:24   desired-temp    21.0
     2013-03-30 23:09:33   humidity        50
     2013-03-30 23:09:33   measured-temp   21.6
     2013-03-19 22:23:26   noReceiver      src:1D2AA1 (A001) 01080101
     2013-03-30 23:09:33   state           T: 21.6 H: 50
     2013-03-30 00:02:27   time-request    -
   Helper:
     mId        0039
     rxType     12
     Respwait:
     Role:
       chn        1
       dev        1
     Rssi:
       At_hmlanama:
         avg        -71.7093023255814
         cnt        86
         lst        -72
         max        -67
         min        -76
Attributes:
   expert     2_full
   firmware   2.1
   group      Thermostat
   model      HM-CC-TC
   peerIDs    
   serialNr   0987654321
   subType    thermostat


Raw Message:


2013.03.30 21:55:15 4: Connection closed for FHEMWEB:1.1.1.1:65093
2013.03.30 21:55:21 5: HMLAN/RAW: /E1E3145,0000,0F9FC6E7,FF,FFBE,7796101E314500000006010000

2013.03.30 21:55:21 5: HMLAN_Parse: HMLANAMA S:E1E3145   stat:0000 t:0F9FC6E7 d:FF r:FFBE m:7796101E314500000006010000
2013.03.30 21:55:21 5: HMLANAMA dispatch A0D7796101E314500000006010000::-66:HMLANAMA
2013.03.30 21:55:21 5: HMLAN_Send:  +1E3145,00,00,
2013.03.30 21:55:21 5: HMLAN_Send:  SBD154A78,00,00000000,01,BD154A78,48A0011234561E3145010E
2013.03.30 21:55:21 5: Triggering Test4Martin (5 changes)
2013.03.30 21:55:21 5: Notify loop for Test4Martin alive: yes
2013.03.30 21:55:21 5: Triggering EMail_Batteriewarnung
.....
2013.03.30 21:55:21 5: HMLAN/RAW: /RBD154A78,0001,0F9FC7F3,FF,FFBE,4880021E314512345680

2013.03.30 21:55:21 5: HMLAN_Parse: HMLANAMA S:RBD154A78 stat:0001 t:0F9FC7F3 d:FF r:FFBE m:4880021E314512345680
2013.03.30 21:55:21 5: HMLANAMA dispatch A0A4880021E314512345680::-66:HMLANAMA
2013.03.30 21:55:21 5: Triggering Test4Martin (1 changes)
2013.03.30 21:55:21 5: Notify loop for Test4Martin NACK
2013.03.30 21:55:22 5: HMLAN/RAW: /E1B0D43,0000,0F9FCBDD,FF,FFC7,0084411B0D43000000012F2440

2013.03.30 21:55:22 5: HMLAN_Parse: HMLANAMA S:E1B0D43   stat:0000 t:0F9FCBDD d:FF r:FFC7 m:0084411B0D43000000012F2440
2013.03.30 21:55:22 5: HMLANAMA dispatch A0D0084411B0D43000000012F2440::-57:HMLANAMA
2013.03.30 21:55:22 5: Triggering KW_Bewegungsmelder (4 changes)
2013.03.30 21:55:22 5: Notify loop for KW_Bewegungsmelder motion
2013.03.30 21:55:22 5: Triggering BZ_Licht_an
.....
2013.03.30 21:55:23 5: HMLAN/RAW: /E1D2AA1,0000,0F9FCF20,FF,FFB8,60A4101D2AA112345606022A00000000

2013.03.30 21:55:23 5: HMLAN_Parse: HMLANAMA S:E1D2AA1   stat:0000 t:0F9FCF20 d:FF r:FFB8 m:60A4101D2AA112345606022A00000000
2013.03.30 21:55:23 5: HMLAN: manual ACK
2013.03.30 21:55:23 5: HMLAN: Skip ACK
2013.03.30 21:55:23 5: HMLANAMA dispatch A1060A4101D2AA112345606022A00000000::-72:HMLANAMA
2013.03.30 21:55:23 5: HMLAN: Skip ACK
2013.03.30 21:55:23 5: Triggering FL_Thermostat_Climate (1 changes)
2013.03.30 21:55:23 5: Notify loop for FL_Thermostat_Climate desired-temp: 21.0
2013.03.30 21:55:23 5: Triggering FL_Thermostat (1 changes)
2013.03.30 21:55:23 5: Notify loop for FL_Thermostat desired-temp: 21.0
2013.03.30 21:55:23 5: HMLAN/RAW: /E1D2AA1,0000,0F9FD024,FF,FFB9,61A4101D2AA112345606022A00000000

2013.03.30 21:55:23 5: HMLAN_Parse: HMLANAMA S:E1D2AA1   stat:0000 t:0F9FD024 d:FF r:FFB9 m:61A4101D2AA112345606022A00000000
2013.03.30 21:55:23 5: HMLAN: manual ACK
2013.03.30 21:55:23 5: HMLAN: Skip ACK
2013.03.30 21:55:23 5: HMLANAMA dispatch A1061A4101D2AA112345606022A00000000::-71:HMLANAMA
2013.03.30 21:55:24 5: HMLAN: Skip ACK
2013.03.30 21:55:24 5: Triggering FL_Thermostat_Climate (1 changes)
2013.03.30 21:55:24 5: Notify loop for FL_Thermostat_Climate desired-temp: 21.0
2013.03.30 21:55:24 5: Triggering FL_Thermostat (1 changes)
2013.03.30 21:55:24 5: Notify loop for FL_Thermostat desired-temp: 21.0
2013.03.30 21:55:24 5: HMLAN/RAW: /E1D2AA1,0000,0F9FD122,FF,FFB9,62A4101D2AA112345606022A00000000

2013.03.30 21:55:24 5: HMLAN_Parse: HMLANAMA S:E1D2AA1   stat:0000 t:0F9FD122 d:FF r:FFB9 m:62A4101D2AA112345606022A00000000
2013.03.30 21:55:24 5: HMLAN: manual ACK
2013.03.30 21:55:24 5: HMLAN: Skip ACK
2013.03.30 21:55:24 5: HMLANAMA dispatch A1062A4101D2AA112345606022A00000000::-71:HMLANAMA
2013.03.30 21:55:24 5: HMLAN: Skip ACK
2013.03.30 21:55:24 5: Triggering FL_Thermostat_Climate (1 changes)
2013.03.30 21:55:24 5: Notify loop for FL_Thermostat_Climate desired-temp: 21.0
2013.03.30 21:55:24 5: Triggering FL_Thermostat (1 changes)
2013.03.30 21:55:24 5: Notify loop for FL_Thermostat desired-temp: 21.0
2013.03.30 21:55:25 5: HMLAN_Send:  K
2013.03.30 21:55:25 5: HMLAN/RAW: /HHM-LAN-IF,03C1,9999999999,1ACA40,123456,0F9FD63C,0006

2013.03.30 21:55:25 5: HMLAN_Parse: HMLANAMA V:03C1 sNo:9999999999 d:1ACA40 O:123456 m:0F9FD63C IDcnt:0006
2013.03.30 21:55:33 5: HMLAN/RAW: /E1D2AA1,0000,0F9FF533,FF,FFBA,6086701D2AA100000000D834

2013.03.30 21:55:33 5: HMLAN_Parse: HMLANAMA S:E1D2AA1   stat:0000 t:0F9FF533 d:FF r:FFBA m:6086701D2AA100000000D834
2013.03.30 21:55:33 5: HMLANAMA dispatch A0C6086701D2AA100000000D834::-70:HMLANAMA
2013.03.30 21:55:33 5: Triggering FL_Thermostat_Weather (3 changes)
2013.03.30 21:55:33 5: Notify loop for FL_Thermostat_Weather T: 21.6 H: 52
2013.03.30 21:55:33 5: Triggering FL_Thermostat (3 changes)
2013.03.30 21:55:33 5: Notify loop for FL_Thermostat T: 21.6 H: 52

2013.03.30 21:55:38 5: HMLAN/RAW: /E1B0D43,0000,0FA00748,FF,FFC8,0184411B0D4300000001302440

2013.03.30 21:55:38 5: HMLAN_Parse: HMLANAMA S:E1B0D43   stat:0000 t:0FA00748 d:FF r:FFC8 m:0184411B0D4300000001302440
2013.03.30 21:55:38 5: HMLANAMA dispatch A0D0184411B0D4300000001302440::-56:HMLANAMA

Hoffe, es ist was verwertbares dabei.
Viele Grüße
Arthur
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: martinp876 am 31 März 2013, 12:22:09
Hi Arthur,

das sieht nach Erfolg aus.
Das Device hat geantwortet,wenn auch mit NACK. Es heisst also,dass die message empfangen wurde aber der Inhalt nicht gepasst hat.

Damit habe ich 2 neue Fragen :
a) wird der statusRequest von device ueberhaupt beantwortet? Test: statusRequest ausloesen und anlernen druecken. Kommt ein ack oder ein NACK?

b) wuerde ein getConfig anstelle eines statusRequest funktionieren? Test: getConfig und eine Nacht warten

Gruss
Martin
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: snoop am 31 März 2013, 13:15:03
Hallo Martin,

Zitata) wird der statusRequest von device ueberhaupt beantwortet? Test: statusRequest ausloesen und anlernen druecken. Kommt ein ack oder ein NACK?
Ein NACK. Nach auf/zu Aktion wechselt der Status auf closed.
Ein getConfig liefert auch ein NACK.
FHEM Update gestern durchgeführt.
Zitatb) wuerde ein getConfig anstelle eines statusRequest funktionieren? Test: getConfig und eine Nacht warten
Ok, Ergebnis wird vermutlich ein NACK sein?! Siehe oben.

Viele Grüße
Arthur
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: martinp876 am 31 März 2013, 17:00:26
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
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: snoop am 31 März 2013, 17:32:42
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?
Titel: Aw: Fehlender Batteriestatus in Readings
Beitrag von: martinp876 am 01 April 2013, 18:11:18
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
Titel: Antw:Fehlender Batteriestatus in Readings
Beitrag von: Gast45 am 22 Februar 2018, 16:30:08
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?
Titel: Antw:Fehlender Batteriestatus in Readings
Beitrag von: Pfriemler am 22 Februar 2018, 17:19:36
 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.
Titel: Antw:Fehlender Batteriestatus in Readings
Beitrag von: Gast45 am 22 Februar 2018, 17:59:33
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 :)
Titel: Antw:Fehlender Batteriestatus in Readings
Beitrag von: stromer-12 am 23 Februar 2018, 17:10:58
Ich habe einen im Briefkasten verbaut, die Batterie hält jetzt 2 Jahre.
Letzte Woche war mal kurz ein Batterie Low aufgetaucht.