After posting yesterday - thanks to CudaNet’s endeavor to capture all openLuup compatible Vera plugins - that the Smart Virtual Thermostat plugin (written by Antor) could run under openLuup thanks to a quick fix, I got asked a few times about this fix… In the meantime I actually simplified the fix I had found earlier. Only one file is to be tweaked as per the attached, so simply drop it into the /etc/cmh-ludl (or whichever folder is your openLuup “base” directory) together with the other un-modified plugin files.
I performed only limited testing so please advise if you see any remaining issues with this fix.
For the technically minded (and it would be great for Akbooer to help me understand if this is indeed truly a difference in openLuup’s implementation of plugins or something more like the change of underlying platform for Lua, e.g. Raspbian v.s. MiOS’s OpenWRT flavor…), it seems that under openLuup, unlike under the real Vera environment, the functions in L_SmartVT1.lua cannot “see” the variables defined in I_SmartVT1.xml that these need. So the quick & easy patch is just to copy the Service IDs and Device types defined in the .xml file and paste these in the .lua, et voil?..
Global functions and variables should be in scope across both files. It was a conscious design decision (perhaps an incorrect one) to place code from I_…xml after that from L_…lua, in order to retain the line numbering of any error messages in the Lua file. This may be different from what Vera does and if it’s that which is causing this problem, I may need to revisit it.
Thank Akbooer… I did not realize the I_ file code was possibly coming “after” the L_ one.
the original plugin seems to rely on local variables in the I_ file to be visible to the functions in the L_ one… so possibly the Vera implementation is different from yours ?
Took me a while to figure that this does not seem to work in openLuup !!! putting aside the issue with the battery check on the sensors’ parent (that I fixed by replacing the battery update timestamp by the last temperature update timestamp) that you will address soon based on your post about an upcoming VeraBridge upgrade.
I believe that the Implementation file controls the order of loading for code segments…
The SmartVt plugin defines the tag before the tag, so the code in the tag is loaded before the code in the L_…lua file… Which makes the variables defined in the tag visible to the code in the L_…lua file…
As mentioned, doing it this way causes the line numbers in any error messages to be mangled…
[quote=“akbooer, post:5, topic:191669”]Really? That is a revelation!!
What makes you think that?[/quote]
I ran into the same issue when developing the EVL3Vista plugin… I originally had a section and was fighting with the line number mismatches in the error messages… I moved the section to the top of the implementation file and started getting a LOT of nil value errors… I decided to remove the section completely and move all the code into the L_…lua file…
You also run into the same issue if you are refactoring your code… move a function definition around and you can cause nil references to functions and variables…
I never thought about the order of loading the components within the implementation file when trying to make SmartVT work with openLuup… Thanks for that explanation…
I am glad I elected for my own plugins to move all functions/variables to the L_.lua and only use the implementation file to load it and call an init function… I cannot yet see drawbacks doing that.
I think that is exactly the right approach. It seems quite perverse to try and embed Lua in XML. The only need of a minimal bit of code is for the tags, and they should simply be a call to a routine in a Lua file, if they are any more than just a one-liner.
However, we have to deal with legacy code here, so it seems I must honour this (previously unknown) convention. Thanks so much for pointing it out.
It does seem to be perverse… but it actually has it’s uses… Many small bits of code that don’t warrant a full plugin can be achieved as a single file implementation by embedding the code inside the tags… (ie: implementations for SengLED Boost, Eco Plugs, PTZ camera controls, etc)
[quote=“logread, post:1, topic:191669”]After posting yesterday - thanks to CudaNet’s endeavor to capture all openLuup compatible Vera plugins - that the Smart Virtual Thermostat plugin (written by Antor) could run under openLuup thanks to a quick fix, I got asked a few times about this fix… In the meantime I actually simplified the fix I had found earlier. Only one file is to be tweaked as per the attached, so simply drop it into the /etc/cmh-ludl (or whichever folder is your openLuup “base” directory) together with the other un-modified plugin files.
I performed only limited testing so please advise if you see any remaining issues with this fix.
For the technically minded (and it would be great for Akbooer to help me understand if this is indeed truly a difference in openLuup’s implementation of plugins or something more like the change of underlying platform for Lua, e.g. Raspbian v.s. MiOS’s OpenWRT flavor…), it seems that under openLuup, unlike under the real Vera environment, the functions in L_SmartVT1.lua cannot “see” the variables defined in I_SmartVT1.xml that these need. So the quick & easy patch is just to copy the Service IDs and Device types defined in the .xml file and paste these in the .lua, et voil?..[/quote]
Have tried the modified lua file. I can’t see any variables on the “Variable” tab. Done all the ‘vera dance’ things including rebooting openLoop with no success.
Even the original unmodified plugin should show some variables in the device after initialization.
Just to check… Did you reference both the device description file (D_SmartVT1.xml) and the device implementation file (I_SmartVT1.xml) when you created the device ?
No I didn’t reference I_SmartVT1.xml when creating device. how do I do this in openLuup? normally it automatically appears in the Attributes page or I fill in the imp_file box. interestingly no imp-file box appears.
Depends how you want to create the device. If using the AltUI interface then it’s simply the third box on the menu. If you’re using luup.creste_device() it’s the fifth parameter, the one immediately after the device file.
Of course it is! I’ve used the AltUI interface before, got stuck in using the luup_create device method without fully understanding the parameters. Many thanks akbooer
Runs very well on my setup. But bear in mind that setting “heat” is in fact a forced heating for a default period of one hour. I do not think “cool” is functional even in the unmodified Vera version (though I would need to dig again into the code to check this out). “Auto” works flawlessly for me
If you see the control panel reverting to “off” immediately after setting it to “auto” then I suspect you either may still be using the original plugin files, or your plugin configuration misses key control variables (temperature sensors IDs, heater device IDs…). In the latter case, go to Device/Variables and set these up, followed by a luup reload.
