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