Lua and Scenes not running

[Tarkus-NJ]

It seems that group activity Lua and Scenes are not running when triggered by associated group conditional. The Lua runs fine through a standard Vera manually triggered scene

[toggledbits]

Logic summary, please. Preferably after triggering conditions that would run scenes and Lua.

[Tarkus-NJ]

*************************************************** REACTOR LOGIC SUMMARY REPORT ***************************************************

(snipped -- see attachment)

activitysummary.txt

[toggledbits]

Hmmm. OK. Let's get a log snippet. The process is described in the Troubleshooting section of the Tools tab. Probably best to post as an attachment (plain text file), given that Github wants everything posted in the thread to be Markdown. Make sure you do some action that would run activities like "Zone 2 Power On" (the instructions say just to Restart, but in this case you'll need to do more).

[Tarkus-NJ]

Snippet attached Snippet.txt

[Tarkus-NJ]

Patrick,

Scenes / Lua activities working intermittently, but if they do it takes a minute or up to a few minutes to kick in, sometimes not at all.

[toggledbits]

Unfortunately the snippet doesn't show any useful state changes. Let's focus on a single condition/group: the group with id "grpb1z6koc", called "Zone 2 Power On" under Functions > Zone 2 Functions > Zone 2 AV Inputs, looks like a simple condition that goes TRUE when the Yamaha receiver zone 2 is switched on, and is has true and false activities. So let's just look at that one.

Go through the snippet process again--debug on, restart the sensor, go to the Status tab, and then immediately turn the receiver's zone 2 on or off (doesn't matter which), and observe the state change on the status tab. Toggle the zone power again, and take the snippet.

While you're doing that, I'm going to make the debug less chatty. Sheesh.

[Tarkus-NJ]

I did a reboot of my vera and it seems to have improved a lot 5-7 seconds for my hdmi matrix to switch inputs. I will keep my eye on it to see if it is stable, running lua direct not through a scene.

[Tarkus-NJ]

It is starting to act up again intermittent delays sometimes a minute to exectue lua. I followed your snippet instruction and attached a new snippet. The activites are lua and the and the condition group is Receiver Zone 2 grpb27c6pk

This changed from "grpb1z6koc", called "Zone 2 Power On" which you referenced.

As a test I also changed the activity action on Receiver Zone 2 grpb27c6pk to just turn on a virtual switch and that did not work as well even though the status was true. This test is not in snippet,

Receiver Zone 2 grpb27c6pk = True and Receiver Zone 2 grpb27c6pk = False Are running lua and should be reflected in snippet. Snippet2.txt

[toggledbits]

Unfortunately this test case is so large that the snippet runs out before I can see the complete response to the condition changes.

Can you set up a simple RS that only does the Zone2Power test and runs the activities associated with On and Standby, nothing else? Let's see how that does for starters.

[Tarkus-NJ]

Just set up a new sensor with just Receiver Zone 2 power. Lua is executing on both true and false but seems like its taking about 15 seconds for power state change to be visible and execute true lua. False lua seem to execute almost immediately based on seeing my tv screen change (lua controls HDMI Matrix switch) but reactor status takes 10-15 seconds to update to false. I also disabled my production sensor before going through the whole snippet routine on the simple test sensor. Snippet attached.

Snippet3.txt

[toggledbits]

Whew, That's much better.

Looking at the log, from the time Luup dispatches the watch for Zone2Power changing to call to run the "root.false" activity is 33 milliseconds (watch at 22:03:33.355, Lua starts running at 22:03:33.388). Lua execution completes at 22:03:34.442, a little more than one second later. That seems to be consistent with the luup.sleep() call in your original Lua (I didn't unpack the encoded Lua in the log snippet to see if that delay is still there; I'm assuming it is). The entire update ends at 34.447, 5ms later. so the logged performance is pretty crisp, I'd say.

but reactor status takes 10-15 seconds to update to false

By this I'm assuming you mean the Status tab display. I'm not too worried about that, as I discovered a bug yesterday that causes a delay on that tab. The next revision will have the bug fixed and the status page is noticeably crisper.

Then at 22:05:34.377 we have a switch from Standby to On. The RS completes its evaluation at 22:05:34.397, so just 20ms later, and starts the Lua activity at 34.411. The Lua activity completes at 35.465, again a little over a second and consistent with your past Lua code. The entire task finishes at 35.470, 5ms later. Total response time 1.093 seconds. Again, pretty crisp.

As I continued to study the prior log, I think I did see a potential scheduling issue. I'm not sure if that's a bug in some aspect of the task scheduling of changed groups, or if somehow your config has a loop. You might check to see that your service conditions examining GroupStatus_xxx are not looking at the group status of a parent group of the condition, its ancestors or siblings. The "Group State" condition type that I added today includes those checks. But I will continue to look at this on my side, since I do see some repetition in the evaluations that I'm not happy with, or at least, I can't explain why they are being done (which by definition makes me unhappy with them).

So as of right now, to summarize, here's where I think we are with this:

• Delay on Status is a known bug and cosmetic;
• Underlying operation of the simple test case is showing crisp response as expected;
• Continued examination of the complex (prior) test case suggests some undesirable repetition of evaluation, which could be a scheduling bug, or could be a logic loop. I am continuing investigation on the possibility of the former.

[toggledbits]

OK, so based on the long form and short form sensor configuration snippets, and the config from your other report, I think I see the issue. Stay tuned. I'll have a new beta package out later today.

[toggledbits]

Reactor Beta 3.0-19083 links have just been emailed to all beta participants. This version contains the fix for this bug.

[Tarkus-NJ]

Preliminary testing of Reactor Beta 3.0-19083 looks good in resolving issue #19. Keep in mind that I am working remotely so I needed to add some delays to activities to slow up the process so I could track the triggering of some virtual switches. Once I am home I will be able to remove delays to evaluate more fully. The good news is activities are executing correctly from what I can see and updating on the status tab seems quicker. Also liking the new group state condition.

[toggledbits]

A simple debugging tool you can add to your conditions is a little tricky feature of the "Comment" service type: if the first character is star (* ASCII 42), the ~message~comment text will be written to the event log, which is shown in the Logic Summary. You can keep the logic summary tab open and refresh it as you work with the devices or the RS in a different tab.

[Tarkus-NJ]

This issue seem to be resolved and stable from what I can see. Will continue to monitor.