First, there's a built-in driver for the Zooz ZSE11 "Q Sensor" that you may wish to consider using (at the moment, it has problems with motion, but I imagine those will be fixed soon). However, if you want something it doesn't provide or want to customize the driver, here's one I wrote for this device. It provides access to all parameters described in the manual, should accommodate either USB or battery power (as noted: don't switch it up after installation, or at least don't switch USB to battery). Other than that, it should work as expected, providing attributes for motion, temperature, humidity, lux, and tamper (which is apparently just moving the sensor).
Currently only on GitHub. May add it to HPM if there is interest:
(To install, follow the usual steps: copy and paste code from "Raw" link into "Drivers Code.")
For anyone using this: I just uploaded a minor update with a couple minor fixes, mostly affecting the refresh() and configure() commands and initial pairing (should now correctly detect power source sooner in all cases and run configure() on initial pairing when it should be awake regardless of power source, which it may not have done before).
Thank you for this driver . Have been using it on two zse11s and seem to have an issue with the refresh of the temp. Temp seems to only update after doing a manual refresh. If displayed on the dashboard as a tempureture ti does not change at all. Try with zse11 at room temp and on top of a glass of ice. Temp only change after a manual refresh. Hubitat C-7 with latest fw.
Thanks for the report! I found a typo there (and in another parameter) where I had the incorrect size, so setting the configuration parameter failed.
I also do some more testing and got everything to work reliably when on USB power. For some reason, on battery power, some of these configuration sets appear to not be working. Basic Z-Wave Tool works more reliably but still not 100%, so not sure if it's something with this driver or a timing thing or what...I'll have to do some more playing around to figure that one out.
You might see if increasing delay between commands or adding some delay before the NMI makes a difference. I have seen issues like this with other similar battery sensors in the past.
I've put the delay up to 1000 ms and it didn't seem to matter, though I took it back down a bit since it didn't seem to help that much. I thought about increasing the delay before the NMI--and tried to do so in my latest revision--but should probably find a more elegant solution than pauseExecution() (which I settled on), or maybe I just didn't "delay" long enough. Feel free to experiment and let me know anyone figures out anything.
(On a related note, I wish Hubitat would publish an example of what they consider a "good" driver for battery-powered Z-Wave devices. I've seen some community drivers that just assume the device is awake for a configure()--sending the commands and not seeming to care what, if anything, happens--and some that wait for the WakeUpNotification (which I'm doing and sounds preferable), and I'm not sure what other considerations there may be...again, all for "sleepy" devices. Listening ones are much easier!)
Hey guys, am I missing something here ? Both the default driver supplied by hubitat as well as this driver I updated both do not show any motion status.. All of my other motion detectors clearly show motion status... here's a display from an AEON Motion Sensro:
Probably not missing anything, but it's a mystery either way. My suggestion: with either my driver or Hubitat's, take a look at the logs while you have debug logging enabled (remember that it automatically disables itself after 30 minutes). If you don't see see any debug logs generated while you believe the sensor should detect motion, then there is some odd problem. With firmware 1.09 on the sensor (I believe the only version they've shipped publically), you should see a SensorBinaryReport, though with older firmware (or current firmware with a hidden parameter set) you may see a NotificationReport instead (which, if you're using Hubitat's 2.2.6 driver, is what it's looking for and is why that doesn't currently work; but keep in mind that NotificationReport is also used for tamper, so unless you look at the actual values inside, it could be at least either of these).
Also, if you haven't tried this yet, I'd recommend using my driver and leaving the sensor alone for a bit so its actual motion sensor "resets," then come back to it and generate motion (by default, it will flash blue, though this is a parameter you can disable; I also have bad luck with this if I'm "too close" to the sensor, FWIW). That will ensure the senor actually sends something, which it might not have been doing if there was constant motion. I'd only recommend my driver for the moment given the likely problems your firmware will have with Hubitat's current model, though either should work once that's addressed.
Thanks for that.. After about 45 minutes or so and after using the driver references in your reply, it magically started showing the motion category. This begs a a question; when you update a driver, does it update the device itself, or does it just update the controller's interpretation of the data coming from the device ? And, is there something the user can do to accelerate the change once you update the driver, or at least to make sure that it's been installed correctly ?
My understanding is that in the underlying system, each driver is a class that is attached for processing device events. Replacing the code replaces this class, but doesn't execute any code methods. As a result, sometimes it maybe necessary to trigger the updated() method by saving the device preferences; for sleepy devices like this one, some updates may not be executed until the next device wakeup occurs -- it all depends on the changes in that new code revision what, if anything, is needed for changes to complete.
What does "Current States" on the device page look like? My guess is that there are no temperature reports coming in for whatever reason, no value there, and thus no Dashboard template that can display these values.
Well.......I let this just sit there overnight and this morning there is a temp reading. If I blow on the sensor for a few seconds it sure enough increases both temp and humidity which is what I would expect.
Oddly, although motion still works, it take a longer time to reset though. Last night it seemed to show the motion state virtually instantly and when I stopped the motion it would go back to inactive also pretty much instantly. This morning it takes about 10 seconds for the motion to go back to inactive once I stop that motion. It is possible that I was still using the Hubitat driver at that moment though.
Not sure if this is the latest information for the Zooz Q sensor, but I was just gifted one for Christmas. I was expecting it to be Hubitat compatible by now, but I can't find it in the compatibility list. Is this community drive still the best option? And if so, is it available via Package Manger yet? Thanks!
There is a built-in driver, not sure why it isn't on the list. This one isn't in HPM but it's easy to install manually if you do prefer it for whatever reason.
My suggestion: with either my driver or Hubitat's, take a look at the logs while you have debug logging enabled (remember that it automatically disables itself after 30 minutes). If you don't see see any debug logs generated while you believe the sensor should detect motion, then there is some odd problem. With firmware 1.09 on the sensor (I believe the only version they've shipped publically), you should see a 
