Auto Dimmer smartApp (Sept 2015 V2 update)

As to changing the available options, this is something that you can do for your self.
The code that generates these settings starts on line 303 (dimmersPage())
The options section for the inputs define the available choices. Adding other values in the same form as those present will allow selecting them from the mobile app once you save and publish the changes.

As to a description of how auto dimmer works, if you can elaborate on what specifically you would like clarification on, I can add/modify the information that I’ve written in the first post here.

Thanks so much Mike. The code tweaks worked perfectly as instructed.

Let’s say I access “Specific Dimmer Settings” for one of my dimming bulbs and toggle “Auto Adjust Levels during LUX Changes” to ON. and set Percentage Change to 5%. Let’s assume the LUX levels outside go from 1000 to 3000. How does the light bulb dimming behaviour differ from just setting the global LUX/dim levels as I’ve done now?

I’m pulling LUX from the weather app, so these lux values won’t change a whole lot during the day.

Ah, got it.
The auto adjust functions as a built in ramp function while the dimmer is on.
When this option is selected, auto dimmer listens for lux events, then adjusts the current dimmer level by the selected percentage until it meets the dimmer level that you have configured for that specific lux range.
It adjusts the dimmer level by the percentage selected every minute, until the new level is met.
I use 1%, since this level change is almost imperceptible.
These events can be seen in the ide live logging.

Basically if you were to leave a light on all day, the level would automatically adjust to follow the settings that you have configured.
If this option is not selected, then the only way to reset a dimmers level (reevaluate the current dimmer level against lux) is by turning it off, then on again.

In my case I have an Fibaro mounted outside, it reports current lux values as they change, so the auto dim feature works well in this case.

That’s a very well thought out option Mike…makes sense now. The weather station LUX is not very precise, so tracking it will likely see little benefit. That said, I’m going to look at the Fibaro device.

I’ve noticed that the zigbee bulbs run a lot cooler when dimmed, so this app is about perfect to manage this. I haven’t done power measurements at all on zigbee dimmed bulbs, but I’m guessing your app has the potential to save a fair bit of power. Thanks again.

Probably less power draw, no idea really, I created this as I got tired very quickly of being blinded in the morning by my LED can fixtures and wanted something to take care of the dim levels that didn’t require constant dinking with or required static settings that had no relation to how much lighting was required at any given point in the day.

While there’s not a lot of commentary about this app, it does have over 200 downloads…

Some information for those looking to pull LUX from the free Smart Weather Tile for this app:

A. Install the Smart Weather Tile from the web IDE as a device for yourself. There is a template provided. You just need to define a zip code in the device settings

I’m not in the US, so a zip code does not work for me. Fortunately you can leave it blank and your hub location will be used. Alternately you can enter in a weather underground station ID (pws:STATIONID). If you look on the weather underground web site for your area, you can find stations near you. Look in the web URL for the pws:STATIONID and enter that into the device settings for the Smart Weather Tile (instead of a zip code) on your smartphone. I tried a few until I found one with more accurate LUX updates.

B. The weather tile doesn’t update itself, and the programs I tried to fix it don’t work as they seem to have timer issues. This one, using events to trigger updates, worked perfectly: “Manual Weather Refresh” written by Daniel Vorster: Smart Weather station tile app
I copied the code and published the app to myself using the web ide. This app updates the weather tile perfectly driven off events, rather than timers. Being that I have lights activated by motion sensors, I used one of those sensor events to trigger a Weather Tile update.

Loving the auto dimmer :slight_smile:

1 Like

How much power does a dimmed Zigbee LED bulb use? I could find nothing using Google with respect to that question, so here you go :slight_smile: Mike, it turns out using the Auto Dimmer app can save a lot of power. In our Kitchen for example we use 7 Ecosmart LED downlights in Halo track and at full brightness, it’s simply too bright, even at night. I have these dimmed down to 20% during the day. I found that the Philips Hue and GE-link bulbs run a LOT cooler when dimmed, which I’m guessing will only increase their life, and save power doing it.

Because the SmartThings Zigbee controlled wall plug reports power use in the iOS app “Notifications”, I just used that to read power as I set the bulbs at various brightness levels. The bulbs were removed and installed in my shop trouble light, plugged into the SmartThings outlet, for testing.

GE-link at full bright:

GE-Link at 50% brightness:

GE-Link at 25% brightness:

Philps Hue White at full brightness:

Philps Hue White at 75% brightness:

Philps Hue White at 50% brightness:

Philps Hue White at 25% brightness:


Thank you @Mike_Maxwell !!! :astonished::joy:

I needed a way for all the lights in my house to constantly self-adjust to have rooms evenly lit:

  • minimize perceived visual contrast such that interior lights coordinate to seamlessly “match” one another
  • and also “match” the exterior daylight level, appreciating how bright\dark the room’s exterior window happens to be at any moment. :sunrise: :white_sun_small_cloud: :sunny: :white_sun_cloud: :thunder_cloud_rain: :crescent_moon: :milky_way:

Your AutoDimmer app is the reason I bought a SmartThings hub, and am now in process of buying a ton of new dimmer switches\outlets, as well as learning how to properly code on this platform.

I’ve got a few wishes\ideas to help add AutoDimmer functionality. Before I get too far along down that road, may I ask, are you still interested in enhancing this app :slight_smile:?.. …or has this app since been deprecated :sweat:?

YIKES, I have noticed a marked degree of developer unhappiness over the SmartThings platform as of late :skull_crossbones: ; maybe I should have pinged you on a better day

I’m still here, and the app is still in use and supported my me.
Glad you like it!
What did you have in mind?


Was hoping to save you time by making all the code changes myself (and then um, pull request?) but oh no! I’m finding ST is terribly lacking in the VisualStudio\IntelliSense\Step-Thru-Debugger\ObjectOriented type functionality that I usually depend on to sling out rapid dev work that works as needed. Therefore am afraid it is going to be a long while before I get through enough ST learning curve to make meaningful progress. Gotta keep my day job.

Currently the dimmer level % preference values are restricted to increments of 10%. Turns out I need 1% increment granularity otherwise several of my light fixtures are slightly too bright\dim. Yeah, call me Goldilocks. I see there’s a ST option to code as a numeric range (type:“number”, range:“0…100”) but then I loose the nifty displayed “%” unit identifier you provided via enum. I can manually edit the existing enum’s to add in all 101 individual % values [0,1,2,99,100] easy enough, but then I feel a lil contrived, like it should be a GUI slider or something.
—Btw on a separate but slightly relate note, I tried my hand doing a similar thing with the LUX pref values, but using a dynamic range ("${luxDark}…*") and submitOnChange to allow for arbitrary integer values while still preventing user from accidentally overlapping their LUX threshold settings (luxDark < luxDusk < luxBright). Didn’t quite work tho, might be too advanced\messy for now; k nevermind that on the LUX values.

Currently the AutoAdjust ramp rate % values are restricted to [1,2,5]. Wish it had larger rate values for a number of reasons. I manually edited the enum to add “[…,10,100]”. The ‘100’ basically acting as an “instant\rampless” AutoAdjust speed.

If I’m understanding the AutoAdjust logic correctly, then the above 2 Wish’s might cause out-of-range and endless-dimmer-teetering problems when the dimmer%\LUX integer preference values aren’t evenly divisible. So to safeguard, think I just have to add in a Math.MIN\MAX to these 2 lines (right?) like:

if (crntDimmerLevel < newDimmerLevel){
	rampLevel = Math.min( crntDimmerLevel + rampInt, newDimmerLevel )
} else {
	rampLevel = Math.max( crntDimmerLevel - rampInt, newDimmerLevel )

Currently the AutoAdjust bool and ramp rate % preference is provided separately on each individual dimmer switch device’s dynamic pref page. Love this feature but I have sooo many individual dimmers to keep tweaking and re-configuring (first world problems). Wish these 2 AutoAdjust settings were also available at an app instance ‘default’ level. Kinda like the dimDark\dimDusk\dimDay\dimBright preferences, where I could set it once and then optionally still proceed to visit the per-dimmer dynamic page to explicitly opt in\out (bool?) and\or tweak ramp rate % of a specific dimmer switch. I do get how to code part of this, but not yet comfortable enough to implement without breaking too much of something else; looks like this impacts several lines throughout the app.

Currently the app doesn’t accept a name (aka ‘label’?). Won’t this be awkward when I install multiple instances of this app (maybe one for each side of the house), but have no way to label which is which? I did start trying to add in the “label” preference per documentation, however so far I’m just ending up with several orphaned installed app instances that do NOT appear in the ST Android app but DO appear in the ST IDE’s list of installed SmartApps. Starting to suspect either outdated ST documentation or a ST bug, but hopefully it’s just [me] user error cause that’s way easier\faster to correct.

Wish-E <— Whoa, I need to contemplate this one after I’ve had more time with ST.
Currently the app allows for only 1 illuminance sensor (per installed app instance). What about my rooms that span either side of the house, with a wall of exterior windows facing the sunrise and another wall of windows facing the sunset. Can I handle this “bipolar gradient” room as-is using multiple app instances? Maybe. But the first knee-jerk thought that came to mind was a desire for 1 app instance to accept multiple illuminance sensors. In which case would probably also need to accept a predefined “multi-LUX” aggregation option {MIN\MAX\AVERAGE} (‘WeightedAverage’? hmm I donno) on the default pref page as well as the per-dimmer dynamic pref pages. Or I guess same could be achieved via a separate virtual multi-LUX aggregator illuminance sensor; has someone already developed such a virtual sensor?

Wish-F <— Whoa, I need to contemplate this one after I’ve had more time with ST.
Currently the app allows for 3 static LUX thresholds, resulting in the brightness detection being constrained to a resolution of 4 possible brightness levels. Maybe that’s good enough (I hope so). But if turns out to need a more fine-grained resolution, then may be nice to upgrade logic into a more dynamic function curve type of interpolation. The “Lux Auto Brightness” Android App [in Google Play Store] comes to mind as a working example of this functionality: user supplies an array of {Lux->DimmerLevel%} key\value pairs [ {0lux->5%} , {100lux->20%} , {1000lux->100%} ] with as many (or few) pairs as desired, and then the app effectively smooths out the gap between each supplied pair at runtime.

Short initial reply, will take more time than I have right now to sort through all these.
The case for Enums are two fold, a, I don’t like unconstrained ad hoc user inputs, and b, until very recently submitOnChange did not work for numeric values on android. If range limits on inputs work now, I may consider changing To numeric. In any event changing the enum list isn’t that big of a deal.
Have considered the need to support additional lux sensors, this could be done on a per dimmer override, like the levels, however this seems clumsy to me, better approach I feel would be to create a zone configuration where by the zone options can dictate the overrides for the selected dimmers if desired.
Adding an app label is easy enough, however this could be solved by the zone parent child implementation, thus keeping app sprawl to a minimum.
Regarding the gradient vs static range interpolation, while it makes sense, from a practical perspective in two years of use 4 ranges have proven to be more than enough to achieve the desired effect.
Also keep in mind the desire to keep the ui simple enough for the average user to configure and use.
I’m not getting the auto ramp value range expansion, personally I do not like abrupt changes for this mode…, if all dimmers supported decimal values I would have implemented that, anything over 1% incremental changes per cycle is distracting imho.

I’m liking the options a zone implementation provides, optional lux sensor, optional zone overrides.
Lux averaging for multiple lux sensors at the global level also makes sense.

I’ve also been looking for an excuse to refactor/re write this app as the core functionality hasn’t changed much in two years.


Hurray, I ended up able to add in this parameter and make the corresponding code changes after all. Lets me easily enable AutoAdjust on all my lights with 1 tap.

Yes, I do rather like the self-guidance (dummy-proofing) benefit the Enum’s add to the user experience.

Turns out I WAS supplying the correct label code all along, but just wasn’t visible in the mobile app due to a SmartThings bug (child app discovery checkbox); bug which has since been fixed.

:grinning: That does sound nice! I’m thrilled to hear this has already crossed your mind.

After several more weeks using this in the main room, I’m starting to suspect the 4 ranges are going to suffice for me too (thank goodness).

I too am finding anything over a couple % to be distracting.
The value I get from having a “100%” ramp rate option is to help me in the initial lux\dimmerLevel preference tweaking phase throughout the day. I may be in this phase for a while, till I figure out exactly which lux thresholds and dimmer levels work out best for each room. The resultant instant (abrupt) autodimming behavior allows me to more easily notice when (and if) the auto-dimming is kicking in, and also saves me time that I’d otherwise have to wait for the more gradual 1% [per minute] rate.
Eventually once I narrow down luxThreshold\dimmerLevel pref settings for each room, then I expect to revert back to the more gradual 2% or 1% rate.

I don’t want to pack in so many features as to render the code too monstrous to support or too susceptible to platform bugs. :sweat: I see what happens.

When lights are first turned on after a lux change the lights come on at the previous dim setting then 1-2 seconds later switch to the new setting. Is this something you guys see?

Example. lights were last on at 60% (not from physical switch, but from this app) and then later in the day the light turns on at 10% from this app. The light comes on at 60% (previous setting) then switches to 10% 1-2 seconds later? I’m not sure if I’m doing something wrong in how I’m using this app.

I have apps turning the dimmer on, but with no level instruction. auto Dimmer sets the level. It’s just very disruptive to have the change in level especially when it’s dark and you want a low light, but it comes on bright first before dimming to the correct level.

Happens to me. Not sure it can be fixed unless dim level could be set without the light being turned on.

yup, that’s the way the app works, nothing can be done about this on the code end of things, these dimmers just don’t have a way of presetting a dimmer level.
I wrote the app this way so that the dim level would be modified the same way when turned on via ST or the physical switch.

Perhaps in the device type? I remember someone had written a DTH for the GE link that gave it the option to dim to on and dim to off. It also added an option for the speed at which the dim happened.

that would fix it, wouldn’t to be too hard to implement with any dimmer actually…
find the off command then change it to this delayBetween( “zwaveSetLevel, 0 or 1”, “zwaveOff”)
just replace the command text with the actual commands.

Which dimmer do you have? Most (all?) can turn on at a specific level. Try having whichever smartapp you’re using set the dimmer level to 1 instead of having it turn lights on.

For example, in Rule Machine have it
"Set these dimmers"
"To this level"

In SmartRules

Do not turn ON the lights first, just set the level.

(The DH will typically send a basicSet or switchMultilevelset to the device with the new level, which will turn on the device at the new level.)

Well that doesn’t work if you are using motion events to turn the light on.

Motion - app sets level 1 - Auto Dimmer raises to preferred level. motion goes inactive, but not long enough to turn the light off. Then a new motion event will cause the app to change the level to 1 - then auto dimmer will raise.

Sorry, could you clarify the steps and the smartapp you’re using (smart lighting?)