DynamicGroupController and attributes

[gwp1]

@toggledbits I guess that's the problem: there are only Global expressions selectable. Looking thru the rules:

[toggledbits]

Back in mid-2021 there were a bunch of changes to variable evaluation and the rules around that, and among them, a rule cannot set or examine a local variable in another rule. I suspect you're just noticing the effect of that here. The engine still runs those rules, but you cannot edit them and leave them in that condition. The shared variable needs to be moved to global scope.

[gwp1]

@toggledbits I suspected that might be the case (something changed). Of course, I've poked at the Deactivated rule this morning so I've probably broken things now.

I'm guessing I need to convert any Local expression "sets" to Global to fix this?

[toggledbits]

@gwp1 said in Reactor Ex Machina:

I'm guessing I need to convert any Local expression "sets" to Global to fix this?

Not all, just the ones that referred to from other rules.

[retireditguy]

@toggledbits
Working on migrating off of Vera. I am also trying to use Reactor Ex Machina and wonder whether the changes you referenced above might also keep REM from shutting down properly. REM toggles the lights off and on up until the expiration of the active period. REM ends without turning all of the lights off. The construct I am wondering about is - {{ each light in REM_Lights: performAction( light, 'power_switch.off' , { } 0 }}
I assume this is supposed to turn all of the lights in the array. I modified the "code" to handle the local/global variable change by moving cycler_stim to Global , but otherwise my REM is as it was after you modified "Deactivate REM' back on May 28, 2021. Any ideas?

https://smarthome.community/topic/557/solved-random-ghosting-of-lights-when-away/32?_=1677904265383

[retireditguy]

The Board changed ) : to an emoticon.

[retireditguy]

This post is deleted!

[gwp1]

@retireditguy Here are my rulesets and it works just fine.

[retireditguy]

Except for the values defining the active time in "Active Period", our scripts are identical. Additionally we are both controlling Hubitat systems. My testing seems to indicate that REM only shuts off one light at the end of the defined period. I believe it was the last one turned on. Are you sure that REM turns off all of your lights at the end of the defined period? I suspect there may be something wrong with the execution of the statement {{ each light in REM_Lights: performAction( light, 'power_switch.off' , { } ) : 0 }} as I noted above. Another "anomaly" occurs at start-up. The 3 scripts together are sensitive to the start sequence. If "Cycler" is started before both "Active Period" and "Deactivated", "Cycler" will trigger as soon as either starts since they both change cycler_stim.

[toggledbits]

@retireditguy said in Reactor Ex Machina:

I suspect there may be something wrong with the execution of the statement {{ each light in REM_Lights: performAction( light, 'power_switch.off' , { } ) : 0 }}

The expression you show is incorrect -- where you have a colon (:) at the end of the each subexpression (after the closing paren of performAction()) should be a semicolon (;), like this:

${{ each light in REM_lights: performAction( light, 'power_switch.off', {} ); 0 }}

[gwp1]

@toggledbits Not gonna lie, you made me go squint at mine just to be sure.

[kellyjelly32]

If anyone is interested, I will copy/paste my code here for my solution. It builds on the initial "Reactor Ex Machina" from 2021 but incorporates the changes made to MSR since then. I also modified it in such a way to have the OFF switching done individually for each light with definable delays. A bathroom light that way can go OFF after a random 1-5m while the kitchen stays on for longer for example. I made some other changes as well to suit my needs. It works for me, it might not for you.

You need four "Global Expressions":

• REM_lights

#list of all DeusExMachina (now ReactorExMachina REM) lights to control
#this is an array [ ]
#every entity in ' ' (apostrophes) separated by , (comma) in new line
#check entity list to get canonical ID to be used
#comments start with hash and are ignored
[
'hass>input_boolean_testlight', #Test 
'hass>input_boolean_testlight2', #test2
'hass>input_boolean_testlight3', #Stephan
'hass>input_boolean_testlight4', #Stephan
'hass>input_boolean_testlight5', #Stephan
'hass>input_boolean_testlight5', #Stephan
'hass>input_boolean_testlight5' #Stephan
]

• REM_dummy (leave empty)

• REM_cycler_stimulus (leave empty)

• REM_status (leave empty)

If you want a light to be more frequently "ghosted" add it multiple times into the list. In my case light5. If you are on HA, you can add via the helper section some virtual toggles as I did to test your setup. Probably also possible on other platforms.

My rules are like this:

Start & Stop rule (via set/reset reaction), the ghost switching on the lights and then for each light a ghost which switches off so I can manage the individual behavior per light.

The Start&Stop rule:

The reset code bit, hard to read/copy from screenshot:

${{ each light in REM_lights: performAction( light, 'power_switch.off', {} ); 0 }}

The ghost for switching ON a random element/light from the list:

Code:

${{ performAction( REM_lights[ floor( random() * len( REM_lights ) ) ], 'toggle.toggle', {} ) }}

${{ random()*600 + 600 }}

${{ REM_cycler_stimulus + 1 }}

The light-specific OFF ghost:

${{ random()*600 + 300 }}

Some explanation for random function and the values used with it. It randomly generates number between 0 and 1 (example: 0.4739302) The delay time is in seconds. So the above example will create a delay of 300s minimum plus anything between 0 to 10m, effectively a random time of 5m-15m. See what works for you.

This REM is working well for me and I am now finally ready to migrate it all to HA after many years on my trusty Vera Lite which is about to die of flash memory degradation.

[3rdStng]

Ahh... I miss that app. Probably one of my favorites from my Vera days. The "Lighting Director" app on Hubitat just isn't the same.

Thanks for posting your setup @kellyjelly32. I've mocked this into my MSR and if all works well, DeusExMachina returns. Well kinda

[3rdStng]

@kellyjelly32 Is there a way to specify how many lights should be on at one time? I tested REM last night and the most on at the same time appeared to be two. I'm fine with this, but curious if there was an option or way to adjust it. Again, thanks for sharing your logic.

[kellyjelly32]

My REM "Switch ON Ghost" is using the "toggle" action. This means it can also switch a light off if the one chosen randomly is (still) on. Change that to power_switch.on and it can only switch lights ON. This will at least prevent the "ON Ghost" from turning/toggling lights OFF. Then it all comes down the the times used to in the random() functions between the "ON Ghost" toggles/switches lights ON and the "OFF Ghosts" switching lights OFF.
Probably the introduction of another variable like REM_active_lights which is increased every time the "ON Ghost" switches something ON and decreased when the "OFF Ghost xyz" turns it off, you can track how many lights are ON. Add a AND trigger in the "On Ghost" that states "REM_Active_lights" equal/smaller than "4" and you can make sure that no more than four lights will be on at any time.
Probably you need to somehow force the MSR to re-evaluate the "Ghost ON" conditions to start another cycle, once enough lights are out again. Maybe another "Ghost" to keep track of the REM_Active_lights, when below 4 to count the REM_cycler_stimulus up to re-start the ON Ghost.

I will see if I can get it to work...

[3rdStng]

I'm not in need of it. As I was moving off Lighting Director I just happened to notice they had a max number of lights. I think the OG DeusExMachina did too. I think how you have it would be more lifelike. Especially when you couple of a few specific OFF rules so the lights turn off faster than 10-20 minutes.