I'm a little confused about the "Configure" and "Refresh" buttons on a device's page. Can anybody tell me if my thought is correct:
I need to change this device motion sensitivity from its current value of 10, to 6.
I would make the change in "Preferences" and press Save Preferences.
But to get the setting to the device I also need to press "Configure"(?) is this right?
It is a sleepy device so I might need to wait a while, maybe even hours until the device wakes up and talks to Hubitat. It shows "pendingConfig" during this time.
After that, the motion sensor receives the new setting and will no longer be "pendingConfig"
I think maybe I don't actually need the "Refresh" button for the above scenario. As far as I can tell that just tells the device "next time you talk to me, give me all your settings so I can make sure I am displaying them correctly"
But generally, configure would be used to apply all the configuration settings to the device. They could be the preferences you have set as well as anything extra that should be set on the device (maybe something like wake up time).
Again depending on the driver, clicking on save settings should apply/update the settings you changed. It may apply it only if it thinks it was changed.
One thing to keep in mind (again depending on the driver), an update config command could be sent to the device and then it waits on the device to return a result to confirm its been changed and thatn state variable should be updated.
With sleepy devices its possible that the hub is waiting on the device to wake up and return the update. Sometimes you can force this wakeup by pressing a button on the device or even triggering the device. Every device is different.
I have seen situations where when the network is too busy that the response with the updated setting does not make it back to the hub. It gets lost somewhere, but it did get applied on the device itself. Sometimes hitting config a couple times gets everything updated.
The refresh button (depends on how its implemented) may just do something like ask the device for the latest temperature or open/close state. Its not necessarily used to apply the configuration values.
I see, so its not so much a Hubitat feature but a device feature- each device is asked to implement a "Configure" and "Refresh" feature based on a loose concept and each implements it however they wish, like the Wild West. I triggered this sensor to see if it would take the new value but its still pending. I know if I just wait a couple hours it will eventually take, which is fine. Thanks for the insight!
Correct. Its a good and a bad thing. Nice to have flexibility, but also up to the dev to implement it how they want.
For example, when I write my drivers, the configure button resets all the state variables, applies all the settings and then queries the device to get its current values and updates the state variables again.
When I click on save preferences I have it only apply changed values.
I did it this way as I didn't want it to send out 50 different commands just for me updating one value. That would take too long too.
I'm sure the built in drivers have a standard they follow though, but since we can't see I can't say exactly what it is and if its the same across all devices.
Also, it's not even required to implement these features, so you will find some drivers that don't even have them since the author did not find it a useful feature to have.
As mentioned above, yes, that is the goal. Depending on how the driver was written, "Save Preferences" may not do anything different from "Configure," and you'll notice that on hub firmware 2.2.7, "Configure" has been removed from some drivers for this reason. But for your changes to apply, if it's a "sleepy" device, you'll still need to wait for it to wake up. Most battery-powered Z-Wave devices are sleepy. Most powered devices and most Zigbee devices of any kind are not, though individual devices will vary.
What kind of device is this, and what driver is it using? Based on your screenshot, it looks like it was written by one of the Z-Wave driver authors who usually helpfully includes messages in the logs after you save preferences or hit "Configure" that tell you how to wake the device. The logs are often also useful for seeing if the device does wake up (with debug logging enabled, you'll see a WakeUpNotification command getting parsed from what the device sends to the hub and likely the driver sending or requesting configuration changes). So, besides looking at "Current States," the logs will likely be of help if you want to make sure.
Otherwise, waiting for the next wake up interval to pass will work, too. By default this is once or twice a day for a lot of devices, though some drivers/devices let you configure this too (though there's generally little reason to). I have never seen a sleepy Z-Wave device where a "regular" event like motion causes an actual wakeup (in the specific sense of what this means for sleepy Z-Wave devices), though I don't doubt that there could be some oddballs out there.
This is a Zooz ZSE29 Z-Wave outdoor motion sensor, driver type "Zooz Outdoor Motion Sensor". You are right about the messages telling how to wake, that is nice! (screenshot below). I hadn't noticed it before because I only looked at the "Events" button on the specific device page (as at the top of the first screen shot above), which doesn't have all the same details as the overall Hubitat log. I mistakenly thought both log views showed the same info just presented differently.
This particular device seems to "wake" and apply settings with battery updates (about twice a day) but not for motion or lux updates.
Depending on how the driver was written, "Save Preferences" may not do anything different from "Configure," and you'll notice that on hub firmware 2.2.7, "Configure" has been removed from some drivers for this reason. But for your changes to apply, if it's a "sleepy" device, you'll still need to wait for it to wake up. Most battery-powered Z-Wave devices are sleepy. Most powered devices and most Zigbee devices of any kind are not, though individual devices will vary.
