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 
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!
OK
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