Current Value vs. State...An App Conundrum

Got a question that I'm hoping someone will be able to answer definitively for me. In an app, which is "faster", using deviceInput.currentValue(attribute) or using a state variable? The context here is that I have a app that controls lights by motion. And I don't want the app to change the level back to the original settings if motion goes active again before the timeout. For example, the lights go on to 100% with motion and I dim them to 50%. I don't want those to be reset to 100% if motion is just active again before the timeout to turn them off. So, at the beginning of the motionActive currently I am using a state variable. And it is working perfectly. I have tried using currentValue in the past to check if the switch of the light is off or not and that worked too. So, I'm wondering if one will always be more efficient. I've made so many other changes (hardware and software) that I don't have a real solid frame of reference.

Or am I totally inventing something to be concerned with? Or is there no appreciable difference? I'm not familiar enough with what happens in the background when an app loads to be able to make an informed guess. I know that the current value of all of the attributes for a device are cached when a driver loads, but I didn't think the same was true of apps.

Thanks for satisfying my curiosity!!

List item

2 Likes

That’s a good question..

I haven’t done any real tests..

But so far, in what I have done, I haven’t noticed a difference..

Oh...I should also say, is one more efficient from a resource perspective? Is state cached when the app loads? Not really huge with my example, but as you start to scale up apps, it could mean a lot of compute cycles.

1 Like

You could sort of benchmark this if you wanted to. Put each in their own loop of, say, 50k times and call it that many times. Print the time before and after the loops. Be prepared for this to potentially crash your hub or at least stop it dead for some amount of time. It's possible their won't be enough threads or the driver doesn't run threaded from something that is mission critical... and then crash.

I'll let somebody with a dev hub try that out for me.
:smiley:

Thinking aloud here..

If the ‘lastvalue’ is kept on the device, then wouldn’t the app have to query the device to get that value?

A state variable is kept in the app and would be instantly available, without the app having to query the device

I would think if this is correct then the state variable would be quicker/have less overhead

I have not tested the difference but have used both methods in my apps

Andy

1 Like

In my experience I would say it depends on how often and quickly you are updating the state variables and needing to access the values. When I was developing my UPS NUT driver I found that the value I set in a state variable wasn’t always updated. But this said the updates were happening very frequently and could have been a multi-threaded situation.

But I agree with other that state should be the best since the overhead of creating an event and logging to the database isn’t needed. But keep in mind that state variables reset when your hub restarts, at least that’s been my experience.

1 Like