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.
Wish-A
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.
Wish-B
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 )
}
Wish-C
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.
Wish-D
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.
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.
?
; maybe I should have pinged you on a better day
That does sound nice! Iām thrilled to hear this has already crossed your mind.
I see what happens.