The type of power source used while joining the device determines the type of device it’s joined as and it can’t be changed afterwards.
When the device is joined as a powered device it won’t report the battery level or go to sleep so if you try powering it by batteries they’ll probably die within a day.
When the device is joined as a battery device you can still power it by USB, but it behaves like a battery device so you have to manually wake the device up if you make changes to the settings.
Important
I’ve noticed that motion reporting sometimes stops working after changing settings and/or manually waking the device up, but if you point it away from you for a few minutes it should start working again.
I second the request for temperature correction, it really should be baked in day 1. I have two I am testing out, but have hopes to use them as wired high-polling-rate temperature sensors for my thermostat if everything works how I want it.
Hey @krlaframboise
Have you encountered an issue with this sensor in bright sunlight the lux reading is 0? One can simulate it with a bright LED flash light on the sensor as well.
I need the information shown in live logging because it shows the actual data being sent from the device. If you could remove // from in front of the log.trace line at the bottom of the code before producing the live logging data that would be even more helpful…
It looks like that trace logging will be necessary because regular logging doesn’t display the raw sensormultilevel data, but next time before posting the results please click on “Motion Sensor” so that none of the logs for your other devices are shown. Thanks
No, that was my fault, I figured that method had a logtrace line, but it doesn’t.
Can you put the line of code below in between lines 384 and 385 and try one more time. I only need the last screenshot showing the logging results, but make sure that next time you actually have a log entry showing that it reported 0 and the lines will be longer so make sure that none of the information gets cutoff.
The scaledSensorValue in the first trace line from the bottom shows a negative value which is why my handler is reporting it as 0.
According to the z-wave specs for this command class the value sent by the device must be a signed decimal, but the device is sending values over the maximum positive value of a 2 byte signed decimal so ST is converting it into a negative value which is the expected behavior for this command class.
The device should be sending reports with the size field set to 4 instead of 2 so I’ll report that firmware bug to Zooz, but I can add a workaround to the handler to make it report the correct value.
Noticed the device association with SmartThings correctly picked the custom ‘Zooz Q Sensor’ DH this time too, which its never done in the past.
Even though its night, shining the same LED flash light at the sensor registered over 35,000 lux, which hasn’t happened before. Looks like they fixed it.
