Originally posted by: <email address deleted>
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
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
ok super danke!
Wenn ich mir das aussuchen darf (freu) dann wäre es erwünscht.
Vielen Dank!
LG
edank
Am Sonntag, 14. Oktober 2012 19:04:31 UTC+2 schrieb 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
>
>>
>>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
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
Am Montag, 15. Oktober 2012 09:16:38 UTC+2 schrieb 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
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
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
>
>
> Am Montag, 15. Oktober 2012 09:16:38 UTC+2 schrieb 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
>>
>>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
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:
>
> 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
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
werde ich richten.
Gruß
Martin
Am Montag, 15. Oktober 2012 19:38:22 UTC+2 schrieb 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:
>>
>> 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
>>
>>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Sollte drin sein
>
>
>>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Super funktioniert!
Danke!
LG
edank
Am Mittwoch, 17. Oktober 2012 07:55:22 UTC+2 schrieb Martin:
>
> Sollte drin sein
>>
>>
>>>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
Am 17.10.2012 19:33, schrieb edank:
> Super funktioniert!
>
> Danke!
>
> LG
> edank
>
> Am Mittwoch, 17. Oktober 2012 07:55:22 UTC+2 schrieb Martin:
>
> Sollte drin sein
>
>
> --
> 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
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
Am Freitag, 19. Oktober 2012 10:00:48 UTC+2 schrieb Ruebezahl:
>
> 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
>
>
> Am 17.10.2012 19:33, schrieb edank:
>
> Super funktioniert!
>
> Danke!
>
> LG
> edank
>
> Am Mittwoch, 17. Oktober 2012 07:55:22 UTC+2 schrieb Martin:
>>
>> Sollte drin sein
>>>
>>>
>>>> --
> To unsubscribe from this group, send email to
> fhem-users+...@googlegroups.com
>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
Am 20.10.2012 22:39, schrieb 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
>
>
>
>
>
> Am Freitag, 19. Oktober 2012 10:00:48 UTC+2 schrieb Ruebezahl:
>
> 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
>
>
> Am 17.10.2012 19:33, schrieb edank:
>> Super funktioniert!
>>
>> Danke!
>>
>> LG
>> edank
>>
>> Am Mittwoch, 17. Oktober 2012 07:55:22 UTC+2 schrieb Martin:
>>
>> Sollte drin sein
>>
>>
>> --
>> To unsubscribe from this group, send email to
>> fhem-users+...@googlegroups.com
>
> --
> 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
Originally posted by: <email address deleted>
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
Am 21.10.2012 00:51, schrieb 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
>
> --
> 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
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
Am Montag, 22. Oktober 2012 15:28:12 UTC+2 schrieb 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
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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.
Am Dienstag, 23. Oktober 2012 07:10:46 UTC+2 schrieb 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.
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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?
>
>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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?
>>
>>
>>
>>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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?
>
>
>
> --
> 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
Originally posted by: <email address deleted>
>
> 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.
>
>
> 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?
>>>
>>>
>>>
>>> --
> To unsubscribe from this group, send email to
> fhem-users+...@googlegroups.com
>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
> 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.
>
>
>
>
>
>
>
> 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?
>>
>>
>>
>> --
>> To unsubscribe from this group, send email to
>> fhem-users+...@googlegroups.com
>
> --
> 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
Originally posted by: <email address deleted>
Wahl des Sendeabstandes kann ich nicht einordnen.
Probier doch mal den Anhang aus
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
/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
>
>
> --
> 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
Originally posted by: <email address deleted>
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
Am Mittwoch, 24. Oktober 2012 06:23:12 UTC+2 schrieb Ruebezahl:
>
> *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
>
>
> --
> To unsubscribe from this group, send email to
> fhem-users+...@googlegroups.com
>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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.
> Testen mus ich noch den shortcut 'self' als peerId. Der geht in deser
> Funktion jetzt nicht.
> Der rest - insbesondere getConfig - sollte funktionieren
>
> Gruss,
> Martin
>
> Am Mittwoch, 24. Oktober 2012 06:23:12 UTC+2 schrieb Ruebezahl:
>
> /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
>>
>>
>> --
>> To unsubscribe from this group, send email to
>> fhem-users+...@googlegroups.com
>
> --
> 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
Originally posted by: <email address deleted>
Hi RB,
leider kann ich deinen log nicht lesen - kannst du es in einfachen standard
ascii schicken?
ᅵᅵ DEFᅵᅵᅵᅵᅵᅵᅵ 189E00
Danke
Martin
Am Donnerstag, 25. Oktober 2012 06:29:35 UTC+2 schrieb Ruebezahl:
>
> 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.
> Testen mus ich noch den shortcut 'self' als peerId. Der geht in deser
> Funktion jetzt nicht.
> Der rest - insbesondere getConfig - sollte funktionieren
>
> Gruss,
> Martin
>
> Am Mittwoch, 24. Oktober 2012 06:23:12 UTC+2 schrieb Ruebezahl:
>>
>> *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
>>
>>
>> --
>> To unsubscribe from this group, send email to
>> fhem-users+...@googlegroups.com
>>
>>
>> --
> To unsubscribe from this group, send email to
> fhem-users+...@googlegroups.com
>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
Am 25.10.2012 12:16, schrieb 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
> --
> 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
Originally posted by: <email address deleted>
Ich hoffe mit dem Anhang geht es besser????
Am 25.10.2012 12:09, schrieb Martin:
> Hi RB,
>
> leider kann ich deinen log nicht lesen - kannst du es in einfachen
> standard ascii schicken?
>
> ᅵᅵ DEFᅵᅵᅵᅵᅵᅵᅵ 189E00
>
> Danke
> Martin
>
> Am Donnerstag, 25. Oktober 2012 06:29:35 UTC+2 schrieb Ruebezahl:
>
> 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.
>> Testen mus ich noch den shortcut 'self' als peerId. Der geht in
>> deser Funktion jetzt nicht.
>> Der rest - insbesondere getConfig - sollte funktionieren
>>
>> Gruss,
>> Martin
>>
>> Am Mittwoch, 24. Oktober 2012 06:23:12 UTC+2 schrieb Ruebezahl:
>>
>> /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
>>>
>>>
>>> --
>>> To unsubscribe from this group, send email to
>>> fhem-users+...@googlegroups.com
>>
>> --
>> To unsubscribe from this group, send email to
>> fhem-users+...@googlegroups.com
>
> --
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Originally posted by: <email address deleted>
>
>
> 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?
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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 getConfig
=> anlernen ausloesen
- damit wir einmal den Inhalt des Speichers sehen koennen.
Gruss
Martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
> 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 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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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?
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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 loglevel 1
dann so 10-20 min laufen lassen.
Gruss
Martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
>
>
>>
>> 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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
> => 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?
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
> --
> 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
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
>
> 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
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
>
> --
> 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
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
Am Freitag, 30. November 2012 11:47:02 UTC+1 schrieb 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
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
Am Samstag, 1. Dezember 2012 00:03:15 UTC+1 schrieb 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
>
>
>
> Am Freitag, 30. November 2012 11:47:02 UTC+1 schrieb 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
>>
>>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
Originally posted by: <email address deleted>
uff - habe schon an mir gezweifelt.
ja, solle bei HMLAN stimmen.
Am Dienstag, 30. Oktober 2012 16:48:45 UTC+1 schrieb Ruebezahl:
>
> 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+...@googlegroups.com
>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
> 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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com