Bewegungsmelder HM-SEC-MDIR

[edank]

Hallo an alle,

habe mir besagten Bewegungsmelder gestern gekauft.

Es funktioniert alles so wie es sein soll (bzw. wie ich es mir vorgestellt habe).

Eines verstehe ich aber nicht er schickt alle 4 Minuten seinen Status(motion oder alive), Helligkeit, Batterie und Cover.

Der Wert Cover ist bei mir aber immer "open", ob ich jetzt die Wand und Deckenhalterung anbringe oder nicht (diese Halterung betätigt einen kleinen Schalter).

Ist dies ein normales Verhalten?

Oder verstehe ich etwas falsch?

LG

edank

[Martin]

ist ein bug - wird behoben

Ist eigentlich der event alle 4 min erwünscht - mit cover closed - oder nur einer mit cover open oder Batterie low?

Gruss
Martin

[edank]

ok super danke!

Wenn ich mir das aussuchen darf (freu) dann wäre es erwünscht.

Vielen Dank!

LG

edank

[Martin]

Eine Testversion is in
https://groups.google.com/group/fhem-users/attach/8d24ef0e8eddb0/10_CUL_HM.pm?part=4&authuser=0&view=1
zu finden.
Freigeben kann ich sie erst wenn ein CUL Problem geloest ist.

ok super danke!

Wenn ich mir das aussuchen darf (freu) dann wäre es erwünscht.

noch unklar: alle 4 min eine Wiederhohlung des Events (cover closed) oder nur wenn sich der Zustand aendert?
Normal sollten nur Aenderungen gemeldet werden - der gleiche Zustand nochmal ist ja kein Event.
Der aktuelle Zustand sollte sowieso lesbar sein.

Die Frage habe ich noch anderen gestellt - mal auf die Reaktionen warten

Gruss
Martin

[edank]

Super, danke werde ich gleich ausprobieren.

Na wenns gesendet wird warum soll man dann es nicht loggen?

Bei den FHT Fensterkontakten ist das ja auch so. Jede Meldung muss ja nicht mit einem  Event enden.

LG

edank

Am Montag, 15. Oktober 2012 19:01:02 UTC+2 schrieb edank:

Super, danke werde ich gleich ausprobieren.

Na wenns gesendet wird warum soll man dann es nicht loggen?

Bei den FHT Fensterkontakten ist das ja auch so. Jede Meldung muss ja nicht mit einem  

[edank]

Hallo,

habe es jetzt ausprobiert jetzt funktioniert der Status-Wechsel.

Nur ist der Status verdreht.

Ohne Halterung = closed

mit Halterung    = open

LG

edank

Am Montag, 15. Oktober 2012 09:16:38 UTC+2 schrieb Martin:

[Martin]

werde ich richten.
 Gruß
Martin

[Martin]

Sollte drin sein

[edank]

Super funktioniert!

Danke!

LG

edank

Am Mittwoch, 17. Oktober 2012 07:55:22 UTC+2 schrieb Martin:

Sollte drin sein

[Rüdiger Bente]

Hallo,

bei mir will das Ding einfach nicht,

bleibt immer auf dem stateￜￜ motionￜￜ hￜngen und ￜndert den nicht mehr.

Gibt es irgendeinen Trick bei der Config oder was muss ich da beachten.Meine Config ist:
define TH_Bewegungsmelder CUL_HM 189E00
attr TH_Bewegungsmelder devInfo 810100
attr TH_Bewegungsmelder firmware 1.0
attr TH_Bewegungsmelder hmClass sender
attr TH_Bewegungsmelder model HM-SEC-MDIR
attr TH_Bewegungsmelder room Treppenhaus
attr TH_Bewegungsmelder serialNr IEQ0538645
attr TH_Bewegungsmelder subType motionDetector
attr TH_Bewegungsmelder actCycle 00:02

LG

RB

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

[edank]

Hallo Ruebezahl,

habe keine AHnung ob es Dir hilft, aber ich habe meinen zuerst mit Homematic-Konfigurator konfiguriert.

Das funktioniert glaube ich aber nur dann wenn du den HM Lan Adapter verwendest.

LG

edank

[Martin]

Hallo,

Ich denke das ist so.

Der detektor meldet "motion" - und nicht "no-motion". Da ich keinen Habe, kann ich es nicht sehen.
Evtl kannst du mal traces schicken? Evtl fehlt da etwas

Du kannst am datum den Zeitpunkt der letzten Meldung sehen. Insofern ist die Aussage "Motion um 12:00" zu lesen

Gruss
Martin

[Rüdiger Bente]

Hallo,

"dat war et" wï¿œrde der Kï¿œlner jetzt sagen.
Ich hatte zwar den MDIR schon einmal konfiguriert, aber warum auch immer muss der seine Konfiguration wieder verloren haben.
Jetzt lï¿œuft er wie er es soll.

Danke.

LG

RB

[Rüdiger Bente]

Hallo,

dieses Problem ist vermutlich etwas vielschichtiger.

Der state-Wert hï¿œlt immer den letzten gemeldeten Status fest, das heiï¿œt,
wenn "motion" entdeckt wurde, dann bleibt auch dieser state so lange
erhalten, bis der MDIR etwas anderes meldet, dann steht da alive.
Unabhï¿œngig davon wird das "motion" Event immer richtig gemeldet und kann
ï¿œber notify abgefangen werden. Andere Events wie Brightness oder
Batterie setzen dann "alive".
Von der reinen Ansicht her verwirrt natï¿œrlich der Status "motion", denn
er kann durchaus ï¿œber 4 Minuten lang sein, obwohl in diesem Zeitraum
nichts mehr erfasst wurde.
Eine Lï¿œsung aus diesem Dilemma ist in meinen Augen nicht ganz trivial
und hï¿œngt sehr stark von der Konfiguration des MDIR ab.
Eine zu diskutierende Idee wï¿œre es vielleicht Attribute mit
Konfigurationswerte zu belegen und dann entsprechend den Status zu setzen???

Ich denke, ich werde mal meine Erfahrungen mit dem MDIR ins Wiki
einpflegen, damit andere nicht auch noch diese Probleme wie ich haben.

LG

RB

[Martin]

Hallo,

Es haengt von den 'motion usern' ab - aber mir wuerde der Status nicht passen, aus etwas anderen Gruenden.
1) der status zeigt den Hauptzustand an, der ist 'motion'.
 => active sollte nicht auf state abgebildet werden und in einem eigenen reading abgelegt werden.
2) wie bei allen Knoepfen und Tastern sollte in state die letzte Aktion stehen. Bei tastern koennte es pressLong oder pressShort. bei motion nur motion. Das wichtige ist hier der Zeitstempel. Der ist bei allen readings zu beachten, die koennten auch uralt sein.

3) wenn man sich eine intelligente Darstellung im Interface wuenscht sollte man evtl alle Variablen je nach Uhrzeit highlighten. Also alles was neuer ist als 5min hervorheben. alles was aelter ist wie ein Tag kursiv. Irgendwie so.

=> ich geben dir recht, die Darstellung am Frontend kann noch verbessert werden - jedenfalls die welche ich benutze.

Den State alive werde ich ueberdenken und voraussichtlich aus state entfernen - der ist hier falsch.
Mal auf die Reaktionen warten
Gruss
Martin

[Ruebezahl]

Hallo,

deine Argumente bezüglich des Status haben was für sich, anderseits ist bei dem Bewegungsmelder vermutlich nie eine konsistente Vorgehensweise in Sachen des Status möglich, denn "Motion" dauert ja möglicherweise nur wenige Augenblicke, dann ist der Sensor intern ja wieder im Zustand Scanning. Nur leider wird uns dieser Zustand nicht mitgeteilt und die Variationsbreite der Konfiguration macht es schwierig, diesen Status in FHEM simuliert abzubilden. Ich stimme dir zu, nehmen wir das kleinste Übel hier. In Zusammenhang mit den Readings lässt sich ja ein vernünftiger Betrieb erzielen.

LG

RB

[Martin]

Hallo,

ich gehe davon aus, dass der Sensor den Trigger wiederholt solange sich etwas tut - kannst du dies bestaetigen?
Der korrekte State waere 'last_motion' +Datum/Uhrzeit. Diese Semantik wuerde evtl die Fragen wie du sie dir gestellt hast klaeren. Umstellen wuerde ich so etwas nicht gerne, da sich sicher viele schon auf 'motion' eingestellt und einprogrammiert haben.
Wuerde 'silent' angezeigt waere das kontraproduktiv - der User wuerde anstatt immer 'motion' eben immer 'quiet' sehen - oder besser 'quiet_since'. Bringt also keinen Vorteil und muss unschoen ueber timer eingebaut werden.

Der Verlauf koennte ueber events und logeintraege nachvollzogen werden, wenn es jemand interessiert.

[Ruebezahl]

Hallo,

kommt stark auf die Konfiguration des MDIR an, wann was gemeldet wird.


Wenn bei der o.g. Konfig eine Ereignis bei Sekunde 1 auftritt und ein weiteres bei Sekunde 15, so wird Ereignis 1 sofort an FHEM gemeldet und Ereignis 2 erst nach 60 Sekunden. Der Haken bei "Innerhalb...." ist dafür verantwortlich. Aber das sehe ich als kein Problem an und kann eh durch die Konfiguration beeinflusst werden.

Haben wir eine Chance diese Konfiguration auch per FHEM durchzuführen?

LG

RB

[Martin]

klar koennen wir.

Mal sehen - im Angebot sind:
EVENT_FILTER_PERIOD      min="0.5"     max="7.5" unit="s" default="0.5"
EVENT_FILTER_NUMBER    min="1"       max="15" default="3"
CAPTURE_WITHIN_INTERVAL type="boolean" default="false"
MIN_INTERVAL                    min="0"        max="4" default="4"
BRIGHTNESS_FILTER         min="0"        max="7" default="7"
LED_ONTIME                      min="0.0"     max="1.275" unit="s" default="0.5"

Ist es dass was du suchst?
Da ein paar der Variablen bitfelder sind und nicht einfach geschrieben werden koennen musst du erst die Variablen auslesen (get Config) und dann mit set regSet setzen.
Die Register trage ich nach, kein Problem
Gruss
Martin

[Rüdiger Bente]

Super, genau das trifft den Punkt, weil es lï¿œstig ist, erst immer wieder diese Homematicsoftware zu benutzen, um die Felder zu setzen.

MIN_INTERVAL muss dann ja float sein, weil es gehen, glaube ich, Werte von 15 sec. bis 4 Minuten.

LG

RB

Am 23.10.2012 12:29, schrieb Martin:

klar koennen wir.

Mal sehen - im Angebot sind:

EVENT_FILTER_PERIODￜ ￜￜￜ min="0.5" ￜￜￜ max="7.5" unit="s" default="0.5"
EVENT_FILTER_NUMBER ￜￜ min="1" ￜￜ ￜￜ max="15" default="3"

CAPTURE_WITHIN_INTERVAL type="boolean" default="false"

MIN_INTERVAL ￜￜￜ ￜￜￜ ￜￜ ￜ ￜ ￜ ￜ min="0" ￜￜ ￜ ￜ max="4" default="4"
BRIGHTNESS_FILTER ￜￜￜ ￜￜￜ min="0" ￜￜￜￜￜￜ max="7" default="7"
LED_ONTIMEￜ ￜￜￜ ￜￜￜ ￜￜ ￜ ￜ ￜ ￜￜ min="0.0" ￜￜￜ max="1.275" unit="s" default="0.5"

Ist es dass was du suchst?
Da ein paar der Variablen bitfelder sind und nicht einfach geschrieben werden koennen musst du erst die Variablen auslesen (get Config) und dann mit set regSet setzen.
Die Register trage ich nach, kein Problem
Gruss
Martin



Am Dienstag, 23. Oktober 2012 09:56:24 UTC+2 schrieb Ruebezahl:

Hallo,

kommt stark auf die Konfiguration des MDIR an, wann was gemeldet wird.

Wenn bei der o.g. Konfig eine Ereignis bei Sekunde 1 auftritt und ein weiteres bei Sekunde 15, so wird Ereignis 1 sofort an FHEM gemeldet und Ereignis 2 erst nach 60 Sekunden. Der Haken bei "Innerhalb...." ist dafï¿œr verantwortlich. Aber das sehe ich als kein Problem an und kann eh durch die Konfiguration beeinflusst werden.

Haben wir eine Chance diese Konfiguration auch per FHEM durchzufï¿œhren?

LG

RB


Am Dienstag, 23. Oktober 2012 09:15:24 UTC+2 schrieb Martin:

Hallo,

ich gehe davon aus, dass der Sensor den Trigger wiederholt solange sich etwas tut - kannst du dies bestaetigen?

[Martin]

MIN_INTERVAL muss dann ja float sein, weil es gehen, glaube ich, Werte von 15 sec. bis 4 Minuten.

nein - min interval ist ein interger von 0 bis 4
event filter period und led ontime sind float.

Alle Werte wie angegeben, sollte auch so in HM-CONFIG sein - die sollten das gleiche xml benutzen. 
Falls es nicht stimmt,  ncoh mal  melden, auch das XML kann einen Fehler haben.

Einbau von Registern kein Problem - da gibt es jetzt eine Vorlage.

Zu beachten
get reglist zeigt alle vorhandenen register  der entity
set getConfig ist die komfortabelste moeglichkeit alles zu lesen, was configuration im device ist. Auf device-ebene angewendet werden alle Kanaele auch gleich mit bedient
get reg all gibt eine interpretierte Liste aller Werte. Ausgegeben werden nur die Werte, die vorhanden UND dekodierbar sind. Nicht alle Register werden dekodiert
set regSet regname ? gibt beschreibung zu diesem register
set regSet regname wert [peerlchannel] schreibt in das register. Peerchannel ist notwendig, wenn es register in List3 sind.
Danach sollte man noch mal getConfig machen - die Werte im FHEM speicher werden refresht - und man kann pruefen was geschrieben wurde.

[Rüdiger Bente]

Ich habe mal nachgeschaut, was man bei der HM-LAN Software fï¿œr den MDIR konfigurieren kann:

Parameter	Werte
Empfindlichkeit	Auslￜsen beiￜ {jedem,2,3,4,5,6,7,8,9,10,11,12,13,14,15} Sensor-Impuls
Wahl des Sendeabstandes	{klassisch oder dynamisch) klassisch = Sendeabstand = 240 Sekunden (+- 10%) dynamisch = Der MDIR meldet die erste Bewegung sofort, weitere bewegungen nach der Zeit beim Mindestsendeabstand
Mindestsendeabstand	{15,20,60,120} Sekundenￜ (das werden die 1-4 sein!!!ￜ Mein Fehler)
Innerhalb des Sendeabstandes erkannte Bewegung senden	{ja, nein}
Helligkeitsfilter	{1,2,3,4,5,6,7,8}
LED-Leuchtzeit (gn/rt)	{0 - 1.27s}

Am 23.10.2012 14:25, schrieb Martin:

MIN_INTERVAL muss dann ja float sein, weil es gehen, glaube ich, Werte von 15 sec. bis 4 Minuten.

nein - min interval ist ein interger von 0 bis 4
event filter period und led ontime sind float.

Alle Werte wie angegeben, sollte auch so in HM-CONFIG sein - die sollten das gleiche xml benutzen.ￜ
Falls es nicht stimmt,ￜ ncoh malￜ melden, auch das XML kann einen Fehler haben.

Einbau von Registern kein Problem - da gibt es jetzt eine Vorlage.

Zu beachten

get reglist zeigt alle vorhandenen registerￜ der entity

[Martin]

Wahl des Sendeabstandes kann ich nicht einordnen.
Probier doch mal den Anhang aus

[Rüdiger Bente]

Too many arguments for main::CUL_HM_Name2Id at /usr/share/fhem/FHEM/10_CUL_HM.pm line 1588, near "$hash)"
BEGIN not safe after errors--compilation aborted at /usr/share/fhem/FHEM/10_CUL_HM.pm line 2231.

war die Antwort nach dem reload

Am 23.10.2012 20:03, schrieb Martin:

Wahl des Sendeabstandes kann ich nicht einordnen.
Probier doch mal den Anhang aus

[Martin]

 war mir nicht aufgefallen. Ist in regRaw und getRegRaw. Die angefaengte Version sollte gehen.
Testen mus ich noch den shortcut 'self' als peerId. Der geht in deser Funktion jetzt nicht.
Der rest - insbesondere getConfig - sollte funktionieren

Gruss,
Martin

[Rüdiger Bente]

Hallo Martin,

ich habe das mal ausprobiert, ich wï¿œrde sagen, so weit ich feststellen kann, hat sich die Konfiguration im MDIR nicht verï¿œndert.
Ich sehe bei den Attributen protCmdPend und dort steht das CMD's pending sind.

Nach einem Neustart von FHEM habe ich dieses Log produziert:

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2012.10.25 06:14:01 =~=~=~=~=~=~=~=~=~=~=~=
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.

SecurityCheck:

XX_WEB,XX_WEBphone,XX_WEBtablet has no basicAuth attribute.
tPort has no password/globalpassword attribute.

Restart fhem for a new check if the problem is fixed,
or set the global attribute motd to none to supress this message.

fhem> list TH_Bewegungsmelder
Internals:
ￜￜ CFGFNￜￜￜￜￜ /etc/fhem/Treppenhaus.cfg
ￜￜ DEFￜￜￜￜￜￜￜ 189E00
ￜￜ IODevￜￜￜￜￜ XX_LANInterface
ￜￜ NAMEￜￜￜￜￜￜ TH_Bewegungsmelder
ￜￜ NRￜￜￜￜￜￜￜￜ 735
ￜￜ STATEￜￜￜￜￜ motion
ￜￜ TYPEￜￜￜￜￜￜ CUL_HM
ￜￜ Readings:
ￜￜￜￜ 2012-10-21 10:44:20ￜￜ batteryￜￜￜￜￜￜￜￜ ok
ￜￜￜￜ 2012-10-25 06:11:19ￜￜ brightnessￜￜￜￜￜ 33
ￜￜￜￜ 2012-10-21 10:44:20ￜￜ coverￜￜￜￜￜￜￜￜￜￜ closed
ￜￜￜￜ 2012-10-24 22:24:02ￜￜ motionￜￜￜￜￜￜￜￜￜ on (to broadcast)
ￜￜￜￜ 2012-10-24 11:31:15ￜￜ noReceiverￜￜￜￜￜ src:189E00 (A641) 012738
ￜￜￜￜ 2012-10-24 22:24:02ￜￜ stateￜￜￜￜￜￜￜￜￜￜ motion
Attributes:
ￜￜ devInfoￜￜￜ 810100
ￜￜ firmwareￜￜ 1.0
ￜￜ hmClassￜￜￜ sender
ￜￜ modelￜￜￜￜￜ HM-SEC-MDIR
ￜￜ roomￜￜￜￜￜￜ Treppenhaus
ￜￜ serialNrￜￜ ..........
ￜￜ subTypeￜￜￜ motionDetector

fhem> set TH_Bewegungsmelder getConfig
fhem> list TH_Bewegungsmelder
Internals:
ￜￜ CFGFNￜￜￜￜￜ /etc/fhem/Treppenhaus.cfg
ￜￜ DEFￜￜￜￜￜￜￜ 189E00
ￜￜ IODevￜￜￜￜￜ XX_LANInterface
ￜￜ NAMEￜￜￜￜￜￜ TH_Bewegungsmelder
ￜￜ NRￜￜￜￜￜￜￜￜ 735
ￜￜ STATEￜￜￜￜￜ motion
ￜￜ TYPEￜￜￜￜￜￜ CUL_HM
ￜￜ Readings:
ￜￜￜￜ 2012-10-21 10:44:20ￜￜ batteryￜￜￜￜￜￜￜￜ ok
ￜￜￜￜ 2012-10-25 06:11:19ￜￜ brightnessￜￜￜￜￜ 33
ￜￜￜￜ 2012-10-21 10:44:20ￜￜ coverￜￜￜￜￜￜￜￜￜￜ closed
ￜￜￜￜ 2012-10-24 22:24:02ￜￜ motionￜￜￜￜￜￜￜￜￜ on (to broadcast)
ￜￜￜￜ 2012-10-24 11:31:15ￜￜ noReceiverￜￜￜￜￜ src:189E00 (A641) 012738
ￜￜￜￜ 2012-10-24 22:24:02ￜￜ stateￜￜￜￜￜￜￜￜￜￜ motion
ￜￜ cmdStack:
ￜￜￜￜ ++A0016DC1EA189E0000040000000000
ￜￜￜￜ ++A0016DC1EA189E0001040000000001
ￜￜￜￜ ++A0016DC1EA189E000103
ￜￜ Helper:
ￜￜￜￜ getCfgList all
ￜￜￜￜ getCfgListNo 4
ￜￜￜￜ mIdￜￜￜￜￜￜￜ 004A
ￜￜￜￜ rxTypeￜￜￜￜ 12
Attributes:
ￜￜ devInfoￜￜￜ 810100
ￜￜ firmwareￜￜ 1.0
ￜￜ hmClassￜￜￜ sender
ￜￜ modelￜￜￜￜￜ HM-SEC-MDIR
ￜￜ protCmdPend 3 CMDs pending
ￜￜ roomￜￜￜￜￜￜ Treppenhaus
ￜￜ serialNrￜￜ ..........
ￜￜ subTypeￜￜￜ motionDetector

fhem> get TH_Bewegungsmelder reg all
TH_Bewegungsmelder type:motionDetector -

fhem> get TH_Bewegungsmelder reglist
Unknown argument reglist, choose one of param reg regList
fhem> get TH_Bewegungsmelder regList
motionDetector -
intKeyVisibrange:0 to 1bool: visibility of internal keys
pairCentralrange:0 to 16777215dec: pairing to central
brightFilterrange:0 to 7: brightness filter
captInIntervalrange:0 to 1bool: capture within interval
evtFltrPeriodrange:0.5 to 7.5s: event filter period
minIntervalrange:0 to 4: minimum interval 0,15,20,60,120s
evtFltrNumrange:1 to 15: sensitivity - read sach n-th puls
ledOnTimerange:0 to 1.275s: LED ontime

fhem> list TH_Bewegungsmelder
Internals:
ￜￜ CFGFNￜￜￜￜￜ /etc/fhem/Treppenhaus.cfg
ￜￜ DEFￜￜￜￜￜￜￜ 189E00
ￜￜ IODevￜￜￜￜￜ XX_LANInterface
ￜￜ LASTIODevￜ XX_LANInterface
ￜￜ MSGCNTￜￜￜￜ 1
ￜￜ NAMEￜￜￜￜￜￜ TH_Bewegungsmelder
ￜￜ NRￜￜￜￜￜￜￜￜ 735
ￜￜ STATEￜￜￜￜￜ motion
ￜￜ TYPEￜￜￜￜￜￜ CUL_HM
ￜￜ XX_LANInterface_MSGCNT 1
ￜￜ XX_LANInterface_RAWMSG E189E00,0000,21D98D9B,FF,FFC0,8EA610189E00BB89A006012100
ￜￜ XX_LANInterface_RSSI -64
ￜￜ XX_LANInterface_TIME 2012-10-25 06:16:23
ￜￜ lastMsgￜￜￜ No:8E - t:10 s:189E00 d:BB89A0 06012100
ￜￜ Readings:
ￜￜￜￜ 2012-10-25 06:16:23ￜￜ batteryￜￜￜￜￜￜￜￜ ok
ￜￜￜￜ 2012-10-25 06:16:23ￜￜ brightnessￜￜￜￜￜ 33
ￜￜￜￜ 2012-10-25 06:16:23ￜￜ coverￜￜￜￜￜￜￜￜￜￜ closed
ￜￜￜￜ 2012-10-24 22:24:02ￜￜ motionￜￜￜￜￜￜￜￜￜ on (to broadcast)
ￜￜￜￜ 2012-10-24 11:31:15ￜￜ noReceiverￜￜￜￜￜ src:189E00 (A641) 012738
ￜￜￜￜ 2012-10-24 22:24:02ￜￜ stateￜￜￜￜￜￜￜￜￜￜ motion
ￜￜ cmdStack:
ￜￜￜￜ ++A0016DC1EA189E0000040000000000
ￜￜￜￜ ++A0016DC1EA189E0001040000000001
ￜￜￜￜ ++A0016DC1EA189E000103
ￜￜ Helper:
ￜￜￜￜ addValￜￜￜￜ 0
ￜￜￜￜ getCfgList all
ￜￜￜￜ getCfgListNo 4
ￜￜￜￜ mIdￜￜￜￜￜￜￜ 004A
ￜￜￜￜ rxTypeￜￜￜￜ 12
ￜￜￜￜ Respwait:
Attributes:
ￜￜ devInfoￜￜￜ 810100
ￜￜ firmwareￜￜ 1.0
ￜￜ hmClassￜￜￜ sender
ￜￜ modelￜￜￜￜￜ HM-SEC-MDIR
ￜￜ protCmdPend 3 CMDs pending
ￜￜ protLastRcv 2012-10-25 06:16:24
ￜￜ roomￜￜￜￜￜￜ Treppenhaus
ￜￜ serialNrￜￜ ..........
ￜￜ subTypeￜￜￜ motionDetector

fhem> set TH_Bewegungsmelder regSet minInterval minInterval 1
fhem> list TH_Bewegungsmelder
Internals:
ￜￜ CFGFNￜￜￜￜￜ /etc/fhem/Treppenhaus.cfg
ￜￜ DEFￜￜￜￜￜￜￜ 189E00
ￜￜ IODevￜￜￜￜￜ XX_LANInterface
ￜￜ LASTIODevￜ XX_LANInterface
ￜￜ MSGCNTￜￜￜￜ 1
ￜￜ NAMEￜￜￜￜￜￜ TH_Bewegungsmelder
ￜￜ NRￜￜￜￜￜￜￜￜ 735
ￜￜ STATEￜￜￜￜￜ motion
ￜￜ TYPEￜￜￜￜￜￜ CUL_HM
ￜￜ XX_LANInterface_MSGCNT 1
ￜￜ XX_LANInterface_RAWMSG E189E00,0000,21D98D9B,FF,FFC0,8EA610189E00BB89A006012100
ￜￜ XX_LANInterface_RSSI -64
ￜￜ XX_LANInterface_TIME 2012-10-25 06:16:23
ￜￜ lastMsgￜￜￜ No:8E - t:10 s:189E00 d:BB89A0 06012100
ￜￜ Readings:
ￜￜￜￜ 2012-10-25 06:16:23ￜￜ batteryￜￜￜￜￜￜￜￜ ok
ￜￜￜￜ 2012-10-25 06:16:23ￜￜ brightnessￜￜￜￜￜ 33
ￜￜￜￜ 2012-10-25 06:16:23ￜￜ coverￜￜￜￜￜￜￜￜￜￜ closed
ￜￜￜￜ 2012-10-24 22:24:02ￜￜ motionￜￜￜￜￜￜￜￜￜ on (to broadcast)
ￜￜￜￜ 2012-10-24 11:31:15ￜￜ noReceiverￜￜￜￜￜ src:189E00 (A641) 012738
ￜￜￜￜ 2012-10-24 22:24:02ￜￜ stateￜￜￜￜￜￜￜￜￜￜ motion
ￜￜ cmdStack:
ￜￜￜￜ ++A0016DC1EA189E0000040000000000
ￜￜￜￜ ++A0016DC1EA189E0001040000000001
ￜￜￜￜ ++A0016DC1EA189E000103
ￜￜￜￜ ++A0016DC1EA189E0001050000000001
ￜￜￜￜ ++A0016DC1EA189E0001080200
ￜￜￜￜ ++A0016DC1EA189E000106
ￜￜ Helper:
ￜￜￜￜ addValￜￜￜￜ 0
ￜￜￜￜ getCfgList all
ￜￜￜￜ getCfgListNo 4
ￜￜￜￜ mIdￜￜￜￜￜￜￜ 004A
ￜￜￜￜ rxTypeￜￜￜￜ 12
ￜￜￜￜ Respwait:
ￜￜￜￜ Shadowreg:
ￜￜￜￜￜￜ RegL_01:ￜￜￜ 02:00
Attributes:
ￜￜ devInfoￜￜￜ 810100
ￜￜ firmwareￜￜ 1.0
ￜￜ hmClassￜￜￜ sender
ￜￜ modelￜￜￜￜￜ HM-SEC-MDIR
ￜￜ protCmdPend 6 CMDs pending
ￜￜ protLastRcv 2012-10-25 06:16:24
ￜￜ roomￜￜￜￜￜￜ Treppenhaus
ￜￜ serialNrￜￜ ..........
ￜￜ subTypeￜￜￜ motionDetector

fhem> set TH_Bewegungsmelder getConfig
fhem> list TH_Bewegungsmelder
Internals:
ￜￜ CFGFNￜￜￜￜￜ /etc/fhem/Treppenhaus.cfg
ￜￜ DEFￜￜￜￜￜￜￜ 189E00
ￜￜ IODevￜￜￜￜￜ XX_LANInterface
ￜￜ LASTIODevￜ XX_LANInterface
ￜￜ MSGCNTￜￜￜￜ 1
ￜￜ NAMEￜￜￜￜￜￜ TH_Bewegungsmelder
ￜￜ NRￜￜￜￜￜￜￜￜ 735
ￜￜ STATEￜￜￜￜￜ motion
ￜￜ TYPEￜￜￜￜￜￜ CUL_HM
ￜￜ XX_LANInterface_MSGCNT 1
ￜￜ XX_LANInterface_RAWMSG E189E00,0000,21D98D9B,FF,FFC0,8EA610189E00BB89A006012100
ￜￜ XX_LANInterface_RSSI -64
ￜￜ XX_LANInterface_TIME 2012-10-25 06:16:23
ￜￜ lastMsgￜￜￜ No:8E - t:10 s:189E00 d:BB89A0 06012100
ￜￜ Readings:
ￜￜￜￜ 2012-10-25 06:16:23ￜￜ batteryￜￜￜￜￜￜￜￜ ok
ￜￜￜￜ 2012-10-25 06:16:23ￜￜ brightnessￜￜￜￜￜ 33
ￜￜￜￜ 2012-10-25 06:16:23ￜￜ coverￜￜￜￜￜￜￜￜￜￜ closed
ￜￜￜￜ 2012-10-24 22:24:02ￜￜ motionￜￜￜￜￜￜￜￜￜ on (to broadcast)
ￜￜￜￜ 2012-10-24 11:31:15ￜￜ noReceiverￜￜￜￜￜ src:189E00 (A641) 012738
ￜￜￜￜ 2012-10-24 22:24:02ￜￜ stateￜￜￜￜￜￜￜￜￜￜ motion
ￜￜ cmdStack:
ￜￜￜￜ ++A0016DC1EA189E0000040000000000
ￜￜￜￜ ++A0016DC1EA189E0001040000000001
ￜￜￜￜ ++A0016DC1EA189E000103
ￜￜￜￜ ++A0016DC1EA189E0001050000000001
ￜￜￜￜ ++A0016DC1EA189E0001080200
ￜￜￜￜ ++A0016DC1EA189E000106
ￜￜￜￜ ++A0016DC1EA189E0000040000000000
ￜￜￜￜ ++A0016DC1EA189E0001040000000001
ￜￜￜￜ ++A0016DC1EA189E000103
ￜￜ Helper:
ￜￜￜￜ addValￜￜￜￜ 0
ￜￜￜￜ getCfgList all
ￜￜￜￜ getCfgListNo 4
ￜￜￜￜ mIdￜￜￜￜￜￜￜ 004A
ￜￜￜￜ rxTypeￜￜￜￜ 12
ￜￜￜￜ Respwait:
ￜￜￜￜ Shadowreg:
ￜￜￜￜￜￜ RegL_01:ￜￜￜ 02:00
Attributes:
ￜￜ devInfoￜￜￜ 810100
ￜￜ firmwareￜￜ 1.0
ￜￜ hmClassￜￜￜ sender
ￜￜ modelￜￜￜￜￜ HM-SEC-MDIR
ￜￜ protCmdPend 9 CMDs pending
ￜￜ protLastRcv 2012-10-25 06:16:24
ￜￜ roomￜￜￜￜￜￜ Treppenhaus
ￜￜ serialNrￜￜ ..........
ￜￜ subTypeￜￜￜ motionDetector

fhem> quit
Bye...
Connection closed by foreign host.



LG

RB

Am 24.10.2012 09:43, schrieb Martin:

ï¿œwar mir nicht aufgefallen. Ist in regRaw und getRegRaw. Die angefaengte Version sollte gehen.

[Martin]

Hi RB,

leider kann ich deinen log nicht lesen - kannst du es in einfachen standard ascii schicken?

ￜￜ DEFￜￜￜￜￜￜￜ 189E00

Danke
Martin

[Martin]

btw - warum den registername 2 mal?

fhem> set TH_Bewegungsmelder regSet minInterval minInterval 1

hier wird 'minInterval' nach minInterval  geschrieben, die 1 ist uebrig - wuerde im bedarf als peerID interpretiert

schoen ist doch auch
fhem> set TH_Bewegungsmelder regSet minInterval 1

Gruss
Martin

[Rüdiger Bente]

gute Frage...... vermutlich ein freudscher Tatterich in den grauen
Zellen ;-)

habe das jetzt noch einmal mit frisch gestartetem FHEM gemacht und ohne
den Tatterich,
das Ergebnis ï¿œndert sich aber nicht

LG

RB

[Rüdiger Bente]

Ich hoffe mit dem Anhang geht es besser????

ￜￜￜￜ 2012-10-21 10:44:20ￜￜ batteryￜￜￜￜￜￜￜￜￜ ok

ￜￜￜￜ 2012-10-25 06:11:19ￜￜ brightnessￜￜￜￜￜ 33

ￜￜￜￜ 2012-10-21 10:44:20ￜￜ coverￜￜￜￜￜￜￜￜￜￜￜ closed
ￜￜￜￜ 2012-10-24 22:24:02ￜￜ motionￜￜￜￜￜￜￜￜￜￜ on (to broadcast)

ￜￜￜￜ 2012-10-24 11:31:15ￜￜ noReceiverￜￜￜￜￜ src:189E00 (A641) 012738

ￜￜￜￜ 2012-10-24 22:24:02ￜￜ stateￜￜￜￜￜￜￜￜￜￜￜ motion

Attributes:
ￜￜ devInfoￜￜￜ 810100
ￜￜ firmwareￜￜ 1.0
ￜￜ hmClassￜￜￜ sender
ￜￜ modelￜￜￜￜￜ HM-SEC-MDIR
ￜￜ roomￜￜￜￜￜￜ Treppenhaus
ￜￜ serialNrￜￜ ..........
ￜￜ subTypeￜￜￜ motionDetector

fhem> set TH_Bewegungsmelder getConfig
fhem> list TH_Bewegungsmelder
Internals:
ￜￜ CFGFNￜￜￜￜￜ /etc/fhem/Treppenhaus.cfg
ￜￜ DEFￜￜￜￜￜￜￜ 189E00
ￜￜ IODevￜￜￜￜￜ XX_LANInterface
ￜￜ NAMEￜￜￜￜￜￜ TH_Bewegungsmelder
ￜￜ NRￜￜￜￜￜￜￜￜ 735
ￜￜ STATEￜￜￜￜￜ motion
ￜￜ TYPEￜￜￜￜￜￜ CUL_HM
ￜￜ Readings:

ￜￜￜￜ 2012-10-21 10:44:20ￜￜ batteryￜￜￜￜￜￜￜￜￜ ok

ￜￜￜￜ 2012-10-25 06:11:19ￜￜ brightnessￜￜￜￜￜ 33

ￜￜￜￜ 2012-10-21 10:44:20ￜￜ coverￜￜￜￜￜￜￜￜￜￜￜ closed
ￜￜￜￜ 2012-10-24 22:24:02ￜￜ motionￜￜￜￜￜￜￜￜￜￜ on (to broadcast)

ￜￜￜￜ 2012-10-24 11:31:15ￜￜ noReceiverￜￜￜￜￜ src:189E00 (A641) 012738

ￜￜￜￜ 2012-10-24 22:24:02ￜￜ stateￜￜￜￜￜￜￜￜￜￜￜ motion

ￜￜￜￜ 2012-10-25 06:16:23ￜￜ batteryￜￜￜￜￜￜￜￜￜ ok

ￜￜￜￜ 2012-10-25 06:16:23ￜￜ brightnessￜￜￜￜￜ 33

ￜￜￜￜ 2012-10-25 06:16:23ￜￜ coverￜￜￜￜￜￜￜￜￜￜￜ closed
ￜￜￜￜ 2012-10-24 22:24:02ￜￜ motionￜￜￜￜￜￜￜￜￜￜ on (to broadcast)

ￜￜￜￜ 2012-10-24 11:31:15ￜￜ noReceiverￜￜￜￜￜ src:189E00 (A641) 012738

ￜￜￜￜ 2012-10-24 22:24:02ￜￜ stateￜￜￜￜￜￜￜￜￜￜￜ motion

ￜￜￜￜ 2012-10-25 06:16:23ￜￜ batteryￜￜￜￜￜￜￜￜￜ ok

ￜￜￜￜ 2012-10-25 06:16:23ￜￜ brightnessￜￜￜￜￜ 33

ￜￜￜￜ 2012-10-25 06:16:23ￜￜ coverￜￜￜￜￜￜￜￜￜￜￜ closed
ￜￜￜￜ 2012-10-24 22:24:02ￜￜ motionￜￜￜￜￜￜￜￜￜￜ on (to broadcast)

ￜￜￜￜ 2012-10-24 11:31:15ￜￜ noReceiverￜￜￜￜￜ src:189E00 (A641) 012738

ￜￜￜￜ 2012-10-24 22:24:02ￜￜ stateￜￜￜￜￜￜￜￜￜￜￜ motion

ￜￜￜￜ 2012-10-25 06:16:23ￜￜ batteryￜￜￜￜￜￜￜￜￜ ok

ￜￜￜￜ 2012-10-25 06:16:23ￜￜ brightnessￜￜￜￜￜ 33

ￜￜￜￜ 2012-10-25 06:16:23ￜￜ coverￜￜￜￜￜￜￜￜￜￜￜ closed
ￜￜￜￜ 2012-10-24 22:24:02ￜￜ motionￜￜￜￜￜￜￜￜￜￜ on (to broadcast)

ￜￜￜￜ 2012-10-24 11:31:15ￜￜ noReceiverￜￜￜￜￜ src:189E00 (A641) 012738

ￜￜￜￜ 2012-10-24 22:24:02ￜￜ stateￜￜￜￜￜￜￜￜￜￜￜ motion

[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

[Rüdiger Bente]

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

[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

[Rüdiger Bente]

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

[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

[Rüdiger Bente]

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

[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

[Rüdiger Bente]

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

Schreibtisch ï¿œund dann komme ich besser an den Anlernknopf

LG

--

[Martin]

uff - habe schon an mir gezweifelt.
ja, solle bei HMLAN stimmen.

[Kai]

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

[Martin]

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

[Kai]

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

[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

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

[Kai]

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

[Martin]

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 <hmlan> 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

[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 <hmlan> 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)

[Martin]

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

[Kai]

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

attr global verbose 1

attr COC loglevel 1 

hab ich jetzt gesetzt

Muss ich irgendwas triggern, damit er den BewMelder anspricht? Müsste ja alle 4 Minuten eine Connection COC -> Bewmelder sehen?

[Kai]

Also,

sowie ich sehe, schreibt er nur bei einer erkannten Bewegung ins Log

Hab jetzt mal eine Bewegung ausgelöst:

2012.11.19 22:29:37 1: COC: A0D578441161BF600000001572080 -32

2012.11.19 22:29:38 1: SW: As0E01A011F112341AC8A80201C80000

2012.11.19 22:29:38 1: COC: A0E0180021AC8A8F112340101C80033 -54

2012.11.19 22:29:38 1: SW: As0E02A011F112341AC8A80201C80000

2012.11.19 22:29:38 1: COC: A0E0280021AC8A8F112340101C80033 -54

2012.11.19 22:29:38 1: SW: As0E03A011F112341AC8A80201C80000

2012.11.19 22:29:38 1: COC: A0E0380021AC8A8F112340101C80033 -54

2012.11.19 22:29:38 1: SW: As0E04A011F112341AC8A80201C80000

2012.11.19 22:29:39 1: COC: A0E0480021AC8A8F112340101C80033 -53.5

2012.11.19 22:34:38 1: SW: As0E05A011F112341AC8A80201000000

2012.11.19 22:34:38 1: COC: A0E0580021AC8A8F112340101000031 -51.5

Sonst schreibt er nix ins Log, nur bei einer Bewegung

[Martin]

Klar, dass nichts gesendet wird, der Melder schickt auch nicht, dass er aufgewacht ist, demnach darf FHEM nicht senden.

Um mich noch einmal zu synchronisieren:
den melder ist mit FHEM gepairt? Wenn nein, kannst du dies machen?
Evtl sendet er das "Aufwachen" nur, wenn er eine Zentrale kennt.

Ansonsten sollte das Auslesen bei 'config funktionieren - also
set <name> getConfig
=> anlernen ausloesen
- damit wir einmal den Inhalt des Speichers sehen koennen.

Gruss
Martin

[Kai]

Um mich noch einmal zu synchronisieren:
den melder ist mit FHEM gepairt? Wenn nein, kannst du dies machen?

Er ist mit FHEM gepair - angelernt habe ich ihn mit set COC hmPairForSec 600 und dann die Pair-Taste am Bewegungsmelder gedrückt

 

Evtl sendet er das "Aufwachen" nur, wenn er eine Zentrale kennt.

Das kann sein - er scheint tatsächlich nicht zu senden - kein keepAlive oder ähnliches. - jedenfalls sehe ich nix im Log. Letztendlich kommt nur was, wenn ich ihn durch eine Bewegung auslöse

 

Ansonsten sollte das Auslesen bei 'config funktionieren - also
set <name> getConfig
=> anlernen ausloesen
- damit wir einmal den Inhalt des Speichers sehen koennen

Werd ich später mal zu Hause versuchen und mich wieder melden 

Gruß

Kai 

[Kai]

was bewirkt eigentlich get reg all?

Ist das nur eine Command Queue, die abgearbeitet werden muss oder ist das die tatsächliche Config des Device? Weil dann wäre der minINterval tatsächlich 1

fhem> get BZ_BewMelder reg all

BZ_BewMelder type:motionDetector -

List:1 Peer:broadcast   brightFilter:   value:0

List:1 Peer:broadcast   captInInterval: value:0bool

List:1 Peer:broadcast   minInterval:    value:1

Was bedeutet 1 in dem Fall? Eine Minute?

Weil regList zeigt folgendes:

minInterval     range:0 to 4    : minimum interval 0,15,20,60,120s

was setzt man dann? Eine Range= 1 bis 4 oder die Anzahl der Sek?

[Martin]

Ich hole einmal aus...

Am Dienstag, 20. November 2012 12:31:18 UTC+1 schrieb Kai:

was bewirkt eigentlich get reg all?

a) get liefert immer Ergebnisse DIREKT zurueck (sollte generell in FHEM so sein)
b) Alle Aktionen, die auf das device direkt zugreifen koennen nicht mit "get" realisiert werden, da sie zu lange dauern
c) get liefert also Daten aus dem "Speicher" in fhem
d) get reg all liefert eine Tabelle aller DECODIERTEN register, die zu der Entity (channel oder device) gehoeren.
e) Es gibt bei manchen Devices mehr Register, die in FHEM (noch) nicht angezeigt werden.

Ist das nur eine Command Queue, die abgearbeitet werden muss oder ist das die tatsächliche Config des Device? Weil dann wäre der minINterval tatsächlich 1

Es ist einen Kopie der Parameter aus den Device. Also getConfig (und ein paar andere Methodem) lesen Daten aus dem Device und speichern es in FHEM. Diese "kopie" wird dargestellt.
Ich reite deshalb darauf herum weil es eben einen Unterschied machen kann. Wenn du ein device resetest bleiben die Daten in FHEM stehen (weis ich ja nicht)

fhem> get BZ_BewMelder reg all

BZ_BewMelder type:motionDetector -

List:1 Peer:broadcast   brightFilter:   value:0

List:1 Peer:broadcast   captInInterval: value:0bool

List:1 Peer:broadcast   minInterval:    value:1

Was bedeutet 1 in dem Fall? Eine Minute?

hmmm... ich habe nicht alle Werte der Bausteine verstanden. Mein Tip waere, wass es die helligkeitseinstellung ist, die auch jeder billige MD hat.
FHEM tip:
get BZ_BewMelder regList
Zeigt dir alle von FHEM dekodierten Register zu diesem Baustein an plus eine (sehr) kurze Bemerkung. Ausserdem info ueber den gueltigen Wertebereich. Diese Liste enthaelt keine Werte, ist also unabhaengign vom auslesen des devices.

Weil regList zeigt folgendes:

minInterval     range:0 to 4    : minimum interval 0,15,20,60,120s

was setzt man dann? Eine Range= 1 bis 4 oder die Anzahl der Sek?

Range ist von 0 bis 4, also 5 Werte (immer diese Digitaltechnik...)
Das einsetzen der Reihenfolge nach, also 0=0, 15=1,20=2....

Mitlerweile ist dies aber ueberholt. In diesem Fall werden in der neusten Version 'literals' verarbeitet.
Wenn du updatest hast du die Moeglichkeit  "0", "15", "20",... einzugeben (der Wertebereich ist von HM vorgegeben).
Ist hier nicht so gravierend, aber bei anderen Registern, die mit Namen arbeiten. Das ist dann durchgaengig, sprich es ist in get reg all, get reg minInterval und get regList vorhanden.

Weitere Anmerkung:
wenn du ein register veraenderst, (set regSet minInterval 20) wird beim 'lesen' angezeigt werden"set_20'. "set_..." zeigt immer an, dass der Wert geaendert wurde, FHEM aber keine Bestaetigung von Device hat. Wenn du einen 'refresh' mit getConfig machst, sollte "set_20" zu "20" werden.

Ausblick:
Die wichtigsten Werte sollen in Readings dargestellt werden. Alle Werte darzustellen ist bei einigen Devices unmoeglich, da die schiere Anzahl zu gross ist (dimmer, blind,...)
Den mechanismus habe ich gestern eingebaut - jetzt kann ich a) jedes Register darstellen lassen (einen Wert aendern...) b) nach bugs suchen

Gruss
Martin
 

 

 

[Kai]

Hallo Martin,

erstmal vielen Dank für deine Geduld und deine Antworten - ich hab jetzt ein wenig herumgespielt und jetzt konnte ich den minInterval-Wert ändern. Dazu hab ich kurz nachdem ich die Pair Taste am Bewegungsmelder gedrückt habe den Befehl abgesetzt. CMD Pending ist auch jetzt auf Done....

Sollte jetzt erstmal so klappen

[Martin]

Es sollte eigentlich funktionieren, dass du den Befehl absetzt und dann anlernen drueckst.
Mit dem Wakeup ist es noch unklar - der scheint bei allen devices einen anderen Trigger zu haben.
Vielleicht finden wir den ja noch.

Kannst du noch einmal loggen mit
attr global verbose 1
attr <hmlan> loglevel 1

dann so 10-20 min laufen lassen.

Gruss
Martin

[Kai]

so, hab jetzt mal ne Weile mitlaufen lassen (Bewegung/Keine Bewegung)

Pairtaste konnte ich noch nicht drücken, da ich momentan nicht zu Hause bin - wenn Du da noch Daten von brauchst, einfach Bescheid geben

2012.11.21 13:06:33 1: COC: A0D2A8441161BF600000001277150 -59

2012.11.21 13:06:33 1: SW: As0E01A011F112341AC8A80201C80000

2012.11.21 13:06:33 1: COC: A0E0180021AC8A8F112340101000037 -57.5

2012.11.21 13:07:04 1: COC: A0D2B8441161BF600000001286750 -58

2012.11.21 13:07:04 1: SW: As0E02A011F112341AC8A80201C80000

2012.11.21 13:07:04 1: COC: A0E0280021AC8A8F112340101C80035 -56

2012.11.21 13:07:33 1: COC: A0D2C8441161BF60000000129D850 -73

2012.11.21 13:07:33 1: SW: As0E03A011F112341AC8A80201C80000

2012.11.21 13:07:33 1: COC: A0E0380021AC8A8F112340101C80035 -56.5

2012.11.21 13:08:33 1: SW: As0E04A011F112341AC8A80201000000

2012.11.21 13:08:35 1: SW: As0E04A011F112341AC8A80201000000

2012.11.21 13:08:35 1: COC: A0E0480021AC8A8F112340101000037 -57.5

2012.11.21 13:10:32 1: COC: A0D2D8441161BF6000000012A5D50 -66.5

2012.11.21 13:10:32 1: SW: As0E05A011F112341AC8A80201C80000

2012.11.21 13:10:32 1: COC: A0E0580021AC8A8F112340101C80034 -55.5

2012.11.21 13:11:03 1: COC: A0D2E8441161BF6000000012BD850 -59

2012.11.21 13:11:03 1: SW: As0E06A011F112341AC8A80201C80000

2012.11.21 13:11:03 1: COC: A0E0680021AC8A8F112340101C80034 -55

2012.11.21 13:11:34 1: COC: A0D2F8441161BF6000000012CD250 -65

2012.11.21 13:11:34 1: SW: As0E07A011F112341AC8A80201C80000

2012.11.21 13:11:34 1: COC: A0E0780021AC8A8F112340101C80036 -57

2012.11.21 13:22:29 1: SW: As0E08A011F112341AC8A80201000000

2012.11.21 13:22:29 1: COC: A0E0880021AC8A8F112340101000034 -54.5

2012.11.21 13:23:19 1: SW: As0E09A011F112341AC8A80201C80000

2012.11.21 13:23:21 1: SW: As0E09A011F112341AC8A80201C80000

2012.11.21 13:23:21 1: COC: A0E0980021AC8A8F112340101C80034 -55

2012.11.21 13:26:49 1: SW: As0E0AA011F112341AC8A80201000000

2012.11.21 13:26:49 1: COC: A0E0A80021AC8A8F112340101000034 -55

[Martin]

danke Kai,

ein Paar bewegungen hat es wohl schon gegeben.
ich gehe davona us, dass der 161BF6 der Bewedungdmelder ist.

Der meldet sich recht unregelmaessig und hat keinen Peer eingestellt (nur Sanity-check, kein Problem)
Da keine Meldungen an die Zentral gehen denke ich, dass er nicht mit fhem gepairt ist.

Es ist nicht warscheinlich, dass man dem 'event' Daten schicken kann. Eher denke ich das sich das Device regelmaessig melden wuerde, wenn es mit der Zentrale gepairt ist. Oder nur alle 24h... dein Log ist ~15h lang

Liegen ich richtig?

Gruss
Martin

[Kai]

ein Paar bewegungen hat es wohl schon gegeben.
ich gehe davona us, dass der 161BF6 der Bewedungdmelder ist.

Jep, richtij

 

Der meldet sich recht unregelmaessig und hat keinen Peer eingestellt (nur Sanity-check, kein Problem)
Da keine Meldungen an die Zentral gehen denke ich, dass er nicht mit fhem gepairt ist.

Hmm - laut Readings = PairedTo000000 

Er liefert mir auch nach dem neu Pairen gestern (deswegen kommt ~15h hin) auch Meldungen von unknown oder dead

2012-11-21_10:59:17 BZ_BewMelder Activity:unknown

2012-11-21_11:19:17 BZ_BewMelder Activity:dead

2012-11-21_12:15:33 BZ_BewMelder Activity:unknown

2012-11-21_12:17:36 BZ_BewMelder Activity:unknown

2012-11-21_12:37:36 BZ_BewMelder Activity:dead

Wohlgemerkt, die kamen, obwohl nix getriggert wurde (BewMelder stand im dunklen Schrank, um ihn nicht aus versehen auszulösen)

 

Es ist nicht warscheinlich, dass man dem 'event' Daten schicken kann. Eher denke ich das sich das Device regelmaessig melden wuerde, wenn es mit der Zentrale gepairt ist. Oder nur alle 24h... dein Log ist ~15h lang

Liegen ich richtig?

jau, siehe oben

filtert man den ganzen Motion und Brightness Quatsch raus, sender er dann zusätzlich noch alive Meldungen - diese sind seit gestern Abend

2012-11-20_21:38:59 BZ_BewMelder Activity:alive

2012-11-20_21:40:33 BZ_BewMelder Activity:unknown

2012-11-20_21:50:34 BZ_BewMelder Activity:dead

2012-11-21_10:59:17 BZ_BewMelder Activity:unknown

2012-11-21_11:19:17 BZ_BewMelder Activity:dead

2012-11-21_12:15:33 BZ_BewMelder Activity:unknown

2012-11-21_12:17:36 BZ_BewMelder Activity:unknown

2012-11-21_12:37:36 BZ_BewMelder Activity:dead

2012-11-21_13:07:36 BZ_BewMelder Activity:alive

2012-11-21_13:27:36 BZ_BewMelder Activity:dead

Warum sendet er manchmal dead, manchmal alive und manchmal unknown - wobei alive immer die erste Statusmeldung nach einem MOtion Event ist

 

[Martin]

 

Der meldet sich recht unregelmaessig und hat keinen Peer eingestellt (nur Sanity-check, kein Problem)
Da keine Meldungen an die Zentral gehen denke ich, dass er nicht mit fhem gepairt ist.

Hmm - laut Readings = PairedTo000000 

das ist 'nicht mit der Zentrale gepairt'
=> koennte sein, wenn du es pairst, dass es regelmaessig einen Status schickt.

Er liefert mir auch nach dem neu Pairen gestern (deswegen kommt ~15h hin) auch Meldungen von unknown oder dead

2012-11-21_10:59:17 BZ_BewMelder Activity:unknown

2012-11-21_11:19:17 BZ_BewMelder Activity:dead

2012-11-21_12:15:33 BZ_BewMelder Activity:unknown

2012-11-21_12:17:36 BZ_BewMelder Activity:unknown

2012-11-21_12:37:36 BZ_BewMelder Activity:dead

 

Das kommt von der Einstellung, wie haeufig sich das Device melden muss, um nicht als Verstorben zu gelten. 
Unknown kommt nach einem Neustart von FHEM. Wenn nach der 'lebenszeit' keine message von dem Device gesehen wurde  gilt es als dead. Hier sind also 20min eingestellt. Kannst du im Attribut "actCycle" nachlesen und auch einstellen.

Wohlgemerkt, die kamen, obwohl nix getriggert wurde (BewMelder stand im dunklen Schrank, um ihn nicht aus versehen auszulösen)

Es kommt auch nicht vom MDIR - der schreibt keinen eigenen Nachruf. da laeuft der ActionDetector - der pruefen soll, ob es noch action vondem Device gibt.

Es waere einen Test wert, zu probieren, ob das Device regelmaessig meldet, wenn er eine Zentrale eigerichtet bekommt.

Gruss
Martin

[Kai]

=> koennte sein, wenn du es pairst, dass es regelmaessig einen Status schickt.

jch dachte eigentlich, das sei durch hmPairforsec und drücken der Pairtaste am Mdir schon geschehen

 ´

 

Das kommt von der Einstellung, wie haeufig sich das Device melden muss, um nicht als Verstorben zu gelten. 
Unknown kommt nach einem Neustart von FHEM. Wenn nach der 'lebenszeit' keine message von dem Device gesehen wurde  gilt es als dead. Hier sind also 20min eingestellt. Kannst du im Attribut "actCycle" nachlesen und auch einstellen.

ok, das macht sinn und erklärt das Verhalten

 

Es waere einen Test wert, zu probieren, ob das Device regelmaessig meldet, wenn er eine Zentrale eigerichtet bekommt.

ok, wie pair ich das mit der Zentrale? Zentrale =Fhem?

[Martin]

Am Mittwoch, 21. November 2012 18:10:40 UTC+1 schrieb Kai:

=> koennte sein, wenn du es pairst, dass es regelmaessig einen Status schickt.

jch dachte eigentlich, das sei durch hmPairforsec und drücken der Pairtaste am Mdir schon geschehen

Es waere einen Test wert, zu probieren, ob das Device regelmaessig meldet, wenn er eine Zentrale eigerichtet bekommt.

ok, wie pair ich das mit der Zentrale? Zentrale =Fhem?

Es geht auf verschiedene Weise.
hmpairserial, pair, hmpairforsec sollten es machen
Den Weg ueber register  habe ich noch nicht geteste...
set RM regSet pairCentral 123456  #123456 ist die HMID von FHEM

Am muss es  - nach dem Auslesen  - in pairedTo stehen. Sonst hat es nicht funktioniert

Ueberal ggf Anlernen Druecken - die Kommunikation ueber wakeup kalppt ja noch nicht.

Gruss
Martin

[Matzek]

Hallo miteinander,

ich hoffe ich bin hier richtig. (Vielleicht lohnt sich auch ein neuer thread: "Bewegungsmelder für dummies"!  :-P  )

Ich komme mit meinen HM-Bewegungsmelder nicht klar. Anlernen funktioniert super - wie gewohnt!!  ;-)

Wenn ich mich richtig erinnere, konnte man in FHEM-5.2 im State noch motion oder alive auslesen, was aus oben genannten Gründen (die ich nicht voll verstanden habe) geändert. Die 4 Minuten Reaktionszeit haben mich natürlich auch gestört -> HM-LanKonfigurator gekauft -> Zeit auf 15 sec gestellt und an FHEM-5.3 angelernt! 

Ich habe weder in den Readings noch mit dem ActionDetector etwas auswertbares gefunden. Act-Cycle steht im actiondetect auf 600 und im Bewegungsmelder auf 000:01.

Habt ihr einen praktiblen Ansatz, wie ich den Bewegungsmelder in FHEM nutzen kann? 

Folgenden Log zeigt mir FHEM:

2012-11-29_20:48:02 BM1 motion
2012-11-29_20:48:02 BM1 motion: on (to ActionDetector)
2012-11-29_20:48:26 BM1 motion
2012-11-29_20:48:26 BM1 motion: on (to ActionDetector)
2012-11-29_20:48:53 BM1 motion
2012-11-29_20:48:53 BM1 motion: on (to ActionDetector)
2012-11-29_20:53:52 BM1 motion
2012-11-29_20:53:52 BM1 motion: on (to ActionDetector)
2012-11-29_20:55:52 BM1 motion
2012-11-29_20:55:52 BM1 motion: on (to ActionDetector)

Vielen Dank!

Grüße

Matthias

[Rüdiger Bente]

Hallo Matthias,

ich habe derzeit den MDIR im Einsatz und hatte am Anfang auch so meine Probleme.
Bei mir laeuft er mit folgender Konfiguration

define FL_Bewegungsmelder CUL_HM #####
attr FL_Bewegungsmelder devInfo 810100
attr FL_Bewegungsmelder firmware 1.0
attr FL_Bewegungsmelder hmClass sender
attr FL_Bewegungsmelder model HM-SEC-MDIR
attr FL_Bewegungsmelder room Flur
attr FL_Bewegungsmelder serialNr -----------
attr FL_Bewegungsmelder subType motionDetector

define FileLog_FL_Bewegungsmelder FileLog /var/log/fhem/FL_Bewegungsmelder-%Y.log FL_Bewegungsmelder
attr FileLog_FL_Bewegungsmelder logtype text
attr FileLog_FL_Bewegungsmelder room Server-Logs

define FL_Bewegungsmelder_Motion notify FL_Bewegungsmelder:motion.* {if(ReadingsVal("FL_Bewegungsmelder","brightness","40")<37){fhem "set FL_Lampe_Garderobe on-for-timer 60"}}
attr FL_Bewegungsmelder_Motion room Flur

Natï¿œrlich muss man den Wert (37) bei dem Readingsval an die Gegebenheiten in dem Raum anpassen, das ist der Wert, ab welcher Helligkeit nicht mehr geschaltet werden soll.
Auch die on-for-timer Zeit ist ein ï¿œberdenkenswert, sollte sich nach dem Wert richten, die du fï¿œr die Reaktionszeit eingestellt hat.

LG

RueBe

Am 29.11.2012 21:02, schrieb Matzek:

Hallo miteinander,

ich hoffe ich bin hier richtig. (Vielleicht lohnt sich auch ein neuer thread: "Bewegungsmelder fￜr dummies"! ￜ:-P ￜ)

Ich komme mit meinen HM-Bewegungsmelder nicht klar. Anlernen funktioniert super - wie gewohnt!! ￜ;-)

Wenn ich mich richtig erinnere, konnte man in FHEM-5.2 im State noch motion oder alive auslesen, was aus oben genannten Grￜnden (die ich nicht voll verstanden habe) geￜndert. Die 4 Minuten Reaktionszeit haben mich natￜrlich auch gestￜrt -> HM-LanKonfigurator gekauft -> Zeit auf 15 sec gestellt und an FHEM-5.3 angelernt!ￜ

Ich habe weder in den Readings noch mit dem ActionDetector etwas auswertbares gefunden. Act-Cycle steht im actiondetect auf 600 und im Bewegungsmelder auf 000:01.

Habt ihr einen praktiblen Ansatz, wie ich den Bewegungsmelder in FHEM nutzen kann?ￜ

Folgenden Log zeigt mir FHEM:

2012-11-29_20:48:02 BM1 motion
2012-11-29_20:48:02 BM1 motion: on (to ActionDetector)
2012-11-29_20:48:26 BM1 motion
2012-11-29_20:48:26 BM1 motion: on (to ActionDetector)
2012-11-29_20:48:53 BM1 motion
2012-11-29_20:48:53 BM1 motion: on (to ActionDetector)
2012-11-29_20:53:52 BM1 motion
2012-11-29_20:53:52 BM1 motion: on (to ActionDetector)
2012-11-29_20:55:52 BM1 motion
2012-11-29_20:55:52 BM1 motion: on (to ActionDetector)

Vielen Dank!

Grￜￜe

Matthias

[Martin]

Hallo

 

Wenn ich mich richtig erinnere, konnte man in FHEM-5.2 im State noch motion oder alive auslesen,

"Motion" sollte immer noch  kommen.
"alive" ist kein Zustand des Melders selbst, hat also in state nichts verloren. Ein "alive" wuerden deinen zustand motion im state verdraengen.
Wenn du wissen willst, wann die Letzte Meldung kam kannst du dies in den diversen Protokoll-variablen nachsehen.

 

Die 4 Minuten Reaktionszeit haben mich natürlich auch gestört -> HM-LanKonfigurator gekauft -> Zeit auf 15 sec gestellt und an FHEM-5.3 angelernt! 

Ich habe weder in den Readings noch mit dem ActionDetector etwas auswertbares gefunden. Act-Cycle steht im actiondetect auf 600 und im Bewegungsmelder auf 000:01.

Das sind 2 unterschiedliche dinge - hast du die doku gelesen?
die 600 im ActionDetector sagen, dass der Action-detector alle 600sec (10min) prueft, ob alle devices sich nach vereinbarung gemeldet haben
die 00:01 bedeuted, dass der mdir sich alle 1min melden sollte. Wenn der Action Detector dran kommt prueft er, od das letzte Melden des mdir laenger als 1min zurueck liegt.
Die Einstellung 000:01 ist nicht sinnvoll. Du solltest ein Interval nehmen, von dem du sicher weist, dass sich der mdir regelmaessig meldet - also 3 min oder laenger.
den Actiondetector kannst du bis auf 30sec interval runterregeln. Aus Performancegruenden halte ich dies nicht fuer sinnvoll. Ziel dieser einstellung ist einen Alarm (event, alarme habe wir leider nicht) zu erzeugen wenn sich ein Bauteil nicht mehr meldet - also die Batterie nicht low sondern leer ist oder das device einfach komplett defekt ist. Eine ueberwachung alle 10min ist m.E. mehr als genug.

Habt ihr einen praktiblen Ansatz, wie ich den Bewegungsmelder in FHEM nutzen kann?

was ist dein Ziel? 
Du kannst das uebliche:
- ueber fhem auf motion reagieren und aktionen einleiten mit notify
- mdir direkt pairen mit HM aktoren und dies aus FHEM steuern/ueberwachen
- mdir aus fhem konfigurieren (regSet/ getConfig / get reg)           
 und die Register: evtFltrPeriod ,evtFltrNum,minInterval,captInInterval,brightFilter,ledOnTime

fehlt hier etwas?

Gruss
Martin

[Martin]

define FL_Bewegungsmelder_Motion notify FL_Bewegungsmelder:motion.* {if(ReadingsVal("FL_Bewegungsmelder","brightness","40")<37){fhem "set FL_Lampe_Garderobe on-for-timer 60"}}
attr FL_Bewegungsmelder_Motion room Flur

Natï¿œrlich muss man den Wert (37) bei dem Readingsval an die Gegebenheiten in dem Raum anpassen, das ist der Wert, ab welcher Helligkeit nicht mehr geschaltet werden soll.
Auch die on-for-timer Zeit ist ein ï¿œberdenkenswert, sollte sich nach dem Wert richten, die du fï¿œr die Reaktionszeit eingestellt

hat.

Interesanter Ansatz.  Ich haette vesucht, solche Details aus der Zentrale rauszuhalten. Jeder billig-bewegungslender verwaltet seine helligkeitsschwelle selbst, sollte ein teurer HM auch koennen. Ich denle das Register "brightFilter" sollte dir so etwas beretis im device abfangen. Wenn deine Garderobenlampe von HM ist kannst du diese auch gleich mit denm MDIR pairen und die on-zeit dort konfigurieren. bei HM kann man das sehr geziehlt.

Gruss
Martin

[Rüdiger Bente]

Fï¿œr mich war das die einfachste Art der Konfiguration. Und da FHEM auf einem exklusiven Raspberry lï¿œuft, spielt Performance keine Rolle. Der Raspi gammelt eh im unteren einstelligen CPU% Bereich rum.
Zweites Argument ist noch, das ich mit diesem MDIR generell Erfahrungen mit Bewegungsmeldern sammeln will und da ist eine direkte und einfache Kontrolle der Parameter ohne an das Gerï¿œt zu mï¿œssen, natï¿œrlich hilfreich.

LG

RueBe

Am 30.11.2012 11:57, schrieb Martin:

define FL_Bewegungsmelder_Motion notify FL_Bewegungsmelder:motion.* {if(ReadingsVal("FL_Bewegungsmelder","brightness","40")<37){fhem "set FL_Lampe_Garderobe on-for-timer 60"}}
attr FL_Bewegungsmelder_Motion room Flur

Natï¿œrlich muss man den Wert (37) bei dem Readingsval an die Gegebenheiten in dem Raum anpassen, das ist der Wert, ab welcher Helligkeit nicht mehr geschaltet werden soll.
Auch die on-for-timer Zeit ist ein ï¿œberdenkenswert, sollte sich nach dem Wert richten, die du fï¿œr die Reaktionszeit eingestellt

hat.

Interesanter Ansatz.ￜ Ich haette vesucht, solche Details aus der Zentrale rauszuhalten. Jeder billig-bewegungslender verwaltet seine helligkeitsschwelle selbst, sollte ein teurer HM auch koennen. Ich denle das Register "brightFilter" sollte dir so etwas beretis im device abfangen. Wenn deine Garderobenlampe von HM ist kannst du diese auch gleich mit denm MDIR pairen und die on-zeit dort konfigurieren. bei HM kann man das sehr geziehlt.

Gruss
Martin

--

[Martin]

Hallo,

sicher hast du die richtige Entscheidung fuer deine Anwendung getroffen. Dennoch eine Anmerkung zu Performance:
Die Performance der Platform ist wichtig, aber nicht alles. Ein Problem ist die Performance der Luft und die des IO device.
1) Wenn du alles ueber die Zentrale schleifst verdoppelst du die Aktivitaet in der Luft - Kann sogar noch hoeher sein.
2) die Luft Schnittstelle deiner Zentrale ist der 2. Engpass. Hier muessen letztendlich alle Kommandos durch.
3) wichtig ist auch die Latenzzeit - verursacht durch Wartezeiten an der Schnittstelle. Ist um so relevanter je mehr Devices man betreibt. Die mittlere Performance ist eigentlich Nebensache, der Spitzenwert ist das Problem.
4) latencen der wakeup devices koennen durch 3) aus der spec laufen da fhem keine Trafficpriorisierung hat.
5) single point of failure: Zum Schalten brauche ich den sensor und des aktor. Wenn ein Sender ausfaellt ist der eben weg - alles andere geht noch. Wenn ich die Zentrale brauche und diese aus irgened einem Grund aufgibt ist im ganzen Haus schluss
6) Testfreundlichkeit: Es erleichtert mir u.a. das experimentieren: wenn ich die Zentrale schrotte findet meine Frau immer noch den Lichtschalter in den Keller um das Bier zu holen ;-)
7) beim Bewegungsmelder nicht relevant, bei allen anderen schaltern schon ist die reaktionszeit. Die kann merklich langsamer werden, wenn die Zentrale im spiel ist.

Daher meine Entscheidung: alles was ich direkt schalten kann mache ich direkt. Logging und komplexe Dinge, Zeitsteuerungen, Logs  und Maintenance kommen aus der Zentrale. Da gibt es noch genug.

Aber letztlich alles geschmackssache - wir sind ja an diesem Project, weil wir es nach eigenen Anforderungen gestalten koennen

LG Martin

[Matzek]

Hi Martin, hi Ruebezahl,
danke für eure aufschlussreichen Antworten.

Die Entscheidung "alive" nicht zu nutzen, wenn es kein MDIR-eigener Befehl ist, ist natürlich sinnvoll und gewohnt konsequent!

Die Doku zu Action-Detector habe ich schon gelesen, aber im Tunnelblick den MDIR zum laufen zu bringen, komplett falsch interpretiert! Das schau mir in einer ruhigen Minute nochmal genau an und passe die Werte an - Danke auch hier für die Empfehlungen!

Mein Ziel ist es über fhem und notify einen Alarm zu schalten. Ich dachte notify löst nur bei Zustandsänderung aus ??? Deswegen wusste ich nichts damit anzufangen und hatte den gar nicht probiert, weil der state ja immer motion bleibt! Morgen früh probiere das gleich aus (über state und readings) und berichte dann!

Die Idee von Ruebezahl mit den Helligkeitswerten, klingt interessant - ist aber für Fortgeschrittene! Ein schlechtes Bauchgefühl hätte ich bei der Lösung aber trotzdem, da sie immer von der entsprechenden Umgebungshelligkeit abhängt und die ist doch in den häufigsten Fällen nicht konstant! Mal sehen - Lernen kann man sicher was dabei!

ob da was fehlt?! Wahrscheinlich nicht! :-)

Schönen Abend.
MfG
Matzek

[Matzek]

So,
notify auf motion funktioniert! ->  BM1:* {if($value{"BM1"} eq "motion") {fhem "set BM1motion on"}}
Der Dummy BM1 wird durch das notify gesetzt und ich setze den an anderer Stelle zurück!
Perfekt!

Vielen Dank für eure Unterstützung.

Grüße
Matthias