luup.variable_get and optimization

Is it expensive to use several times “luup.variable_get”, instead of accessing the variable one time and storing its value ?

Hi Vosmont,

I doubt you can notice and performance difference. I would say, go for easy to understand code.

For luup.variable_set it is a different story as that needs a write to NVRAM so I use wrapper code to only store it when value has changed. Checking with luup.variable_get ofcourse :smiley:

Cheers Rene

Ok thanks.

I’m not sure you need a wrapper :
when you use luup.variable_set with an unchanged value, there’s no action in the logs. So the luup engine must already do this control.

mmm, ok. I do see lots of log entries for set values even if not changing I thought. I’ll have a look again then. And you may be right on UI7 as that seems to write the data once a minute or so and not immediately I think. But a comment from anyone who knows the inner workings of the box may be able to tell what these ‘magic boxes’ really do. ;D

Cheers Rene

There is a hashtag #hooks when the old value is the same as the new, in the logs trace. Is this what you are talking about ?

#hooks indicates the number of luup.variable_watch callback routines watching that particular variable. So it will be zero for most.

I redid the test and indeed there is well a line in logs. I do not know why I was persuaded.
There is on the other hand an information about the not changed value. Maybe that the Vera does not thus record the identical value.

... variable: Data was: test now: test #hooks: 0 upnp: 0 skip: 0 v:(nil)/NONE duplicate:1 ...
... variable: Data was: test now: test2 #hooks: 0 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 ...

It does record it and it get’s a new timestamp!!!

But writes to NVRAM are not immediate … the flush the accumulated changes to NVRAM every 6 minutes.

Of course that means when Vera Restarts or crashes during that 6 minutes … it’s important for Vera to flush the changes.

That works great on UI5 … I think there are problems with this on UI7 … and that is why there are so many problems with people saying things are not getting saved!

it’s this flush that generates these log entries with “UserData::WriteUserData” and “UserData::TempLogFileSystemFailure” which are flooding the logs ?

I found that when using api.setDeviceStateVariablePersistent() rather then the old UI5 set_device_state from your JS UI it does write it to permanent storage right away. It did not work properly in the first few UI7 versions and I had hit and miss on the variables retained on a reload, but since 7.05 it seem to work ok.

Cheers Rene