openLuup: Suggestions

Plugins & Plugin Development openLuup
#181

Hi AK,

Can I make an other openLuup / VeraBridge suggestion? Is it possible to start those before any other plugins? This way all devices, local and especially remote will be availble to all others. Several plugins (or actually developers :wink:) assume devices are known before their Lua start up code gets run as this will always be true on a Vera.

Let me describe my scenario why I ask this. I had two Veras bridged since the start so they have low device IDs (6 & 7) and start as one the first devices. One of my plugins (id 105) sets several watches to run some complex automation (Reactor was not yet around), all working just fine. Recently I got a new Plus and bridged that too and this bridge has id 190. Then I moved all devices from one of the first Veras to the Plus and some of my watches stopped working. I could see in the log file the watches got set, no error message nothing, but none of the watches to the new bridge would show in the scheduler watch table (thank you, thank you for those console functions in openLuup). Then I realized the bridge with id 190 was not yet started when my plugin with id 105 would set the watches. I now put in a 30 seconds delay in the plugin startup and that gives bridge 190 time to initialize all devices, but it assumes that is enough time, and increases chances of missing changes due to a reload.

Hence my ask if it is possible to start the VeraBridge plugins before any of the others. And maybe an error message when trying to set a watch on a none existing device id?

Cheers Rene

#182

No need to explain! I’ve had exactly the same issues, and used the same solution (luup.call_delay) myself.

I think the suggestion of scheduling VeraBridge(s) first is a good one. Just need to think a little more to see if there are any ‘gotchas’.

In fact, I was just about to revisit device startup for VeraBridge anyway because at the moment I substitute a dummy implementation file for any bridged device plugins, so that they don’t execute. This works, but means that it looks as those those devices don’t accept their usual action requests, although they are actually handled by the bridge. So I’m going to change to using the correct implementation file, but not calling the startup routine for any bridged devices.

Thanks for the suggestion.

1 Like
#183

Well, I totally screwed up the attempt to ‘fix’ this issue. It led to an exponentially increasing I/O and cpu load on both openLuup and Vera.

My latest go at this is in the development branch v19.11.3

Sorry for the inconvenience.

AK

#184

The latest development version (v19.11.8) has this feature.

It was actually a bit harder than you might think, since I added job priorities as a general feature to the scheduler. This not only determines the order in which startup jobs are run, but also affects the scheduling order of time slices for continuing jobs.

At the moment, this is just an internal feature not accessible by the user. Currently, startup jobs are ordered thus:

  • openLuup
  • AltUI
  • VeraBridge
  • … the rest (no priority)

If there are other similar circumstances that you think might benefit from this feature, then do let me know.

Thanks for the original suggestion.

AK

#185

Thanks AK, I’ll give it a try later this week.

Cheers Rene

#186

Hi @akbooer,

Kudo’s again. Works like a charm.

Cheers Rene

1 Like
#187

Hi akbooer,

is it possible an automatic lua installation of only Openluup software with your simple console (I noticed the console function is included in the last sw version released)?

tnks

donato

#188

Hi

It has always been the case that openLuup does not need AltUI in order to run, but only to provide an interface. The console has limited functionality as a UI and is really only a way of examining the state of the system in detail.

However, depending on what you need in your installation, it may be sufficient just to use the console. What exactly do you mean by:

automatic lua installation

…?

AK

#189

Hi,

with “automatic lua installation” I refer to file “openLuup_install.lua” that install openluup and ALTUI.

tnks

donato

#190

There’s nothing to stop you from removing AltUI from any system. Equally it’s easy to modify the standard install file to not install it in the first place.

Are you sure that such a bare-bones system will do what you need? (I assume that this is for your data acquisition front ends?)

#191

Hi akbooer,

yes it’s for my front-end systems. Eventually I’ll modify the standard install file.

tnks

donato

#192

Can’t recall how exactly you have the front-end configured for watching variables. If you use the AltUI Data Storage Provider to push to DataYours, then you will still need AltUI! If you’re using just DataWatcher, then all thould be OK.

#193

Yes, I’ve only Datayours for watching variables.

tnks

#194

@akbooer, One possible suggestion/request: Would it be possible to add a lua code field associated each individual scene watch? Application would be to reduce the number or identical or near identical scenes where I would want to trigger only a very small variation to the code depending which trigger started the scene. It is equivalent to the trigger lua on the vera? Maybe it’s already there but I didn’t figure how to use it?

#195

The device variable watch functionality is entirely implemented in AltUI, so I have no control over that.

I did wonder why @amg0 chose to require just a logical statement rather than a Lua function there, but that’s the way it is.

There is, however, a work-around. According to Lua syntax, it’s perfectly acceptable to define an in-line function and evaluate it to return the required boolean value. Within that function, you can do pretty much what you need to do.

Here’s an example which simply writes the new variable value to the log…

(function () luup.log (new) return true end) ()

take care with the final open/close parentheses, which evaluate the given function.

Here’s the relevant section of the log (the variable watch in this case is looking at openLuup’s CpuLoad .)

2020-01-21 10:44:11.823   luup.variable_set:: 2.openLuup.CpuLoad was: 0.3 now: 0.30 #hooks:1
2020-01-21 10:44:11.825   luup.watch_callback:: 2.openLuup.CpuLoad function: 0x006e9290
2020-01-21 10:44:11.825   luup_log:3: 0.30
2020-01-21 10:44:11.825   luup.call_action:: 0.urn:micasaverde-com:serviceId:HomeAutomationGateway1.RunScene 
2020-01-21 10:44:11.928   luup.scenes:: scene 6, test altui watch, initiated by command

You can see that AltUI has a watch callback which is activated by the variable change, the function code is run and outputs to the log, and because the return value is true, it then runs the scene.

Hope this works for you.

(One day, perhaps, openLuup will get its own version of triggers with Lua code.)

PS: There is one caveat here… the code is run in the context of the AltUI plugin, NOT in the global scene/startup Lua one. This means that you can’t access the usual global variables/functions you may have defined in startup, so it might limit its application.

1 Like
#196

Thanks AK, I was suspecting that it was controlled my by ALTUI than openLuup as I was writing the previous post. I ended up using the “clone” scene function of ALTUI as it is simpler than to work around this limitation through Lua and less error prone so it isn’t all that bad.

#197

yes, I have not checked lately but a function should be ok if it returns a bool true/false.

the point of the lua context is valid, I never quite figured out how I could run in another context

#198

On Vera, I don’t think you can (well, you could isolate the environment from the plugin, but you couldn’t share the scene/startup one.) Under openLuup, you could. But I wouldn’t worry about it.

Ideally they both should behave the same anyway.

#199

Well, it has taken about 18 months to get around to this, but I am looking at incorporating this into the next release. It’s also relevant for the next version of the ZWay plugin which will number its child devices in a similar way.

Thanks for the (old) suggestion @reneboer!

#200

AK - wanted to try out the cjson in the latest dev release (release is working fine so far!). However not being a unix expert, I’ve no idea if I installed it or not successfully. So suggestion is: can one of the console pages (system parameters perhaps?) indicate if it has been found and is in use or not so. May be there is somewhere this already gets indicated but I couldn’t find it. I tried AltUI–> OS Command–>Find Json but it wasn’t found. Where does it end up on a RasPi? Here is my attempted install report - it seems like it worked?:

/$ sudo apt-get install lua-cjson
Reading package lists...
Building dependency tree...
Reading state information...
The following NEW packages will be installed:
  lua-cjson
0 upgraded, 1 newly installed, 0 to remove and 119 not upgraded.
Need to get 18.0 kB of archives.
After this operation, 56.3 kB of additional disk space will be used.
Get:1 http://mirrordirector.raspbian.org/raspbian/ jessie/main lua-cjson armhf 2.1.0+dfsg-2 [18.0 kB]
debconf: unable to initialize frontend: Dialog
debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Readline
debconf: (This frontend requires a controlling tty.)
debconf: falling back to frontend: Teletype
dpkg-preconfigure: unable to re-open stdin: 
Fetched 18.0 kB in 1s (15.0 kB/s)
Selecting previously unselected package lua-cjson:armhf.(Reading database ... 
(Reading database ... 5%
........................
(Reading database ... 100%
(Reading database ... 32185 files and directories currently installed.)Preparing to unpack .../lua-cjson_2.1.0+dfsg-2_armhf.deb ...Unpacking lua-cjson:armhf (2.1.0+dfsg-2) ...Setting up lua-cjson:armhf (2.1.0+dfsg-2) ...Processing triggers for libc-bin (2.19-18+deb8u7) ...
1 Like