Luup variable watch not working in startup lua

Plugins & Plugin Development openLuup
#1

Hi AK,

I just realized that the exact same luup.variable_watch codes I am running in the lua test and in the startup lua do not work in the startup lua.
It seems like the variable watch get killed unlike what happens on the vera. Is it an expected behavior?

I am suspecting that it is related to the order by which the modules are being loaded during startup.

#2

You’ll have to be a bit more precise than that. I can’t really work out (a) what happens , or (b) what you’re expecting?

Lua Startup and Test Lua share the same context, along with scenes, so redefining a global function in one will impact the others.

#3

I have the following code:

for k, v in pairs(luup.devices) do if v.category_num == 4 and (v.subcategory_num == 1 or v.subcategory_num == 3 or v.subcategory_num == 6) then luup.variable_watch("alarmaction", "urn:micasaverde-com:serviceId:SecuritySensor1", "ArmedTripped", k) end if v.category_num == 4 and (v.subcategory_num == 2) then luup.variable_watch("floodaction", "urn:micasaverde-com:serviceId:SecuritySensor1", "ArmedTripped", k) end end

In my startup lua which does not execute. (the variable watch actually does not work). The functions are defined also in the startup lua above this code.

When I put this same code in a scene code or in the the test lua window and execute them then the variable watch work.

#4

If these variables are bridged from a remote Vera, then I understand exactly why this does not work…

…the Lua Startup is run before VeraBridge initialisation runs.

#5

Ahh that’s exactly why then. Is there any reason why the startup lua code wouldn’t be loaded last?

#6

Yes. In Vera, the startup code runs before device initialisation, so openLuup does the same.

One of the problems with startup is that you don’t actually know when device startup is finished - some never are! They are all asynchronous, and even when their startup jobs exit, many plugins have delayed startup sections to avoid the general melee which happens during restart. It is, quite frankly, a nightmare.

What’s different here is that VeraBridge does not run on Vera! (Early version did, but no more.) A design choice for stability was to make the bridge recreate every device and variable from scratch. You can see that clearly in the Startup log and the first part of the running log. It is a lot less effort than comparing every attribute and variable and changing any that are different, noting whether there are more or less, having to adjust variable IDs if they don’t match, … It is this sort of decision which makes openLuup stable. I could re-write the bridge initialisation, but I’m not going to because there are far more useful things to be doing!

So the bottom line is that variable watch in startup does work, but only for devices and variables which exist at that time and are not subsequently deleted.

#7

It makes sense. Thanks. I think I will need to create another workaround it seems. Maybe to run this code with a delay.

for posterity I just put the variable watch in the startup lua within a function and then called that function with a 5 sec luup call delay. It seems to work.

#8

Hi rafale,

As a workaround I created a plugin that loads all my special modules with watches on OpenLuup. Is working fine too.

Cheers Rene

#9

[quote=“reneboer, post:8, topic:199490”]Hi rafale,

As a workaround I created a plugin that loads all my special modules with watches on OpenLuup. Is working fine too.

Cheers Rene[/quote]

Thanks Rene! If I had a lot of these I would probably need the same. My startup lua is starting to get long so your idea could be a good alternative.

#10

Yes, I really think that there comes a point when your Startup code really belongs elsewhere. Not a bad place to start trying ideas out, though. Indeed, that’s what it’s really for.