Reactor dimmer mirror/follower help

[mbc2237]

Hello all. I am running into issues trying to get two Ge/Jasco dimmers to mimic each other. Here is my reactor logic so far:

(hopefully that uploaded)

All works really well except the off and on functions from the switches. I believe that the problem is in how the switch tells the load to turn on and off. There is a ramp up/down. This causes the targetlevel and getstate evaluations to write during the ramp. I tried to delay the action of writing for 2 seconds to wait for the ramp to complete but this means that there is a 2-3 second delay in any matching of the switch conditions. And even then sometimes the other switch will write its condition first. Not the one that is being altered. I’ve looked into trying to make those switches have an instant on and off without the ramp but have not been able to get that working. Thoughts?

[rigpapa]

Explain your logic a bit more for us. What is each condition meant to do? What are the changes condition meant to do? Did you know that changes will only produce a very brief pulse for a few milliseconds?

[mbc2237]

thanks for the quick reply! The initial setup was from your post here: Mirror Dimmer Setting to 2nd Device but it was closed so I couldn’t continue the conversation.

The logic you provided does make sense to me but I admit I am still struggling. The first group (dimmer_status_check) checks if the dimmer changes state, if it does, it loads that value into the targetlevel expression. the second group checks to see if the reactor sensor matches the targetlevel expression and if not, will set that dimmer to the targetlevel. I think

I have two dimmers that I want to be able to operate but have the other follow. So if I turn on the light from the “bar” it makes the “main” lights match with the converse also applying. Control from main and the bar lights follow. I thought that adding a"debounce" to let the conditions settle before evaluating them would correct the issues I am having but I am not sure how to do that. I tried delaying the reset of the condition but that didnt give the correct behavior. I also thought I could delay the actions until the targetlevel expression stopped updating but that didn’t work for me either. I may be headed down the wrong path altogether? It’s the first time I am trying something with your powerful tool and clearly missing something(s).

[mbc2237]

I’ll also add that the only time there seems to be an issue is controlling from the switches themselves. I think this is due to the ramp speed and when the conditions are evaluated. Example, I turn off the lights from the switch. The action of the switch is to dim the lights and then turn off (default and I do not think I can modify this). Watching the status screen I can see that the targetlevel is written at like 94 when dimming from 100, then again at like 15, but then it isnt written again. this tends to make the lights that are in the process of turning off, come back on at 15 to match the targetlevel. this is very hard for me to explain so I hope this is helping.

[mbc2237]

Just tried simplifying the logic based on your initial comment. I now have this:

this one also works until I turn the light off from either switch. then the evaluation avalanches and restarts the engine.

[rigpapa]

Try adding a “delay reset” option on the changes operators of 2-3 seconds. That will dampen the response and should make it deaf to the interim changes. It will have the additional benefit of making those conditions’ state changes more visible in the status display.

[mbc2237]

After this many hours, I’m throwing things at the wall to see what sticks. this is what I have now:

Not sure if I need to set the expression with the getstate value or I can just use that in the activity function. I also am trying to avoid where I run into a waterfall with both trying to match the state of the other endlessly. I am hoping that the delay I put in there let’s the state settle before continuing.

[rigpapa]

I don’t see any “delay reset” options on your conditions, as I suggested. If your switches are reporting mid-ramp values, that’s going to retrigger the conditions (because they are pulses, really short pulses by default – milliseconds), and that will make the activities go nuts. The “delay reset” option on those conditions will make it react on the first change but ignore any additional changes in the delay/ramp period (2-3 seconds).

[mbc2237]

Thanks rigpapa. I do have them in there, just didn’t provide a screenshot of the conditions page. Right now I have a 3 second reset delay. All is working now unless a user change happens too quickly, like turning the lights off, but back on before the full routine is able to run, then things can get our of sync. I have also noticed that even though I do not have any throttling conditions, I believe reactor is causing Lua engine to reload fairly often.

I could very likely be something else, but I’m only noticing now that I am spending a lot of time in reactor. As long as the Lua engine doesn’t continue to restart, I can call this problem solved, even though the required delays are a little disappointing, but not a reactor issue. Now off to the next task. Thanks again!

[mbc2237]

New to the forum but seems rigpapa might be the only one that lurks it. Thanks @rigpapa. Still getting the constant please wait and Lua reloads. if I kill (disable) all my reactor sensors, the situation stops. Seems to reload immediately after a condition fires which then hijacks the activities from running. Happens often during even just my testing and use but not always though. Not sure the percentage of time. I’m not sure how to troubleshoot. Anyone else run into this? rigpapa, have you come across this in your own use/testing?

[rigpapa]

Try this:

1. Go into the Reactor master device, Advanced > New Service

2. Copy-paste (do not retype) the following into the New Service field:

    urn:toggledbits-com:serviceId:ReactorSensor
   

3. For New Variable, enter WatchResponseHoldOff

4. For New Value enter 0 (zero).

5. Press Add and pause a moment.

6. Press Reload Engine

7. Hard refresh your browser (link)

See if that helps. If not, the next step is to upgrade firmware to 7.32 beta 4 and install the latest Reactor update from Github (not in the App Marketplace). This may not be a bad idea anyway, but maybe not do too many things at once… wait and see…

[mbc2237]

Thanks again! I’ll keep you posted.

[mbc2237]

Sadly, that solution didn’t work. I’m on GitHub GitHub - toggledbits/Reactor: Reactor (for Vera and openLuup) is a Vera Home Automation plugin that provides advanced programmable logic. but I cannot find the 7.32 beta 4 mentioned anywhere. I was also on your site but didn’t find it. I can confirm that the engine is now only restarting when a condition (but not every time) is evaluated. Probably every other to every third time.

[rigpapa]

OK. Let’s take it half-way and have you install Reactor 3.9 from Github:

1. Go to the Reactor Github repository.
2. Click the green Code button and choose Download ZIP from the pop-up menu.
3. Save the ZIP file somewhere on your local hard drive. When it has downloaded, unzip it. This will create a folder with a number of files you will be uploading to your Vera.
4. Open the Vera UI file uploader at Apps > Develop Apps > Luup files
5. Open a file browser/explorer to the directory unzipped in step 3 (display the files/directory contents).
6. Select all of the files as a group in the file window, and drag them as a group to the Upload button in the Vera UI.
7. When the upload completes, your Vera will reload. At that point hard refresh your browser. This is very important!
8. Once the Vera is back up and your browser is refreshed, you should be able to confirm Reactor is running version 3.9 by going to the master device’s About tab.

At some point after, you should also completely reboot your Vera (reload only restart the Luup process, not the entire system). This will finalize the install of some background stuff (e.g. internet health check). You can do this by pasting and running this command in Apps > Develop apps > Test Luup code (Lua):

    os.execute( "/sbin/reboot" )

[mbc2237]

thank you for the help, yet again. If we can get this going, I will certainly make sure I find your donate area on your page. in the meantime, I verified that I am now onV. 3.9. followed the steps above. but first time testing, I got an engine reload. I can see that the condition is met in the status, but then the engine reloads. upon restart, the conditions now reevaluate, but immediately reload the engine. it is probably only conjecture, but it appears to reloads immediately after the first device state command is sent. I verified that I can run a test scene (outside of Reactor) for the same device and a restart does not occur.

[rigpapa]

Disable the dimmer follower ReactorSensor (only) and reload Luup. Let’s see if it calms down.

[mbc2237]

Confirmed, disabling the reactor sensor and manipulating any device or scene no longer restarts the engine. Once enabled again, the restarts start again.

[rigpapa]

If you go into that ReactorSensor, to Advanced > Variables, you will find a variable called cdata. Go as if you were going to edit it, but copy-paste it from the value editor into a reply here.

[mbc2237]

{“version”:20045,“timestamp”:1643394594,“variables”:{“targetlevel”:{“name”:“targetlevel”,“expression”:“”,“index”:0},“Getstate_undercab”:{“name”:“Getstate_undercab”,“expression”:“getstate( "Under cab light dimm", "urn:upnp-org:serviceId:Dimming1", "LoadLevelStatus" )”,“index”:1,“export”:0},“targetlevelminus”:{“name”:“targetlevelminus”,“expression”:“targetlevel * .75”,“index”:2}},“conditions”:{“root”:{“type”:“group”,“name”:“Reactor Sensor 2”,“id”:“root”,“conditions”:[{“id”:“grp1g9l11og”,“name”:“master_dimmer_change”,“operator”:“and”,“type”:“group”,“conditions”:[{“id”:“cond1g9l18ut”,“type”:“service”,“operator”:“change”,“device”:159,“service”:“urn:upnp-org:serviceId:Dimming1”,“variable”:“LoadLevelStatus”,“value”:“”,“devicename”:“Under cab light dimm”,“options”:{“holdtime”:2}}]},{“id”:“grp1g9l14rj”,“name”:“master_dimmer_off_on”,“operator”:“and”,“type”:“group”,“conditions”:[{“id”:“cond1g9l3adf”,“type”:“service”,“operator”:“change”,“device”:159,“service”:“urn:upnp-org:serviceId:Dimming1”,“variable”:“LoadLevelStatus”,“value”:“0”,“devicename”:“Under cab light dimm”}]},{“id”:“grp1gb1ei5g”,“name”:“any_under_20_percent”,“operator”:“or”,“type”:“group”,“conditions”:[{“id”:“cond1gb1rkqv”,“type”:“service”,“operator”:“<”,“device”:159,“service”:“urn:upnp-org:serviceId:Dimming1”,“variable”:“LoadLevelStatus”,“value”:“20”,“devicename”:“Under cab light dimm”},{“id”:“cond1gb1tpzv”,“type”:“service”,“operator”:“<”,“device”:162,“service”:“urn:upnp-org:serviceId:Dimming1”,“variable”:“LoadLevelStatus”,“value”:“20”,“devicename”:“Under cab dimmer fri”},{“id”:“cond1gb1u020”,“type”:“service”,“operator”:“<”,“device”:161,“service”:“urn:upnp-org:serviceId:Dimming1”,“variable”:“LoadLevelStatus”,“value”:“20”,“devicename”:“Under cab dimmer sto”}],“options”:{“duration”:5,“duration_op”:“ge”},“disabled”:true}],“operator”:“or”,“disabled”:true}},“serial”:36,“activities”:{“grp1g9l11og.true”:{“isReactorScene”:1,“id”:“grp1g9l11og.true”,“name”:“grp1g9l11og.true”,“groups”:[{“groupid”:“grp0”,“actions”:[{“type”:“setvar”,“index”:2,“variable”:“targetlevel”,“value”:“{Getstate_undercab}”},{“type”:“device”,“index”:3,“device”:162,“devicename”:“Under cab dimmer fri”,“service”:“urn:upnp-org:serviceId:Dimming1”,“action”:“SetLoadLevelTarget”,“parameters”:[{“name”:“newLoadlevelTarget”,“value”:“{Getstate_undercab}”}]},{“type”:“device”,“index”:4,“device”:161,“devicename”:“Under cab dimmer sto”,“service”:“urn:upnp-org:serviceId:Dimming1”,“action”:“SetLoadLevelTarget”,“parameters”:[{“name”:“newLoadlevelTarget”,“value”:“{Getstate_undercab}”}]}],“delay”:3,“delaytype”:“inline”}]},“grp1g9l14rj.true”:{“isReactorScene”:1,“id”:“grp1g9l14rj.true”,“name”:“grp1g9l14rj.true”,“groups”:[{“groupid”:“grp0”,“actions”:[{“type”:“setvar”,“index”:1,“variable”:“targetlevel”,“value”:“80”},{“type”:“device”,“index”:2,“device”:159,“devicename”:“Under cab light dimm”,“service”:“urn:upnp-org:serviceId:Dimming1”,“action”:“SetLoadLevelTarget”,“parameters”:[{“name”:“newLoadlevelTarget”,“value”:“80”}]},{“type”:“device”,“index”:3,“device”:162,“devicename”:“Under cab dimmer fri”,“service”:“urn:upnp-org:serviceId:Dimming1”,“action”:“SetLoadLevelTarget”,“parameters”:[{“name”:“newLoadlevelTarget”,“value”:“80”}]},{“type”:“device”,“index”:4,“device”:161,“devicename”:“Under cab dimmer sto”,“service”:“urn:upnp-org:serviceId:Dimming1”,“action”:“SetLoadLevelTarget”,“parameters”:[{“name”:“newLoadlevelTarget”,“value”:“80”}]}]}]},“grp1gb1ei5g.true”:{“isReactorScene”:1,“id”:“grp1gb1ei5g.true”,“name”:“grp1gb1ei5g.true”,“groups”:[{“groupid”:“grp0”,“actions”:[{“type”:“setvar”,“index”:1,“variable”:“targetlevel”,“value”:“27”,“reeval”:1},{“type”:“device”,“index”:2,“device”:159,“devicename”:“Under cab light dimm”,“service”:“urn:upnp-org:serviceId:Dimming1”,“action”:“SetLoadLevelTarget”,“parameters”:[{“name”:“newLoadlevelTarget”,“value”:“{targetlevel}”}]},{“type”:“device”,“index”:3,“device”:162,“devicename”:“Under cab dimmer fri”,“service”:“urn:upnp-org:serviceId:Dimming1”,“action”:“SetLoadLevelTarget”,“parameters”:[{“name”:“newLoadlevelTarget”,“value”:“{targetlevelminus}”}]},{“type”:“device”,“index”:4,“device”:161,“devicename”:“Under cab dimmer sto”,“service”:“urn:upnp-org:serviceId:Dimming1”,“action”:“SetLoadLevelTarget”,“parameters”:[{“name”:“newLoadlevelTarget”,“value”:“{targetlevelminus}”}]}]}]}},“device”:171}

[mbc2237]

There are some variables that I am not using at all since I was testing additional functionality of the scene, like what is seen in the additional expressions. but during the testing I disabled all but this condition

and still had the issue.