Aqara Presence Sensor FP1 (RTCZCGQ11LM)

[Verteo]

Device

• Product name: Aqara Presence Sensor FP1
• Manufacturer: aqara
• Model identifier: lumi.motion.ac01
• Device type :
  • Sensor

Screenshots

Basic

Identify

Other clusters that are not mentioned above

Additional Information:

https://www.zigbee2mqtt.io/devices/RTCZCGQ11LM.html

[Mimiix]

I am not sure of it is paired correctly. Can you try to re pair it and see if more clusters show up.

[Verteo]

I'm not sure either. I tried repairing it multiple times and also I tried the method for missing data on Xiaomi devices and nothing really changed except a time cluster sometimes appears and disappers on reading simple descriptors

Is there anything else I can try?

I captured a log of the pairing, maybe it can help.

click to expand log

``` 19:11:52:881 APS-DATA.indication srcAddr: 0xca45, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0xFCC0, lqi: 255, rssi: -64 19:11:52:882 asdu: 180a0afc001000 19:11:52:883 APS-DATA.indication from unknown node 0x54EF441000471A48 19:11:53:082 poll node 00:17:88:01:09:c7:26:e5-0b 19:11:53:083 Poll light node Lightbar 1 19:11:53:274 Master: read param with arg 0x19 19:11:53:304 Device TTL 2800 s flags: 0x7 19:11:53:764 rule event /config/localtime: 19:11:52.763 -> 19:11:53.763 (1000ms) 19:11:53:782 APS-DATA.request id: 62, addrmode: 0x03, addr: 0x0017880109c72717, profile: 0x0000, cluster: 0x0031, ep: 0x00 -> 0x00 queue: 0 len: 2 tx.options 0x04 19:11:53:784 asdu (length: 2): 1e06 19:11:53:832 APS-DATA.confirm id: 62, status: 0x00 SUCCESS 19:11:53:834 APS-DATA.confirm request id: 62 -> confirmed, timeout 0 19:11:53:849 APS-DATA.indication srcAddr: 0x4749, srcEp: 0x00 dstAddrMode: 2, profile: 0x0000, cluster: 0x8031, lqi: 255, rssi: -63 19:11:53:850 asdu: 1e00060600 19:11:53:851 APS-DATA.indication request id: 62 -> finished 19:11:53:852 APS-DATA.request id: 62 erase from queue 19:11:53:852 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 8, node: 0x4749 19:11:53:921 poll node 00:17:88:01:0b:80:5d:01-0b 19:11:53:923 Poll light node Filament WA 19:11:54:263 Daylight now: solarNoon, status: 170, daylight: 1, dark: 0 19:11:54:763 poll node ec:1b:bd:ff:fe:9e:45:93-01 19:11:54:764 Poll light node On/Off plug-in unit 2 19:11:54:775 rule event /config/localtime: 19:11:53.763 -> 19:11:54.763 (1000ms) 19:11:55:653 poll node 00:17:88:01:09:e8:3c:9c-0b 19:11:55:654 Poll light node Hue Iris 19:11:55:764 rule event /config/localtime: 19:11:54.763 -> 19:11:55.763 (1000ms) 19:11:56:466 poll node 00:17:88:01:09:c7:27:17-0b 19:11:56:467 Poll light node Lightbar 2 19:11:56:659 APS-DATA.request id: 75, addrmode: 0x03, addr: 0x0017880109c726e5, profile: 0x0000, cluster: 0x0031, ep: 0x00 -> 0x00 queue: 0 len: 2 tx.options 0x04 19:11:56:660 asdu (length: 2): 1f00 19:11:56:712 APS-DATA.confirm id: 75, status: 0x00 SUCCESS 19:11:56:713 APS-DATA.confirm request id: 75 -> confirmed, timeout 0 19:11:56:754 APS-DATA.indication srcAddr: 0x7637, srcEp: 0x00 dstAddrMode: 2, profile: 0x0000, cluster: 0x8031, lqi: 255, rssi: -44 19:11:56:755 asdu: 1f000500038d1f07ffff2e21008d1f07ffff2e21000000240200ff8d1f07ffff2e21009c3ce80901881700442625020fe08d1f07ffff2e21001727c70901881700494725020fdc 19:11:56:756 APS-DATA.indication request id: 75 -> finished 19:11:56:757 APS-DATA.request id: 75 erase from queue 19:11:56:779 rule event /config/localtime: 19:11:55.763 -> 19:11:56.778 (1015ms) 19:11:57:306 poll node 00:17:88:01:09:c7:26:e5-0b 19:11:57:307 Poll light node Lightbar 1 19:11:57:765 rule event /config/localtime: 19:11:56.778 -> 19:11:57.763 (985ms) 19:11:58:188 poll node 00:17:88:01:0b:80:5d:01-0b 19:11:58:189 Poll light node Filament WA 19:11:58:764 rule event /config/localtime: 19:11:57.763 -> 19:11:58.763 (1000ms) 19:11:59:080 poll node ec:1b:bd:ff:fe:9e:45:93-01 19:11:59:081 Poll light node On/Off plug-in unit 2 19:11:59:539 APS-DATA.request id: 89, addrmode: 0x03, addr: 0x0017880109c726e5, profile: 0x0000, cluster: 0x0031, ep: 0x00 -> 0x00 queue: 0 len: 2 tx.options 0x04 19:11:59:540 asdu (length: 2): 2003 19:11:59:585 APS-DATA.confirm id: 89, status: 0x00 SUCCESS 19:11:59:586 APS-DATA.confirm request id: 89 -> confirmed, timeout 0 19:11:59:602 APS-DATA.indication srcAddr: 0x7637, srcEp: 0x00 dstAddrMode: 2, profile: 0x0000, cluster: 0x8031, lqi: 255, rssi: -44 19:11:59:603 asdu: 20000603038d1f07ffff2e2100015d800b01881700cf7f25020fff8d1f07ffff2e210093459efeffbd1beca3a825020fa98d1f07ffff2e2100481a47001044ef54fc83160002ff 19:11:59:604 APS-DATA.indication request id: 89 -> finished 19:11:59:605 APS-DATA.request id: 89 erase from queue 19:11:59:606 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 8, node: 0x7637 19:11:59:606 neigbor 0x54ef441000471a48 is unknown child 19:11:59:737 APS-DATA.indication srcAddr: 0x83fc, srcEp: 0x00 dstAddrMode: 2, profile: 0x0000, cluster: 0x0013, lqi: 255, rssi: -45 19:11:59:738 asdu: 01fc83481a47001044ef548c 19:11:59:739 APS-DATA.indication from unknown node 0x54EF441000471A48 19:11:59:743 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 2, node: 0x83FC 19:11:59:744 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 1, node: 0x83FC 19:11:59:745 new node - ext: 0x54ef441000471a48, nwk: 0x83FC 19:11:59:747 device announce 0x54EF441000471A48 (0x83FC) mac capabilities 0x8C 19:11:59:748 set fast probe address to 0x54EF441000471A48 (0x83FC) 19:11:59:748 FP indication 0x0000 / 0x0013 (0x54EF441000471A48 / 0x83FC) 19:11:59:749 ... (0x54EF441000471A48 / 0x83FC) 19:11:59:750 device announce 0x54EF441000471A48 (0x83FC) mac capabilities 0x8C 19:11:59:799 ZDP get node descriptor for 0x83FC 19:11:59:801 APS-DATA.request id: 92, addrmode: 0x03, addr: 0x54ef441000471a48, profile: 0x0000, cluster: 0x0002, ep: 0x00 -> 0x00 queue: 0 len: 3 tx.options 0x00 19:11:59:802 asdu (length: 3): 01fc83 19:11:59:803 ZDP get node descriptor for 0x83FC 19:11:59:803 APS-DATA.request id: 93, addrmode: 0x03, addr: 0x54ef441000471a48, profile: 0x0000, cluster: 0x0002, ep: 0x00 -> 0x00 queue: 1 len: 3 tx.options 0x00 19:11:59:804 asdu (length: 3): 02fc83 19:11:59:848 rule event /config/localtime: 19:11:58.763 -> 19:11:59.805 (1042ms) 19:11:59:882 APS-DATA.confirm id: 93, status: 0xD0 19:11:59:894 APS-DATA.confirm id: 92, status: 0x00 SUCCESS 19:11:59:895 APS-DATA.confirm request id: 92 -> confirmed, timeout 0 19:11:59:919 poll node 00:17:88:01:09:e8:3c:9c-0b 19:11:59:920 Poll light node Hue Iris 19:11:59:964 APS-DATA.indication srcAddr: 0x83fc, srcEp: 0x00 dstAddrMode: 2, profile: 0x0000, cluster: 0x8002, lqi: 255, rssi: -44 19:11:59:966 asdu: 0100fc8302408c34126c7f00002c7f0000 19:11:59:967 APS-DATA.indication request id: 92 -> finished 19:11:59:968 APS-DATA.request id: 92 erase from queue 19:11:59:969 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 3, node: 0x83FC 19:11:59:970 DB pushZdpDescriptorDb() 19:12:00:116 DB UPDATE device_descriptors SET data = x'02408c34126c7f00002c7f0000', timestamp = 1648919520 WHERE device_id = (SELECT id FROM devices WHERE mac = '54:ef:44:10:00:47:1a:48') AND endpoint = 0 AND type = 2 19:12:00:117 DB INSERT INTO device_descriptors (device_id, endpoint, type, data, timestamp) SELECT id, 0, 2, x'02408c34126c7f00002c7f0000', 1648919520 FROM devices WHERE mac = '54:ef:44:10:00:47:1a:48' 19:12:00:132 APS-DATA.request id: 96, addrmode: 0x02, addr: 0x83fc, profile: 0x0000, cluster: 0x0005, ep: 0x00 -> 0x00 queue: 0 len: 3 tx.options 0x00 19:12:00:133 asdu (length: 3): 1bfc83 19:12:00:134 FP indication 0x0000 / 0x8002 (0x54EF441000471A48 / 0x83FC) 19:12:00:134 ... (0x54EF441000471A48 / 0x83FC) 19:12:00:135 ZDP indication search sensors 0x54EF441000471A48 (0x83FC) cluster 0x8002 19:12:00:425 [2] get active endpoints for 0x54ef441000471a48 19:12:00:426 ZDP get active endpoints for 0x83FC 19:12:00:437 APS-DATA.request id: 98, addrmode: 0x03, addr: 0x54ef441000471a48, profile: 0x0000, cluster: 0x0005, ep: 0x00 -> 0x00 queue: 1 len: 3 tx.options 0x00 19:12:00:438 asdu (length: 3): 03fc83 19:12:00:489 APS-DATA.indication srcAddr: 0x83fc, srcEp: 0x00 dstAddrMode: 2, profile: 0x0000, cluster: 0x0002, lqi: 255, rssi: -44 19:12:00:490 asdu: 020000 19:12:00:491 APS-DATA.request id: 100, addrmode: 0x02, addr: 0x83fc, profile: 0x0000, cluster: 0x8002, ep: 0x00 -> 0x00 queue: 2 len: 17 tx.options 0x04 19:12:00:492 asdu (length: 17): 0200000010400f5f11472b0040002b0000 19:12:00:526 APS-DATA.confirm id: 96, status: 0x00 SUCCESS 19:12:00:527 APS-DATA.confirm request id: 96 -> confirmed, timeout 0 19:12:00:547 APS-DATA.confirm id: 96, status: 0x00 SUCCESS 19:12:00:548 APS-DATA.confirm id: 96, status: 0x00, match: 0 19:12:00:566 APS-DATA.indication srcAddr: 0x83fc, srcEp: 0x00 dstAddrMode: 2, profile: 0x0000, cluster: 0x8005, lqi: 255, rssi: -44 19:12:00:567 asdu: 1b00fc830101 19:12:00:568 APS-DATA.indication request id: 96 -> finished 19:12:00:568 APS-DATA.request id: 96 erase from queue 19:12:00:569 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 7, node: 0x83FC 19:12:00:570 FP indication 0x0000 / 0x8005 (0x54EF441000471A48 / 0x83FC) 19:12:00:570 ... (0x54EF441000471A48 / 0x83FC) 19:12:00:571 ZDP indication search sensors 0x54EF441000471A48 (0x83FC) cluster 0x8005 19:12:00:572 ZDP indication search sensors 0x54EF441000471A48 (0x83FC) clear timeout on cluster 0x8005 19:12:00:611 [3] get simple descriptor 0x01 for 0x54ef441000471a48 19:12:00:614 ZDP get simple descriptor 0x01 for 0x83FC 19:12:00:615 APS-DATA.request id: 102, addrmode: 0x03, addr: 0x54ef441000471a48, profile: 0x0000, cluster: 0x0004, ep: 0x00 -> 0x00 queue: 2 len: 4 tx.options 0x00 19:12:00:615 asdu (length: 4): 04fc8301 19:12:00:635 APS-DATA.indication srcAddr: 0x83fc, srcEp: 0x00 dstAddrMode: 2, profile: 0x0000, cluster: 0x8005, lqi: 255, rssi: -44 19:12:00:637 asdu: 1b00fc830101 19:12:00:638 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 7, node: 0x83FC 19:12:00:639 FP indication 0x0000 / 0x8005 (0x54EF441000471A48 / 0x83FC) 19:12:00:640 ... (0x54EF441000471A48 / 0x83FC) 19:12:00:641 ZDP indication search sensors 0x54EF441000471A48 (0x83FC) cluster 0x8005 19:12:00:668 wait response fastEnddeviceProbe() 0x54EF441000471A48, elapsed 51 ms 19:12:00:695 APS-DATA.confirm id: 98, status: 0x00 SUCCESS 19:12:00:696 APS-DATA.confirm request id: 98 -> confirmed, timeout 0 19:12:00:733 APS-DATA.indication srcAddr: 0x83fc, srcEp: 0x00 dstAddrMode: 2, profile: 0x0000, cluster: 0x8005, lqi: 255, rssi: -44 19:12:00:734 asdu: 0300fc830101 19:12:00:735 APS-DATA.indication request id: 98 -> finished 19:12:00:736 APS-DATA.request id: 98 erase from queue 19:12:00:737 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 7, node: 0x83FC 19:12:00:738 FP indication 0x0000 / 0x8005 (0x54EF441000471A48 / 0x83FC) 19:12:00:739 ... (0x54EF441000471A48 / 0x83FC) 19:12:00:739 ZDP indication search sensors 0x54EF441000471A48 (0x83FC) cluster 0x8005 19:12:00:799 wait response fastEnddeviceProbe() 0x54EF441000471A48, elapsed 183 ms 19:12:00:810 APS-DATA.confirm id: 102, status: 0x00 SUCCESS 19:12:00:812 APS-DATA.confirm request id: 102 -> confirmed, timeout 0 19:12:00:813 rule event /config/localtime: 19:11:59.805 -> 19:12:00.801 (996ms) 19:12:00:831 APS-DATA.confirm id: 100, status: 0x00 SUCCESS 19:12:00:833 aps request id: 100 finished, erase from queue 19:12:00:857 APS-DATA.indication srcAddr: 0x83fc, srcEp: 0x00 dstAddrMode: 2, profile: 0x0000, cluster: 0x8004, lqi: 255, rssi: -43 19:12:00:860 asdu: 0400fc8312010401f0ff000300000300c0fc0203001900 19:12:00:862 APS-DATA.indication request id: 102 -> finished 19:12:00:866 APS-DATA.request id: 102 erase from queue 19:12:00:870 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 5, node: 0x83FC 19:12:00:871 DB pushZdpDescriptorDb() 19:12:00:873 DB UPDATE device_descriptors SET data = x'010401f0ff000300000300c0fc0203001900', timestamp = 1648919520 WHERE device_id = (SELECT id FROM devices WHERE mac = '54:ef:44:10:00:47:1a:48') AND endpoint = 1 AND type = 4 19:12:00:874 DB INSERT INTO device_descriptors (device_id, endpoint, type, data, timestamp) SELECT id, 1, 4, x'010401f0ff000300000300c0fc0203001900', 1648919520 FROM devices WHERE mac = '54:ef:44:10:00:47:1a:48' 19:12:00:888 FP indication 0x0000 / 0x8004 (0x54EF441000471A48 / 0x83FC) 19:12:00:889 ... (0x54EF441000471A48 / 0x83FC) 19:12:00:890 ZDP indication search sensors 0x54EF441000471A48 (0x83FC) cluster 0x8004 19:12:00:891 ZDP indication search sensors 0x54EF441000471A48 (0x83FC) clear timeout on cluster 0x8004 19:12:00:946 [4.1] Get manufacturer code 19:12:00:948 [4.2] get basic cluster attr 0x0004 for 0x54ef441000471a48 19:12:00:949 APS-DATA.request id: 107, addrmode: 0x02, addr: 0x83fc, profile: 0x0104, cluster: 0x0000, ep: 0x01 -> 0x01 queue: 0 len: 5 tx.options 0x00 19:12:00:950 asdu (length: 5): 101c000400 19:12:00:973 APS-DATA.indication srcAddr: 0x83fc, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x000A, lqi: 255, rssi: -44 19:12:00:975 asdu: 0000000000 19:12:00:976 0x54EF441000471A48 missing cluster 0x000A, frame control 0x00000000 19:12:00:979 DB pushZdpDescriptorDb() 19:12:00:982 DB UPDATE device_descriptors SET data = x'010401f0ff000300000300c0fc03030019000a00', timestamp = 1648919520 WHERE device_id = (SELECT id FROM devices WHERE mac = '54:ef:44:10:00:47:1a:48') AND endpoint = 1 AND type = 4 19:12:00:997 APS-DATA.request id: 110, addrmode: 0x02, addr: 0x83fc, profile: 0x0104, cluster: 0x000A, ep: 0x01 -> 0x01 queue: 1 len: 11 tx.options 0x00 19:12:00:998 asdu (length: 11): 180001000000e26040db29 19:12:01:001 FP indication 0x0104 / 0x000A (0x54EF441000471A48 / 0x83FC) 19:12:01:003 ... (0x54EF441000471A48 / 0x83FC) 19:12:01:125 APS-DATA.indication srcAddr: 0x83fc, srcEp: 0x00 dstAddrMode: 2, profile: 0x0000, cluster: 0x0006, lqi: 255, rssi: -63 19:12:01:126 asdu: 04fdff040101190000 19:12:01:160 APS-DATA.indication srcAddr: 0x83fc, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0000, lqi: 255, rssi: -44 19:12:01:162 asdu: 18010a050042106c756d692e6d6f74696f6e2e6163303101002035 19:12:01:163 Node data 0x54ef441000471a48 profileId: 0x0104, clusterId: 0x0000 19:12:01:164 FP indication 0x0104 / 0x0000 (0x54EF441000471A48 / 0x83FC) 19:12:01:165 ... (0x54EF441000471A48 / 0x83FC) 19:12:01:165 Clear fast probe timeout for cluster 0x0000, 0x54EF441000471A48 19:12:01:166 ZCL attribute report 0x54EF441000471A48 for cluster: 0x0000, ep: 0x01, frame control: 0x18, mfcode: 0x0000 19:12:01:167 payload: 050042106c756d692e6d6f74696f6e2e6163303101002035 19:12:01:168 0x54EF441000471A48 skip Xiaomi attribute 0x0000 19:12:01:207 APS-DATA.request id: 113, addrmode: 0x03, addr: 0x54ef441000471a48, profile: 0x0104, cluster: 0x0000, ep: 0x01 -> 0x01 queue: 2 len: 5 tx.options 0x00 19:12:01:209 asdu (length: 5): 101d000400 19:12:01:222 APS-DATA.confirm id: 107, status: 0x00 SUCCESS 19:12:01:224 APS-DATA.confirm request id: 107 -> erase from queue 19:12:01:225 aps request id: 107 finished, erase from queue 19:12:01:241 APS-DATA.indication srcAddr: 0x83fc, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0xFCC0, lqi: 255, rssi: -44 19:12:01:243 asdu: 18020af700412d03281c05210100082135010a2137760c20141020011220006520ff6620036720006820006920016a20016b2003 19:12:01:244 Node data 0x54ef441000471a48 profileId: 0x0104, clusterId: 0xFCC0 19:12:01:245 0x54EF441000471A48 extract Xiaomi special attribute 0x00F7 19:12:01:246 03 Device temperature 28 °C 19:12:01:247 05 RSSI dB (?) 1 (0x0001) 19:12:01:248 08 unknown 309 (0x0135) 19:12:01:248 0a Parent NWK 30263 (0x7637) 19:12:01:249 0c unknown 20 (0x14) 19:12:01:250 10 unsupported tag (data type 0x20) 19:12:01:250 12 unsupported tag (data type 0x20) 19:12:01:251 65 battery 255% 19:12:01:252 66 unknown 3 (0x03) 19:12:01:252 67 unknown 0 (0x00) 19:12:01:253 68 unsupported tag (data type 0x20) 19:12:01:254 69 charging 1 (0x01) 19:12:01:254 6A unsupported tag (data type 0x20) 19:12:01:255 6b unknown 3 (0x03) 19:12:01:256 FP indication 0x0104 / 0xFCC0 (0x54EF441000471A48 / 0x83FC) 19:12:01:257 ... (0x54EF441000471A48 / 0x83FC) 19:12:01:258 ZCL attribute report 0x54EF441000471A48 for cluster: 0xFCC0, ep: 0x01, frame control: 0x18, mfcode: 0x0000 19:12:01:258 payload: f700412d03281c05210100082135010a2137760c20141020011220006520ff6620036720006820006920016a20016b2003 19:12:01:416 poll node 00:17:88:01:09:c7:27:17-0b 19:12:01:418 Poll light node Lightbar 2 19:12:01:437 APS-DATA.indication srcAddr: 0x83fc, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0000, lqi: 255, rssi: -44 19:12:01:438 asdu: 181c0104000042056171617261 19:12:01:439 Node data 0x54ef441000471a48 profileId: 0x0104, clusterId: 0x0000 19:12:01:448 FP indication 0x0104 / 0x0000 (0x54EF441000471A48 / 0x83FC) 19:12:01:449 ... (0x54EF441000471A48 / 0x83FC) 19:12:01:450 APS-DATA.request id: 117, addrmode: 0x03, addr: 0x54ef441000471a48, profile: 0x0104, cluster: 0x0000, ep: 0x01 -> 0x01 queue: 2 len: 5 tx.options 0x00 19:12:01:452 asdu (length: 5): 101e000500 19:12:01:483 APS-DATA.indication srcAddr: 0x83fc, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0xFCC0, lqi: 255, rssi: -44 19:12:01:485 asdu: 18030af700412d03281c05210100082135010a2137760c20141020011220006520ff6620036720006820006920016a20016b2003 19:12:01:486 Node data 0x54ef441000471a48 profileId: 0x0104, clusterId: 0xFCC0 19:12:01:487 0x54EF441000471A48 extract Xiaomi special attribute 0x00F7 19:12:01:488 03 Device temperature 28 °C 19:12:01:489 05 RSSI dB (?) 1 (0x0001) 19:12:01:489 08 unknown 309 (0x0135) 19:12:01:490 0a Parent NWK 30263 (0x7637) 19:12:01:491 0c unknown 20 (0x14) 19:12:01:491 10 unsupported tag (data type 0x20) 19:12:01:492 12 unsupported tag (data type 0x20) 19:12:01:493 65 battery 255% 19:12:01:493 66 unknown 3 (0x03) 19:12:01:494 67 unknown 0 (0x00) 19:12:01:495 68 unsupported tag (data type 0x20) 19:12:01:495 69 charging 1 (0x01) 19:12:01:496 6A unsupported tag (data type 0x20) 19:12:01:497 6b unknown 3 (0x03) 19:12:01:497 FP indication 0x0104 / 0xFCC0 (0x54EF441000471A48 / 0x83FC) 19:12:01:498 ... (0x54EF441000471A48 / 0x83FC) 19:12:01:499 ZCL attribute report 0x54EF441000471A48 for cluster: 0xFCC0, ep: 0x01, frame control: 0x18, mfcode: 0x0000 19:12:01:499 payload: f700412d03281c05210100082135010a2137760c20141020011220006520ff6620036720006820006920016a20016b2003 19:12:01:613 APS-DATA.confirm id: 110, status: 0x00 SUCCESS 19:12:01:615 APS-DATA.confirm request id: 110 -> erase from queue 19:12:01:691 aps request id: 110 finished, erase from queue 19:12:01:704 APS-DATA.confirm id: 110, status: 0x00 SUCCESS 19:12:01:705 APS-DATA.confirm id: 110, status: 0x00, match: 0 19:12:01:721 APS-DATA.indication srcAddr: 0x83fc, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x000A, lqi: 255, rssi: -44 19:12:01:722 asdu: 10000b01c3 19:12:01:723 FP indication 0x0104 / 0x000A (0x54EF441000471A48 / 0x83FC) 19:12:01:724 ... (0x54EF441000471A48 / 0x83FC) 19:12:01:743 APS-DATA.indication srcAddr: 0x83fc, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x000A, lqi: 255, rssi: -45 19:12:01:745 asdu: 10000b01c3 19:12:01:747 FP indication 0x0104 / 0x000A (0x54EF441000471A48 / 0x83FC) 19:12:01:748 ... (0x54EF441000471A48 / 0x83FC) 19:12:01:769 rule event /config/localtime: 19:12:00.801 -> 19:12:01.767 (966ms) 19:12:01:788 APS-DATA.confirm id: 113, status: 0x00 SUCCESS 19:12:01:789 APS-DATA.confirm request id: 113 -> erase from queue 19:12:01:826 aps request id: 113 finished, erase from queue 19:12:01:834 APS-DATA.confirm id: 117, status: 0x00 SUCCESS 19:12:01:836 APS-DATA.confirm request id: 117 -> erase from queue 19:12:01:860 APS-DATA.indication srcAddr: 0x83fc, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0000, lqi: 255, rssi: -44 19:12:01:861 asdu: 181d0104000042056171617261 19:12:01:862 APS-DATA.request id: 117 erase from queue 19:12:01:863 Node data 0x54ef441000471a48 profileId: 0x0104, clusterId: 0x0000 19:12:01:869 FP indication 0x0104 / 0x0000 (0x54EF441000471A48 / 0x83FC) 19:12:01:870 ... (0x54EF441000471A48 / 0x83FC) 19:12:01:909 APS-DATA.request id: 124, addrmode: 0x03, addr: 0x54ef441000471a48, profile: 0x0104, cluster: 0x0000, ep: 0x01 -> 0x01 queue: 0 len: 5 tx.options 0x00 19:12:01:910 asdu (length: 5): 101f000500 19:12:01:935 APS-DATA.indication srcAddr: 0x83fc, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0000, lqi: 255, rssi: -44 19:12:01:937 asdu: 181e0105000042106c756d692e6d6f74696f6e2e61633031 19:12:01:938 Node data 0x54ef441000471a48 profileId: 0x0104, clusterId: 0x0000 19:12:01:945 FP indication 0x0104 / 0x0000 (0x54EF441000471A48 / 0x83FC) 19:12:01:946 ... (0x54EF441000471A48 / 0x83FC) 19:12:01:969 DEV no DDF for 0x54EF441000471A48, modelId: lumi.motion.ac01 19:12:01:971 DEV create on-the-fly DDF for 0x54EF441000471A48 19:12:01:987 APS-DATA.confirm id: 124, status: 0x00 SUCCESS 19:12:01:988 APS-DATA.confirm request id: 124 -> erase from queue 19:12:02:013 APS-DATA.indication srcAddr: 0x83fc, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0000, lqi: 255, rssi: -44 19:12:02:014 asdu: 181f0105000042106c756d692e6d6f74696f6e2e61633031 19:12:02:015 APS-DATA.request id: 124 erase from queue 19:12:02:016 Node data 0x54ef441000471a48 profileId: 0x0104, clusterId: 0x0000 19:12:02:022 FP indication 0x0104 / 0x0000 (0x54EF441000471A48 / 0x83FC) 19:12:02:023 ... (0x54EF441000471A48 / 0x83FC) ```

[Smanar]

After some search It perhaps normal. This device use the cluster 0xFC00

• Attribute 0x0142 > presence
• Attribute 0x0144 > mode
• Attribute 0x0146 > distance

[SwoopX]

I'd assume we need the linked PR to tickle some more insights out of the device.

[ebaauw]

Is this the sensor with radar for presence detection and USB power? Where did you get it, if you don’t mind me asking?

[Verteo]

I'd assume we need the linked PR to tickle some more insights out of the device.

Ok, I will look into doing a deconz build with that patch.

Is this the sensor with radar for presence detection and USB power? Where did you get it, if you don’t mind me asking?

Yes, that's right. It's the radar sensor. I got it off Aliexpress, every now and then it's available to buy. The curiosity won me over so I was okay with a little bit extra

[ebaauw]

The specs look very promising (apart from requiring permanent power, but I suppose that comes with active sensing). Unfortunately it' sold out for now...

[Verteo]

I'd assume we need the linked PR to tickle some more insights out of the device.

Ok, I will look into doing a deconz build with that patch.

I compiled deconz with the PR and nothing changed

The specs look very promising (apart from requiring permanent power, but I suppose that comes with active sensing). Unfortunately it' sold out for now...

I agree, that's why it sparked my curiosity. The power draw I can measure at moment is around 0.15 W, maybe it will consume more power once properly configured?

[github-actions[bot]]

As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

[SwoopX]

Ping

[wvuyk]

If anyone is interested, I received my device yesterday. I can send it out to one of the devs as a loan device? I am guessing that with the distance measurement etc it might be efficient if you have the device hands on?

As I understand it is already working in Zigbee2mqtt?

[SwoopX]

No need, already got one here for testing but thanks.

You might want to try out the current draft DDF. Please note that deconz version 2.15.1 is required for setting the config items and sensitivity cannot be changed without any further code changes.

{
  "schema": "devcap1.schema.json",
  "manufacturername": "aqara",
  "modelid": "lumi.motion.ac01",
  "vendor": "Xiaomi",
  "product": "Aqara FP1 presence sensor RTCZCGQ11LM",
  "sleeper": false,
  "status": "Gold",
  "path": "/devices/fp1_presence_sensor_rtczcgq11lm.json",
  "subdevices": [
    {
      "type": "$TYPE_PRESENCE_SENSOR",
      "restapi": "/sensors",
      "uuid": [
        "$address.ext",
        "0x01",
        "0xfcc0"
      ],
      "items": [
        {
          "name": "attr/id"
        },
        {
          "name": "attr/lastannounced"
        },
        {
          "name": "attr/lastseen"
        },
        {
          "name": "attr/manufacturername"
        },
        {
          "name": "attr/modelid"
        },
        {
          "name": "attr/name"
        },
        {
          "name": "attr/swversion",
          "refresh.interval": 84000,
          "read": {
            "at": "0x0006",
            "cl": "0x0000",
            "ep": 1,
            "fn": "zcl"
          },
          "parse": {
            "at": "0x0006",
            "cl": "0x0000",
            "ep": 1,
            "eval": "Item.val = Attr.val",
            "fn": "zcl"
          }
        },
        {
          "name": "attr/type"
        },
        {
          "name": "attr/uniqueid"
        },
        {
          "name": "config/devicemode",
          "refresh.interval": 300,
          "parse": {
            "at": "0x0144",
            "cl": "0xfcc0",
            "ep": 1,
            "eval": "if (Attr.val == 0) { Item.val = 'undirected' } else if (Attr.val == 1) { Item.val = 'leftright' } else { Item.val = 'unknown' }",
            "fn": "zcl"
          },
          "read": {
            "at": "0x0144",
            "cl": "0xfcc0",
            "ep": 1,
            "fn": "zcl"
          },
          "write": {
            "at": "0x0144",
            "cl": "0xfcc0",
            "dt": "0x20",
            "ep": 1,
            "eval": "if (Item.val == 'undirected') { 0 } else if (Item.val == 'leftright') { 1 }",
            "fn": "zcl"
          },
          "values": [
            ["\"undirected\"", "Undirected"],
            ["\"leftright\"", "Left and right"] 
          ],
          "default": "undirected"
        },
        {
          "name": "config/on"
        },
        {
          "name": "config/reachable"
        },
        {
          "name": "config/sensitivity",
          "refresh.interval": 300,
          "parse": {
            "at": "0x010C",
            "cl": "0xfcc0",
            "ep": 1,
            "eval": "Item.val = Attr.val",
            "fn": "zcl"
          },
          "read": {
            "at": "0x010C",
            "cl": "0xfcc0",
            "ep": 1,
            "fn": "zcl"
          },
          "write": {
            "at": "0x010C",
            "cl": "0xfcc0",
            "dt": "0x20",
            "ep": 1,
            "eval": "Item.val",
            "fn": "zcl"
          },
          "values": [
            [1, "Low"],
            [2, "Medium"],
            [3, "High"]
          ],
          "default": 3
        },
        {
          "name": "state/lastupdated"
        },
        {
          "name": "state/presence",
          "refresh.interval": 300,
          "read": {
            "at": "0x0143",
            "cl": "0xfcc0",
            "ep": 1,
            "fn": "zcl"
          },
          "parse": {
            "at": "0x0143",
            "cl": "0xfcc0",
            "ep": 1,
            "eval": "Attr.val != 1 ? Item.val = true : Item.val = false",
            "fn": "zcl"
          },
          "default": false
        }
      ]
    }
  ]
}

[wvuyk]

@SwoopX Thanks!

The DDF helped to get the device going indeed.

I notice a (for me) new attribute devicemode , is that where we will see the extra info like distance and direction in later? I have played a bit with it and it is indeed a very good occupancy sensor! I sat in sight of the sensor for 15 minutes, not moving (reading) and it reported presence all that time. When I moved away it took maybe 20 seconds before the device reported no presence. Also checked it in the bathroom, while being behind a curtain in the shower... it stil reported occupancy. The price is steep, but it is a very promising device...

{
"config": {
"devicemode": "undirected",
"on": true,
"reachable": true,
"sensitivity": 3
},
"etag": "e460f507dfc0f0457105980852326443",
"lastannounced": null,
"lastseen": "2022-04-27T12:14Z",
"manufacturername": "aqara",
"modelid": "lumi.motion.ac01",
"name": "Presence 18 Motion",
"state": {
"lastupdated": "2022-04-27T11:47:26.872",
"presence": false
},
"swversion": "20210121",
"type": "ZHAPresence",
"uniqueid": "54:ef:44:10:00:47:1c:13-01-fcc0"
}

[popy2k14]

got two on alixpress. Any hint's when this sensor will be supported in the release version?

thx

[ebaauw]

Received mine this week! Got it to pair to my Aqara M2 hub; please let me know if you need sniffer logs how the Aqara hub handles the device. Got it to pair with deCONZ v1.16.1 as well, thanks for this PR! Looks like Homebridge Hue already exposes it as (unknown) motion sensor, based on state.presence.

Couple of questions:

• What are the valid values for config.sensitivity?
• Why not expose config.sensitivitymax (and normalise config.sensitivity values to 0 (lowest) ... config.sensitivitymax (highest))?
• Is the definition for the 0xFCC0 cluster still missing from general.xml, or is there something wrong in my setup?

[popy2k14]

Got also two of them from Ali and two more are on the way. i must say wow, they blow my mind. Perfectly for living room (couch), bathroom (shower), ... One little thing which could be better is the 5m range. But i can live with that. Just want to let you know.

[radischem]

Fortunately I also received a sensor. Unfortunately it shows in Phoscon (finds the device even though it’s saying no device found) including motion but doesn’t transfer that info to HA. Could someone here explain what I need to change and where to get it running properly? Would be much appreciated :)

[popy2k14]

I had no such issue, Do you see the device under devices in HA? If not, restart HA core & run service deconz refresh devices.

[radischem]

Deleted the device in Phoscon and started over again with the same result. Searching for a sensor in Phoscon, it will populate the list, but Phoscon declares the search as unsuccesful (although you can see behind the popup that it is indeed successful - somehow - in finding the presence sensor).

The device is then visible in HA (tried both restart and refresh with the same results), but only as binary sensor which has the state "on", no matter if I'm around or 2 rooms away :(

Phoscon is Presence 20210121

[popy2k14]

It's normal that the search behaves like that. In my case also deCONZ in the back showed the sensor. Also HA is just having an binary sensor with my two sensors.

But it should toggle between those states.

Just an few hint's: If you have something moving in the room it could be stucked at triggered on. In my case it was a helium-balloon from a party which moved a little bit. Also dogs or cat's could be an issue.

Be sure the room is completely empty!

With previous radar sensors i also had issues with thin (dry)walls. Maybe that's the case for you?

You can lower the sensitivity on this sensors. But i think, currently you have todo this with the rest API.

Which deconz version do you have? You posted your IP address. Mine is 2.16.1 (official HA addon) + 2.17.0 beta FP1 DDF (taken here from github).

Good luck

PS.: with some pairing issues at the beginning, they noiw perform very well.

[ebaauw]

I now have three working and one broken FP1 devices. Still messaging with the shop on AliExpress to replace the broken one...

There's a new firmware out, version 0.0.0_0054, see https://github.com/Koenkk/zigbee-OTA/pull/127. Upgrading one device on the Aqara M1 hub, and another one on deCONZ.

I tried one of the sensors in my hallway and it behaves perfectly. The one in my living room continues to detect presence while my ceiling fans are turning (up to two minutes after turning them off). Otherwise detection seems fine. The one in my dining room continues to detect presence regardless, maybe the Hue Ensis hanging above my dining table is moving slightly?

I'm trying out settings the detection region in the Aqara app, but I'm afraid I fail to understand how it's supposed to work. The app doesn't consistently show the person symbol where it detects presence. I created a detection region excluding the grid elements where (I think) the ceiling fans are located, and set sensitivity to low, but I don't seem to get consistent results. Had anyone already figured out the region logic?

[SwoopX]

@ebaauw Funny that you mention the detection area, as I played around with that just yesterday and I'd say I understand it 90%. Might need to reset the sensor and redo what I did to get the remaining 10%. I got a pretty adventurous setup with an E1 hub here to get the Xiaomi stuff completely isolated and off of my network, but regardless.

So, apparently you're pretty much free to define quite a number of detection areas (presumably limited to 28, but not sure). Each time an area is defined, it is written to 0x0150 as a 7 Byte ostring. The app gives you a 7 x 4 area (top to bottom Y1 - Y7 and left to right X1 - X4), which is composed as follows:

01:05:00:00:00:01:ff
|| || || || || || ||
|| || || || || || ---- reserved (always ff)
|| || || || || ||
|| || || || || |------ Y7 coordinate
|| || || || || ------- reserved (always 0)
|| || || || ||
|| || || || |--------- Y5 coordinate
|| || || || ---------- Y6 coordinate
|| || || ||
|| || || |------------ Y3 coordinate
|| || || ------------- Y4 coordinate
|| || ||
|| || |--------------- Y1 coordinate
|| || ---------------- Y2 coordinate
|| ||
|| ------------------- detection area index
||
---------------------- yet unknown

To now mark an area for detection, the respective X-coordinate value needs to represent the Y-coordinate. X1=1, X2=2, X3=4, X4=8.

Example with detection index 1 and detection area x2y4: 01:01:00:20:00:00:ff

Presence in a detection area, as far as I can tell, is reported via 0x0151 as ostring (I currently observed 2 Bytes here, but could be more), e.g. 07:08. I'm 99% sure the 2nd Byte represents the X-coordinate, but I'm not sure what the 1st Byte is supposed to mean, either the detection area index or the Y-coordinate.

When setting an area of interference (or whatever it is called), I haven't observed any writes. No clue yet if and to what extend that impacts any processing on the device directly. I also haven't seen any way to delete detection areas, but that might have been a screen resolution issue on my end. If there's indeed no button in the app, it might be be reset with zeroing out the detection area for the respective index?

So much for now...

[ebaauw]

I've seen the 0x0150 and 0x0151 attributes in the sniffer as well, and your analysis makes sense. Unfortunately, the GUI doesn't display ostring values in any usable way. @manup could that be changed into showing an array of (hex) byte values?

I've read online that the FP1 does, indeed, detect motion. I.e. it compares the result of the next scan with that of the previous scan. It doesn't detect human bodies, it detects subtle changes in the scan results due to breathing (one of the sites suggested it could be used to raise an alarm if someone stops breathing). That would also explain why it takes some time before it can detect presence: it needs a couple of scan results before it can conclude so.

I also read that the grid as displayed in the Aqara app is misleading. The detection area is cone shaped, not rectangular. Consequently, the coordinates are not rectangular (x, y), but polar (angle, distance). Come to think of it, this makes a lot of sense physically: the FP1 sends out a microwave and listens for echoes. The echoes from closer objects arrive earlier than the echoes of more distant objects. That would imply that 0x0151 would issue a report per increasing distance during each scan.

Funny part: I've seen some repeated reports for 0x0151, but only occasionally (looking at the Aqara M2 hub). I see a lot of repeated reports for 0xFFF2, which is an ostring of 24 bytes. I have seen values 01:08 for 0x0151 (and 01:02 and 01:04). Maybe 0x0151 only reports changes, where 0xFFF2 reports echoes? There seems to be some on-device logic, to process scan results (0xFFF2) to changes (0x0151) to presence events (0x0143) to presence detected (0x0142); each step taking some time. EDIT: The FP1 detects moving objects by frequency changes of the reflected microwave due to the Doppler effect. That also explains why movement to/from the sensors is easier to detect then left/right movement.

I think only the detection area is sent to the FP1; the other areas are just for the benefit of the app. I can confirm that 0x0150 seems to encode the coordinates as you indicate. The first two bytes are 03:01 in my case. And that 01 corresponds to the first byte in the 0x0151 value.

It would seem the FP1 only reports 0xFFF2 (and 0x0151) when the Aqara app is open on the "grid" view. The M1 writes value 0x01 to 0x0155 while the app is opening that view. I haven't captured any reset of 0x0155, maybe it just times out?

[SwoopX]

@manup could that be changed into showing an array of (hex) byte values?

+1 over here. That would also come in handy e.g. for the Develco/frient firmware version and eliminate the necessity to use a script for displaying it correctly.

Surely, the grid layout presented by the app was chosen to simplify reality. This here would be indeed more accurate (it's info material from the P1). What now comes into my mind is that setting the detection/approach distance my eventually impact the reported or to be expected values on 0x0151 respectively.

With the E1 hub, I interestingly haven't observed anything on 0xFFF2 but I had the app running all the time doing the sniff. More than happy to doublecheck if that eventually occurs without it. Anyway, I noted them in the capture you shared with me any maybe we can make some sense out of it jointly. There weren't many Bytes inside the (ostring?) attribute changing though.

Also still curious on the very first Byte on my analysis above, but as said, I should reset the sensor first to eventually learn what purpose it might have. Anyway, more than happy to share my capture, just need to carve out all the OTA packages. Somehow, the device tried to update, but the hub hasn't provided any data which flooded the log.

[Otnow]

@SwoopX, @ebaauw, for a long time I was going to analyze the protocol of work with the regions, but there were other priorities. Thanks for the motivation to finally do it 🙂

Here is what I was able to understand and clarify at the moment in addition to the above:

Regions

As you rightly noted, the grid of regions looks like this:

         ^
    X1 X2 X3 X4
Y1 | 1| 2| 4| 8|
Y2 | 1| 2| 4| 8|
Y3 | 1| 2| 4| 8|
Y4 | 1| 2| 4| 8|
Y5 | 1| 2| 4| 8|
Y6 | 1| 2| 4| 8|
Y7 | 1| 2| 4| 8|

Detection regions

Detection regions are created, modified and deleted using attribute 0x0150 (cluster: 0xfcc0, type: 0x41) in the following format:

_ _ : _ _ : _ _ : _ _ : _ _ : _ _ : _ _ 
| |   | |   | |   | |   | |   | |   | |
| |   | |   | |   | |   | |   | |   | - - hex value (0 or F): 0 when deleting and
| |   | |   | |   | |   | |   | |   |     F when creating/changing a region
| |   | |   | |   | |   | |   | |   |
| |   | |   | |   | |   | |   | |   - - - hex value (0 or F): 0 when deleting and
| |   | |   | |   | |   | |   | |         F when creating/changing a region
| |   | |   | |   | |   | |   | |
| |   | |   | |   | |   | |   | - - - - - hex value (0 - F): 0 when deleting and
| |   | |   | |   | |   | |   |           0-F when creating/changing a region 
| |   | |   | |   | |   | |   |           (sum of the selected values X1-X4 for the Y7 row)
| |   | |   | |   | |   | |   |
| |   | |   | |   | |   | |   - - - - - - hex value: always 0
| |   | |   | |   | |   | |
| |   | |   | |   | |   | - - - - - - - - hex value (0 - F): 0 when deleting and
| |   | |   | |   | |   |                 0-F when creating/changing a region
| |   | |   | |   | |   |                 (sum of the selected values X1-X4 for the Y5 row)
| |   | |   | |   | |   |
| |   | |   | |   | |   - - - - - - - - - hex value (0 - F): 0 when deleting and
| |   | |   | |   | |                     0-F when creating/changing a region
| |   | |   | |   | |                     (sum of the selected values X1-X4 for the Y6 row)
| |   | |   | |   | |
| |   | |   | |   | - - - - - - - - - - - hex value (0 - F): 0 when deleting and
| |   | |   | |   |                       0-F when creating/changing a region
| |   | |   | |   |                       (sum of the selected values X1-X4 for the Y3 row)
| |   | |   | |   |
| |   | |   | |   - - - - - - - - - - - - hex value (0 - F): 0 when deleting and
| |   | |   | |                           0-F when creating/changing a region
| |   | |   | |                           (sum of the selected values X1-X4 for the Y4 row)
| |   | |   | |
| |   | |   | - - - - - - - - - - - - - - hex value (0 - F): 0 when deleting and
| |   | |   |                             0-F when creating/changing a region
| |   | |   |                             (sum of the selected values X1-X4 for the Y1 row)
| |   | |   |
| |   | |   - - - - - - - - - - - - - - - hex value (0 - F): 0 when deleting and
| |   | |                                 0-F when creating/changing a region
| |   | |                                 (sum of the selected values X1-X4 for the Y2 row)
| |   | |
| |   | - - - - - - - - - - - - - - - - - hex value (1 - A): region index (application limits 10)
| |   |
| |   - - - - - - - - - - - - - - - - - - hex value: always 0
| |
| - - - - - - - - - - - - - - - - - - - - hex value (1 - 3): command code:
|                                         1 - create a region
|                                         2 - delete region
|                                         3 - change region
|
- - - - - - - - - - - - - - - - - - - - - hex value: always 0

Accordingly, after regions are created, the sensor starts reporting events related to them using attribute 0x0151 (cluster: 0xfcc0, type: 0x41) in the following format:

_ _ : _ _
| |   | |
| |   | - - hex value (1,2,4,8): event code:
| |   |     1 - enter
| |   |     2 - leave
| |   |     4 - presence
| |   |     8 - no presence
| |   |
| |   - - - hex value: always 0
| |
| - - - - - hex value (1 - A): region index (application limits 10)
|
- - - - - - hex value: always 0

Other regions

Other regions are set using attributes:

• 0x0153 (cluster: 0xfcc0, type: 0x23) - exits and entrances
• 0x0154 (cluster: 0xfcc0, type: 0x23) - interference source
• 0x0156 (cluster: 0xfcc0, type: 0x23) - edge

in the following format (hex value is passed to the sensor as int):

0 x _ _ _ _ _ _ _ _
    | | | | | | | |
    | | | | | | | - - hex value (0 - F): sum of the selected values X1-X4 for the Y1 row
    | | | | | | |
    | | | | | | - - - hex value (0 - F): sum of the selected values X1-X4 for the Y2 row
    | | | | | |
    | | | | | - - - - hex value (0 - F): sum of the selected values X1-X4 for the Y3 row
    | | | | |
    | | | | - - - - - hex value (0 - F): sum of the selected values X1-X4 for the Y4 row
    | | | |
    | | | - - - - - - hex value (0 - F): sum of the selected values X1-X4 for the Y5 row
    | | |
    | | - - - - - - - hex value (0 - F): sum of the selected values X1-X4 for the Y6 row
    | |
    | - - - - - - - - hex value (0 - F): sum of the selected values X1-X4 for the Y7 row
    |
    - - - - - - - - - hex value: always 0

---

Test environment:

• Aqara Hub M1S CN (ZHWG15LM): 3.4.2_0008.0616
• Aqara Presence Detector FP1 (RTCZCGQ11LM): 0.0.0_0054

[SwoopX]

@Otnow That's awesome and many thanks for chiming in! Was planning to reach out that evening as well. Haven't had the time yet to really dive deep into that, but that confirms that I seem to have some constraints in my test setup which didn't allow me to see and catch everything. Above that, some observations I made today while sniffing are confirmed 🙂

Really cool to see how fast things can go if the right people connect. One goodie I just discovered, in case you didn't already know: tag 0x08 of the special reporting is the firmware version as displayed in the app. Seems to be applicable for many devices.

[Otnow]

@SwoopX, you are welcome 🙂

One goodie I just discovered, in case you didn't already know: tag 0x08 of the special reporting is the firmware version as displayed in the app. Seems to be applicable for many devices.

I'm also trying to understand the structure of the heartbeat-message and had a hunch about it, so thanks for the confirmation 👍

[ebaauw]

Managed to place the FP1 in my dining room so it doesn't "see" the floor-stand fan and it now seems to detect (non-) presence without fail. I cannot seem to place the FP1 in my living room so it doesn't "see" the ceiling fans, nor can I configure its regions so it ignores them. But I did find a low-tech workaround with dubious aesthetics: I placed a piece of aluminium foil over the sensor. Next, I'll be changing my deCONZ rules next to use the Hue motion sensor to turn on the room, and the FP1 to turn it off.

I'm thinking the regions don't influence whether the sensor reports (overall) presence and presence events, only the detailed reporting per region (based on index). We would need a way to expose presence per region in such a way they can be used in rules (the Aqara app supports automations on presence per region). I think the cleanest way is to expose a ZHAPresence sensors resource per region, in addition to the current "overall" ZHAPresence. I think that should be doable in a DDF, without the need to mess with C++ code. I don't think the DDF syntax is powerful enough to express optional services, but we could simply define them all, and have people comment them out (or simply ignore the resources for the unused regions).

Then, I could define a region for my open kitchen in the dining room, detecting when I'm standing near the counter, to control the kitchen lights independently from the dining room table light, using one FP1. The FP1 could be way more powerful than I anticipated.

[manup]

I've seen the 0x0150 and 0x0151 attributes in the sniffer as well, and your analysis makes sense. Unfortunately, the GUI doesn't display ostring values in any usable way. @manup could that be changed into showing an array of (hex) byte values?

Yes I'll try to figure something out perhaps simply QByteArray::toHex() , I get my FP1 this week for testing sounds like a complex beast :)

[ebaauw]

So the automation on regions in the Aqara app has four region detection events:

• Region Manned (labelled "People exists" on the choose trigger condition selection);
• Region Unmanned (also labelled "People exists" on the selection);
• Region In;
• Region Leave.

Attribute 0x0151 corresponds to these events: the first byte indicates the region, the second byte the event:

Raw Value	Event
01	In
02	Leave
04	Manned
08	Unmanned

I think this attribute is enough to define state.presence of the region-specific ZHAPresence resource:

if (Item.val[0] === region) Attr.val = [1, 4].includes(Item.val[1])

[ebaauw]

Funny, the device stops reporting 0xFFF2 after a while, and only restart this after the app writes 1 to 0x0155. Apparently 0xFFF2 encodes the data to display the icon on the grid. Still don't understand the logic when it will show and when it won't.

I also saw the FP1 requesting and receiving the current time from the coordinator. And it does poll its parent every 5 minutes or so, even though is has Receiver On When Idle.

Here are some successive values for 0xFFF2 (double-checked for successive ZCL sequence numbers):

 0                             1                             2
 0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5  6  7  8  9  0  1  2  3

aa:74:12:84:73:d9:09:41:0f:00:02:62:b9:ba:9f:42:01:01:d8:04:00:0c:6b:00
aa:74:12:84:74:d8:09:41:0f:00:02:62:b9:ba:a4:43:01:01:ef:09:00:0d:d0:00
aa:74:12:84:75:d7:09:41:0f:00:02:62:b9:ba:a7:44:01:01:d0:08:00:09:ff:00
aa:74:12:84:76:d6:09:41:0f:00:02:62:b9:ba:a8:45:01:01:d0:06:00:08:d8:00
aa:74:12:84:77:d5:09:41:0f:00:02:62:b9:ba:b2:46:01:01:d0:06:00:08:d8:00
aa:74:12:84:78:d4:09:41:0f:00:02:62:b9:ba:bc:47:01:01:d0:06:00:08:d8:00
aa:74:12:84:79:d3:09:41:0f:00:02:62:b9:ba:c7:48:01:01:d0:06:00:08:d8:00

Bytes 5 and 15 are counting up, and byte 6 is counting down.

After deleting the detection regions, I see no major difference:

aa:74:12:84:d8:74:09:41:0f:00:02:62:b9:bf:4e:c6:01:01:fe:00:00:0b:b8:00
aa:74:12:84:d9:73:09:41:0f:00:02:62:b9:bf:58:c7:01:01:fe:00:00:0b:b8:00

It would seem this is indeed raw sensor data, before the region logic has been applied. Still no clue how to interprete it.

[SwoopX]

I have to say right now, the idea of exposing 10 additional presence sensors (based on the above identified maximum) is not too charming for me. I'd rather vouche for adding something like areapresence and areapresenceevent. Not too sure about what to do with the other areas yet. Presumably the resource should/must keep track of the max indexes used as well.

Admittedly, the suggested above would not allow to actually see the current state of all areas at a glance, but it would be enough to fire events based on what's been reported. Regarding the "global" presence state, my perception is also that it doesn't change when anything in an area is going on.

Anyway, it's remarkable how feature rich the device is and it amazingly solved the "issues" a regular motion/presence sensor gives you.

[ebaauw]

Problem with exposing the regions in an array or object is that you’d need to enhance the rules syntax to include these in conditions. That will be C++ coding. Ideally, we’d only have additional resources (or array entries) for regions that are actually defined. Not sure if the device actually reports this, or if we need to conclude that from the 0x0151 events. That would also need C++ code to enhance the DDF syntax for conditional resources and/or resource items.

[manup]

In a ResourceItem we can encode this into a unsigned 32-bit number which can be handled by rules perhaps with some additional operations? As far as I understand we have 10 regions with 4 events / (states?).

2-bits for each region:

region 0:    bits 0-1
region 1:    bits 2-3
...
region 10:   bits 17-18

A rule condition looking at such a value could have an additional mask like 0x03 to only check against the first two bits.

Quick-n-dirty idea:

{
  "address": "/sensors/00:17:88:01:09:a6:06:d1-01-fc00/state/areamap",
  "operator": "mask_eq",
  "value": "3,2"
}

This would then trigger if the value in first two bits (mask = 3) is 2.

On the DDF and API side we need a generic approach to describe such binary structure and expose some meaningful attributes. E.g. this is an array of ten 2-bit enums with following values.

An API client sees:

{
  "state": {
    "area0": "in",
    "area1": "leave",
    ...
    "area9": "unmanned"
  }
}

(or whatever we come up with what's convenient for API clients to consume)

[SwoopX]

If currently hacked something together which looks like this, just for the sake being able to play around with it

{
    "config": {
        "detectionarea": "010122110000ff",
        "devicemode": "undirected",
        "on": true,
        "reachable": true,
        "sensitivity": 3,
        "triggerdistance": "medium"
    },
    "etag": "13ff209f9401b317987d42506dd4cd79",
    "lastannounced": null,
    "lastseen": "2022-06-28T23:13Z",
    "manufacturername": "aqara",
    "modelid": "lumi.motion.ac01",
    "name": "Presence 165",
    "state": {
        "lastupdated": "2022-06-28T23:13:38.577",
        "presence": true,
        "presenceareaevent": 18,
        "presenceevent": "Leave 1"
    },
    "swversion": "20210121",
    "type": "ZHAPresence",
    "uniqueid": "54:ef:44:10:00:47:1a:48-01-0406"
}

In that example, you can configure the areas via detectionarea sending the desired hex value. presenceareaevent in turn fires the events based on attribute 0x0151 where the last digit is the event and anything before the detection area. As to my understanding, this would also allow rules to trigger on individual events per area.

@manup The detection area events are always 2 Bytes long. If more than 1 area is defined, consecutive events are reported per area as to my observations.

[popy2k14]

Guys, the cheapest offer on aliexpress since they are available. Now down under 60 Euro. There are two offers currently.

Here is the link: https://de.aliexpress.com/item/1005004450930450.html?spm=a2g0o.productlist.0.0.1da37b93WF90Tx&algo_pvid=f3acbafa-e171-4c74-ba19-d8e5a4f3b5fc&algo_exp_id=f3acbafa-e171-4c74-ba19-d8e5a4f3b5fc-0&pdp_ext_f=%7B%22sku_id%22%3A%2212000029303525377%22%7D&pdp_npi=2%40dis%21EUR%21%2158.65%21%21%21%21%21%402101e9d016566937349224934ed2d4%2112000029303525377%21sea

[arthur-morgan-1]

This sensor only shows clear/detected for me, no directions or anything else...

[MattL0]

How to set the most sensitive value ? Is is 1 or 3?

Also, is it sensitive to ''presense'' or non presence, or other logic?

[lightheaded]

Hi @ebaauw! Are you still working on getting regions to work without the Aqara app?

[popy2k14]

Hey guys, i have really strange issues with my 8x fp1 sensors. Sadly, i was so hyped about this type of radar zigbee sensor i have added them to every room. That was no good idea. I have those issues with them:

• sometimes they are just unreachable and come back again (every few minutes), repairing doesnt solve this.

• two of them are now stucked in "presence" state, re-pair, lower sensitivity doesnt solvethe issue. They are now unusable. Here is a thread on the home assistant forum: https://community.home-assistant.io/t/aqara-fp1-stuck-on-detected-occupancy/438350

Someone flipped the PCB inside the case and this solved the issue for him. Maybe a custom 3D case could solve the issue?

• The detection range is not 120 degrees as described. You have to get really straight to the sensor to get detected. Also the sensor is nothing for large rooms, because the range is too low.

Anyone of you have similar issues? Is there a firm,ware newer than 54?

PS.: i have written a support ticket to aqara about the issues. But i dont think there will come back something usefull.

thx

[ebaauw]

Hi @ebaauw! Are you still working on getting regions to work without the Aqara app?

It’s still on my todo list, but not in the upper regions.

sometimes they are just unreachable and come back again (every few minutes)

I saw that as well, until I moved them to a second network, with only end devices. Same for the Aqara E1 roller blind controller and the IKEA FYRTUR.

two of them are now stucked in "presence" state

There is a Zigbee call to force-clear the state. It’s exposed through the API, config/resetpresence.

The detection range is not 120 degrees as described.

As I understand, the detection zone is really a pie shape, rather than a square as suggested by the Aqara app. Placing the sensor is crucial (and challenging since it’s wired to power). I’m afraid my apartment isn’t big enough to exceed the range. Still not sure how the various settings influence the detection range.

I do have an issue with the vertical detection range: the register my ceiling fans, which I want to turn off when there’s no more presence. I put placed some aluminium foil above the sensor to block their vision, but have been fantasising to place that inside the housing.

[popy2k14]

sometimes they are just unreachable and come back again (every few minutes)

I saw that as well, until I moved them to a second network, with only end devices. Same for the Aqara E1 roller blind controller and the IKEA FYRTUR.

Dont want to make an new gateway/network just for this. My workaround is to retain the last value, this works reliable. Just wanted to know if i am alone and if there is another workaround.

two of them are now stucked in "presence" state

There is a Zigbee call to force-clear the state. It’s exposed through the API, config/resetpresence.

Yeah i know the call, which is also exposed to HA, but sadly half of the time, it just do nothing :-(

The detection range is not 120 degrees as described.

As I understand, the detection zone is really a pie shape, rather than a square as suggested by the Aqara app. Placing the

I do have an issue with the vertical detection range: the register my ceiling fans, which I want to turn off when there’s no more presence. I put placed some aluminium foil above the sensor to block their vision, but have been fantasising to place that inside the housing.

sensor is crucial (and challenging since it’s wired to power). I’m afraid my apartment isn’t big enough to exceed the range. Still not sure how the various settings influence the detection range.

Yeah, maybe i should place two of them in my big room, but with all the issues this sensor has. I likley will not buy another one,

PS.: Got answer from aqara with an standard nonsense answer, so i think that's a dead end :-(

Is there a firmware newer than 54?

[ebaauw]

According to my Aqara M2 hub (set to Mainland China to support the FP1), there's no newer firmware than 54.

[popy2k14]

ok, thx.

[patmalcolm91]

Has anyone figured anything more out regarding the raw sensor data on 0xfff2? I've been experimenting with my device and have started to understand the packet structure a bit more. I'm posting my findings here in the hope that it sparks more discussion.

I can confirm that writing 0x01to 0x0155 causes the device to start sending packets on 0xfff2. I receive two main types of packets: one that is 17 bytes long, and another that is 24 bytes long. The structure of the 24-byte packet is basically the same as that of the 17-byte packet, with the exception of two flag bytes (and of course the additional 7 bytes at the end):

aa:74:0b:84:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:00
aa:74:12:84:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:01:0G:HH:JJ:00:KK:LL:00

Bytes 1, 2, and 4 are always the same (and seem to also match those posted above in https://github.com/dresden-elektronik/deconz-rest-plugin/issues/5928#issuecomment-1167869104). My guess is these are either constant or possibly encode the firmware version information.

Byte 3 is always 0x0b in the 17-byte packet and 0x12 in the 24-byte packet (seemingly indicating the size of the packet in bytes after the header, excluding the null byte at the end).

Bytes 5-16 (marked as xx) seem to encode a packet ID and/or timestamp. Some sets of bytes count up together and others count down. They don't seem to encode any data from the sensor, though.

Byte 17 is always 0x00in the 17-byte packet and 0x01in the 24-byte packet.

For the 24-byte packet:

Byte 18 (marked as 0G) seems to be some sort of flag, always being either 0x00or 0x01 (EDIT: I've now seen some occurrences of the value 0x02 as well). I haven't yet found any pattern to indicate what it means, though. EDIT: I've found that the number encoded by the two bytes 0G:HHrepresents the distance from the sensor (i.e. the Y-coordinate). Specifically, 0x0G*0x100 + 0xHH is the distance away from the sensor in centimeters.

Bytes 21 and 24 are always 0x00.

Bytes 19, 20, 22, and 23 (marked as HH, JJ, KK, and LL respectively) seem to encode the actual raw sensor data. I tried interpreting plotting a live graph of (HH:JJ, KK:LL) and a few similar combinations (with this one being the best so far) walking around in front of the sensor, and there does seem to be some correlation, but the data is either too noisy, or I'm not interpreting the data quite right, so I don't see enough of a pattern to be confident. I've also tried only looking at packets with the 0G flag set or unset, and it hasn't helped.

Byte 20 (JJ), when interpreted as a signed 8-bit integer, appears to correlate with the left-right direction (X-coordinate), with a value of zero meaning directly in front of the sensor. This value is fairly noisy, however (especially when moving around), and the values seem to max out at around ±70 even when the motion is on the very edge of the quoted field of view. I suspect I'm still missing a detail here.

I still haven't found the pattern in bytes 22 and 23 (KK and LL).

Here is an example series of packets received from my sensor in case anyone wants to investigate themselves:

aa:74:0b:84:51:02:09:41:08:00:02:63:e2:d5:65:1e:00
aa:74:12:84:52:fa:09:41:0f:00:02:63:e2:d9:e8:1f:01:00:e0:e6:00:23:3c:00
aa:74:12:84:53:f9:09:41:0f:00:02:63:e2:d9:e9:20:01:01:2f:da:00:14:22:00
aa:74:12:84:54:f8:09:41:0f:00:02:63:e2:d9:ea:21:01:01:27:d9:00:06:e6:00
aa:74:0b:84:55:fe:09:41:08:00:02:63:e2:d9:eb:22:00
aa:74:0b:84:55:fe:09:41:08:00:02:63:e2:d9:eb:22:00
aa:74:12:84:56:f6:09:41:0f:00:02:63:e2:d9:ec:23:01:01:67:fd:00:07:2b:00
aa:74:12:84:57:f5:09:41:0f:00:02:63:e2:d9:f2:24:01:01:2b:0a:00:1f:0e:00
aa:74:12:84:57:f5:09:41:0f:00:02:63:e2:d9:f2:24:01:01:2b:0a:00:1f:0e:00
aa:74:12:84:58:f4:09:41:0f:00:02:63:e2:d9:f2:25:01:00:d9:08:00:a1:01:00
aa:74:12:84:59:f3:09:41:0f:00:02:63:e2:d9:f4:26:01:00:c3:f4:00:41:57:00
aa:74:12:84:5a:f2:09:41:0f:00:02:63:e2:d9:f4:27:01:00:b3:e9:00:37:36:00
aa:74:12:84:5b:f1:09:41:0f:00:02:63:e2:d9:f5:28:01:00:9d:03:00:a1:a1:00
aa:74:12:84:5c:f0:09:41:0f:00:02:63:e2:d9:f6:29:01:00:95:0e:00:2e:a6:00
aa:74:12:84:5d:ef:09:41:0f:00:02:63:e2:d9:f6:2a:01:00:96:0a:00:81:3a:00
aa:74:12:84:5e:ee:09:41:0f:00:02:63:e2:d9:f7:2b:01:00:9d:0b:00:7a:08:00
aa:74:12:84:5f:ed:09:41:0f:00:02:63:e2:d9:f8:2c:01:00:96:fa:00:4c:4a:00
aa:74:12:84:60:ec:09:41:0f:00:02:63:e2:d9:f9:2d:01:00:a5:11:00:48:a0:00
aa:74:12:84:61:eb:09:41:0f:00:02:63:e2:d9:fa:2e:01:00:96:00:00:56:38:00
aa:74:12:84:62:ea:09:41:0f:00:02:63:e2:d9:fb:2f:01:00:97:0a:00:59:76:00
aa:74:12:84:63:e9:09:41:0f:00:02:63:e2:d9:fb:30:01:00:9c:19:00:59:8f:00
aa:74:12:84:64:e8:09:41:0f:00:02:63:e2:d9:fc:31:01:00:aa:0e:00:be:6b:00
aa:74:12:84:65:e7:09:41:0f:00:02:63:e2:d9:fd:32:01:00:c3:22:00:6e:a5:00
aa:74:12:84:66:e6:09:41:0f:00:02:63:e2:d9:fe:33:01:00:a5:1b:00:52:ac:00
aa:74:12:84:67:e5:09:41:0f:00:02:63:e2:d9:fe:34:01:00:76:10:00:ca:44:00
aa:74:12:84:67:e5:09:41:0f:00:02:63:e2:d9:fe:34:01:00:76:10:00:ca:44:00
aa:74:12:84:68:e4:09:41:0f:00:02:63:e2:d9:ff:35:01:00:5b:03:00:78:7c:00
aa:74:12:84:69:e3:09:41:0f:00:02:63:e2:da:00:36:01:00:5f:f5:00:3b:65:00
aa:74:12:84:6a:e2:09:41:0f:00:02:63:e2:da:01:37:01:00:1d:e0:00:58:93:00
aa:74:12:84:6a:e2:09:41:0f:00:02:63:e2:da:01:37:01:00:1d:e0:00:58:93:00
aa:74:12:84:6b:e1:09:41:0f:00:02:63:e2:da:01:38:01:00:46:ff:00:49:f7:00
aa:74:12:84:6c:e0:09:41:0f:00:02:63:e2:da:02:39:01:00:31:fd:00:30:c0:00
aa:74:12:84:6d:df:09:41:0f:00:02:63:e2:da:03:3a:01:00:5d:f3:00:c0:84:00
aa:74:12:84:6e:de:09:41:0f:00:02:63:e2:da:0a:3b:01:01:2b:dd:00:0e:7b:00
aa:74:12:84:6f:dd:09:41:0f:00:02:63:e2:da:0b:3c:01:01:32:db:00:16:c9:00
aa:74:12:84:6f:dd:09:41:0f:00:02:63:e2:da:0b:3c:01:01:32:db:00:16:c9:00
aa:74:12:84:70:dc:09:41:0f:00:02:63:e2:da:0c:3d:01:01:16:d6:00:10:36:00
aa:74:12:84:71:db:09:41:0f:00:02:63:e2:da:0c:3e:01:00:dc:c5:00:0c:7b:00
aa:74:12:84:72:da:09:41:0f:00:02:63:e2:da:0d:3f:01:01:28:d9:00:06:d5:00
aa:74:12:84:73:d9:09:41:0f:00:02:63:e2:da:0e:40:01:01:5d:e0:00:07:71:00
aa:74:0b:84:74:df:09:41:08:00:02:63:e2:da:0e:41:00
aa:74:12:84:75:d7:09:41:0f:00:02:63:e2:da:0e:42:01:01:4a:de:00:1c:5c:00
aa:74:12:84:76:d6:09:41:0f:00:02:63:e2:da:0f:43:01:01:36:db:00:1c:03:00
aa:74:0b:84:77:dc:09:41:08:00:02:63:e2:da:10:44:00
aa:74:12:84:78:d4:09:41:0f:00:02:63:e2:da:15:45:01:01:53:df:00:07:29:00
aa:74:0b:84:79:da:09:41:08:00:02:63:e2:da:15:46:00
aa:74:0b:84:79:da:09:41:08:00:02:63:e2:da:15:46:00
aa:74:12:84:7a:d2:09:41:0f:00:02:63:e2:da:18:47:01:01:5b:e0:00:0b:0c:00
aa:74:12:84:7b:d1:09:41:0f:00:02:63:e2:da:18:48:01:00:aa:dc:00:36:e4:00
aa:74:12:84:7c:d0:09:41:0f:00:02:63:e2:da:19:49:01:00:75:e8:00:26:d2:00
aa:74:12:84:7c:d0:09:41:0f:00:02:63:e2:da:19:49:01:00:75:e8:00:26:d2:00
aa:74:12:84:7d:cf:09:41:0f:00:02:63:e2:da:1a:4a:01:00:59:e9:00:76:f5:00
aa:74:12:84:7e:ce:09:41:0f:00:02:63:e2:da:1a:4b:01:00:7c:fc:00:23:dd:00
aa:74:12:84:7f:cd:09:41:0f:00:02:63:e2:da:1b:4c:01:00:9c:07:00:58:01:00
aa:74:12:84:7f:cd:09:41:0f:00:02:63:e2:da:1b:4c:01:00:9c:07:00:58:01:00
aa:74:12:84:80:cc:09:41:0f:00:02:63:e2:da:1c:4d:01:00:a0:07:00:73:1b:00
aa:74:12:84:81:cb:09:41:0f:00:02:63:e2:da:1c:4e:01:00:a8:0c:00:13:55:00
aa:74:12:84:82:ca:09:41:0f:00:02:63:e2:da:1d:4f:01:00:a5:ee:00:8a:e6:00
aa:74:12:84:83:c9:09:41:0f:00:02:63:e2:da:1e:50:01:00:c1:f6:00:4f:09:00
aa:74:12:84:84:c8:09:41:0f:00:02:63:e2:da:1e:51:01:00:d6:01:00:c1:d7:00
aa:74:12:84:85:c7:09:41:0f:00:02:63:e2:da:1f:52:01:00:f1:14:00:76:d4:00
aa:74:12:84:86:c6:09:41:0f:00:02:63:e2:da:1f:53:01:01:07:13:00:2c:1a:00
aa:74:12:84:87:c5:09:41:0f:00:02:63:e2:da:20:54:01:01:0d:16:00:56:59:00
aa:74:12:84:88:c4:09:41:0f:00:02:63:e2:da:21:55:01:01:59:00:00:30:49:00
aa:74:12:84:89:c3:09:41:0f:00:02:63:e2:da:21:56:01:01:28:ee:00:aa:d5:00
aa:74:12:84:8a:c2:09:41:0f:00:02:63:e2:da:22:57:01:01:29:f0:00:2e:d8:00
aa:74:12:84:8b:c1:09:41:0f:00:02:63:e2:da:24:58:01:01:3a:e0:00:17:48:00
aa:74:12:84:8c:c0:09:41:0f:00:02:63:e2:da:25:59:01:01:1d:f9:00:27:81:00
aa:74:12:84:8d:bf:09:41:0f:00:02:63:e2:da:29:5a:01:01:67:f5:00:0b:e5:00
aa:74:12:84:8d:bf:09:41:0f:00:02:63:e2:da:29:5a:01:01:67:f5:00:0b:e5:00
aa:74:0b:84:8e:c5:09:41:08:00:02:63:e2:da:2a:5b:00
aa:74:12:84:8f:bd:09:41:0f:00:02:63:e2:da:2c:5c:01:01:43:dd:00:06:91:00
aa:74:12:84:90:bc:09:41:0f:00:02:63:e2:da:2c:5d:01:01:1d:d7:00:07:36:00
aa:74:0b:84:91:c2:09:41:08:00:02:63:e2:da:2d:5e:00
aa:74:12:84:92:ba:09:41:0f:00:02:63:e2:da:32:5f:01:01:3b:dc:00:07:97:00
aa:74:12:84:93:b9:09:41:0f:00:02:63:e2:da:33:60:01:01:4f:de:00:07:b1:00
aa:74:12:84:94:b8:09:41:0f:00:02:63:e2:da:34:61:01:01:42:dd:00:06:7a:00
aa:74:12:84:95:b7:09:41:0f:00:02:63:e2:da:34:62:01:01:3d:dc:00:06:b5:00
aa:74:12:84:96:b6:09:41:0f:00:02:63:e2:da:35:63:01:01:28:d9:00:07:27:00
aa:74:12:84:97:b5:09:41:0f:00:02:63:e2:da:36:64:01:01:16:d6:00:06:39:00
aa:74:12:84:98:b4:09:41:0f:00:02:63:e2:da:37:65:01:01:2b:da:00:06:4f:00
aa:74:12:84:99:b3:09:41:0f:00:02:63:e2:da:37:66:01:01:4a:de:00:06:21:00
aa:74:12:84:9a:b2:09:41:0f:00:02:63:e2:da:38:67:01:01:07:d3:00:09:60:00
aa:74:12:84:9a:b2:09:41:0f:00:02:63:e2:da:38:67:01:01:07:d3:00:09:60:00
aa:74:12:84:9a:b2:09:41:0f:00:02:63:e2:da:38:67:01:01:07:d3:00:09:60:00
aa:74:0b:84:9b:b8:09:41:08:00:02:63:e2:da:39:68:00
aa:74:0b:84:9b:b8:09:41:08:00:02:63:e2:da:39:68:00

[michalmo]

@patmalcolm91 thanks for this reverse engineering work on the 0xfff2 data packets, the missing piece is that byte JJ is the angle from center in degrees. Distance, angle and some trigonometry gives you the X and Y coordinates (my testing shows that each square of the grid is 1 meter x 1 meter).

[slavendam]

Did anyone succeed to get distance and angle from Aqara FP2 sensor?

[amaisano]

FYI firmware 58 is now available for the FP1.

[greyman12]

Did the latest firmware break the ability to use regions?

[tophee]

@greyman12 no, the firmware is not the problem. I upgraded to version 58 several weeks ago and the regions worked fine. It seems more likely that one of the latest releases of Zigbee2MQTT broke something. I managed to get regions to work again after I downgraded to v1.35.1.