Reactor 3.0 Beta Now Available

Yup, I knew I would have to bring it to this level. The fixed AND-OR grouping is not an uncommon paradigm, and a good place to start, but was never expected to be the end. Crazy to think that v1.0 had its public debut less than 10 months ago.

2 Likes

I just posted beta3.0-19104 to the Github repository’s beta3.0 branch. If you are using beta3.0, please update to this version.

Hello
I’m not able to install the Reactor 3.0
I did install ALTUI, copy the files of ALTUI from Github but i’m not able to launch the lua script
May you help to get a clear install procedure ?
Thanks

Are you ALTUI on Vera or ALTUI on openLuup?

Hi
Thanks for your reply
i’m on Vera UI7

OK. No AltUI required, but if you’re trying to install it, I recommend you get it properly installed and working before installing Reactor 3.0. There are instructions for installing the Reactor 3.0 Beta on the first post of this thread, at the bottom.

Hi
Thanks i did it the simple way !
I gave you 5 via paypal
Nice plugin, pretty good job
Thanks

1 Like

I am currently travelling and will not have access to my Veras for 2 weeks. If someone running Reactor 3.0 Beta that has access to the 7.0.29 RC firmware could test, I would appreciate the helping hand!

I’ve just upgraded to the latest RC.
No apparent issue, I’m running your latest 3.0 github code, I’ve been firing some Reactor sensors and they behave normally … so yeah, at first sight all good.

1 Like

Hi
Did try the plugin today, works well

1 Like

@rigpapa - Enjoy your travels! That said, I can confirm that the latest Reactor beta has been working perfectly on a Vera Plus running the RC firmware for the past 24 hours with sensors that trigger due to sun and house mode transitions.

$ ssh vera cat /etc/cmh/version
1.7.4453

$ git lg -1
* 583e859 - (HEAD -> beta3.0, origin/beta3.0) Update version for release (5 days ago) <Patrick Rigney>
1 Like

I have found a problem with the latest beta but only while using the Activities editor. I haven’t regression tested it against an earlier beta so I am not 100% certain this is a new issue or existing 3.0 issue.

Steps to reproduce:

  1. Create a Reactor Sensor with multiple re-usable Condition Groups
  2. Under Activities, create 5 or 6 Device Actions under the main Reactor Sensor Group
  3. Under Activities, Copy Actions From the main Reactor Sensor Group to a sub-group within the same sensor

At this point, the web app will start leaking memory to the point that my browser (Safari) terminates the web page.

Work-around: As soon as you Copy From, click Save.

Ok. I’ve got a Linux laptop with me with openLuup installed, so I’ll see if I can reproduce it on that rig.

I have experimented with moving scenes into Reactor but are getting some difficulties in case there are many Device Actions in the list of Activities.

In total I have around 30 Activities as maximum but when I start adding them, my system becomes slower and slower as soon as I get to 20 and at 24 or 25 Activities the system becomes completely unresponsive and the browser times out.

Only way to get the system stable is opening another browser and delete the Reactor Sensor.

Sensor 24 report.zip (1.3 KB)

@rigpapa is looking into a potential resource leak in the Activities editor, likely correlated with the number of activities being edited. I provided a repeatable scenario a few posts earlier. In my case, the resources grow to the point that Safari actually terminates the rogue page with a warning.

I did find what I believe to be the cause, but I’m not able to publish the fix at the moment due to internet restrictions (who in the heck blocks github???). I will be back at my desk 5/3 and will publish it ASAP with background info.

2 Likes

@blacey and @Leifgg,

Got back to my desk a couple of hours ago, and packaged up my fix (based on hypothesis). Please install the latest beta3.0 branch version (19123) from Github (instructions in the head post of this topic) and give it a try.

Ok, so I regressed the user scenario above and it works better unless I hit “revert” at which point it consumes enough resources that Safari reloads the page with “This webpage was reloaded because a problem occurred” error message. So it seems the case where I copied 5+ activities from one activity condition to another without quickly hitting save is fixed however, if I click Revert, and then “Ok”, I see the spinning cursor and Safari whacks the page with the same error. Let me know if you need additional details…

Did same test again (after update) but instead of manually doing the scene in Reactor I did do an import. Still same problem, it never finishes loading all Actions and browser (Firefox) times out and eventually crashes. Enclosed some pics.Pics.zip (283.5 KB)

OK. So I’m relying on you guys for thoroughness and content here. I do not have a Mac, so I cannot test Safari. I do use Firefox, but I am not able to duplicate the problem with an activity of 64 devices. So, I’m code reviewing intently, walking through carefully, and making (hopefully) intelligent guesses at things that could lead to the problem.

The 19123 fix posted yesterday attempts to reduce overall request traffic to the server (Vera) when loading actions (since that’s the only way I can get them currently) by wrapping the request in a Promise and re-using that object for all similar requests. This appears to have had some benefit (or we just may be lucky/chancy). Still, I’m not completely sold that I’m on the right track, as the browser should manage a large number of requests (as it does loading a page with 100 images) handily without crashing. What Vera does is another matter, but I’m not ready for that dive yet.

I have a new version of J_ReactorSensor_UI7.js that goes a step further on the above optimization. Please install and test it. You can download it by right-clicking this link and choosing “Save Link As…”. You only need to send this single file to your Vera. Then do a hard-refresh on your browser–very important. Go into the Tools page, and make sure the version shown in the footer contains “19124” (not 19123 or anything else)–then you’ll know the right version is running on the browser. Then repeat test and let me know your findings.

This patch also removes the “Common Actions” section of the menu (will not affect your configuration) for the moment, just to eliminate one code path from the research. If this patch resolves the issue, I’ll re-enable “Common Actions” with some additional modifications and as you to retest with that in place.

I appreciate you both being my eyes and hands on this.