Re: Bewegungsmelder HM-SEC-MDIR

[Guest]

Originally posted by: <email address deleted>

Der Anhang ist gut, die Webdarstellung ist mist.

Mittlerweile hast du die richtige Schreibweise von get regList gefunden
Das kommando sollte auch klar sein.

Ausgefuehrt wurde noch nichts, das kannst du am command-stack sehen - und
am eintrag protCmdPend - Kommandos die auf  Verarbeitung warten.
Grund ist, dass man auf einige Devices nicht so einfach schreiben kann  
(auch nicht lesen). FHEM speichert die kommandos bis schreiben moeglich
ist.
Der MDIR hat 2 modi zum Schreiben und Lesen im Angebot
a) config: wenn der Anlernknopf gedrueckt wird sollte FHEM die Daten senden
- d.h.alle kommandos aus dem Stack abarbeiten
b)wakeup: Immer wenn das Device aufwacht (ist das alle 4 min?) schickt es
eine message an die Zentrale - dann sollten die Daten auch automatisch
uebertragen werden.

Einfach so schreiben geht bei diesen device(leider) nicht).

Geht eine der beiden Methoden (oder beide)? Stimmern die 3-4min?

Gruss
Martin


--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Ok, dann per Anhang....

Ein blindes Huhn........

Es sieht so aus, als wenn nur die Methode Anlernknopf die Queue abbaut.
Aber ich kann an dem Bewegungsmelder keine Änderung der Konfiguration
feststellen.
Ich habe danach minInterval auf 1 (=15s) gesetzt, aber die Reaktion im
Log zu sehen kam erst nach der mit der HM-LAN Software gesetzten 60
Sekunden.
Im Log waren auch einige (3) RESPONSE TIMEOUT  und ein MISSING ACK. Das
muss ich zeitmässig noch mal näher verifizieren, wann das aufgetreten ist.
Leider bietet Putty keinen Timestamp im Log an  ((  (Könnte man bei
FHEM-Commandline nicht wahlweise einen Timestamp vor die Ausgabe
schreiben???)


LG

RB

Am 25.10.2012 14:00, schrieb Martin:
> Der Anhang ist gut, die Webdarstellung ist mist.
>
> Mittlerweile hast du die richtige Schreibweise von get regList
> gefunden
> Das kommando sollte auch klar sein.
>
> Ausgefuehrt wurde noch nichts, das kannst du am command-stack sehen -
> und am eintrag protCmdPend - Kommandos die auf Verarbeitung warten.
> Grund ist, dass man auf einige Devices nicht so einfach schreiben
> kann  (auch nicht lesen). FHEM speichert die kommandos bis schreiben
> moeglich ist.
> Der MDIR hat 2 modi zum Schreiben und Lesen im Angebot
> a) config: wenn der Anlernknopf gedrueckt wird sollte FHEM die Daten
> senden - d.h.alle kommandos aus dem Stack abarbeiten
> b)wakeup: Immer wenn das Device aufwacht (ist das alle 4 min?) schickt
> es eine message an die Zentrale - dann sollten die Daten auch
> automatisch uebertragen werden.
>
> Einfach so schreiben geht bei diesen device(leider) nicht).
>
> Geht eine der beiden Methoden (oder beide)? Stimmern die 3-4min?
>
> Gruss
> Martin
>
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hallo Martin,

anbei ein Logauszug.


Der MDIR meldet sich mit einem alive alle 30 Sekunden (laut FHEMlog),
Statusmeldungen wie "Cover open" oder "Brightness" werden circa alle 240
- 360 Sekunden übermittelt, das ist nicht sehr regelmässig.

LG

RB


Am 26.10.2012 10:36, schrieb Martin:
>
> Ob der Wert gesetzt ist kannst du mit getConfig pruefen - das Kommando
> kannst du gleich mit auf 'den stack legen', es wird mit einem Anlernen
> ausgefuehrt.
>
> RESPONSE TIMEOUT nicht gut. Es kommt wenn vom Device Daten angefordert
> wurden und diese nicht gekommen sind.  Kann bei einem getConfig
> mehrfach kommen da mehrer Bloecke von Daten gelesen werden.
>
> Wenn du einen Log hast kann ich gerne einmal nachsehen.
> Ich habe gestern Abend eine neue Version abgegeben - da geht das Lesen
> mit HMLAN besser (du hast HMLAN? oder CUL?).
> Es ist aber noch nicht fertig da beispeilsweise meine RC12 nicht ihre
> kompletten daten losweren kann. Das Problem liegt in HMLAN - wie eine
> CUL reagiert habe ich nicht probiert.
> Missing ACK koennte ein Fehler beim Schreiben gewesen sein - die
> werden i.A. mit ACK quittiert
>
> Interessieren wuerde mich
> - in welchen imterval meldet sich dein MDIR?
> - kannst du eine Sequenz loggen wenn commands  am stack liegen und das
> device erwacht?
> - kannst du eine Sequenz loggen wenn commands  am stack liegen und du
> anlernst?
>
> Danke
> Martin
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hallo RB,

habe die Logs mal durchgesehen.
1) die alive message kommt 'nervig oft'. Sollte man eigentlich nur bei
"events" - also bei einer Zustandsaenderung schicken. Zusammen mit der Dead
ueberwachung  koennte man den Event auch ganz fallen lassen  - aber
wenigstens auf 'reportOnChange' umstellen Bei Alive ist ein 'dead' nicht
moeglich - daher gibt es ja jetzt den 'actiondetector'
2) das auslesen der Parameter hat nicht funktioniert. Das war aber auch
nicht die Letzte SW. Kannst du es noch einmal mit 2035 probieren?
getConfig, dann anlernen.
3) die message type 70 wird aktuell nicht ausgewertet - kommt aber mir
zusatzinfo. Die werde ich mal roh in ein Reading schreiben bis sie einer
Dekodieren kann.
4) demnaechst, - naechste Version - ist die triggermessage zerlegt und
sollte die events count, brightness und nextTransmit liefern. Bitte
beobachten.
5) Cover open kommt nur mit geoeffnetem cover - ich nehme an der war auch
offen bei dir, sonst ist es eine alte SW oder ein bug


Gruss
Martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hallo Martin,

anbei der neueste Versuch mit der 2035, nach meiner bescheidenen Meinung
hat sich nicht viel geändert (oder gar nichts???)

Cover ist derzeit immer open, der MDIR steht noch auf meinem
Schreibtisch  und dann komme ich besser an den Anlernknopf

LG

RueBe


Am 29.10.2012 13:40, schrieb Martin:
> Hallo RB,
>
> habe die Logs mal durchgesehen.
> 1) die alive message kommt 'nervig oft'. Sollte man eigentlich nur bei
> "events" - also bei einer Zustandsaenderung schicken. Zusammen mit der
> Dead ueberwachung  koennte man den Event auch ganz fallen lassen  -
> aber wenigstens auf 'reportOnChange' umstellen Bei Alive ist ein
> 'dead' nicht moeglich - daher gibt es ja jetzt den 'actiondetector'
> 2) das auslesen der Parameter hat nicht funktioniert. Das war aber
> auch nicht die Letzte SW. Kannst du es noch einmal mit 2035 probieren?
> getConfig, dann anlernen.
> 3) die message type 70 wird aktuell nicht ausgewertet - kommt aber mir
> zusatzinfo. Die werde ich mal roh in ein Reading schreiben bis sie
> einer Dekodieren kann.
> 4) demnaechst, - naechste Version - ist die triggermessage zerlegt und
> sollte die events count, brightness und nextTransmit liefern. Bitte
> beobachten.
> 5) Cover open kommt nur mit geoeffnetem cover - ich nehme an der war
> auch offen bei dir, sonst ist es eine alte SW oder ein bug
>
>
> Gruss
> Martin
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hallo,

nach den Logs ist Cover open korrekt. Dein MDIR meldet
FCA610189E00BB89A006014D0E
bei Cover closed sollte dort 00 stehen.

Ist dein MDIR defect (coverkontakt) oder ist das Cover offen?

verwendest du noch die alte Version von HMLAN? Evtl ist ein Update nicht
notwendig bei dir.

Gruss
Martin

Am Dienstag, 30. Oktober 2012 07:03:53 UTC+1 schrieb Ruebezahl:
>
> Hallo Martin,
>
> anbei der neueste Versuch mit der 2035, nach meiner bescheidenen Meinung
> hat sich nicht viel geï¿œndert (oder gar nichts???)
>
> Cover ist derzeit immer open, der MDIR steht noch auf meinem
> Schreibtisch  und dann komme ich besser an den Anlernknopf
>
> LG
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hallo,

Cover ist auch offen gewesen, also der MDIR ist in Ordnung und alles hat
seine Richtigkeit.

Ich habe CUL_HM auf 2035 gebracht, allerdings ist HMLAN auf dem Stand
vom 16.10.2012. Sollte ich das auch mal updaten, ich sehe im SVN, das
die neueste Version vom 27.10. ist?

LG

RueBe


Am 30.10.2012 11:52, schrieb Martin:
> Hallo,
>
> nach den Logs ist Cover open korrekt. Dein MDIR meldet
> FCA610189E00BB89A006014D0E
> bei Cover closed sollte dort 00 stehen.
>
> Ist dein MDIR defect (coverkontakt) oder ist das Cover offen?
>
> verwendest du noch die alte Version von HMLAN? Evtl ist ein Update
> nicht notwendig bei dir.
>
> Gruss
> Martin
>
> Am Dienstag, 30. Oktober 2012 07:03:53 UTC+1 schrieb Ruebezahl:
>
>     Hallo Martin,
>
>     anbei der neueste Versuch mit der 2035, nach meiner bescheidenen
>     Meinung
>     hat sich nicht viel geï¿œndert (oder gar nichts???)
>
>     Cover ist derzeit immer open, der MDIR steht noch auf meinem
>     Schreibtisch  und dann komme ich besser an den Anlernknopf
>
>     LG
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Moin,

ich klinke mich hier mal ein. Ich hab weder den HMLAN noch die Homematic
Software und würde gerne den MinInterval setzen. Geht das mittlerweile - so
wie ich das hier in dem Thread verstanden habe, ging das doch nicht?

set BZ_BewMelder regSet minInterval 1

-> Argument "unknown" isn't numeric in bitwise and (&) at
/usr/share/fhem/FHEM/10_CUL_HM.pm line 1869

minInterval sollte doch Integer sein oder?

Gruß

Kai

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hallo Kai,

da muss ich sicher noch eine Anleitung schreiben (oder habe ich schon im
EinsteigerDoc? weiss nicht mehr)
a) deine Aussage ist korrekt
b) einige (dieses auch) Register sind bitfelder - also bruchteile von
Bytes. Die kann ich nicht aendern ohne den Rest des Bytes zu kennen.

Du solltest also erst einmal die Daten aus dem Deive lesen (getConfig)
damit die Werte in FHEM vorliegen. Danach solltest du das Kommando
ausfuehren koennen.
An einer besseren Fehlermeldung werde ich gleich arbeiten.

Gruss
Martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hallo Martin,

da muss ich sicher noch eine Anleitung schreiben (oder habe ich schon im
> EinsteigerDoc? weiss nicht mehr)


Also gefunden hab ich nix in der Doku

 

> a) deine Aussage ist korrekt
> b) einige (dieses auch) Register sind bitfelder - also bruchteile von
> Bytes. Die kann ich nicht aendern ohne den Rest des Bytes zu kennen.
>
 

> Du solltest also erst einmal die Daten aus dem Deive lesen (getConfig)
> damit die Werte in FHEM vorliegen. Danach solltest du das Kommando
> ausfuehren koennen.
> An einer besseren Fehlermeldung werde ich gleich arbeiten.


Ok, wenn ich das richtig verstehe, sollte ich erst

fhem> set BZ_BewMelder getConfig

machen und dann ein

 set BZ_BewMelder regSet minInterval 1

Allerdings schein ich noch was falsch zu machen, die Fehlermeldung bleibt
gleich

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

>
> da muss ich sicher noch eine Anleitung schreiben (oder habe ich schon im
>> EinsteigerDoc? weiss nicht mehr)
>
>
> Also gefunden hab ich nix in der Doku
>
hmm da muss ich noch etwas machen

>
>  
> Ok, wenn ich das richtig verstehe, sollte ich erst
>
> fhem> set BZ_BewMelder getConfig
>
> machen und dann ein
>
>  set BZ_BewMelder regSet minInterval 1
>
> Allerdings schein ich noch was falsch zu machen, die Fehlermeldung bleibt
> gleich
>

erst einmal korrekt.
1)getConfig leist die Daten
 Anmerlungen: Die Daten koennen bei einigen devices nicht  sofort gelesen
werden, da man auf das aufwachen des device warten muss. Ich komme einfach
nicht schneller ran.
Du musst also warten bis die Daten gelesen sind. Ich schaetze beim
Bewegungsmelder sind dies 4 min?
Sehen kannst du es an vielen stellen
- keine kommands mehr pending
- register-readings vorhanden
- prot-state auf done

2) danach koennen Daten geschrieben werden.


Das auslesen der Daten muss nur einmal erfolgen, damit ich eine Basis habe,
von der aus ich aendern kann. Die Daten werden auch bei save gespeichert.
Noch habe ich keinen Automatismus, konfigurationen nach dem Start zu
lesen... vielleicht  bekomme ich so etwas hin.

Kann es an der Wartezeit gelegen haben?

Gruss
Martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hi Martin,

 

> 1)getConfig leist die Daten
>  Anmerlungen: Die Daten koennen bei einigen devices nicht  sofort gelesen
> werden, da man auf das aufwachen des device warten muss. Ich komme einfach
> nicht schneller ran.
> Du musst also warten bis die Daten gelesen sind. Ich schaetze beim
> Bewegungsmelder sind dies 4 min?
>

Momentan ja, weil minINterval=4 ist

 

> Sehen kannst du es an vielen stellen
> - keine kommands mehr pending
>

steht bei mir auf protCmdPend 61 CMDs_pending  

Wie kommt das? Der Bewegungsmelder scheint aber einwandfrei zu funktionieren

 

> - register-readings vorhanden
>

ist auch vorhanden mit folgenden Werten:

battery ok 2012-11-16 19:18:46
brightness 40 2012-11-18 20:20:25
cover closed 2012-11-16 19:18:46
motion on (to BZ_ActionDetector) 2012-11-18 20:20:25
motionCount 86_next:8 2012-11-18 20:20:25
state motion 2012-11-18 20:20:25

Dazu noch eine Nebenfrage: Ich hab den Bewegungsmelder mit Autodetect
angelernt und er hat auch automatisch ein Gerät ActionDetector generiert.
Wofür ist dieser?



 

> - prot-state auf done
>

protState hab ich gar nicht


 

> 2) danach koennen Daten geschrieben werden.  
>


Also lese ich die Daten, warte auf den nächsten Cycle und schreibe dann die
Daten neu?


 Gruß

Kai

PS: Gibts irgendwo ne TechDoku welche Werte der HM-SEC-MDIR liefert? Mich
interessiert was actStatus und actCycle bedeutet

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hallo Kai,
>
>  
>
>> Sehen kannst du es an vielen stellen
>> - keine kommands mehr pending
>>
>
> steht bei mir auf protCmdPend 61 CMDs_pending  
> Wie kommt das? Der Bewegungsmelder scheint aber einwandfrei zu
> funktionieren
>
hmm. ich habe keinen Bewegungsmelder und kann den nicht testen.
fakt ist, dass seit einiger Zeit keinen Kommandos von fhem an den
Bewegungsmelder geschickt wurden.
Dein mdir-o wird gefuettert wenn er
- aufwacht  (sollte regelmaessign passieren)
- anlernt ( musst du manuell machen, wie auch immer anlernen geschaltet
wird.

Kannst du mit einmal ein paar messages schicken, die regelmaessign kommen?
Mal sehen, ob da etwas nicht stimmt
also mit
attr global verbose 1
attr loglevel 1

>
>  
>
>> - register-readings vorhanden
>>
>
> ist auch vorhanden mit folgenden Werten:
>
> battery ok 2012-11-16 19:18:46
> brightness 40 2012-11-18 20:20:25
> cover closed 2012-11-16 19:18:46
> motion on (to BZ_ActionDetector) 2012-11-18 20:20:25
> motionCount 86_next:8 2012-11-18 20:20:25
> state motion 2012-11-18 20:20:25
>
> Dazu noch eine Nebenfrage: Ich hab den Bewegungsmelder mit Autodetect
> angelernt und er hat auch automatisch ein Gerät ActionDetector generiert.
> Wofür ist dieser?
>
 
Der ueberwacht, ob sich dein mdir auch regelmaessig meldet.  devices haben
oft einen event 'battery low' - aber keinen 'battery empty' .
Du erhaeltst nach starten vn fhem einen event 'alive' wenn sich das device
meldet - oder ein 'dead' wenn es sich nicht meldet nach seiner maxzeit.
Fuer den MDIR-O sollte es aber nicht automatisch kommen, wusste ich noch
nicht. habe es jetzt eingebaut. Default ist also nach 10min keine message
wird es einen event geben.
Den Zustand kannst du im device UND im activityDetector sehen

Gruss
Martin

>
>
>
>  
>
>> - prot-state auf done
>>
>
> protState hab ich gar nicht
>
>
>  
>
>> 2) danach koennen Daten geschrieben werden.  
>>
>
>
> Also lese ich die Daten, warte auf den nächsten Cycle und schreibe dann
> die Daten neu?
>
>
>  Gruß
>
> Kai
>
> PS: Gibts irgendwo ne TechDoku welche Werte der HM-SEC-MDIR liefert? Mich
> interessiert was actStatus und actCycle bedeutet
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

>
> Kannst du mit einmal ein paar messages schicken, die regelmaessign kommen?
> Mal sehen, ob da etwas nicht stimmt
> also mit
> attr global verbose 1
> attr loglevel 1
>

Mach ich . allerdings schein global verbose 1 der kleinste Loglevel zu
sein. War das von Dir beabsichtigt?
attr COC loglevel 1 hab ich auch gesetzt (hab ein COC im HM-Modus)

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Am Montag, 19. November 2012 16:45:59 UTC+1 schrieb Kai:
>
>
>
>> Kannst du mit einmal ein paar messages schicken, die regelmaessign
>> kommen? Mal sehen, ob da etwas nicht stimmt
>> also mit
>> attr global verbose 1
>> attr loglevel 1
>>
>
> Mach ich . allerdings schein global verbose 1 der kleinste Loglevel zu
> sein. War das von Dir beabsichtigt?
> attr COC loglevel 1 hab ich auch gesetzt (hab ein COC im HM-Modus)
>
ja. Dann ist der ganze andere m... weg und ich erhalte alles aus dem
IO-device. Der Trace wird sehr klein und ich mus nicht so lange suchen

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com