openLuup: debugging plugins with ZeroBrane Studio

[akbooer]

I use ZBS for developing openLuup - it's an excellent IDE, and one of my frustrations has been that I couldn't easily use its extensive breakpoints, watch window, and stack window capabilities to debug plugins.

The reason it doesn't (didn't) work is that the Lua implementation files and code, referenced in the I_xxx.xml device file, are not imported into openLuup with the usual 'require' mechanism, but are loaded as text files and 'compiled' into the device environment in a complicated mix of code coming from <functions> <files>and <action> tags  in various places, so ZBS doesn't know they're being used.

However, it turns out there's a simple way around this.  Here's a new plugin I'm developing/ testing... (good, eh?)

Code: [Select]

module ("L_TestPlugin", package.seeall)

function init (lul_device)
  luup.log ("TEST device number is: " .. lul_device)
end

The following is the I_TestPlugin.xml implementation file:

Code: [Select]

<?xml version="1.0"?>
<implementation>
  <functions>
    function startup (lul_device)
      local m = require "L_TestPlugin"
      return m.init (lul_device)
    end
  </functions>
  <startup>startup</startup>
</implementation>

...so the implementation file simply uses 'require' and calls the entry point (with the device number) directly.

You can set breakpoints, debug as usual, and get the right line numbers in any error messages that openLuup generates.

My thanks to both @explorer and @vosmont  for sowing the seeds of this idea a long time ago.

_______________________

see @vosmont's: openLuup: Unit/fonctional testing on openLuup

for @explorer's contributions, they are PMs to me during April 2016...
...and a key post on this thread!

[akbooer]

Let me add one caveat to this approach on debugging openLuup plugins... it may only work if you have one device instance of the plugin installed.

The reason for this is that all openLuup code (devices, plugins, scenes, ...) runs in a single Lua instance (this is why it is so memory efficient.)  While the various code environments are generally separate so that variables are in separate namespaces, loading an actual module with require will mean that if it is not fully re-entrant (ie. does not have any top-level variables, either local or global) then top-level variables will be shared between instantiations.  This could certainly lead to unexpected behaviour.

However, for almost all debugging needs (who would choose to debug multiple intsances simultaneously?) this modification to the implementation file works like a charm... just remember to revert to the more usual format for any production-ready code which may require multiple plugin instances.

[Buxton]

Do I need to use ZeroBrane for Vera to debug a plugin, or can I connect the vanilla ZeroBrane to your debug plugin?  I'm not sure how to setup the vanilla ZeroBrane for openLuup.

[akbooer]

I do all my development and debugging of openLuup within vanilla ZeroBrane Studio on a Mac.

There are several approaches and 'tricks' which I could describe given the need and some time, but my basic method is to run an entire openLuup process within ZBS. 

Because of the XML content of implementation files, openLuup loads them itself, so the debugger doesn't have the context for those files.  However, there is an easy way around this, described in the previous post in this thread, and then you can set breakpoints, examine variables, etc., etc...

Let me know if you need more.

PS: you did well to find this old and neglected thread!

[explorer]

I was checking this forum after upgrading my openLuup system to version 18.3.15 after almost a year away from it, and noticed some activity on this "neglected" topic. It brought some good memories, so I thought I'd share my vanilla ZBS debugging techniques...

I updated my old notes and attached them here along with the modified loader code. Hope it helps.

P.S. I really like openLuup, it runs rock solid for months. Had to update to the newer version only because GitHub recently changed the SSL security, and AltUI failed to download. I was happy to see that AK already took care of that. Thanks!

[akbooer]

@explorer... what a pleasure to see one of your very rare posts to this forum.  I'm sure that most users are quite unaware of the critical input that you've had to several key aspects of openLuup.  A public "thank you" for that.

Your latest post seems important enough to me to:

• make the topic sticky, and,
• look closely at incorporating your changes to the loader.

I debug locally on my development system, but there are clearly times when being able to debug a separate system will be useful.

[akbooer]

...look closely at incorporating your changes to the loader

Done!  Available in the development branch as v.18.3.17

Thanks again, @explorer, I'd be pleased to hear that these changes work as expected, and save you (or others) from any tedium when updating in future.  Perhaps a slight edit now required for your debugging instructions!

[explorer]

I just returned from vacation and what a pleasant surprise! Thank you!

Updated my system to the latest openLuup development branch, it worked like a charm. Adjusted debugging instructions in my original post.

[Buxton]

Thanks guys for the shortcuts.  That saved a lot of effort.  I'm pretty much up and running, however, I am running into an error when running an openluup instance (needed to run/debug an instance of a long abandoned plugin).

The debugger stops at line 579 with a nil value in userdata.lua  (local ol = luup.devices[2]).  I can get past the error if I substitute  "luup.devices[2]" with "user_data.devices[2]" but I don't want to break anything and chances are the error is the result of a startup environment problem on my part.

I'm running ZB on a Windows 10 machine and openluup on an OrangePi2PC.

Any guidance much appreciated.

[akbooer]

luup.devices[2] is the openLuup plugin.  It's always there. (On Vera, this is the scene controller device.)

How did you start up the openLuup instance?  What is in the startup log?  What's in the user_data.json file?

It would be wrong to make the substitution you propose. I've certainly never seen a problem at this stage of system initialisation.

[Buxton]

I start with _debug.lua in the cmh-ludl folder.  I'm sure this is an environment problem on my end.  The debugger is picking up the JSON and arrays, but is not setting variables---which is causing the nil value.  The start-up log shows errors as well with variable initialization:

Code: [Select]


2018-04-08 16:15:17.692   luup.create_device:: ERROR [1] D_ZWaveNetwork.xml /  /  : .\openLuup\loader.lua:388: attempt to call global 'setfenv' (a nil value)
2018-04-08 16:15:17.707   luup.create_device:: ERROR [2] D_openLuup.xml /  /  : .\openLuup\loader.lua:388: attempt to call global 'setfenv' (a nil value)

[akbooer]

What version(s) of Lua are you running?  Both must be v5.1...

[Buxton]

Ah, well that's probably part of the problem as I'm running 5.2.  At least that's what ZBS says (version running) on the local machine.  I realize that Lua has made substantial changes between versions (including 5.3), but why are you using 5.1?

[akbooer]

...but why are you using 5.1?

Because that's what Vera/MiOS uses, and openLuup has to be compatible.

[Buxton]

Is it possible to debug startup code (in the AltUI startup window), or do I need to create a temporary plugin to set breakpoints for such code?  If so, do I just place the name of the lua code file I want to debug within the startup tag of the temp plugin?