Unfortunately that didn't work either. First, I tried various ways to start from a clean state before starting:
- just remove the device from HE (force remove)
- remove from HE and set to pairing mode (5 sec press on device)
- remove from HE and set to pairing mode (5 sec press on device), after that do the 10sec press - 1 sec wait - 5 seconds press reset
Always the same effect: after the second pairing when I single press the button, I never get the 'previously paired' message. When I do a 5 seconds press instead, it gives me the 'previously paired' but the results are the same.
Current States
- powerSource : dc
is the only thing I get. Following is the communication log after the second pairing.
dev:7882023-03-12 02:07:19.210 PMinfofp-test2 Received Write Attribute Response for cluster:FCC0 , data=[00] (Status: Success)
dev:7882023-03-12 02:07:19.208 PMdebugfp-test2 parse: Desc Map: [raw:catchall: 0104 FCC0 01 01 0040 00 6F72 00 01 115F 04 01 00, profileId:0104, clusterId:FCC0, clusterInt:64704, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:6F72, isClusterSpecific:false, isManufacturerSpecific:true, manufacturerId:115F, command:04, direction:01, data:[00]]
dev:7882023-03-12 02:07:19.202 PMdebugfp-test2 parse: description is catchall: 0104 FCC0 01 01 0040 00 6F72 00 01 115F 04 01 00
dev:7882023-03-12 02:07:19.193 PMinfofp-test2 Received Write Attribute Response for cluster:FCC0 , data=[00] (Status: Success)
dev:7882023-03-12 02:07:19.189 PMdebugfp-test2 parse: Desc Map: [raw:catchall: 0104 FCC0 01 01 0040 00 6F72 00 01 115F 04 01 00, profileId:0104, clusterId:FCC0, clusterInt:64704, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:6F72, isClusterSpecific:false, isManufacturerSpecific:true, manufacturerId:115F, command:04, direction:01, data:[00]]
dev:7882023-03-12 02:07:19.184 PMdebugfp-test2 parse: description is catchall: 0104 FCC0 01 01 0040 00 6F72 00 01 115F 04 01 00
dev:7882023-03-12 02:07:19.036 PMinfofp-test2 Received Write Attribute Response for cluster:FCC0 , data=[00] (Status: Success)
dev:7882023-03-12 02:07:19.033 PMdebugfp-test2 parse: Desc Map: [raw:catchall: 0104 FCC0 01 01 0040 00 6F72 00 01 115F 04 01 00, profileId:0104, clusterId:FCC0, clusterInt:64704, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:6F72, isClusterSpecific:false, isManufacturerSpecific:true, manufacturerId:115F, command:04, direction:01, data:[00]]
dev:7882023-03-12 02:07:19.028 PMdebugfp-test2 parse: description is catchall: 0104 FCC0 01 01 0040 00 6F72 00 01 115F 04 01 00
dev:7882023-03-12 02:07:19.006 PMdebugfp-test2 Unprocessed FCC0 attribute report: cluster=FCC0 attrId=00FF value=23300F9D30EC10398DE83780873E9D59 status=null data=null
dev:7882023-03-12 02:07:19.003 PMdebugfp-test2 parse: Desc Map: [raw:6F7201FCC028FF00411023300F9D30EC10398DE83780873E9D59, dni:6F72, endpoint:01, cluster:FCC0, size:28, attrId:00FF, encoding:41, command:0A, value:23300F9D30EC10398DE83780873E9D59, clusterInt:64704, attrInt:255]
dev:7882023-03-12 02:07:19.000 PMdebugfp-test2 parse: description is read attr - raw: 6F7201FCC028FF00411023300F9D30EC10398DE83780873E9D59, dni: 6F72, endpoint: 01, cluster: FCC0, size: 28, attrId: 00FF, encoding: 41, command: 0A, value: 1023300F9D30EC10398DE83780873E9D59
dev:7882023-03-12 02:07:18.995 PMinfofp-test2 Received Write Attribute Response for cluster:FCC0 , data=[00] (Status: Success)
dev:7882023-03-12 02:07:18.983 PMdebugfp-test2 parse: Desc Map: [raw:catchall: 0104 FCC0 01 01 0040 00 6F72 00 01 115F 04 01 00, profileId:0104, clusterId:FCC0, clusterInt:64704, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:6F72, isClusterSpecific:false, isManufacturerSpecific:true, manufacturerId:115F, command:04, direction:01, data:[00]]
dev:7882023-03-12 02:07:18.870 PMdebugfp-test2 parse: description is catchall: 0104 FCC0 01 01 0040 00 6F72 00 01 115F 04 01 00
dev:7882023-03-12 02:07:18.769 PMdebugfp-test2 sending ZigbeeCommands : [he raw 0x6F72 0 0 0x8002 {40 00 00 00 00 40 8f 5f 11 52 52 00 41 2c 52 00 00} {0x0000}, delay 50, he raw 0x6F72 1 01 0xFCC0 {14 5F 11 01 02 FF 00 41 10 02 32 71 76 20 79 16 48 28 87 18 12 21 55 72 36} {0x0104}, delay 50, he raw 0x6F72 1 01 0xFCC0 {14 5F 11 01 02 50 01 41 07 01 01 ff ff 00 00 ff} {0x0104}, delay 50, he raw 0x6F72 1 01 0xFCC0 {14 5F 11 01 02 50 01 41 03 06 55 35} {0x0104}, delay 50, he raw 0x6F72 1 01 0xFCC0 {14 5F 11 01 02 50 01 41 07 01 02 ff ff 00 00 ff} {0x0104}, delay 50, he raw 0x6F72 1 01 0xFCC0 {14 5F 11 01 02 50 01 41 03 06 55 35} {0x0104}, delay 50, he wattr 0x6F72 0x01 0xFCC0 0x0155 0x20 {01} {115F}, delay 50, he raw 0x6F72 1 01 0xFCC0 {14 5F 11 01 02 f2 ff 41 aa 74 02 44 00 9c 03 20} {0x0104}, delay 50, he raw 0x6F72 1 01 0xFCC0 {14 5F 11 01 02 f2 ff 41 aa 74 02 44 01 9b 01 20} {0x0104}, delay 50]
dev:7882023-03-12 02:07:18.765 PMdebugfp-test2 aqaraBlackMagic() for FP1
dev:7882023-03-12 02:07:18.761 PMinfofp-test2 Received device announcement, data=[01, 72, 6F, 49, 8A, 65, 00, 10, 44, EF, 54, 8C] (Sequence Number:01, Device network ID: 6F72, Capability Information: 8C)
dev:7882023-03-12 02:07:18.758 PMdebugfp-test2 parse: Desc Map: [raw:catchall: 0000 0013 00 00 0040 00 6F72 00 00 0000 00 00 01726F498A65001044EF548C, profileId:0000, clusterId:0013, clusterInt:19, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:6F72, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[01, 72, 6F, 49, 8A, 65, 00, 10, 44, EF, 54, 8C]]
dev:7882023-03-12 02:07:18.753 PMdebugfp-test2 parse: description is catchall: 0000 0013 00 00 0040 00 6F72 00 00 0000 00 00 01726F498A65001044EF548C
sys:12023-03-12 02:07:13.237 PMinfoZigbee Discovery Running
Is this on a C-7?
The reset procedure for the device is to hold the button until the light blinks three times, then let go (this takes about 5 seconds).
You also may need to be fairly close to the hub during the pairing process until you get the rest of the attributes. Then you can move it wherever.
@marco_t at the moment there are so many hiccups with various Zigbee devices related to the latest HE platform change, so that you'll never be sure whether the problem is with the particular device and driver, or it is a system issue. I would wait for a week or two, until the HE system stabilizes. Currently, there are problems pairing other super-standard Zigbee sensors such as GE Dimmers and Hue motion sensors... and there are HE system updates almost daily.
There are too many non-standard initialization commands in this driver, which is one of the reasons for the problematic pairing to HE. For me, two or three pairing attempts very close to the hub (less than 1 meter away!) has always worked, but everyone's environment is always different.
thanks @FriedCheese2006 for clarifying. I thought 5 seconds is pairing. learned something some. And no, this is a c-8.
@kkossev good call-out, I noticed the higher update frequency. I might play around a bit more but not invest too much time.
that seems to have done the trick. I am still not getting the 'previously paired' message during the 2nd pair, BUT the Current States now show up and update.
So I've just bought two if these FP1 sensors. I paired them (successfully I think!) By:
- hold the parking button 5 seconds. See Hubitat add it as a 'decive'. Wait 2 minutes
- add the Aqara P1 driver to my Hubitat. Change it from 'Device' to the driver
- pair by holding the button 5 seconds,
- repeat step 3
It appears to be paired successfully. However, it seems to be awfully slow. It takes around 3-5minutes to detect motion (presence and motion state changes at the same time), and approximately 10minutes to clear presence and motion.
Is that normal? Or is it something that'll speed up more after I use it more? Thanks!
This is what I'm getting:
- endpointId: 01
- application: 36
- aqaraModel: RTCZCGQ11LM
- inClusters: 0000,0003,FCC0
- manufacturer: aqara
- model: lumi.motion.ac01
- outClusters: 0003,0019
- softwareBuild:
Holding the button for 5 seconds completes a factory reset and shouldn't be done during normal pairing. You shouldn't need to change the device type from "Device" to this driver manually. That will occur during a successful pairing. This is probably contributing to the 'delays' with reporting. I would:
- Reset the FP1 by holding the button on the back until the light blinks three times, then let go.
- Put the Hubitat hub into pairing mode.
- Wait for pairing to complete.
- Test again.
Ensure that you are within a few feet/a meter of the hub when initially pairing.
Thanks for that. I just followed that:
- Removed the device
- Unplugged, moved it within 10 cm of the hub, plugged back in
- Hold the paring button for 5 seconds (the light blinked 3 times
- Paid successfully with the Hub, with the drivers already installed
It still isn't responding (or very slowly responding), the 'data' is showing:
- endpointId: 01
- application: 36
- aqaraModel: RTCZCGQ11LM
- manufacturer: aqara
- model: lumi.motion.ac01
I'm on 109 using the C-8 hub. I'm reading this post, and it seems to suggest I need to pair it twice? The single click of the pairing button doesn't seem to put mine into pairing, the only way I can get it to repair is by holding it for 5 seconds until the light blinks. When this happens, it will pop up as a 'previously paired device'.
Oh...you should do this then:
There is even newer platform version in beta testing now ( 2.3.5.112 ), better wait until it is rolled out and try again.
Yes, with this driver it is obligatory. Don't delete the device, just pair it twice, some may need even more tries. Pair it very close to the HE hub (1-2 meters away at maximum), once it starts reporting you can move it to its final destination. Keep it away from electronic devices that may generate electromagnetic fields, this device is very sensitive. Try changing the USB power supply as well.
Ive got several available and looking for a solution
Jonathan looking for a solution for fp1 issues regarding interference would be available for some testing i have 4 extra fp1 to use
Resolved! The double posturing was all I needed.
Working really well,
@kkossev, I've tried the latest beta on my C7... not sure if it's me, but it feels like there is a slight delay in activating my bedroom light with the beta version.
I have re-installed the stable version and it definitely feels like the delay has gone, weird!
Note that my sensor is mounted in the same position and not moved, just changed drivers.
Not sure if the beta team has reported a similar experience?
By latest beta do you mean the "Aqara P1 Motion Sensor" version 1.4.0 dated 2023/03/16 11:43 PM ?
Or you mean the HE platform Beta Release 2.3.5.117 ?
Sorry, I meant the Aqara P1 Motion Sensor" version 1.4.0 dated 2023/03/16 11:43 PM development driver.
There shouldn't be any difference in the speed of detecting 'motion' between versions 1.2.4 and 1.4.0 .. But I will pay attention at this when I come back to this driver, thank you for the report!
Hey @iEnam, I now noticed that I have forgotten to update the dev. branch to the latest code. It is now ver 1.4.1 +some other minor fixes. Can you try again if you notice any issues? Thank you for your help!
