I changed out a Leviton plugin dimmer for an Enbrighten plugin dimmer, controlling a dimmable LED lamp. I don't really need continuous dimming levels -- low, medium, and high works fine. So I wrote an ON rule for accomplishing that, and a companion OFF rule for making sure that the next ON command (from a 4-button IHSENO TS0044 (Tuya) remote) set the initial lighting level to low. The rules both work fine, but some oddities with the dimmer became apparent.
First, the pre-staging function seems to only work when the dimmer is already ON. Second, the dimmer turns ON to the "minimum level" preference no matter what the ON rule commands (more explanation below).
My preference settings for the dimmer (in case they are critical, I didn't test all combinations) are: Transition time = ASAP; pre-staging ENABLED, start level change rate = Fast; level reporting interval = 1s; minimum level = 20% (which matches the ON rule value for "low").
The ON and OFF rules have no trigger, since I use the Button Controllers app to assign the Run Action of the ON rule to button 2 PUSHED of my remote, and the Run Action of the OFF rule to button 2 DoubleTapped.
The Delay and Speak lines were used for debugging, and should be disabled or deleted to use the rule.
So here's the evidence of the anomalies mentioned above.
Starting with the lamp (and thus dimmer) in the OFF state, pressing the assigned remote button enters Branch 2 -- which is correct, since the "minimum level" preference = 20% and the initial dimmer level is set in the OFF rule to 20%.
However, the last Speak command says that vDimLevelNew is 50%, which should set the dimmer to the medium level, BUT instead the lamp turns ON at the 20% low level.
Note that the "minimum level" preference is what actually controls the light level, so setting that preference to, for example, 30%, sets the light to 30% even though the initial dimmer level is set in the OFF rule to 20%.
However, setting the initial dimmer level to your low level in the OFF rule is required, otherwise the lamp starts at its last light level at the time the lamp was turned OFF (so, if the light was at 100% when you turn the lamp OFF, turning the lamp ON starts at 100% instead of the low level if you omit this OFF rule command).
The Dim command in the OFF rule must come before the Off command, or the light won't turn OFF -- instead, it will turn on the dimming level in the Dim command.
Pressing the remote button a 2nd time ALSO enters Branch 2, and the last Speak command says that vDimLevelNew is 50% -- and this time, the dimmer is set to the medium level.
Pressing the remote button a 3rd time cycles to the 100% high level, and subsequent presses correctly cycle through low-medium-high.
So, weird behavior for this plugin dimmer, but at least consistent and a workaround exists.
I have no idea whether these rules will work for an Enbrighten in-wall dimmer.
I mulled this complicated setup overnight and came up with two thoughts:
(a) Make sure the rule isn't running multiple times without your realizing it (i.e. "Check the Logs"), and if it is, consider introducing Set PB = false as 1st action, and PB = true as last action, with a R.E. of "PB == true";
and
(b) If you prefer a (much more compact) rule that sets the dimmer's Level to (A,B,C) brightness based on an input value (1-100), I can show you how to create a "lookup table" within RM.
The logs show, in order from an OFF state, for a sequence of 4 button pushes:
Dimmer was turned on [digital] {lamp is at 20%}
Dimmer was set to 50% [digital] {lamp is at 50%}
Dimmer was set to 100% [digital] {lamp is at 100%}
Dimmer was set to 20% [digital] {lamp is at 20%}
This is what I want (initial ON state is at 20%), and the Rule is not running multiple times. The weird part is that the ON logic for the first button press goes through Branch 2 of my Rule, which should set the dim level to 50% (which is not desired behavior). The dimmer just ignores the attempt in Branch 2 and turns the lamp ON to the "minimum level" preference (20%). So that's how I get the desired initial low light setting. However, as long as the dimmer behavior is consistent with the intent of the Rule, I'm fine.
I confess to not understanding your suggestion -- what is PB, just a variable to capture "Push Button" state? And what is "P.E."?
Lastly, I'd love to learn more about RM, so I'd appreciate your sharing how to create a "lookup table" within RM.
Sorry, was time-constrained last reply, so let me elaborate: "PB" is Rule Machine (RM) speak for "Private Boolean", a built-in local boolean variable possessed by every rule which does nothing by itself, but can be toggled using the Set Private Boolean action in RM. "P.E." means nothing because I mistyped, lol. I meant "R.E." as in "Required Expression" which you can define to act as a go/no-go conditional for your rule's evaluation and execution.
The two go together for preventing a rule from firing again while already in progress. But since your rule is not doing that, I won't elaborate further, as so much has already been posted about PB/RE usage.
Instead, let's focus on Branch 2 of your rule and why the dimmer isn't being set correctly to 50%, as I believe you've pinpointed this as the crux of the problem. Can you post a screenshot (use Windows Clip feature if on PC) of the hub Logs from the moment you press the button while the light was Off?
I'll have to read up on Private Booleans and Required Expressions! Do note that I have "Ignore Trigger Events While Running" activated for the ON and OFF rules -- I had thought that this setting would prevent each rule from firing again while already in progress (i.e., doing what you said PB's and RE's can do).
Here's a screen shot of 4 successive button presses starting from an OFF state:
There are no triggers, since I presume you are going to fire it from Button Controller or other means (nor a Required Expression, since "Ignore Triggers While Running" is enabled).
This rule continually increments a numeric index (called levelIndex) which cycles through 0, 1, 2 and 3. In turn, a corresponding value is pulled from the levelLookup list and assigned to levelNext. Finally, your lamp is dimmed to the given level (which includes Off when 0).
Thus, the rule mimics a 3-way dimmer with preset levels. It sidesteps the need for pre-staging and conditionals altogether.
The beauty of this approach, aside from being concise and easy-to-follow, is that you can edit the level values as well as expand the cycle – by raising the % 4 modulus to 5 or 6 while inserting additional comma-delimited stops in levelLookup – to permit more levels. You could also quite easily control additional devices here, or simply copy the rule as needed, as it is entirely context-agnostic.
Frigging brilliant! Fewer variables, shorter code, and easy to modify levels!
However, please note with respect to the GE plugin dimmer:
Level Pre-staging MUST be disabled or the dimmer will not turn ON at all unless an explicit ON command is sent at the end of the rule.
With Level Pre-staging disabled, the first button press from the OFF state generally takes 1 to 10 seconds to turn the lamp ON (counting from when the blue indicator light on the dimmer unit turns ON), with 6-7 seconds being the most frequent delay. Sometimes, the light never turns ON.
Sometimes, the lamp starts at 50%, so the lamp goes from medium to high. I believe that this is related to the light never going ON in a previous cycle, since the Local Vars table shows vLevelNext (my var name) incrementing through the lookup table values, so when the light does not go on at 20%, the next level is of course 50%.
So there seems to be something weird happening in (1) the timing of commands from RM, or (2) the driver, or (3) the dimmer firmware.
I'll post my rule version and a sample log later tonight.
There is still a delay for the first press after an OFF state where the lamp fails to light. I tried changing the fade in the Dim commend to "2" and "3", but that didn't help (in short testing, "3" got me up to 21 sec. delay). So it might be a timing thing in RM and/or the dimmer unit. However, the WAF would zero if the first level didn't come on within a second (preferably less).
Well, I really like your rule and how you've creatively introduced a local variable to represent the number of values it will cycle through.
I would be very hesitant about blaming RM for the weird timing issue, however, as it's surely just doing what it's told at the moment Actions transpire. (FYI, my choice to include "Fade: 1" in my example rule was completely arbitrary; just there for illustration.)
Instead, I get the sense that your Enbrighten dimmer is behaving a bit oddly in how it handles Level = 0 (which most devices tend to interpret as Off), and returning from Off to a commanded Level.
May I suggest turning off Pre-Staging in the driver (don't forget SAVE) just to see if that odd effect disappears? And maybe tinkering with the Transition timing there as well. Because no dimmer ought to have such a substantial delay going from Off to On.
Note: Whenever my plug-in dimmers would act up, I sometimes found that unplugging them briefly helped. However, one (Shlage) eventually burned out, and another (GE) got shady, so I ditched them both and opted for Zigbee LED bulbs in the (now) always-on lamps. Never been happier.
You ARE generous, liking "my" rule -- totally cloned from your rule and tweaked in a very minor way! And I learned a LOT about RM techniques that I didn't even know existed before your posting.
I strongly suspect that the driver or firmware in the GE dimmer is to blame, not RM. The dimmer does seem to correctly handle Level = 0 = OFF, but (as you suggest) it is returning from OFF to a commanded level that seems to be problematic.
Note that my testing with your rule has been with Pre-Staging disabled, since otherwise an explicit ON command must be added at the end of the rule (that is, with PS enabled, setting a DIM level does NOT turn the dimmer unit ON).
Note that my original rule (with lots of conditionals) doesn't have the delay, BUT that rule didn't cycle through to OFF -- it only went through a low-medium-high cycle. I used a double-click to invoke a separate OFF rule.
For now, I'm reverting to my original rule rather than your more elegant 4-level rule, but I'll keep playing with settings to see if I can make the delay disappear when using my variant of your rule.
Before you jump back to the old room, try inserting an if-then where the rule checks whether the dimmer is already turned on. If so, just set the level. If not, turn on and set the level in two actions.
Thanks for the info, but the Jasco updates are only for Z-wave, and the Lutron product is BlueTooth. I already have 9 of the GE/Jasco Enbrighten plugin dimmers and want to stay with Zigbee.
The less-elegant (compared to harmony7's lookup-table approach) rule in my initial post above works well enough. My primary reason for posting was to alert other users to the oddities that appear to exist in the GE dimmer: "First, the pre-staging function seems to only work when the dimmer is already ON. Second, the dimmer turns ON to the "minimum level" preference no matter what the ON rule commands ...)."
FYI - Lutron does not use Bluetooth. Lutron uses their own proprietary radio frequency protocol called Lutron Clear Connect RF. It operates at 434MHz, without much competition.
Bluetooth, Zigbee, Thread, and some WiFi all operate in the 2.4GHz frequency space.
