So I have some simple logic already to brighten or dim a light if it’s turned on in the morning or night. But I am trying to figure out how to use that same logic and expression/variables so that I don’t have to create these for ~10 different lights. For example, the logic would be something like:
If “Master Bathroom Vanity” is turned on, then the “Master Bathroom Vanity” is captured, and then only that light is pulled into the action for applying dim level = 100.
That is exactly what I’m trying to do, but I didn’t think you could set the loadlevellast successfully. I tried this back in the day with PLEG and even though I’d set it on Vera device variables, it wouldn’t translate locally to the switch when it was manually turned on.
Your solution would be perfect, as I could just blanket set those levels based on day and then not turn any on unless they were turned on locally.
Also, I almost always set the root sensor to nul lol. Most of my sensors are just sorta folders for different types of scenes.
I used to set up Reactor routines to sense “On” and immediately limit “Dim” levels, but that grew unnecessarily cumbersome, as I think you also discovered.
Setting the LoadLevelLast variable directly was a revelation, one that I’m happy to say changed my entire approach. For example, it allows me to preset the initial “On” level of any light, no matter the dim level someone last manually set.
I just create a routine that fires when Light X goes “Off”, which then resets its LoadLevelLast to N for next time. Really very straightforward! (It has the added benefit that grouped lights can have their levels better balanced, and also helps my bulbs last longer, by not always running at full brightness.)
NOTE: Contrary to my assertion, it was later shown that presetting levels with LoadLevelLast only affects Vera-controlled ON and OFF actions, but not manual control at the physical switch.
NOTE: I’ve asked @rigpapa, creator of Reactor, for a provision allowing us to [Set Luup Variable] directly, instead of using Lua script, but he is generally averse (rightly so!) to users poking around with Advanced Variables and – even more so – Device Parameters. After all, these are often calculated/derived values that get updated by Vera and/or overwritten as needed; thus setting them manually usually makes no sense (either has no effect or, worse, creates an error condition).
Fortunately for us, advanced variable LoadLevelLast is of the benign variety that users can alter without any consequence, and it gets used as expected. (CORRECTION: It was later shown that presetting levels with LoadLevelLast only affects Vera-controlled ON and OFF actions, but not manual control at the physical switch.)
Alright, so that works - but only when turning it on via Vera. If I set variable, then physically turn it on at the switch, the light returns to the setting it was last turned on at. For example, light at 75%, then turn off. Then run lua to set it to 25%. Turning on from the switch, it will turn on at 75%. If I had turned it on from Vera, it would turn to 25%.
This is sorta more what I was thinking originally. Basically have a condition with an “or” for say 10 different lights. If any of them are turned on, then the expression would capture WHICH device turned on, then set the LoadLevelTarget, which would would automatically dim or brighten that specific light. If you turned on another light later, it will adjust that one next time, and so on.
I can make a condition for morning and another condition for night, but I don’t know how to capture the device that triggers it true in the OR startement, and then subsequently target that device in the activity for setting the level.
Weird that my dimmer switch behaves differently than yours. Mine happily dims to whatever Vera/Reactor instructed via LoadLevelLast, regardless of how I last turned it off. (CORRECTION: It was later shown that presetting levels with LoadLevelLast only affects Vera-controlled ON and OFF actions, but not manual control at the physical switch.)
In your case, I have a feeling @rigpapa’s upcoming plug-in, SceneSlayer, might help you tackle this scenario most easily.
In the meantime, it may be necessary — even preferable — to utilize basic, independent subgroups – one for each light – rather than try to roll then into one big “OR” group (after all, with the latter arrangement, you’d run the risk of having two or more devices turning on at the same time, or having the Activities affect other lights that are already on, etc.).
I just swear that there’s a way to get the device id from the trigger and then insert it into the action. Something with the curly braces within an expression…
And @LibraSun the dimmers come on differently when using local vs vera control. I’m not sure that turning them off different has an effect. You should test your setup by having it at 85%, then turn off (doesn’t matter how), then send lua variable set to like 25%. Then go turn your switch on from the physical wall switch and see if it goes to 25 or 85.
In answer to your careful observation, YES – it turns out I was completely mistaken about LoadLevelLast acting as expected for local control of the dimmer(s)!
Sorry about that mistake (I’ll go back and edit my earlier replies). I thought I had tested each setup more thoroughly than I evidently did, but now realize that the preset levels have only been affecting Vera-controlled ON and OFF actions, not manual/local turning of the switch on or off.
haha no worries on the mistake! Thanks for helping try to isolate the best way to do this. I really like the idea of having preset ‘on’ levels based on time of day and I’m just continuing to dig into a way to systematically do it, with the least amount of work on vera. In one home, I just run a master house reset as part of the morning scene. Setting tons of lights to a specific level, then cutting them off after 30 seconds. Its just trashy method. Trying to do it a bit more elegantly haha
THanks again for help today in this one! The search continues!
I promise to keep my thinking cap on, because obviously, having an elegant, easy-to-maintain solution beats spot-treating the problem.
NOTE: Apparently, Lutron attempts to solve this by allowing the user to assign a “Preset Light Level” value to their dimmers. Perhaps other manufacturers have proprietary means of doing the same, so consult your dimmer’s manual.
But do keep an eye out for SceneSlayer, as I believe Patrick has anticipated your needs with that plug-in…
Yes, I think I remember seeing somewhere that the dimmer stores it differently, some are more flexible than others in how it can be edited. And yes - I always keep an eye out for anything Patrick is working on! Always the best stuff!
OK, this is leaning into OT for Reactor (it’s not specifically a Reactor issue, but rather a generic Vera ZWave device control issue), but I’ll go anyway…
I think this really demands a two-pronged approach, since Vera is going to have one idea about what to do when the light is controlled from its end (via LoadLevelLast), and the dimmer is going to have its own idea based on its configuration. Basically, anywhere you set LoadLevelLast, you also need to change the default preset level on the physical device.
That’s… more complicated… but not insurmountable, maybe. The configuration settings on ZWave devices that have them are usually presented (if they are known) in the “Device Configuration” area of the device’s control panel on Vera. Changing those doesn’t take effect until the next restart/reload when the device is then reconfigured. That’s not helpful. The only way around this is to send the specific ZWave command directly to the device to modify the parameter immediately, circumventing Vera’s handling of the configuration setting.
This requires that you know the following:
The ZWave node ID (not the Vera device number) of the dimmer — this can be found by going into Advanced > Params in the device control panel, and recording the value of the “altid” attribute;
The number of the configuration parameter containing the preset value (this is manufacturer-specific, and may even be model-specific, and may not exist at all — refer to the device documentation);
The size in bytes of the expected value (also in the device documentation).
Armed with all that, you can use the SendData action in service urn:micasaverde-com:serviceId:ZWaveNetwork1 to device 1, the ZWave network, with the following string 112 4 ppp sss vvv, where ppp is the parameter number, sss is the size in bytes (1, 2 or 4), and vvv is the first value byte (for 2 bytes, you need two value bytes in the string, for four bytes, you need four). The 112 is the ZWave command class (configuration, hex 70), and the 4 means “set”; don’t change these.
Example. We’ve discovered in our dimmer documentation that parameter 10 decimal is our preset dimming level, and it’s a one-byte value from 0 to 100 decimal. We find our node number for the dimmer is 115. We want to set its preset to 50%; here’s the action:
Some documentation will give values in hexadecimal (base 16). You can use hexadecimal in the Data parameter string, which would look like this (same data as above, converted): "x70 x4 xa x1 x32", or mixed (and more typical, I think) "x70 4 10 1 50".
One other detail. The ZWave network is “big endian,” meaning that if you need to send two bytes representing a value in the range 0-65535, the first byte is the high byte (math.floor(value / 256)) and the second byte is the low byte (value % 256).
So now, in your Run Lua action in Reactor that sets LoadLevelLast, you would want to add an action like the above, so that Vera and the device are in agreement.
And some cautions:
The device parameters on the dimmer are almost certainly stored in a non-volatile memory. That memory may have been spec’d for cost: to be just solid enough to be written a few times in the multi-year lifetime of the device, but not up to being written several times a day, day after day. So this method may bring about an early demise of the device via Flash dementia (excessive wear to failure).
Make very sure you are sending correct values to the correct device. Sending incorrect values, or sending correct values to the wrong device (particularly one of an entirely different type), could cause bizarre behaviors of that device or another, and be very hard to detect, trace, and fix. Check, double-check, triple-check your work.