I am trying to get my Harmony Hub plug in running on openLuup and it is sure not a trivial exercise. Besides having the same challenges as Multi Switch as I rewrite the json and D…xml files I was banging my head on getting the settings working.
What I found is that the way openLuup deals with handers is different. First the name of the passed request. Vera strips the ‘lr_’ from the lul_request parameter.
I also found that the hander runs not in the same code space as the plugin but on level 0 as you can see in this log. This seems to be causing issues with anything I try with a call_delay() to result in an unknow function error.
You mean in the first parameter of the callback handler? I’ll check it out. I only ever use a one-to-one mapping of requests and handlers, so I’ve not run across that myself. Easily fixed.
I also found that the hander runs not in the same code space as the plugin but on level 0 as you can see in this log.
Yes, a known issue (to me) which doesn’t usually cause problems. I’ll work harder on fixing it.
This seems to be causing issues with anything I try with a call_delay() to result in an unknow function error.
You use call_delay in callback handlers ?!! :o
Can you make this behave more like Vera?
Yes, assuredly. But I can only fix one error at a time… did the attribute fix work OK?
You mean in the first parameter of the callback handler? I’ll check it out. I only ever use a one-to-one mapping of requests and handlers, so I’ve not run across that myself. Easily fixed.[/quote]
Correct, first parameter. I prefer having as little entry point into my code as possible. All personal coding preferences I suppose.
[quote=“akbooer, post:2, topic:190983”]
I also found that the hander runs not in the same code space as the plugin but on level 0 as you can see in this log.
Yes, a known issue (to me) which doesn’t usually cause problems. I’ll work harder on fixing it.
This seems to be causing issues with anything I try with a call_delay() to result in an unknow function error.
You use call_delay in callback handlers ?!! :o[/quote]
Yes as I run an http request to the Harmony Hub from the handlers I use those to not lockup the tread for too long. I have worked around it for openLuup as that seems less sensitive to it and much faster in handling the resonses.
[quote=“akbooer, post:2, topic:190983”]
Can you make this behave more like Vera?
Yes, assuredly. But I can only fix one error at a time… did the attribute fix work OK?[/quote]
Great. And yes that seems to be working now.
Be aware that openLuup does not implement Vera triggers or notifications, but relies on AltUI device watches to provide similar (actually better) functionality. From a programming point of view, however, this means that JSON-encoded definitions of scenes added through an HTTP request will simply not have their triggers stored. You may, instead, do what AltUI does and use luup.variable_watch() to construct your own triggers.
Be aware that openLuup does not implement Vera triggers or notifications, but relies on AltUI device watches to provide similar (actually better) functionality. From a programming point of view, however, this means that JSON-encoded definitions of scenes added through an HTTP request will simply not have their triggers stored. You may, instead, do what AltUI does and use luup.variable_watch() to construct your own triggers.[/quote]
Aha, ok I’ll have a look at that then and add it to the documentation.
The code loaded by “require” has it own global environment (just string, table and some other objects that are shared).
If you defined a global variable in the startup of your plugin, it won’t be available in the loaded code.
implementation file :
<?xml version="1.0"?>
<implementation>
<functions>
function startup (lul_device)
myLib = require("L_myLib1")
end
</functions>
<startup>startup</startup>
module("L_myLib2", package.seeall)
-- In openLuup, the module myLib1 loaded during the startup sequence is in a dedicated environment.
-- In legacy Vera, the global variables defined in stratup sequence are global everywhere
local myLib = L_myLib1 or myLib
I don’t know if it’s normal (it seems to be the default behaviour of require) but in Vera, it’s possible.
I have found a workaround with “L_PluginName”
For me, it doesn’t seem like a good plan to have modules accessing the global environment. Of course, I invariably do use “package.seeall” but only to access the usual Lua system modules and the Luup environment.
I assume that ‘require’ uses somewhere ‘loadstring’ and that is not, by default, using the caller’s context in openLuup. I may see if I can fix this.
You should be aware, however, that in openLuup, the ‘module’ call is a no-op, and only there for compatibility with Vera code. Outside of the Vera environment, the ‘module’ keyword is now deprecated (in versions of Lua beyond 5.1) , since it’s really not needed.
Best Home Automation shopping experience. Shop at Ezlo!
