This device seems to have the wrong finger print id associated with it.
Hubitat thinks that it is the Heiman 4 Button Key fob.
ID:
Logs:
ID:
Logs:
Only the wall switches are tested compatible at this point, so that’s expected. The fingerprint isn’t in the generic driver and there’s no dedicated driver for it.
Can you please switch the driver to Device, press Get Info and post the fingerprint here for @mike.maxwell
Well then if you can capture the fingerprint right after pairing (have to remove the existing driver that it is bound to), that would be very helpful.
What am I doing here?
Making up a driver for the Tuya PIR Motion sensor model RH040.
Or, modifying the generic zigbee motion sensor, to handle this device.
Does this device work correctly with the generic zigbee motion sensor (no temp) driver?
No.
It paired first as a Heiman key fob with 4 buttons.
But switching to the generic zigbee motion sensor (no temp) driver, saving and clicking Configure yields no response from the sensor?
Correct.
Bummer. Do any of the built-in drivers work even partially with it?
Some of these don't wake up periodically, so will be deaf to any attempts to configure them.
Try switching to the driver, enabling debug logging, then re-pairing in place (i.e. discover ZigBee devices and factory reset the device). When it pairs it will run configure() on the driver you assigned and as it's a fresh pairing it will be awake to receive the config.
well someone sent me one of these, I don't know who, but thanks! I can confirm it works out of the box and joins using generic zigbee motion sensor (no temp) driver, I've added the fingerprint.
The only difference between the fingerprint of the unit I have and the one provided above is the manufacturer:"TUYATEC-b5g40alm" of mine vs TUYATEC-53o41joc...
It seems a decent little sensor, 60 second timeout, and whilst coin powered, it uses the beefy CR2450, and nothing weird noted!
Thanks, @mike.maxwell.
Does it follow the standard Zigbee reporting requests?
That is, if you ask it to report every hour, will it do so?
(Obviously, I'm asking so that I can use that to determine if the device is still active on my network, or not.)
Motion uses the IAS cluster, which almost all motion devices do, this cluster isn't configurable.
I didn't run it long enough to determine what the battery reporting interval was, but it's not going to be every hour.
So to answer your question, no, its not going to report anything every hour.
@mike.maxwell
I only meant battery reporting as an example.
Is there anything that this will report on, and on what frequency will it do it?
Is that customizable in the driver (I know that the answer to this is no.).
In general, for Zigbee, battery powered sensors, I've been checking daily activity. No activity for 24 hours - start investigating, to see if the battery needs replacing.
With your greater experience, is this a good approach to detecting battery failure? Or, would you suggest some other type of test at some other frequency?
I know that nothing is "certain" in this area, but any advice is always appreciated!
24 hours is a good interval, we encourage our drivers to configure battery reports every 12 to 18 hours, not all devices will honor this.
I have the same device model, RH3040, with manufacturer listed as TUYATEC-bd5faf9p. In my case it's marketed as Nedis Zigbee Motion Sensor (PIR).
The generic driver doesn't work, and the motion attribute does not appear in the top right of the device.
Switching to a custom community driver, the "Konke Zigbee Motion Sensor", reveals the motion attribute in the top left. State then works with the test button on the device itself, but oddly not with the actual PIR sensor. Setting the wait-to-inactive state attribute works correctly.
Switching back to the "Generic Zigbee Motion Sensor (no temp)" driver retains the motion attribute but it stops working.
In all cases, the PIR itself returns no signal.
Pressing the "Get info" button returns nothing, so I can't post anything from that.
Using Hubitat 2.3.0.116 on hardware C-7.
Any thoughts?
Update to my own post: Switch forth and back between the Konke driver and the genric driver has rendered one of the sensors in a working state using the Generic driver. But I am unsure why, and I can't seem to reproduce the behavior. Resetting and re-pairing a device makes it find the generic driver, but the state is then registered as active all the time and never changes (and no data is inserted into the log). Not sure if this wonky behavior is relevant, but posted in case it is. 
