Verständnisfrage zu Aqara Bewegungsmeldern

Begonnen von Prof. Dr. Peter Henning, 18 Oktober 2020, 10:50:14

Vorheriges Thema - Nächstes Thema

Prof. Dr. Peter Henning

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


Der_Tom

#1
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 )





Prof. Dr. Peter Henning

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




Der_Tom

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

FunkOdyssey

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.

Der_Tom

https://www.youtube.com/watch?v=gbJ2xS2vp7o

bei 4.18 wird es erklärt , es ist nicht nur eine stunde, sondern 24.

gruss thomas

Prof. Dr. Peter Henning

#6
Ä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

rcmcronny

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

FunkOdyssey

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?

Prof. Dr. Peter Henning

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

FunkOdyssey

Das ist super. Vielen Dank.
Das mit der configList findet man in keiner Doku.

Cupe95

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)

slor

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?
Fhem auf Raspberry Pi 4
CCU3 mit RaspberryMatic mit HMCCU an FHEM
HMCCU, Telegram, Conbee2 und Hue/Tradfri/Osram Lampen AQARA Sensoren, HomeConnect

Prof. Dr. Peter Henning

#13
Hm. Dauerhaft auf 5 Sekunden Totzeit ohne Lötbrücke? Würde mich aber sehr wundern.

LG

pah

slor

@cupe95 hat du den ohne Lötbrucke mal länger als 24 laufen gehabt? In den ersten 24h verhalten sich beide gleich.
Fhem auf Raspberry Pi 4
CCU3 mit RaspberryMatic mit HMCCU an FHEM
HMCCU, Telegram, Conbee2 und Hue/Tradfri/Osram Lampen AQARA Sensoren, HomeConnect

Cupe95

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.

Cupe95

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 :-\

Prof. Dr. Peter Henning


slor

Gibt's schon Resultate ob das bei mehr als einem User ohne Lötbrücke funktioniert?
Fhem auf Raspberry Pi 4
CCU3 mit RaspberryMatic mit HMCCU an FHEM
HMCCU, Telegram, Conbee2 und Hue/Tradfri/Osram Lampen AQARA Sensoren, HomeConnect

shamal2008

#19
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
FHEM auf RasPiI 3+, MapleCUL 868+433MhZ, MAX! via CUL, LD686 LED-Controller, GHoma Plugins,, Shelly, ConbeeII + IKEA + Xiaomi, div. Infodienste & Google Assistant via FHEM;

FunkOdyssey

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?




slor

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
Fhem auf Raspberry Pi 4
CCU3 mit RaspberryMatic mit HMCCU an FHEM
HMCCU, Telegram, Conbee2 und Hue/Tradfri/Osram Lampen AQARA Sensoren, HomeConnect

slor

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)
Fhem auf Raspberry Pi 4
CCU3 mit RaspberryMatic mit HMCCU an FHEM
HMCCU, Telegram, Conbee2 und Hue/Tradfri/Osram Lampen AQARA Sensoren, HomeConnect

juergen012

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.
Fhem unter Proxmox

FunkOdyssey

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".

TomLee

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: battery


Gruß

Thomas

slor

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.
Fhem auf Raspberry Pi 4
CCU3 mit RaspberryMatic mit HMCCU an FHEM
HMCCU, Telegram, Conbee2 und Hue/Tradfri/Osram Lampen AQARA Sensoren, HomeConnect

slor

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?


Fhem auf Raspberry Pi 4
CCU3 mit RaspberryMatic mit HMCCU an FHEM
HMCCU, Telegram, Conbee2 und Hue/Tradfri/Osram Lampen AQARA Sensoren, HomeConnect

StephanFHEM

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.

synci

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 :-)

chris199

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?

gestein

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).

lg, Gerhard