Zooz outdoor sensor v2.0 varying sensitivity

Bought 2 of these and like them ‘cept they aren’t totally weather-proof. I didn’t heed that warning and it cost me. So be warned!

I would like to use time of day to send a custom command to change sensitivity in these units. I’m not a coder and it isn’t apparent to me, other than using config() somehow. Can anyone help with custom command string(s) that the Zooz driver will accept /recognize/execute when the time of day app I intend to write in Rule Machine 4 triggers a change in sensitivity? Thanks!

Good question, I am along for the ride now.

The sensitivity on this device can only be manipulated one of two ways: the knob on the sensor, or the preference on the driver page (which ultimately manipulates a Z-Wave parameter). While the second sounds promising, apps--including rules--can't manipulate preferences on a device page; they can only run things that are exposed as commands. On the device page, commands are shown as buttons at the top of the page in the admin UI, and as you can see, there isn't one that would do this ("custom commands" in RM just let you run any of these commands that built-in Rule Machine actions can't already do), If there's a custom driver floating around for this somewhere, it may be able to be modified to add a command for this, but I'm not aware of any off the top of my head. The other issue is how long the Z-Wave device would take to "wake up" to receive this configuration change; the default interval is 4 hours, and the Hubitat driver does not provide customization for this (again, a custom driver might be able to). So, even if you could do this, it's likely things still won't work quite as well as you'd hope.

Are your sensors in the same area? If so, an alternative would be to group them together with an app like Zone Motion Controllers so that (for example) you'd need two of them to "activate" before you'd consider there to be motion during certain modes (e.g., daytime-oriented modes) and just one otherwise. You could also restrict whatever automation you're using the sensor with to behave differently at day or night (this would work well for motion lighting but obviously less well if you want to send an "OMG, someone is outside!" notification to your phone any time motion is detected, in which case I can see why you'd want this :slight_smile: ).

Final answer? Ok I guess...
Stimulated another question: how is the Zooz sensor not awake and yet able to detect motion?

From my log file:
dev:16502020-07-02 17:46:42.015 errorgroovy.lang.MissingMethodException: No signature of method: zoozOutdoorMotionSensor.configure() is applicable for argument types: (java.lang.String) values: [configVal3(5)] Possible solutions: configure() (configure)

It’s the line about “possible solutions” what gave me hope that there was a way to change the configVal3 parameter using custom commands.

:face_with_monocle:

The wakeup interval is how often the device "wakes up" (from its normal sleepy state, which it does to save batteries--so this generally doesn't apply to mains/USB-powered device) and checks in with Hubitat (or whatever your controller is). This is when it will receive any configuration changes you sent to it. Sensors normally sleep because they don't need to receive anything from the hub (this being an exception), just send things to it. This is unrelated to the fact that the device will send a message to the hub whenever it needs to, e.g., for motion (or lux or whatever)--that just isn't a time when it will do this check.

Some devices solve this by doing tiny wake-ups on a very frequent basis: door locks, blinds/motors, etc. These devices do need to receive messages from the hub on a regular basis. The solution here is "beaming," where they'll just wake up a bit to see if there's anything for them, fully wake up if so, or go back to sleep if not. Most sensor-only devices won't do this, presumably because it's more work to implement for little to no return. (And again, then you also have powered devices like switches/dimmers or smart plugs that don't need to conserve battery and don't sleep in the first place.)

Back to this issue, "possible solutions" is a programming thing: the language compiler/interpreter (for Groovy, which this driver is written in) is just trying to be helpful and suggest method ("function" in other languages) signatures that might match what you're trying to do since whatever was attempted didn't work (in this case, it looks like calling a method that doesn't exist). :slight_smile:

Wow! Thanks for spending so much time and effort on this very comprehensive answer. As far as I’m concerned, this topic is closed.