Hello everyone,
I have been using Home Assistant for a couple of years now and i’m very happy with its flexibility and endeless possibilites. However one thing i have been struggling to make work or even find some code examples for is a way of dimming my lights the way i want (i’m not a very proficent code writer in any language).
Say i have a binary sensor as my button, using esphomeyaml nowdays for all my nodes. How do i make an automation that will cycle the dim level of a light entity?
Preferably it would not do like 10% increments or anything like that, just dim the lights slowly to towards 100% and when it hits 100; slowly down to 0. When you let go of the button the light stops moving (Slowly is relative i guess) Is this even possible?
Theres some complexity added with making the automation remember if the light was increasing or decreasing the last time it was dimmed (i’ve been told KNX dimming behaves this way) or possibly double clicking to set directions. Not entirely sure on what is possible.
I guess i’m not totally locked into it being a HA native automation, i’ve just started learning a little node red, but i cant do much useful with it yet. So i guess a HA automation would be the best, but i’m looking for all and any input on this problem.
Obviously my solution wasn’t for Home Assistant because it didn’t exist a decade ago. Nevertheless, the goal was the same:
Specify a target brightness (0-100).
Specify the duration for achieving the target brightness (minutes).
Specify the ramping mode (adaptive or fixed).
The required ramp rate would be calculated in order to drive a timer that would transmit incremental dimming commands (smallest increment is 1/100 in the other system whereas in Home Assistant it’s 1/255).
If you read the posted link, you’ll see there are several ‘gotcha’ situations that must be handled. For example, while the brightness-level is being ramped, what if someone changes the brightness-level manually, like to full brightness? The ramping effect ought to be cancelled by any manual intervention. Otherwise your manual setting is undone by the next command from the ramping system. There are other scenarios that also require mitigation.
Yes, that link is definitely touching on the subject i’m researching.
I guess it could either initiative the dim cycle when the binary sensor is held at “1” for a number of seconds ( guessing this is the hardest to code and has the most pitfalls when it comes to network/wifi issues)
The other way is if the binary sensor is triggered it starts a dim cycle x=>100%=>0% etc until the binary sensor is triggered again; and the light stops at that % (or value between 0-255).
I have yet to come across any automation that does anything like this so i dont have much to work with (not being a coding genius, i usually adapt other peoples code to my needs)
Is there a particular reason the trigger must be a binary_sensor (activated for umpteen seconds)?
If you make a script, it appears in the UI with an ACTIVATE button. Effectively, it behaves like a momentary binary_sensor (momentary pushbutton). Its native state is off and touching it makes it go on but just momentarily … which triggers the associated script.
Alternately, use an input_button. Turn it on to activate the ramping effect. When the ramping is completed, it toggles the input_button to off. If you want to abort ramping, just turn off the input_button.
No reason other than i recently started using esphomelib for my lightswitches, and i have never seen anything as precise and reactive as the binary sensor integration with the native api. But the triggering method is somewhat secondary i guess. It would be very precise and snappy with these is all
You’d have to have an input_boolean that sets the direction of dimming (up or down).
On detection of a button press the direction would change. On reaching 255 or 0 brightness the direction would change. Other than that there’s the problem of incrementing the brightness every second while the button is pressed. Do you want an automation triggering every second with a condition checking for a button press? This seems like the sort of thing that ends up using more resources than it needs to.
I’m no expert but this would seem to be a situation where a python script with a while loop would do a better job.
I’ve been thinking it would be somewhat complex, its just something that has a huge WAF and is how the dimming systems you buy usually work. I can’t be the only one that has been wanting functionality like this in HA in some way?
This gives big freedom when selecting what to use as lightswitches and the price of a diy lightswitch is fractions of what they cost. Esphomelib has been making goliath steps and is now integral in my system. I guess a rotary encoder setup could be an acceptable compromise.
FWIW, one of the problems of having a ‘press-and-hold-to-dim/brighten’ UI button is that it triggers a continuous stream of dim/brighten commands. Depending on the lighting technology, this stream has the potential to overwhelm the communications channel. It’s a YMMV situation.
FWIW, I chose to equip my home with UPB-based lighting because it’s reliable, easy to manage, and feature-rich. Naturally you must initially program each switch to behave the way you want but later you can optionally send a custom command to have the light behave differently. For example, I can send a command to instruct the light to ramp to X brightness over a period of Y seconds or minutes. That’s one transmitted command and not a sequence of commands to ramp the brightness; the light itself takes care of ramping its brightness. Or instruct it to turn on then automatically turn itself off after Y time. They also support scenes so, again, just one command to instruct multiple lights to set themselves to a desired scene. It’s very flexible and very efficient. There’s no ‘master controller’ needed, no pairing in the zwave/ZigBee sense, etc. Downside is it is (I believe) limited to North American lighting standards … and there’s no comprehensive component for it in Home Assistant.
That sounds like something i could also embrace. I have some zigbee on trial. Its all well and good but its not perfect. I prefer to make everything i can from scratch if possible, the apeal of HA is of course its very very flexible. You can have your coffemaker talk to your car if you want.
I’m guessing a rotary encoder or a “press once to start a dim cycle” is more realistic and robust. Or even giving up and having two buttons, even though its a defeat
I have scenes, but they cant always be 100% what you want, unless you have a light sensor outside to compensate for light levels om any given day.
