All Luup Code has stopped working

Developer's Corner General Dev Discussions
1

I’ve run into a situation where all my code has stopped working. I’m definitely a newbie with the Vera. I’ve been working towards creating an event where when a :-[pin code is entered on a schlage lock, after a short delay, the code checks to see if the user locked or unlocked the lock. If the lock is unlocked it assumes that someone has come home and it turn on a pathway light(s) and will restore hvac to normal operation. If the door is locked it turns off the light(s) and puts the thermostat into energy saving mode or possibly just sets the setpoints directly to energy savings values.

I’ve been creating various events and putting small snipets of code into them for testing and debugging. I’ll just use the run scene button on the event dialog to execute my code.

Suddenly whenever I run any of my code, even an event with a single command to turn on a light, all I get back is a dialog box with a message saying “Received empty response.”.

I’ve tried:

  1. cycling power on the vera
  2. cycling power on my z-wave devices
  3. reseting the z-wave network

The first time I went through these steps it appeared to fix the problem. However, after just executing a few scripts the problem was back and I haven’t been able to get any code to run again.

I can control all my devices from the web UI. I just can’t properly execute any code.

Any ideas would be greatly appreciated.

Thanks in advance for the help

Jay

2

I believe a bug in the Lua code in any of the scenes could stop all your Lua code from working. I would comment out all the Lua code from all the scenes and then add them back in piece by piece. When it breaks, the last piece to be uncommented is probably the problem.

3

Thanks! I’ll give that a try.

4

Thanks Mike. That has fixed it. I would hope that mcv would fix this issue at some point so the product would be more robust. It is not good that one typo in a single event would stop all code in the entire system from running.

Thanks again for your help. There is definitely a fairly steep learning curve with the vera.

5

Yes, we’re rearchitecting the C++/Lua interface. One goal is to compile each and every Lua chunk separately.

Of course, being a very core functionality involved, we can’t promise on which update this would appear.

6

Compiling each chunk separately would be nice, but I would still like all events and scenes to run within the same Lua environment, that way they can share common variables and functions.

Also, it would be nice if the startup Lua script also ran in the same environment as the events and scenes. That way, variables could be created and set to default values in the startup script, and then used by the scenes and events.

7

[quote=“BigstickCarpet, post:6, topic:165717”]Compiling each chunk separately would be nice, but I would still like all events and scenes to run within the same Lua environment, that way they can share common variables and functions.

Also, it would be nice if the startup Lua script also ran in the same environment as the events and scenes. That way, variables could be created and set to default values in the startup script, and then used by the scenes and events.[/quote]

Separate compilation doesn’t imply separate spaces. Exactly what parts should share the same space and which should get it’s own is still on debate, mostly because of concurrency issues.

In any case, to share common function it’s best to use Lua’s module system.

8

Ok, cool. I just wanted to make sure.

The module system won’t get around the inability to share individual object instances between different Lua environments. I could define a custom type in a module, but if I create an instance of that type in my startup script, it won’t be accessible from my scenes and events.

9

That’s correct, and in general I tend roughly towards that: having most Lua code in a single space. The biggest reasons to use separate spaces are for concurrency and isolation.

In the specific case of devices the isolation is highly desirable, so I think they’ll stay on individual spaces.

Currently, other plugins (like the smartphone and wap UIs, or the energy monitor) are in the same space as startup scripts. Probably this should change, again to increase isolation (and thus reliability)

OTOH, Lua itself has several facilities to (partly) isolate code chunks that we’re not using yet. Another direction we might take (no real plans yet, though) would be to port more of the running environment to Lua, instead of relying on the C++ core to arbitrate between the Lua chunks.

As said before, all this is in the daydreaming phase.