Ich habe mir eine Handvoll dieser schnuckeligen Aqara Bewegungsmelder gekauft, und sie über deConz / HUEDevice in FHEM eingebunden. Allerdings verstehe ich ein paar Dinge noch nicht ganz, vielleicht ist jemand schon weiter damit und kann mich erleuchten, ohne dass ich erst tief im Code der entsprechenden Module graben muss.
1. Wenn ich dem HUEDevice einen zweiten nummerischen Parameter mitgebe, also etwa
Zitatdefine <NAME> HUEDevice sensor 3 5 IODev=ZigBridge
- heißt das dann, dass wirklich alle 5 Sekunden ein HTTP Get auf das deConz-Device ausgelöst wird?
2. Was hat es mit der ominösen Totzeit der Aqara auf sich? An einer Stelle im Netz lese ich, dass man unbedingt einen Hardware-Hack (=Lötbrücke) einbauen muss, damit die Sensoren alle 5 Sekunden statt nur alle 60 Sekunden wieder zur Detektion einer neuen Bewegung bereit sind. An anderer Stelle ist zu lesen: Nein, er habe bei sich nur einen Sensor modifiziert, und seitdem seien alle nach 5 Sekunden Totzeit wieder einsatzbereit. Was stimmt den nun? Bei meinen Sensoren ist das noch etwas rätselhaft: Einige sind schnell wieder da, bei anderen dauert es wirklich eine Minute. Das würde darauf hindeuten, dass das irgendwie konfigurierbar ist, eine Dokumentation dazu habe ich aber noch nicht gefunden.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 18 Oktober 2020, 10:50:14
Ich habe mir eine Handvoll dieser schnuckeligen Aqara Bewegungsmelder gekauft, und sie über deConz / HUEDevice in FHEM eingebunden. Allerdings verstehe ich ein paar Dinge noch nicht ganz, vielleicht ist jemand schon weiter damit und kann mich erleuchten, ohne dass ich erst tief im Code der entsprechenden Module graben muss.
1. Wenn ich dem HUEDevice einen zweiten nummerischen Parameter mitgebe, also etwa- heißt das dann, dass wirklich alle 5 Sekunden ein HTTP Get auf das deConz-Device ausgelöst wird?
2. Was hat es mit der ominösen Totzeit der Aqara auf sich? An einer Stelle im Netz lese ich, dass man unbedingt einen Hardware-Hack (=Lötbrücke) einbauen muss, damit die Sensoren alle 5 Sekunden statt nur alle 60 Sekunden wieder zur Detektion einer neuen Bewegung bereit sind. An anderer Stelle ist zu lesen: Nein, er habe bei sich nur einen Sensor modifiziert, und seitdem seien alle nach 5 Sekunden Totzeit wieder einsatzbereit. Was stimmt den nun? Bei meinen Sensoren ist das noch etwas rätselhaft: Einige sind schnell wieder da, bei anderen dauert es wirklich eine Minute. Das würde darauf hindeuten, dass das irgendwie konfigurierbar ist, eine Dokumentation dazu habe ich aber noch nicht gefunden.
LG
pah
zu 2.
standart sind in der tat 60 sekunden zwischen den detektionen, da gibt es auch nichts zu konfugurieren. Nur durch eben diese angesprochene Lötbrücke lässt sich das intervall auf 5 sekunden verkürzen.
ich gebe das jetzt aus der erinnerung wieder, finde leider entsprechende seite nicht mehr.
Im Konfigurationsmodus des sensors detektiert er alle 5 sekunden . diesen Modus behällt er auch noch eine ganze zeit nach einem pairing bei - ich meine mich erinnern zu können 1 Stunde ( kann aber deutlich auch länger gewesen sein ) . Nach dieser Zeit verlässt er diesen moduns und detektiert nur noch alle 60 sekunden. durch die Lötbrücke wird er dauerhaft in diesen "konfigurationsmodus" gebracht.
ggf. komme die gefühlten unterschiede bei dir daher .
gruss Thomas
edit: die verkürzten Zeiten sind dann nur in den 'modifizierten' sensoren aktiv.
ich habe 12 dieser sensoren im einsatz, einen Teil modifiziert, den anderen Teil nicht ( je nach einsatzort und somitz bedarf an schnellen meldezeiten )
Zitatich meine mich erinnern zu können 1 Stunde
Sauber, danke, das ist die Erklärung. Dann werde ich heute nachmittag den Lötkolben anwerfen.
Wie ist das mit dem http get? Wenn das nämlich zuträfe, würde ich die Dinger lieber über MQTT anbinden.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 18 Oktober 2020, 11:42:27
Sauber, danke, das ist die Erklärung. Dann werde ich heute nachmittag den Lötkolben anwerfen.
Wie ist das mit dem http get? Wenn das nämlich zuträfe, würde ich die Dinger lieber über MQTT anbinden.
LG
pah
dazu kann ich dir nichts sagen , ich habe sie über MQTT eingebunden
gruss Thomas
Ich habe das ganz anders im Erinnerung:
Die Lötbrücke ist nicht für die Bewegungsdetektierung, sondern für das Lightlevel/Lux-Intervall.
Bewegungen werden, meiner Meinung nach, immer direkt und unverzüglich weitergegeben.
Ich habe noch nie eine Lötbrucke setzen müssen.
@pah:
Sollte der zweite Wert-Parameter im Define nicht überflüssig sein?
Du hast doch deConz und hier wird gepusht.
https://www.youtube.com/watch?v=gbJ2xS2vp7o (https://www.youtube.com/watch?v=gbJ2xS2vp7o)
bei 4.18 wird es erklärt , es ist nicht nur eine stunde, sondern 24.
gruss thomas
Äh - nö. Beide falsch.
Die Lötbrücke hat nichts mit der Lichtpegelerfassung zu tun - und in der Tat ist nach einer Weile OHNE Lötbrücke eine Totzeit von einer Minute bei der Bewegungserfassung zu beobachten.
LG
pah
Hi,
ich habe 2 Sensoren und beide mit der Lötbrucke und dem FHEM Befehl zum Setzen der Config modifiziert, rennt 1a wie es soll.
Und Deconz macht doch einen Push, keine Notwendigkeit ,das in Intervallen also selbst anzufragen.
Das Config / Doif dazu war (geht sicher auch anders, aber rennt so gut für mich)
defmod Cron.SetPIRConfig DOIF ## Alle 5 Minuten ausführen\
## Helfer für Aqara Motion Sensor Mod \
([+300]) \
(\
## Setzt in deCONZ das Delay für die Meldung "keine Bewegung" auf 10 Sekunden runter\
## ist nötig da deCONZ es nach einen Neustart vergisst!\
set modelid=lumi.sensor_motion.aq2:FILTER=type=ZHAPresence duration 10\
)
attr Cron.SetPIRConfig do always
Ronny
Was ist das den für ein Setter duration?
Den habe ich gar nicht.
Könntest du mir bitte ein List deines Melder geben?
Hast du duration in configList gesetzt?
ZitatAttributes:
IODev ZigBridge
configList /duration (.*)/:{"duration":"$1"}
devStateIcon nomotion:motion_detector@black motion:people_sensor@crimson
event-on-change-reading state,battery,batteryPercent,reachable,temperature
group motionDetector
model lumi.sensor_motion.aq2
room Alarm
LG
pah
Das ist super. Vielen Dank.
Das mit der configList findet man in keiner Doku.
Ich kann beide Schritte hier als funktionstüchtig bestätigen.
Ein Aqara mit Lötbrücke und einen über das Setzen der Duration in FHEM auf die 5 Sekunden Totzeit gebracht.
set FHEMDEVICE configsensor SENSORNUMMER { "duration": 5 }
Beide sind jedoch noch einmal umgebaut in ein schöneres Gehäuse, um sich besser in das Wohnliche zu integrieren.
(Giraschalterprogramm, speziell Blindabdeckung mit ausgefräster Bohrung zum Einsetzen der PIR Linse)
Zitat von: Cupe95 am 02 November 2020, 12:38:28
Beide sind jedoch noch einmal umgebaut in ein schöneres Gehäuse, um sich besser in das Wohnliche zu integrieren.
(Giraschalterprogramm, speziell Blindabdeckung mit ausgefräster Bohrung zum Einsetzen der PIR Linse)
Kannst du bitte ein paar Fotos davon hier teilen?
Hm. Dauerhaft auf 5 Sekunden Totzeit ohne Lötbrücke? Würde mich aber sehr wundern.
LG
pah
@cupe95 hat du den ohne Lötbrucke mal länger als 24 laufen gehabt? In den ersten 24h verhalten sich beide gleich.
Fotos kümmere ich mich nachher mal drum.
Ja seit knapp einem Monat ohne Lötbrücke im 5 Sekunden Betrieb :)
Eingebunden über einen Conbee2, weiß nicht ob das eventuell relevant ist.
Hab dann doch mal fix die Fotos gemacht.
Bei den Materialien habe ich verwendet:
1 x Gira System 55 Reinweiß Blindabdeckung mit Rahmen und Trägerring.
1 x Innenleben des Aqara Motion Sensors
1 x PIR Linse
1 x CR2032 Batterie plus Halterung.
In die Blindabdeckung habe ich mit dem Stufenbohrer die "Ausfräsung" bzw. das Loch im Durchmesser der PIR-Linse ausgebohrt. In dieses Loch die Linse eingeklebt und auf diese dann den Aqara Sensor verklebt. Dort an die Lötstellen die Halterung der Knopfzelle angelötet. Sieht zwar alles sehr wüst aus, aber es funktioniert seit knapp einem Monat ohne Probleme. Dazu ist noch zu sagen das im Original eine Cr2450 ausgeliefert wird. Bisher konnte ich (hab noch einen Originalen) keine Unterschiede der Batterie feststellen, da beide ja mit in FHEM den Batteriewert in % liefern. Bewegung wird im 3 Meter Radius erkannt, wobei der Sensor in einer Höhe von knapp über 2 Metern hängt.
Ich hoffe man kann das erkennen :-\
Siehe vorige Seite.
LG
pah
Gibt's schon Resultate ob das bei mehr als einem User ohne Lötbrücke funktioniert?
Hallo,
ich habe 8 Stk. im Einsatz und das seit ca. 6 Monaten.
Fazit: Es hat nicht nur mit den Sensoren zu tun, sondern auch mit der gerade "aktuellen" bzw. "installierten" Deconz/Phoscon Kombination. Meine Sensoren reagieren "fast" immer, manchmal benötigen sie einen "Stups" (=Drücken des Knopfes an der Seite). Die letzten beiden Versionen von Phoscon war ein (in meinen Augen) Zustand, der witzlos war. Die Sensoren sind tw. "eingefroren" (auf Status: Bewegung erkannt, "in ein paar Sekunden") bzw. waren ganz weg.
Mit der aktuellen 2.05.88 und Firmware 26660700 geht es wieder einigermaßen rund. Sie lassen sich auch wieder anlernen.
Was hilft (bis jetzt) ist das:
([+300])
(set gw.deconz configsensor 3 { "duration": 5 },
set gw.deconz configsensor 9 { "duration": 5 },
set gw.deconz configsensor 34 { "duration": 5 },
set gw.deconz configsensor 56 { "duration": 5 },
set gw.deconz configsensor 36 { "duration": 5 },
set gw.deconz configsensor 38 { "duration": 5 }
set gw.deconz configsensor 68 { "duration": 5 }
)
Das lästige ist halt, dass man bei jedem neuen Sensor dran denken muss, bzw. wenn phoscon den Sensor "vergißt" (was auch gelegentlich vorkommt) und man ihn neu anlernt, er halt eine neue SensorID (Nummer bekommt).
Ich suche schon die längste Zeit "echte" Sensoren unter Zigbee, die einen kurzen Intervall in der Erkennung haben, und unter Phoscon einwandfrei funktionieren. Kurz heißt bei mir 5 sec., da ich sie auch für Durchgänge verwende, die nicht 60 sec hinterher leuchten soll(t)en.
lg aus Wien,
Shamal
Zitat von: shamal2008 am 16 November 2020, 20:42:22
Das lästige ist halt, dass man bei jedem neuen Sensor dran denken muss, bzw. wenn phoscon den Sensor "vergißt" (was auch gelegentlich vorkommt) und man ihn neu anlernt, er halt eine neue SensorID (Nummer bekommt).
Kannst du da nicht über devspec und die Modell-ID (modelid=lumi.sensor_motion.aq2) gehen?
bei mir läuft das
defmod di_SetPIRConfig_duration DOIF ## Alle 5 Minuten ausführen\
## Helfer für Aqara Motion Sensor Mod \
([+300]) \
(attr .._.._MS configList /duration (.*)/:{"duration":"$1"})\
(\
## Setzt in deCONZ das Delay für die Meldung "keine Bewegung" auf 5 Sekunden runter\
## ist nötig da deCONZ es nach einen Neustart vergisst!\
set modelid=lumi.sensor_motion.*:FILTER=type=ZHAPresence duration 5\
)
attr di_SetPIRConfig_duration do always
Zitat von: shamal2008 am 16 November 2020, 20:42:22
Fazit: Es hat nicht nur mit den Sensoren zu tun, sondern auch mit der gerade "aktuellen" bzw. "installierten" Deconz/Phoscon Kombination. Meine Sensoren reagieren "fast" immer, manchmal benötigen sie einen "Stups" (=Drücken des Knopfes an der Seite). Die letzten beiden Versionen von Phoscon war ein (in meinen Augen) Zustand, der witzlos war. Die Sensoren sind tw. "eingefroren" (auf Status: Bewegung erkannt, "in ein paar Sekunden") bzw. waren ganz weg.
Ich habe 2 Melder im Einsatz mit Lötbrücke und diese laufen seit einem Jahr ohne Probleme. Egal welche Deconz / Firmware Version. (Ich mache regelmäßig Updates)
Hallo,
mein Aqara Bewegungsmelder läuft ohne Lötbrücke über den Xiaomi Hub ohne Probleme. Mit Zigbee2Mqtt hatte ich nur Probleme. Deshalb wieder zurück zum Hub.
Gruß
Jürgen K.
Es geht doch hier vorwiegend nur um die "Totzeit" und die damit verbundene Umgehungslösung, oder?
Ich musste in meinen Logs schon ganz genau hinschauen, um das zu erkennen.
Scheinbar habe ich wirklich ca. 50-60 Sekunden Pause zwischen dem letzten noMotion und dem erneuten motion.
Ich weißt es nicht, aber ich tippe darauf, dass stets jemand im Raum war und damit hat sich das "Problem" bestätigt.
Nur ist es bei mir kein "Problem", da ich primär die erste Bewegung zur Alarmauslösung erkennen will und sekundär das Licht darüber schalte.
Die Lichtschaltung nutzt einen on-for-timer und dieser ist länger als die "Totzeit". Aus diesem Grund habe ich nie etwas bemerkt.
Ich könnte die Lötbrücke mal setzen, aber eigentlich will ich das nicht. Denn ich vermute schon eine Veränderung der Batterielaufzeit und ich habe Sorgen bzgl. zu vieler Events. Die Xiaomi Lichtsensoren fluten mal System nämlich mit fünfsekündlichen Events. Das muss nicht sein.
Ich denke, dass es immer auf den Anwendungsfall ankommt. Mir reicht es ohne "Motion Sensor Hack".
ZitatDenn ich vermute schon eine Veränderung der Batterielaufzeit
Hallo,
hab die Brücke drin seit dem Abend als es in dem Video erwähnt wurde, selbst nutz ich zigbee2mqtt.
So verhält sich die Spannung bei mir (siehe comment und Reading des List), der Standort des BM ist im Bad.
Internals:
CID zigbee_0x00158d00032c6d54
DEF zigbee_0x00158d00032c6d54
DEVICETOPIC MQTT2_zigbee_0x00158d00032c6d54
FUUID 5cdf1c6c-f33f-78f5-752b-e2370dd1b7415790
IODev MQTT2_Server
LASTInputDev MQTT2_Server
MQTT2_Server_MSGCNT 6
MQTT2_Server_TIME 2020-11-17 12:53:35
MSGCNT 6
NAME MQTT2_zigbee_0x00158d00032c6d54
NR 132
STATE 1:false
Batterie: 86
TYPE MQTT2_DEVICE
READINGS:
2020-06-26 14:09:28 associatedWith MQTT2_zigbee_Bridge
2020-11-17 12:53:35 battery 86
2020-11-17 12:53:35 linkquality 34
2020-11-17 12:53:35 occupancy false
2020-11-17 12:53:35 voltage 2975
Attributes:
IODev MQTT2_Server
comment voltage 3005 2020-03-05 12:21:47
voltage 2975 2020-04-16 19:40:56
devStateIcon 1.true:message_presence@red 1.false:message_presence@green
imageLink /fhem/deviceimages/mqtt2/RTCGQ01LM.jpg
model zigbee2mqtt_Human_Motion_Sensor
readingList zigbee2mqtt/0x00158d00032c6d54:.* { json2nameValue($EVENT) }
room MQTT2_DEVICE
stateFormat 1:occupancy
Batterie: batteryGruß
Thomas
Zitat von: FunkOdyssey am 17 November 2020, 11:25:03
Es geht doch hier vorwiegend nur um die "Totzeit" und die damit verbundene Umgehungslösung, oder?
Ja, geht es. Im Default melden die Sensoren erst nach 120 Sekunden erneut Motion (Retrigger). (Für mich ist das no-motion uninteressant)
Mit der Lötbrücke bekomme ich alle 5 Sekunden ein motion Event wenn jemand vor dem Sensor ist. Wenn da mal eine Bewegung nicht erfasst wird ist es egal, spätestens nach 10 Sekunden kommt dann wieder motion.
Zitat von: FunkOdyssey am 17 November 2020, 11:25:03
ich vermute schon eine Veränderung der Batterielaufzeit
Mein Sensor im Flur, hat seit Mai 2% Batterie verbraucht. Da laufen wir +15 mal am Tag dran vorbei. Eher öfters. Von daher keine Problem.
Hallo zusammen,
seit neustem schmeißt das Doif hier Fehler:
## Alle 5 Minuten ausführen
## Helfer für Aqara Motion Sensor Mod
([+300])
(attr .._.._MS configList /duration (.*)/:{"duration":"$1"})
(
## Setzt in deCONZ das Delay für die Meldung "keine Bewegung" auf 5 Sekunden runter
## ist nötig da deCONZ es nach einen Neustart vergisst!
set modelid=lumi.sensor_motion.*:FILTER=type=ZHAPresence duration 5
)DOELSE ()
invalid value, 5, for parameter duration
Habt ihr das auch?
ich nutze einen Aqara-Sensor um in einem kleinen Lager-Raum Licht kurz an und auszuschalten. Das lief ohne die Lötbrücke nicht so dolle. Wenn man innerhalb kurzer Zeit zweimal in die Kammer gegangen ist war es oft so, dass das Licht ein paar Sekunden gebraucht hat um wieder an zu gehen.
Mit der Lötbrücke klappt das jetzt astrein! Aber Achtung: Man muss auch die Zeit in der Config des Sensors ändern. Über FHEM hab ich das wie folgt gemacht:
set DECONZ configsensor 10 { "duration": 20 }
wobei 10 durch die bei euch relevante Senor-ID zu tauschen ist und 20 die duration in sek für erneute Erkennung angibt. Bei 5 hat der Sensor permanent Motion und NoMotion gemeldet aber bei 10 bzw. 20 läuft es rund.
Zitat von: slor am 04 November 2021, 16:05:11
Hallo zusammen,
seit neustem schmeißt das Doif hier Fehler:
## Alle 5 Minuten ausführen
## Helfer für Aqara Motion Sensor Mod
([+300])
(attr .._.._MS configList /duration (.*)/:{"duration":"$1"})
(
## Setzt in deCONZ das Delay für die Meldung "keine Bewegung" auf 5 Sekunden runter
## ist nötig da deCONZ es nach einen Neustart vergisst!
set modelid=lumi.sensor_motion.*:FILTER=type=ZHAPresence duration 5
)DOELSE ()
invalid value, 5, for parameter duration
Habt ihr das auch?
Würde mich auch interessieren :-)
Zitat von: slor am 04 November 2021, 16:05:11
Hallo zusammen,
seit neustem schmeißt das Doif hier Fehler:
## Alle 5 Minuten ausführen
## Helfer für Aqara Motion Sensor Mod
([+300])
(attr .._.._MS configList /duration (.*)/:{"duration":"$1"})
(
## Setzt in deCONZ das Delay für die Meldung "keine Bewegung" auf 5 Sekunden runter
## ist nötig da deCONZ es nach einen Neustart vergisst!
set modelid=lumi.sensor_motion.*:FILTER=type=ZHAPresence duration 5
)DOELSE ()
invalid value, 5, for parameter duration
Habt ihr das auch?
Ich habe das gleiche Problem nun auch. Gab es ein Update von FHEM oder Deconz das dies verhindert?
Hallo,
für alle die noch immer den folgenden Fehler haben:
invalid value, 5, for parameter duration
Einfach die Hochkomma um das $1 weglassen (siehe https://forum.fhem.de/index.php/topic,125416.msg1200491.html#msg1200491 (https://forum.fhem.de/index.php/topic,125416.msg1200491.html#msg1200491)).
lg, Gerhard