Also I jumped Vera ship over a year ago and made the full transition to HA with MSR. My HA is running as HAos on an old NUC-like x86 which I got for 80€. It has full gigabit LAN, plenty of USB2.0 for the radios (UZB1 for Z-Wave and Conbee2 for Zigbee) on extensions away from the unit for better performance and of course a SSD with 120GB. Plenty of space and performance for HA with Addons, at least for me. My only headache is the MSR which is currently running as an addon in HA but it is not maintaned anymore from the original publisher... So I am now considering to get a second machine just to run MSR, either bare-metal or as a docker.
Just my 2cents

Restarting reactor from reactor itself after changing any global expressions or making new global expressions is doing the trick for me currently.

Restarting reactor from reactor itself after changing any global expressions or making new global expressions is doing the trick for me currently.
But I am using MSR via the unofficial addon by @mrw298 .

I am using the HA addon provided by @mrw298 , there are no configs other than the access token to be done. I will see what he thinks. My disk is plenty empty.

"Global Expressions" aka those things you can define and use for variables and calculations don't survive a reboot. After a reboot they are gone. The whole page with global variables is empty. I need to define them again. All rules which use one of these "global expressions" have a little yellow warning triangle and in the rule, be it conditions or actions or reactions, they are stated as "missing".
As my system usually runs extremely stable I never noticed it as it never rebooted. Until this weekend when I physically had to shut it down and reboot a few times.
I think it is a HA addon issue from @mrw298 not from MSR itself.

After doing some tinkering again this weekend on my HA real-life system, I noticed that the "global expressions" are not persistent when rebooting / restarting the MSR addon for HA. "global reactions" survive a reboot, as do all the rules (with their reactions / untested with local expressions). Ultimately it is probably an issue with the addon, not with MSR. Just want to see/hear from @toggledbits if there is something special about how the global expressions are saved vs the other stuff.

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...

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.

@toggledbits
I am running the addon in v0.0.7 (2023-02-20) [which is using Reactor build 23049 as per changelog] with:
Home Assistant 2023.3.1
Supervisor 2023.03.1
Operating System 9.5
Frontend 20230302.0 - latest

I was more trying to reach @mrw298 as he is the creator of the addon. Judging from the changelog, I can´t update MSR that simple and need to wait for a new version of his addon to be pushed.

The reminder pops up in any browser I tried so far, probably because it can´t really create a cookie. It even pops up in the HA mobile app. But I think the reactor front-end was never designed to run in such an environment. It is a minor cosmetic nuisance.

I am using the addon for HA, running excellent.
Finally my dream came true, using the excellent reactor engine to automate all my devices, mix and match rules and technologies.
Will offload now finally from my rusty Vera Lite to HA...

Two things: I keep getting the "reminder" to enter the last four digits despite having done it multiple times.
Can I safely update MSR from within the addon or do I need to wait for an update to the addon?

Really appreciate the effort. My Vera with all the non-migrated Z-Wave is currently not reachable (holiday home). Can't migrate the devices to HA without being there. End of March I might be there to do it. Still need to find a way to get MSR to run. There is no easy way to run it on the same hardware my HA is running on (I run HA OS on bare metal). Or have I missed a MSR addon for HA?

Running a HA with zwaveJS2 and an old Vera Lite with some not-yet-migrated devices. Reason for not migrating is that I love Reactor. On HA I was not able to get MSR to run yet.