Re: Bewegungsmelder HM-SEC-MDIR

[Guest]

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

[Guest]

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

[Guest]

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

[Guest]

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

[Guest]

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

[Guest]

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

[Guest]

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

[Guest]

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

[Guest]

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