HM-Sen-MDIR-O

[Groby]

Hallo,

Ich habe einen HM-Sen-MDIR-O mit dem CUL gepairt. Per default hat dieser den Wert brightness etwa alle 6min upgedatet. Jetzt habe ich das Gerät neu in fhem angelegt und nochmals mit dem CUL gepairt, aber leider bleiben die automatischen updates von brightness aus...

Da ich den Sensor als Helligkeitsmesser verwenden will, sollten die updates wieder regelmässig erfolgen. Mehrere Resets mit und ohne autocreate blieben bis jetzt erfolglos...

Update:
Ich habe nochmal ein wenig weitergeforscht. Es scheint einen Unterschied zu machen, ob das Device mit Autocreate neu angelegt wird oder per hmPairSerial <device_id> am CUL angelernt wird. Dann sendet er die brightness Daten entweder alle 6min oder nur bei Bewegung...

Frage: wie kann man das per CMD aktivieren / ändern?

Danke & Gruss, Groby

[martinp876]

Hi Groby,

Es scheint einen Unterschied zu machen, ob das Device mit Autocreate neu angelegt wird oder per hmPairSerial

interessante Beobachtung.
kannst du das noch einmal Testen und nach jedem pairen ein getConfig machen?

In beiden faellen die Roh-messages aufzeichnen
attr global verbose 1
attr mseglog 1
attr <cul> loglevel 1

das attribut "expert" auf "2" setzen in Device und ein "list <device>" machen.

Ich gehe davon aus, das eines der Register dieses Verhalten steuert und beim Anlernen automatisch gesetzt wird.
Gruss Martin

[Groby]

Hallo Martin,

ja ich kann es probieren, kann Dir aber nicht versprechen bis wann ich das schaffe.

Ich habe im übrigen gesehen, das der Bewegungsmelder noch pending cmds hat. Kann ich die irgendwie "wegbügeln"?

In der dürftigen Anleitung habe ich einen Passus unter "9. Sonstige Betriebshinweise" gefunden:
...
9.1 Empfindlichkeit
Bei Betrieb ohne Zentrale löst der Bewegungsmelder bei jedem Sensor-Impuls.
Bei Betrieb mit Zentral kann dort das Ansprechverhalten abhängig von der Bewegungsintensität eigesellt werden.

- Akustisches Signal: unempfindlicher, z.B. 3 Impulse pro Zeitraum ??? komisch kann der Ton :)
- Optisches Signal: empfindlich, z.B. 1-2 Impulse pro Zeitraum
...

Sagt mir jetzt so nichts, aber da mein BM direkt vor/hinter einer Glasbauwand liegt, sollte er nur wenige bis gar keine Bewegungsimpulse mitbekommen...

Mfg, Groby

[Martin Thomas Schrott]

Nett, ist mir garnicht aufgefallen, ich hab mal bei eq3 nachgefragt was sie uns damit sagen wollen :-)
Also Mikrofon hat des Teil nicht und piepsen kann er auch nicht also möglicherweise einfach ein falscher Begriff?
auf englisch haben sie audible verwendet was man auch mit vernehmbar übersetzen könnte -> technisch bedeutet es aber eindeutig akustisch und ist mit etwas hörbarem verknüpft. Tja, suspekt.
lG
Martin

[martinp876]

Hi Groby,

cmdsPending:
- von dir gesendet Aktionen sind im cmd-speicher und warten auf senden.
-- alle commands kommen in den Speicher, die meisten siehst du dort nie, weil sie sehr schnell rausgehen
-- manche Devices sind nicht immer auf Empfang. FHEM wartet auf eine "gute Gelegenheit" das device zu bequatschen.
==> manche reagieren nur auf "config", also anlernen (RC12...)
==> manche empfangen bei wakeup - die wachen regelmaessig auf, dann kann man senden. TC alle 3 min, RHS alle 24h! FHEM kann warten.
==> mischoptionen sind moeglich (config UND wakeup).
Will sagen: wenn kommands noch pending sind solltest du entscheiden ob sie wichtig sind. Dann a) warten oder b) anlernen druecken.

Wenn du sie loshaben willst kannst du das Protokoll 'clearen': alle proto-zaehler und den Stack loeschen:
set <devName> clear msgEvents.

Noch zu wissen: der cmdStack ueberlebt einen restart nicht. Wenn du also einen RHS befragen willst und auf das Aufwachen wartest (bei Auslesen der config kann es sinnvoll sein) sollte fhem keinen update in der Nacht machen. Dann ist der Stack weg...

Zu den Einstellungen:
hast du schon ein get name regList gemacht? Wenn du wissen willst, was fhem unterstuetzt immer der erste Weg.
 
 Akktuell haben wir:
  evtFltrPeriod   min=>0.5,max=>7.5     's'   "event filter period"
  evtFltrNum      min=>1  ,max=>15            "sensitivity - read each n-th puls"
  minInterval     min=>0  ,max=>4             "minimum interval in sec"   ,lit=>{15=>0,30=>1,60=>2,120=>3,240=>4}
  captInInterval  min=>0  ,max=>1             "capture within interval"   ,lit=>{off=>0,on=>1}
  brightFilter    min=>0  ,max=>7             "brightness filter - ignore light at night"
  eventDlyTime    min=>0  ,max=>7620    's'   "event delay time"
  ledOnTime       min=>0  ,max=>1.275   's'   "LED ontime"
  eventFilterTime min=>0  ,max=>7620    's'   "event filter time"

 klar ist mir nicht alles, aber:
 captInInterval: wird ein weiterer Trigger waerend des Intervalls gesendet?
 ledOnTime - klar
 evtFltrPeriod,evtFltrNum: (ich glaube) wie viele trigger muss der MD gesehen haben, bevor er eine trigger ausloest? Scheint mir eine wichtige einstellung, damit nicht bei jedem Windstoss ausgeloest wird.
 minInterval wie schnell hintereinander duerfen trigger gesendet werden?
 eventDlyTime - klingt verstaendlich
 brightFilter interreasant, nicht ganz klar. Hier muss man etwas ausholen. Der MD schickt trigger an seine peers. Diese Trigger enthalten auch die Helligkeit. Wenn du also einen Lichtschalter mit dem md peers bekommt der Lichtschalter IMMER einen trigger wenn bewegung herrscht (beachte obige Filter) - UNABHAENGIG von der Helligkeit! Normal will man tagsueber aber kein Licht anschalten. Bei HM entscheidet immer der Aktor, auch hier. Der MD schickt die Helligkeit als wert zwischen 0 und 200 und in Aktor wird festgelegt ab welchen Wert geschaltet wird.
 brigthFilter kann also nur ein Faktor oder offset sein, der den Lichtwert beeinflusst. waere schoen, wenn du dies herausfinden koenntest.

eine Tute konnte ich nicht finden :-(
 
 Gruss
 Martin
 

[Martin Thomas Schrott]

Hi zusammen,

Antwort ist da :-)

aber zuerst: der brightfilter (wenn ich mich noch richtig erinnere) legt fest wie lange der mdir die aktuelle brightness vor einem absenken sperrt um kurze vorbeifahrende Autos etc. Events zu ignorieren.
Ich hab Infos gesammelt und werde meine und die gesammelten Daten hoffentlich bald zusammengefasst aufbereiten.

so und hier noch die Antwort die alles erklärt:!keine Geräusche!
Es handelt sich hier um Einsatzbeispiele.
Wenn eine bestimmte Anzahl von Impulsen in einem definierten Zeitraum erfasst werden,
können unterschiedliche Aktoren angesprochen werden.
Der 1. Aktor könnte ein optisches Signal auslösen z.B. Beleuchtung (1-2 Impulse pro
Zeitraum)
Der 2. Aktor könnte ein akustisches Signal auslösen z.B. Sirene (3 Impulse pro Zeitraum)


Liebe Grüße
Martin

[Groby]

Hallo Martin & Martin,

Eine ähnliche Vorgehensweise habe ich anhand der Solexa Markisensteuerung abgeleitet, die kleine Wölkchen oder Sonnenstrahlen filtert und erst nach x-Minuten / Messungen reagiert um sie ein/auszufahren...

Die Preisfrage wäre dann, wie die Werte ermittelt werden:

0 = alle 6 min
1 = min aus Messung 6 / 12 min
usw...

oder vielleicht gemittelt, den höheren oder kleineren Wert?

Jedenfalls geht der brightness Wert im Moment bei mir bis 250. Aber in die Theorie würde das auch zur Anleitung passen:

"Ausfiltern von kurzfristigen Helligkeitsschwankungen"

Kurz mal gebabelfischt bright(ness)Filter - könnte passen...

@martinp867: Ich starte mal den Test und wehe wenn ich den BM nicht wieder in den jetzigen Zustand zurückbekomme!!!

MfGroby

[Groby]

Hi martinp876,

ich glaube ich hab's...

Wenn ich keinen Fehler gemacht habe, dann liegt wirklich daran, das man entweder mit HMLan oder CUL pairt. Wobei mir noch nicht so ganz klar ist, ob das immer so ist, oder nur beim Device Reset, einlegen der Batterien, autocreate oder manuell, fhem reboot usw. eine bestimmte Reihenfolge einzuhalten ist... (Nicht zu vergessen, dass ich genau in diesem Fall den loglevel vergessen habe, da live System)...

Ginge das auch über FHEM2FHEM mit einem CUL RAW oder verfälscht das??? Das würde mir sehr entgegen kommen, da ich mein Live System nicht ständig booten / umconfigurieren müsste...  

Fakt ist: HMLan machr per Default keine brightness updates - CUL nur unter bestimmten Vorraussetzungen. Das ist jedenfalls Stand der Dinge nach meinen Beobachtungen...

Ich hab Dir den 1. Salm HMLan autocreate per PM geschickt, es wäre gut wenn Du mal prüfst ob es das ist was Du brauchst...

Da der BM jetzt wieder Ordnungsgemäß im Live System läuft und mein Zeigefinger blutet, vertage ich auf morgen (sonst muss ich morgen früh alles zu Fuß/per Hand einschalten - geht gar nicht ;)

MfGroby

[martinp876]

Hi Groby,

ich werden es mal ansehen. Habe gerade wenig Zeit...., melde mich wieder
Gruss, Martin

[Martin Thomas Schrott]

Hi Groby,

was meinst du damit, dass der hmlan keine brightness updated?
Erhältst du keine brightness readings wenn es dunkler wird? Bei mir ist der md direkt an den hmlan angelernt worden und updated die Werte umgehend wenn sich etwas ändert. Nur wenn es heller wird wartet er den eingestellten Zeitraum ab und gibt erst dann den neuen Wert bekannt.
Wo schaust du bzw wo fehlt dir die Info?

Zusätzlich ist der brightness Wert auch in jeder Motion Meldung enthalten! Also auch wenn er sich nicht geändert hat.

LG
Martin

[Groby]

Hallo Martin,

ich verstehe das im Moment auch nicht und habe deswegen martinp876 div. log files geschickt.

Folgendes Phänomen:
Bei pairing mit HMLan - brightness updates nur mit motion detect

Bei Pairing mit CUL - brightness update ca. alle 6min

Genauso will ich das haben, da ich das Teil nur als LuxMeter betreiben will um die Beleuchtung zu steuern...

Somit bin ich in der Zwickmühle. Beide devices verstrahlen mir die Hütte. Mit CUL kriege ich die RM's nicht richtig angesprochen. Mit HMLan den BM nur im "doofy" Modus.

Also hab ich gedacht, toll da ist doch eine HMLan Config Software für Windows dabei. Pustekuchen.

Der BM taucht nicht in der HMLan-CFG Soft auf, oki denke ich, vielleicht ein Windows 8 Problem. Kein Ding, nehmen wir Windows 7 - findet den HLan nicht - muss man nicht verstehen. Gut also Win XP - auch nicht???

Na schön, dann installiere ich die Soft eben wieder auf Win 8. Von wegen jetzt ist HMLan bockig und will gar nicht mehr gefunden werden. Also der HMLan ist kurz davor vom LKW überfahren zu werden...

Jetzt gets mir wieder besser ;)

MfGroby

[Groby]

Für Alle die mitlesen...

Nach weiteren erfolglosen Pairing Versuchen mit HMLan habe ich den BM wieder mit dem CUL ans Laufen bekommen. Er sendet brightness updates im 6 min Takt - auch ohne motion. Leider sehe ich per list nicht ob der BM noch richtig mit dem CUL gepairt ist.

Also habe ich ein clear readings & msgEvents durchgeführt um über getConfig den aktuellen Status des Gerätes zu ermitteln. Jetzt zeigt er 3 pending cmds und es gilt abwarten bis er die Befehle abgearbeitet hat.

Fortsetzung folgt...

[martinp876]

Der Sensor sollte aufwachen, so einmal am Tag. Dann sollten die Kommandos abgearbeitet werden.
Alternativ kannst du anlernen druecken, dann Wird gleich gesendet.
Das ist bei HMLAN und CUL identisch

Gruss
Martin

[Martin Thomas Schrott]

Guten Morgen,

okay, jetzt haben wir mehrere Baustellen.

Bezüglich des hmlan such mal im Forum, das Problem hatten schon mehrere hier ist das deaktivieren aller nicht benötigten Netzwerkschnittstellen erforderlich damit die Windows Software ihn findet!

Ansonsten ist der hmlan eigentlich sehr freundlich und unkompliziert vor allem wenn du ihn nur mit fhem bedienst ... ich glaube nicht das der hmlan direkt das Problem ist -> eher der mdir, der hat mich am Anfang auch eher etwas ... suchen lassen :-)

Also zurück zum mdir
ich bin immer noch der Meinung, dass du keine regelmäßigen Updates erhalten musst und vielleicht sogar garnicht solltest, denn er sendet immer wenn sich etwas ändert und das genügt ja.
Also alle sechs Minuten ist eigenartig, müsste ich mal bei mir nachsehen ob es da ein reading gibt welches das auslöst, wenn es aktiviert wird.

Bei mir mit hmlan gepaired erhalte ich wie gesagt sofort ein reading update wenn sich die Helligkeit verringert. Erhältst du das auch nicht? Ganz einfach testen indem du den Sensor abdeckst. Im log / eventmonitor oder wo du auch am liebsten nachsiehst solltest du umgehend eine Meldung mit einem geringeren Hellighkeitswert erhalten.

Vergleich doch mal auch die Register die im mdir gesetzt sind wenn du mit cul gepaired hast und wenn du mit hmlan gepaired hast -> wenn etwas anders läuft muss dort auch ein Unterschied zu sehen sein.

Und vergiss den LKW der MDIR ist stärker!
;-)
Liebe Grüße
Martin

[Groby]

Hallo Martin,

nochmals vielen Dank für Deine Hilfe.

Gestern Abend habe ich es hinbekommen, die logs habe ich Dir per PM geschickt.

Komisch ist zum einen, das ein "reset" am Gerät die Einstellungen wohl nicht so ganz sauber löscht. Da soll man als Anfänger erstmal drauf kommen...

upair, pair funktioniert bei beiden Geräten, und die brightness Werte werden auch alle 6 min bei beiden Geräten gesendet, sofern der Pairing process "richtig" abgeschlossen wird.

Ergo konnte nach einem "reset" entweder der CUL oder HMLan nicht richtig pairen, und deshalb kamen nur brightness Events zusammen mit motion Events - So jedenfalls meine Theorie - leider konnte ich mir kein davon Bild machen, da die pending cmds den Gerätestatus nicht updaten wollten...

Nach dem Pairing bewirkt ein herausnehmen und einlegen der Batterien wahre Wunder und der pairing Zustand wid danach auch korrekt angezeigt.

Somit ist der Fall für mich gelöst.

Danke an alle die mitgeholfen haben.

MfGroby