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
Hi Groby,
ZitatEs 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
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
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
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
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
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
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
Hi Groby,
ich werden es mal ansehen. Habe gerade wenig Zeit...., melde mich wieder
Gruss, Martin
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
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
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...
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
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
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
Hi Groby,
super.
Noch einmal im Forum, du hast es ja schon angedeutet, aber noch einmal laut:
Offensichtlich und logischer weise kommen zyklische Meldungen an die Zentrale nur wenn eine Zentrale gepairt ist.
Daher wieder mein Appel:
-IMMER ALLE DEVICES PAIREN
-IMMER pruefen dass es auch funktioniert hat, bei jeder config aenderung!
Hilfreich koennte hier HMinfo sein. Um das pairing zu sehen koennte man (wenn man ein HMinfo deivce names "hm" angelegt hat!)
set hm -de param pairedTo # liste aller devices und deren pairing-partner. Option: Nur Devices, keine channel, auch leere returns.
Gruss
Martin
Hallo zusammen,
da ich das gleiche Problem mit dem HM-Sen-MDIR-O habe, versuche ich erstmal diesen Thread weiter zu führen und mach kein
neues Thema auf.
Ich habe gefühlte 30 Mal den BWM mit meiner FHEM Instanz gepairt. Immer auf verschiede Weise, das Ergebnis ist allerdings immer das Gleiche.
Es werden keine Helligkeitswerte übertragen, nur bei Bewegungserkennung.
Zuerst mal meine HW/SW:
- Linuxrechner mit Debian und FHEM 5.5 - letztes updatefhem heute Morgen gemacht
- CUL433 ( für mein Intertechno-Gelumpe )
- CUL868 ( rfmode Hometatic )
Intertechno läuft einwandfrei ( mehrere Rolladenschalter und Steckdosen )
Nun habe ich mit Homematic angefangen und hab einen HM-Sec-sc und den besagten HM-Sen-MDIR-O erworben.
Der Türkontakt alleine treibt mir die Zornesröte ins Gesicht. Anlernen perfekt, halte ich ihn in der Hand funktioniert er auch einwandfrei.
Auf einem Kunststoffenster mit Metallkern versagt er dann den Dienst. Antenne aus dem Gehäuse geholt, aber trotzdem scheinen
die 4 Meter zwischen beiden Antennen zu viel zu sein ...
Nun zum Bewegungsmelder. Ich beschreibe mal meine Anlernprozedur,:
# /etc/init.d/fhem stop ( aufgrund autocreate )
- Batterie in den resetteten BWM, Selbsttest abwarten, Sensorbereich abdecken
# /etc/init.d/fhem start
fhem> set CUL868 hmPairForSec 120 ( mit der übrig gebliebenen Hand :-) )
- Taste am BWM drücken, Anlernphase wird mit grüner LED bestätigt.
Der MDIR reagiert bei Bewegung, allerdings kommt nicht eine brightness Meldung ohne Bewegung.
Nach ein paar Minuten wechselt die Activity auf "dead" ... und dann kommt nichts mehr.
Ich habe einen kleinen Karton drüber gestülpt, aber es kommt trotzdem keine Helligkeitsänderung alleine.
Hat jemand vielleicht eine Idee warum keine Werte übertragen werden ?
Ergebnis fhem.cfg:
define BWM.Terasse CUL_HM 20AD90
attr BWM.Terasse .devInfo 110100
attr BWM.Terasse .stc 81
attr BWM.Terasse IODev CUL868
attr BWM.Terasse actCycle 000:10
attr BWM.Terasse actStatus alive
attr BWM.Terasse expert 2_full
attr BWM.Terasse firmware 1.6
attr BWM.Terasse model HM-Sen-MDIR-O
attr BWM.Terasse peerIDs 00000000,
attr BWM.Terasse room Terasse
attr BWM.Terasse serialNr KEQ0196038
attr BWM.Terasse subType motionDetector
list BWM.Terasse: ( die 3 protCmdPend nicht beachten, hab den Anlernknopf nicht erneut betätigt )
Internals:
CUL868_MSGCNT 122
CUL868_RAWMSG A0D45844120AD9000000001372A80C0
CUL868_RSSI -106
CUL868_TIME 2013-11-15 13:47:49
DEF 20AD90
EVENTS 109
IODev CUL868
LASTInputDev CUL868
MSGCNT 122
NAME BWM.Terasse
NR 136
STATE motion
TYPE CUL_HM
hmPairSerial KEQ0196038
lastMsg No:45 - t:41 s:20AD90 d:000000 01372A80
protCmdPend 3 CMDs_pending
protLastRcv 2013-11-15 13:47:49
protResnd 3712 last_at:2013-11-15 16:26:02
protSnd 32 last_at:2013-11-15 11:32:09
protState CMDs_processing...
rssi_at_CUL868 avg:-101.2 min:-128.5 max:-90 lst:-106 cnt:122
Readings:
2013-11-15 13:57:59 Activity dead
2013-11-15 13:47:49 brightness 42
2013-11-15 13:47:49 motion on (to broadcast)
2013-11-15 13:47:49 motionCount 55_next:8-240
2013-11-15 13:47:49 state motion
cmdStack:
++A001HMCUL20AD9001040000000001
++A001HMCUL20AD900103
++A401HMCUL000000010A4B455130313936303338
Helper:
burstEvtCnt 3712
getCfgList all
getCfgListNo 4
mId 005D
peerIDsRaw ,00000000
rxType 28
Prt:
sProc 1
Rspwait:
cmd As0F14A001HMCUL20AD9000040000000000
mNo 14
reSent 3522
Role:
chn 1
dev 1
Rssi:
At_cul868:
avg -101.200819672131
cnt 122
lst -106
max -90
min -128.5
Shadowreg:
Attributes:
IODev CUL868
actCycle 000:10
actStatus dead
expert 2_full
firmware 1.6
model HM-Sen-MDIR-O
peerIDs 00000000,
room Terasse
serialNr KEQ0196038
subType motionDetector
Hallo Fuchs
aber die kommandos in Stack sind doch so hilfreich - ein richtiger Glücksfall!!!!!!!
++A001HMCUL20AD9001040000000001
++A001HMCUL20AD900103
++A401HMCUL000000010A4B455130313936303338
ist eine Katastrophe.
was steht in attribut hmId des CUL868?
Das MUSS ein 3-Byte Wert sein - hex als ASCII
so etwas wie 123456 oder EFEFEF oder ABCDEF
Ich werde einmal die Eingabe parsen, damit so etwas nicht mehr vorkommt.
Gruss Martin
Zitatrssi_at_CUL868 avg:-101.2 min:-128.5 max:-90 lst:-106 cnt:122
die 2. Katastrophe sind seine Rssi werte :(
Ich lerne den MDIR nochmal an und poste das list nochmal ... der Stack ist ein Ergebnis meiner verzweifelten Versuche :)
Was sagen die Rssi Werte genau aus ?
Gruss
Andre
Ach herrje - ich setze mir besser selber die Narrenkappe auf.
Den 433 Mhz CUL hatte ich im wohl irgendwie im Laufe der letzten 50 Fehlversuche mit dem Türkontakt CUL868 benannt - keine Ahnung wieso.
Beim 868 Mhz war es dann anders herum.
Die Rssi Werte haben mich das ganze dann nochmal prüfen lassen - danke fhem-hm-knecht ... und auch Martin ;-)
Siehe da, die brightness Werte kommen jetzt auch so wie es sein soll.
Gruss
André
Noch ein Hinweis zu dem Türkontakt HM-SEC-SC, den Du kurz erwähnt hast. Die Dinger funtionieren nicht auf metallischem Untergrund, da die magnetische Wirkung der Homematic-Einheit erheblich geschwächt wird. Habe das auch lange an meinem Garagentor aus Metall versucht.
Da helfen nur Distanzstücke, entweder die, die mitgeliefert werden, oder welche aus Holz/Kunststoff selber machen. Bei mir reicht eine Dicke von 1cm.
Oder neue Fenster einbauen... ;)
Das Problem hat sich jetzt auch erledigt.
Ich habe vor ca. 3 Wochen den Rechner getauscht. Dabei sind die tty's von beiden CUL's vertauscht worden ( andere Reihenfolge der USB-Ports )
Somit war CUL433 für 868 MHz und CUL868 für 433 Mhz zuständig. Wundert mich dass die Intertechno Geräte ohne Probleme funktionierten.
Nach dem Berichtigen der IODevice läuft jetzt selbst der Fensterkontakt ohne Probleme.
Nach der Bemerkung vom fhem-hm-knecht hatte ich mir dieses Thema noch einmal angeschaut, da ich am 868 Mhz CUL die 15cm Antenne habe
und ich mir die schlechten Werte nicht erklären konnte.
Manchmal sieht man den Wald vor lauter Bäumen nicht :-\
Dann geht's jetzt mit der Aufrüstung von Homematic Komponenten weiter. ;)
Gruss
André
Hallo allerseits,
ich suche eine Möglichkeit bei dem Bewegungsmelder die Zeitintervalle zu verkürzen.
Zur Zeit löst meiner nur alle 4 min aus.
Kann man dies vlt. auf 1min reduzieren?
Vielen Dank
Gruß
Wolfgang
Hallo Wolfgang,
Du musst das minInterval entsprechend anpassen, siehe:
siehe http://www.fhemwiki.de/wiki/HM-Sec-MDIR_Funk-Bewegungsmelder_innen
Gruß, Marc
Hallo Marc,
danke für die Info. Ich habe es probiert, komme ich nur so weit, das im Register
R-minInterval set_60
steht.
Gruß
Wolfgang
du musst den anlern knopf kurz drücken nach dem regSet. danach noch mal ein getConfig. dann solltest du den neu gesetzten wert sehen.
gruss
andre
Hi,
noch ein kleiner Hinweis (mögen nicht alle...). Normal sollte autoReadReg = 4 gesetzt sein. Besonders bei Config devices ist dies hilfreich und unproblematisch. Es wird nur nach "anlernen" ausgeführt, also nicht nach neustart von FHEM. Wenn du nun ein Register änderst wird sofort automatisch gelesen.
getConfig sollte manuell nicht notwendig sein. Wenn du es aber auslöst wird das automatische Lesen gelöscht.
Gruss Martin
Zitat von: justme1968 am 18 November 2013, 23:38:04
du musst den anlern knopf kurz drücken nach dem regSet. danach noch mal ein getConfig. dann solltest du den neu gesetzten wert sehen.
gruss
andre
Hallo Marc,
dein Tipp hat scheinbar geholfen. Danke.
@ Martin: Der BM steht auf autoReadReg 4_reqStatus.
Hallo, ich habe noch ne Frage zu Bewegungsmelder.
Auch mit R_minIntervall = 60 kommt es noch vor, dass das Licht ausgeht und es ggf. dann 60 sec dauert bis der Bewegungsmelder das Licht wieder einschaltet.
Kann man dies vermeiden ?
define EG_WC_Licht notify BM03_EG_WC:motion.* {\
if (Value("Lichtsensor1") eq "dunkel") {\
fhem "set UPS01_EG_WC on-for-timer 120";;\
}}
wenn das minInterval rum ist wird die nächste bewegung sofort gemeldet sobald sie erkannt wurde.
das minInterval spielt dann erst mal keine rolle mehr bis wieder motion gesendet wurde.
du kannst versuchen captInInterval zu setzen dann wird auch wärend der pause weiter gemeldet aber das geht zu lasten der batterie oder du setzt die einschalt zeit länger. dann ist der zeitraum länger bevor das licht bei nicht bewegen aus geht.
gruss
andre
... ist zwar schon ein alter Thread, aber da ich seit gestern auch zwei von den Dingern habe und genau die gleichen Probleme auftreten, macht es wohl Sinn ?!
Ich habe jetzt den Thread mehrfach gelesen und alles, was hier so an Hints vorgegeben war, ausgetestet. Auch habe ich beide Teile gestern auf Factory zurück gesetzt, mehrfach neu angelernt (mit und ohne Löschen der entsprechenden Konfig in FHEM). Exemplarisch eine Konfig als Beispiel, wie sie immer beim erneuten Anlernen generiert wird (Namen natürlich bereits geändert):
define OD_IR_GA CUL_HM 448306
attr OD_IR_GA IODev SCC2
attr OD_IR_GA actCycle 000:10
attr OD_IR_GA actStatus alive
attr OD_IR_GA autoReadReg 4_reqStatus
attr OD_IR_GA expert 2_raw
attr OD_IR_GA firmware 1.6
attr OD_IR_GA model HM-Sen-MDIR-O
attr OD_IR_GA peerIDs 00000000,
attr OD_IR_GA room OD.Sensoren
attr OD_IR_GA serialNr NEQ0119307
attr OD_IR_GA subType motionDetectorDas Setzen der "R-minInterval" auf 60 hat bei beiden funktioniert. Auch werden Bewegungen bei beiden gemeldet, ebenso wie die aktuelle Helligkeit. Aber ....
- "brightness" wird nur aktualisiert, wenn Bewegung erkannt wird, unabhängig davon, ob es dunkler oder heller wird
- Beide Sensoren werden in FHEM nach ca. 10 Minuten (geschätzt) auf "dead" gesetzt
- Bei einem Sensor stehen 7 Nachrichten zur Verabeitung an (protCmdPend - 7 CMDs_pending), wobei auch kein Tastendruck, Reset o.ä. hilft.
- Obwohl beide Sensoren identische Konfig haben und mit beiden Sensoren immer jeweils das Gleiche angestellt wurde, zeigen die sich auf der FHEM-GUI unterschiedlich in Bezug auf die Readings
Gerade den letzte Punkt verstehe ich nicht so ganz; die müssen doch identisch sein? Der eine Sensor hat folgende Readings, welche dem anderen Sensor fehlen:
- R-OD_IR_HT_chn-01-peerNeedsBurst - off
- RegL_00. - 02:00 0A:00 0B:00 0C:00 00:00
- RegL_01. - 01:12 02:72 08:00 22:00 00:00
- RegL_04.OD_IR_HT_chn-01 - 01:00 00:00
Für mich vordringliche Frage ist also, wie ich das hinbekomme, das zum einen die Helligkeitswerte unabhängig von erkannter Bewegung ausgelesen werden können, wie man den DEAD- Status weg bekommt und wie man beide Sensoren in einen identischen Zustand bekommt.
Hinzuzufügen wäre ggf. noch, das beide Sensoren derzeit nebeneinander im Büro stehen und auf einen Stackable Busware arbeiten (RPi2). Später wird einer auf einen HM-LAN wirken müssen, der andere weiterhin auf den Stackable resp. auf einen weiteren HM-LAN. Eine direkte Verbindung der Sensoren zu den Aktoren ist baulich nicht möglich. Im Weiteren sollen später die Helligkeitswerte beider Sensoren zusammengefasst werden und als gleitender Mittelwert zur Verfügung stehen (als Funktion o.ä.). Gerade deshalb ist es natürlich wichtig, das diese Werte auch zuverlässig unabhängig von Bewegungen geliefert werden.
mir scheint, dass du sie untereinander gepeert hast, aber nicht mit fhem gepairt.
schau dir mal das wiki pairen genau an.
... ;D ... nene, die sind schon beide korrekt in FHEM angekommen und werden ja auch einzeln in FHEM angezeigt; kann man die überhaupt miteinander verheiraten? SInd doch beides Sensoren ...
Ich habe auch gerade mal die LedOnTime bei einem gesetzt, damit ich zumindest erkenne, wenn er mich sieht. Das hat auch geklappt...
OT: LedOnTime lässt sich ja von 0 - 1.275s setzen. Aber da ist ja nicht jeder beliebige Wert möglich. Wie bekommt man die überhaupt gültige Werte heraus?
Zitatnene, die sind schon beide korrekt in FHEM angekommen und werden ja auch einzeln in FHEM angezeigt;
anzeigen in fhem hat nichts mit pairen zu tun. und solange in deinen readings pairedto 0x000000 steht, weiss ich, dass du nichts vom pairen verstanden hast.
Zitatkann man die überhaupt miteinander verheiraten? SInd doch beides Sensoren ...
ich weiss nicht ob
man das kann, du hast es aber laut reading peerlist geschafft.
... Zitat aus dem WiKi:
ZitatPairing nicht abgeschlossen (bei den Readings "PairedTo" bzw. "R-pairCentral" steht der Wert set_0x1A2B3C). Das Pairing ist erst dann erfolgreich abgeschlossen, wenn das set_ fehlt, also nur noch (beispielhaft) "0x1A2B3C" steht.
Also ein "SET_" sehe ich hier nicht. dennoch gebe ich Dir bezgl. der 0x0... recht; ist mir nicht wirklich aufgefallen. Allerdings wundert es mich, das ich gezielt Dinge wie LedOnTime u.ä. setzen kann.
Zitatich weiss nicht ob man das kann, du hast es aber laut reading peerlist geschafft.
Ist nicht möglich; wie auch, ausser natürlich, ich hätte gerade meinen Zauberstab geschwungen und es möglich gemacht ::)
Zitatdass du nichts vom pairen verstanden hast.
Es wäre nett, wenn Du nicht immer gleich so beleidigend unter die Gürtellinie zielen würdest. Wenn ich denn tatsächlich so dämlich wäre, wie Du es mir immer so gerne unterstellen willst, würden die reichlich vorhandenen HM- Geräte hier ja alle nicht funktionieren... Deine Art- und Weise ist in keinster Weise hilfreich ...