Any performance benefit to reducing number of device attribute reads?

[badbob]

My rule has many conditions that reference the attributes of devices and many conditions repeat the same checks. Is there any performance benefit to read from the attribute from the device once at the start of the rule, store the result in a local variable, and then reference that local variable in conditions?

I think device attribute reads are from the hubitat database and does not involve an actual read from the physical device. And that the hubitat database is updated by periodic polling of the physical device's attributes. So I guess my question is if there is a performance hit with repeat queries of the hubitat database.

Example of current rule in psuedo-code:

if (device.battery > 80 AND device.switch.state = ON) then
// do something
else-if (device.battery > 80 AND device.switch.state = OFF) then
// do something
else-if (device.battery < 70 AND device.switch.state = ON) then
// do something
else-if (device.battery < 70 AND device.switch.state = OFF) then
// do something
end-if

Example of proposed rule in psuedo-code:

set varBatt = device.battery
set varSwState = device.switch.state
if (varBatt > 80 AND varSwState = ON) then
// do something
else-if (varBatt > 80 AND varSwState = OFF) then
// do something
else-if (varBatt < 70 AND varSwState= ON) then
// do something
else-if (varBatt < 70 AND varSwState = OFF) then
// do something
end-if

[bertabcd1234]

@badbob

I think device attribute reads are from the hubitat database and does not involve an actual read from the physical device.

This is true.

@badbob

And that the hubitat database is updated by periodic polling of the physical device's attributes.

Depends on the device and protocol, I suppose, but Z-Wave and Zigbee are the most common and generally send reports to the hub on their own in accordance with how they are configured. Some LAN or cloud devices without a "push" API may need polling, and a subset of older Z-Wave switches/dimmers may too for certain states due to patent issues, but otherwise this generally done by reports sent from the device and not in response to polling from the hub per se.

But, yes, the main idea is that reading a device attribute from an app looks at the hub database and doesn't cause the device or driver to do anything (the driver doesn't even have a way to know that an app is asking for this value).

So, that leaves the last question. I'm sure there is an answer; I just don't know what it is (I suspect there's a tradeoff at some point, but who knows how many of each is the cutoff...), and I can't imagine that the difference would matter much in the real world. I'd do whatever is easiest for you.

Further, there is some caching involved during a single execution of an app, so all of your attribute reads may not necessarily go to the hub database every time (unless you specify true for the parameter to skip cache in your call to currentValue()) -- another reason I'd worry about this less.