"Run Lua" activities/actions no longer running [openLuup/RPi3]

Hello @rigpapa,

My Reactor plugin is running on openLuup/ALTUI and RPi3.

I’ve been learning Reactor but every version past 2.1, “Run Lua” activities no longer run in any Reactor Sensor.

In the summaries, there are multiple references to:
error: message=tick failed, reason=./L_Reactor.lua:902: attempt to index field ‘?’ (a nil value)

Also, on the Tools tab of all the ReactorSensors, this message is near the top:

Today’s sun timing is:
Can’t display sun data: SyntaxError: Unexpected end of JSON input

I enabled “Toggle Debug” in the main Reactor, and recorded the openLuup Log (attached)

I also attached the Reactor “Summary”

Since no one is posting about this particular issue, I suspect there is something hosed in my particular system.

Could you please advise on further troubleshooting steps?

Thank you for all of your work.

Regards,
ChrisTheC

Same behavior here. Also on RPi3 with OpenLuup.

I PMd some instructions to ChrisTheC but haven’t heard back. I’m travelling at the moment and have limited time and access, but I will PM you the same instructions.

Group,

Just got @rigpapa’s PM.

Pasted a code modification into L_Reactor.lua and the “Run Lua” activities portion of my Reactor sensors are working again.

I still think that there is an underlying problem in my system, so this may be just a work around.

My instructions were to replace existing line 902

luup.devices[dev].description, dev, fn, n) --replace this line
( luup.devices[dev] or {} ).description, dev, fn, n) --with this line

I hope it is ok if I shared this.

ChrisTheC

Ok, now go to Tools and find the Logic Summary link, because that part of the code is trying to tell us something.

PM sent

I was getting the same null error while running sensor lua in openluup, and the revised code did stop the error message. However, I’m also getting the following during the untrip actions (which are not executing):

02/09/19 17:52:00 devicewatch: device=8, old="Disarmed", name=EVL3 Vista Partition 1, var=urn:micasaverde-com:serviceId:AlarmPartition2/ArmMode, new="Armed" 02/09/19 17:52:00 condchange: newState=true, cond=cond16873e9d143, oldState=false 02/09/19 17:52:00 evalchange: newState=true, cond=cond16873e9d143, oldState=false 02/09/19 17:52:00 groupchange: newState=true, cond=grp168691f6932, oldState=false 02/09/19 17:52:00 sensorstate: state=true 02/09/19 17:52:00 startscene: scene=__trip, sceneName=__trip 02/09/19 17:52:01 devicewatch: device=8, old="Disarmed", name=EVL3 Vista Partition 1, var=urn:micasaverde-com:serviceId:AlarmPartition2/ArmMode, new="Armed" 02/09/19 17:52:11 error: message=tick failed, reason=./L_Reactor.lua:804: attempt to get length of local 'val' (a number value) 02/09/19 17:52:40 devicewatch: device=10599, old="1", name=Porch Motion, var=urn:upnp-org:serviceId:SwitchPower1/Status, new="0" 02/09/19 17:52:40 condchange: newState=false, cond=cond168691f6933, oldState=true 02/09/19 17:52:40 evalchange: newState=false, cond=cond168691f6933, oldState=true 02/09/19 17:52:40 groupchange: newState=false, cond=grp168691f6932, oldState=true 02/09/19 17:52:40 sensorstate: state=false 02/09/19 17:52:40 startscene: scene=__untrip, sceneName=__untrip

As well, the run scene action is not executing on the sensor trip but it does run directly from the “run” command in Altui. There are no error messages regarding the scene execution.

[code] Version: 2.2stable-19026 config 206 pluginDevice 149
Local time: 2019-02-09T18:06:23-0800, DST=0
House mode: 1
Sun data: {“stamp”:2019040,“civdawn”:1549721883,“nautdawn”:1549720108,“sunset”:1549762244,“nautdusk”:1549765575,“latitude”:34.09,“astrodusk”:1549767330,“longitude”:-118.27,“civdusk”:1549763799,“astrodawn”:1549718352,“sunrise”:1549723438}
Geofence: not running
Power: , battery level

Porch Motion Sensor (#160) armed
Version 19012.1549688013 02/08/19 20:53:33
Message/status: Not tripped
Group #1 false as of 17:52:40
=f (service) Porch Motion (10599) urn:upnp-org:serviceId:SwitchPower1/Status = 1 [false/false as of 17:52:40/17:52:40; 1 => 0 at 17:52:40]
=T (service) EVL3 Vista Partition 1 (8) urn:micasaverde-com:serviceId:AlarmPartition2/ArmMode = Armed [true/true as of 17:52:00/17:52:00; disarmed => armed at 17:52:00]
Trip Actions
Device 10550 (Living Overhead) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue=1 )
Device 10178 (Bedroom Overhead) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue=1 )
Device 10357 (Upper Office Light) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue=1 )
Device 111 (IOS Push) action urn:upnp-org:serviceId:IOSPush1/SendPushOverNotification( Title=Porch Light On, Message=Porch Light On, Priority=1 )
Delay 10 inline
Device 10597 (Entry Table Lamp) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue=1 )
Run scene 5 ACTiBedroom
Run Lua:
luup.inet.wget(‘http://10.17.5.60:8080/jsonrpc?request={“jsonrpc”:“2.0”,“method”:“Addons.ExecuteAddon”,“params”:{“wait”:false,“addonid”:“plugin.video.surveillanceroom”,“params”:{“action”:“show_preview”,“camera_number”:“2”,“id”:“1”}},“id”:2}’)
luup.inet.wget(‘http://10.17.5.60:8080/jsonrpc?request={“jsonrpc”:“2.0”,“method”:“Addons.ExecuteAddon”,“params”:{“wait”:false,“addonid”:“plugin.video.surveillanceroom”,“params”:{“action”:“show_preview”,“camera_number”:“3”,“id”:“1”}},“id”:2}’)
Untrip Actions
Delay 10 inline
Device 10550 (Living Overhead) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue=0 )
Delay 10 inline
Device 10178 (Bedroom Overhead) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue=0 )
Device 10357 (Upper Office Light) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue=0 )
Device 10597 (Entry Table Lamp) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue=0 )[/code]

[quote=“Buxton, post:7, topic:200547”]I was getting the same null error while running sensor lua in openluup, and the revised code did stop the error message. However, I’m also getting the following during the untrip actions (which are not executing):

02/09/19 17:52:00 devicewatch: device=8, old="Disarmed", name=EVL3 Vista Partition 1, var=urn:micasaverde-com:serviceId:AlarmPartition2/ArmMode, new="Armed" 02/09/19 17:52:00 condchange: newState=true, cond=cond16873e9d143, oldState=false 02/09/19 17:52:00 evalchange: newState=true, cond=cond16873e9d143, oldState=false 02/09/19 17:52:00 groupchange: newState=true, cond=grp168691f6932, oldState=false 02/09/19 17:52:00 sensorstate: state=true 02/09/19 17:52:00 startscene: scene=__trip, sceneName=__trip 02/09/19 17:52:01 devicewatch: device=8, old="Disarmed", name=EVL3 Vista Partition 1, var=urn:micasaverde-com:serviceId:AlarmPartition2/ArmMode, new="Armed" 02/09/19 17:52:11 error: message=tick failed, reason=./L_Reactor.lua:804: attempt to get length of local 'val' (a number value) 02/09/19 17:52:40 devicewatch: device=10599, old="1", name=Porch Motion, var=urn:upnp-org:serviceId:SwitchPower1/Status, new="0" 02/09/19 17:52:40 condchange: newState=false, cond=cond168691f6933, oldState=true 02/09/19 17:52:40 evalchange: newState=false, cond=cond168691f6933, oldState=true 02/09/19 17:52:40 groupchange: newState=false, cond=grp168691f6932, oldState=true 02/09/19 17:52:40 sensorstate: state=false 02/09/19 17:52:40 startscene: scene=__untrip, sceneName=__untrip

As well, the run scene action is not executing on the sensor trip but it does run directly from the “run” command in Altui. There are no error messages regarding the scene execution.

[code] Version: 2.2stable-19026 config 206 pluginDevice 149
Local time: 2019-02-09T18:06:23-0800, DST=0
House mode: 1
Sun data: {“stamp”:2019040,“civdawn”:1549721883,“nautdawn”:1549720108,“sunset”:1549762244,“nautdusk”:1549765575,“latitude”:34.09,“astrodusk”:1549767330,“longitude”:-118.27,“civdusk”:1549763799,“astrodawn”:1549718352,“sunrise”:1549723438}
Geofence: not running
Power: , battery level

Porch Motion Sensor (#160) armed
Version 19012.1549688013 02/08/19 20:53:33
Message/status: Not tripped
Group #1 false as of 17:52:40
=f (service) Porch Motion (10599) urn:upnp-org:serviceId:SwitchPower1/Status = 1 [false/false as of 17:52:40/17:52:40; 1 => 0 at 17:52:40]
=T (service) EVL3 Vista Partition 1 (8) urn:micasaverde-com:serviceId:AlarmPartition2/ArmMode = Armed [true/true as of 17:52:00/17:52:00; disarmed => armed at 17:52:00]
Trip Actions
Device 10550 (Living Overhead) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue=1 )
Device 10178 (Bedroom Overhead) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue=1 )
Device 10357 (Upper Office Light) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue=1 )
Device 111 (IOS Push) action urn:upnp-org:serviceId:IOSPush1/SendPushOverNotification( Title=Porch Light On, Message=Porch Light On, Priority=1 )
Delay 10 inline
Device 10597 (Entry Table Lamp) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue=1 )
Run scene 5 ACTiBedroom
Run Lua:
luup.inet.wget(‘http://10.17.5.60:8080/jsonrpc?request={“jsonrpc”:“2.0”,“method”:“Addons.ExecuteAddon”,“params”:{“wait”:false,“addonid”:“plugin.video.surveillanceroom”,“params”:{“action”:“show_preview”,“camera_number”:“2”,“id”:“1”}},“id”:2}’)
luup.inet.wget(‘http://10.17.5.60:8080/jsonrpc?request={“jsonrpc”:“2.0”,“method”:“Addons.ExecuteAddon”,“params”:{“wait”:false,“addonid”:“plugin.video.surveillanceroom”,“params”:{“action”:“show_preview”,“camera_number”:“3”,“id”:“1”}},“id”:2}’)
Untrip Actions
Delay 10 inline
Device 10550 (Living Overhead) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue=0 )
Delay 10 inline
Device 10178 (Bedroom Overhead) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue=0 )
Device 10357 (Upper Office Light) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue=0 )
Device 10597 (Entry Table Lamp) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue=0 )[/code][/quote]

You’re still on 2.2. Upgrade to 2.3 and try again. These issues were addressed shortly before release.

Sorry about that. I should have checked the version first. Here’s the log from the upgrade version.

Version: 2.4stable-19033 config 206 pluginDevice 149 Local time: 2019-02-09T19:45:41-0800, DST=0 House mode: 1

The scene did not run, but there is an error message:

02/09/19 19:43:53 runscene: scene=__trip160, sceneName=__trip160, notice=Starting scene group 2 02/09/19 19:43:53 startscene: scene=5, sceneName=ACTiBedroom 02/09/19 19:43:53 error: message=tick failed, reason=./L_Reactor.lua:900: attempt to index field '?' (a nil value) 02/09/19 19:44:29 action: action=Reset 02/09/19 19:44:29 sensorstate: state=false

This scene is composed entirely of Lua code that creates some data, and then calls a service of a plugin with the data.

[quote=“Buxton, post:9, topic:200547”]Sorry about that. I should have checked the version first. Here’s the log from the upgrade version.

Version: 2.4stable-19033 config 206 pluginDevice 149 Local time: 2019-02-09T19:45:41-0800, DST=0 House mode: 1

The scene did not run, but there is an error message:

02/09/19 19:43:53 runscene: scene=__trip160, sceneName=__trip160, notice=Starting scene group 2 02/09/19 19:43:53 startscene: scene=5, sceneName=ACTiBedroom 02/09/19 19:43:53 error: message=tick failed, reason=./L_Reactor.lua:900: attempt to index field '?' (a nil value) 02/09/19 19:44:29 action: action=Reset 02/09/19 19:44:29 sensorstate: state=false

This scene is composed entirely of Lua code that creates some data, and then calls a service of a plugin with the data.[/quote]

Sorry. I should have been more clear. The 2.3 release fixes the two NEW things you mentioned. The old issue (which is the nil hit on openLuup), still requires you to go in and make the one-line fix, which I’m guessing you did not because of the poor thoroughness of my prior response (I should have warned you to re-apply the patch). The 2.4stable-19033 version (from the Github stable branch) you have installed does not yet contain this fix. The “hotfix” branch, however, now does as of last night, so if you apply that branch in the AltUI plugins page, it should go better.

FYI, the “hotfix” branch comes from the last master (released) branch, and will contain only fixes deemed important enough, and no new features or other work. It is therefore expected to be an incremental improvement from the most recent release, with no regressions or injections. The “stable” branch comes from my “develop” branch, and is therefore likely to contain work in progress and therefore may contain new and interesting behaviors (of the less-desirable variety). Unless you’re putting yourself in line to help test something new, stick with the “hotfix” branch for post-release updates.

OK thx. All is working correctly now.

One small complaint. My log is getting spammed by the Reactor trap for global variables at around lua line 902. I’m using the following generic function to search for a value in a complex table:

local function allmatching(tbl, kvs) local row ="" return function(t, key) repeat key, row = next(t, key) if key == nil then return end for k, v in pairs(kvs) do if row[k] ~= v then row = nil break end end until row ~= nil return key, row end, tbl, nil end

Which yields the following log entries that continue for about 100x

2019-02-11 21:37:47.775 luup_log:149: Reactor: "Porch Motion Sensor" (160) runLua action: "scene5_start" accesses undeclared/uninitialized global "row" 2019-02-11 21:37:47.776 luup_log:149: Reactor: "Porch Motion Sensor" (160) runLua action: "scene5_start" makes assignment to global "row" (missing 'local' declaration?) 2019-02-11 21:37:47.777 luup_log:149: Reactor: "Porch Motion Sensor" (160) runLua action: "scene5_start" accesses undeclared/uninitialized global "row" 2019-02-11 21:37:47.777 luup_log:149: Reactor: "Porch Motion Sensor" (160) runLua action: "scene5_start" makes assignment to global "row" (missing 'local' declaration?)

The search function returns an anonymous function until it does not “nil” out–where it returns the sought for value, so the variable “row” goes out of scope in the primary closure, but remains in global scope because of the first class function behavior of lua. At least that’s what I think is going on. Do I need to adjust the scope of the anonymous function somehow? My lua understanding here is limited… Otherwise, my reactor sensors are working great!

OK. Please post the logic summary (Tools tab), and also run this request and post its output as well:

[tt]http://your-vera-ip:3480/data_request?id=lr_Reactor&action=status[/tt]

Also, since you’re running on openLuup, please send me the output of both “lua -v” and “uname -a”.

OK, so after a bunch of tests I resolved the problem by initializing “row” as an empty table instead of a string:

local function allmatching(tbl, kvs) local row ={} return function(t, key)

There are no error messages now, but during testing I was getting some log errors for global functions that are used in call_delay routines. After setting the “row” variable correctly, these messages stopped. Through all of the many tests, changing this and that and regardless of error messages, the reactor sensor operated correctly… There are no errors in the reactor logic output.

Here are the system stats you asked for:

[code]root@Lurch:~# uname -a
Linux Lurch 4.17.14-sunxi64 #56 SMP Wed Aug 15 14:58:47 CEST 2018 aarch64 aarch64 aarch64 GNU/Linux

root@Lurch:~# lua -v
Lua 5.1.5 Copyright (C) 1994-2012 Lua.org, PUC-Rio
[/code]

So no need for any action, though I’m going to PM you the json status output as there is some private data in there. There are errors parsing the file in several json lint apps and I don’t know if the parse errors are important or not…

[quote=“Buxton, post:14, topic:200547”]OK, so after a bunch of tests I resolved the problem by initializing “row” as an empty table instead of a string:

local function allmatching(tbl, kvs) local row ={} return function(t, key)

There are no error messages now, but during testing I was getting some log errors for global functions that are used in call_delay routines. After setting the “row” variable correctly, these messages stopped. Through all of the many tests, changing this and that and regardless of error messages, the reactor sensor operated correctly… There are no errors in the reactor logic output.

Here are the system stats you asked for:

[code]root@Lurch:~# uname -a
Linux Lurch 4.17.14-sunxi64 #56 SMP Wed Aug 15 14:58:47 CEST 2018 aarch64 aarch64 aarch64 GNU/Linux

root@Lurch:~# lua -v
Lua 5.1.5 Copyright (C) 1994-2012 Lua.org, PUC-Rio
[/code]

So no need for any action, though I’m going to PM you the json status output as there is some private data in there. There are errors parsing the file in several json lint apps and I don’t know if the parse errors are important or not…[/quote]

After requesting all of that of you, I set up your code (with [tt]row[/tt] initialized as a string as in your first post) in a scene on my openLuup, and I got no messages whatsoever. I put your function through its paces by finding and logging all ReactorSensors ([tt]for k in allmatching(luup.devices,{device_type=“urn:schemas-toggledbits-com:device:ReactorSensor:1”})…[/tt]), and it worked fine and didn’t output anything to the log file or events list. I also tried it in “Run Lua” actions with the same (no warnings) result. Everything works exactly as expected. Something must be different between our setups, and I’d like to understand what. Weird. But yeah, it’s just a warning message; it would not/should not affect functionality at all.