How to detect slider last and new state and compare it in action template?
for example: if I move slider called input_number_dimmer from 0 to 5 and then from 5 - 2 automation must first run script.dimm_up five times and then script.dimm_down three times?
I see. You cannot issue a command to set the lightâs brightness and can only increase/decrease it.
I suspect you also have no way of knowing if the light is on or off or itâs current brightness.
What happens if the light is off and you send a command to increase brightness? Does it turn on to full brightness?
What happens if the light is off and you send a command to decrease brightness? Does it turn on then dim itself?
The reason I ask these questions is because I know how to create the solution you want but I also know it will be fragile. Without the ability to receive information from the light, or to set itâs brightness to a specific value, any solution will have a very weak grasp of the lightâs actual state.
EDIT
The situation you described is like the original X10 lighting protocol. You could only turn the light on/off and increase/decrease its brightness in steps. However, you had no way of knowing the lightâs current state. Whatever solution devised to control it is easily derailed by someone manually turning the light on or off or changing its brightness.
I suspect you also have no way of knowing if the light is on or off or itâs current brightness.
No there is no way to know.
What happens if the light is off and you send a command to increase brightness? Does it turn on to full brightness?
If I do that light stays off. I must first press on and then set brightness. Light also memorise last brightness level when I turn light off.
What happens if the light is off and you send a command to decrease brightness? Does it turn on then dim itself?
Same as previous.
Without the ability to receive information from the light
I only know if light is on and I press moon button light goes to brightness 10% and if I press sun light goes to 100%. I also have script for moon and sun button. from 10% to 100% I must press button on remote nine times.
I think you understand that, given the way the light works, any attempt to have Home Assistant keep track of the lightâs current state or brightness can be easily derailed. All it takes is someone using the remote-control to change the lightâs state and brightness and now itâs out of sync with Home Assistant.
Like I said, this works like the original X10 protocol. Actually, itâs worse because if an X10 light is off and I increase its brightness, it will turn on (this wonât).
The success of whatever solution you devise will be increased if you put the remote-control in a drawer to prevent anyone from manually controlling the light. This will help, but not guarantee, your solution can maintain synchronization with the lightâs state and brightness. However, just to underline how fragile this is, it only takes one command failure (for example, you signal the light to turn on but it fails to receive the command) and now Home Assistant and the light are out of sync.
Iâll only provide a high-level view of whatâs required because, and no offense but, I donât want to invest time in what I feel is ultimately an unstable solution.
Start by creating an automation that is triggered by changes to the state of the input_number. In the action section, youâll want to create a template that calculates the numerical difference between trigger.from_state.state and trigger.to_state.state. This tells you the number of increments between its previous level and the new desired one. The sign of this value (positive or negative) tells you the desired direction (increase/decrease).
Youâll may need a separate automation to keep track of the number of times the script is called (perhaps using a counter to track the iterations).
I overlooked to mention that the behavior you described (above) really complicates this project (as if it wasnât complicated enough already).
Hereâs why:
Assume the light is on at 60% and you turn it off by moving the input_number slider to 0%.
The light remembers it was at 60%.
Now you move the slider from 0% to 40%.
We perform a simple calculation to determine how many times we need to run the âincrease brightnessâ script. We subtract the sliderâs previous brightness from the sliderâs current brightness then divide by twenty. (40-0)/20 = 2 times.
HOWEVER, we are obliged to first send a command to turn on the light!
When we do that, the light remembers its previous brightness and automatically turns on to 60%.
Unfortunately, we donât have a record of that anywhere so when the âincrease brightnessâ script runs 2 times, the light will change not from 0% to 40% but from 60% to 100%. Thatâs not the result we wanted.
To handle this properly we have to store the lightâs previous brightness level (60%). We create another input_number, called âprevious_brightnessâ and store it there.
Now the calculation changes slightly. We must subtract the lightâs previous brightness (stored in the input_number we created) from the sliderâs current brightness then divide by twenty. (40-60)/20 = -1 time. That means the âdecrease brightnessâ script must run 1 time.
We send the command to turn the light on and it automatically changes to its previous value, 60%.
The âdecrease_brightnessâ script runs once, and the light is now set to 40%. Perfect, exactly what we wanted.
The problem is how can we know the lightâs previous brightness level? The light doesnât report anything about itself.
One workaround is to take note of the lightâs previous brightness then manually set the âprevious_brightnessâ slider to this value. Consider this to be a âcalibrationâ step that needs to be done just once before we start using the automation.
Are we done? Is it all solved? No!
If the light is currently at 80% and you move the slider to 0%, we do not want to run the âdecrease_brightnessâ script 4 times. No, we want to simply run the âlight_offâ script. That means the automation needs additional logic. If the target brightness is 0% it chooses to run the âlight_offâ script (instead of performing a calculation).
Done yet? Nope. Thereâs still the matter of running the scripts X number of times âŚ
I donât know if youâre familiar with the expression âThe juice is not worth the squeeze.â but this is one of those situations. Worst of all, despite all heroic efforts to devise a workable solution, all it takes is just one glitch, like someone using the remote-control to manually change the lightâs state or brightness, or one of the transmitted commands fails to be received, and everything goes out of sync. Just one sneeze collapses this elaborate house of cards.
What I suggest you do is use a Template Switch. Itâs easy to create and provides the ability to turn the light on/off (no brightness control).
I know there is a lot of problem If you wanna know light status. But I thinking for more simple solution.
I wanna use light like this:
1.Always When I turn light on light alway start on dimm 10% to do that I must run first: script.kitchen_light_on and then script.kitchen_light_moon. And to prevent user on HA to change dimm until light is off I must have automation to disable dimmer when light is off and when light is on to put dimmer to 10%.
2. Then when light is on user can increse/decrese light form 10% to 100% if user decrise light to 0% light must go off and disable dimmer.
And for a start I try to make script to decrese/increse light when I move slider 0-10 or 10-0 and I have problem in template is_state('trigger.from_state.state - trigger.to_state.state','10.0'):
trigger:
platform: state
entity_id: input_number.kitchen_light_dimm
action:
- service: script.toggle
entity_id: >-
{% if is_state('input_number.kitchen_light_dimm','10.0') and is_state('trigger.from_state.state - trigger.to_state.state','-10.0') %}
script.kitchen_light_dimm_up
{% elif is_state('input_number.kitchen_light_dimm','0.0') and is_state('trigger.from_state.state - trigger.to_state.state','10.0') %}
scipt.kitchen_light_dimm_down
{% endif -%}
The following automation should work. I tested a slightly modified version of it on my system.
- alias: 'Slider Test'
trigger:
platform: state
entity_id: input_number.kitchen_light_dimm
action:
service_template: >-
{% set to = trigger.to_state.state | int %}
{% set from = trigger.from_state.state | int %}
{% set diff = (from - to) | round(0) %}
{% if to == 10 and diff == -10 %}
script.kitchen_light_dimm_up
{% elif to == 0 and diff == 10 %}
script.kitchen_light_dimm_down
{% else %}
script.do_nothing
{% endif -%}
Create another script called script.do_nothing. It doesnât have to do anything, it only has to be available. If you read the template youâll understand why itâs needed.
EDIT
Simplified the template. The variable called slider was not needed.
You canât with the approach youâve chosen where the template tests for every possible change in brightness. Thatâs impractical.
The approach I suggested (in my overly-long post) calculates the number of levels the brightness must change. So if the brightness must change by +4 levels, it would call script.kitchen_light_dimm_up four times. If the change is -2 levels then it would call script.kitchen_light_dimm_down two times.
I also provided a solution to handle the other complication, namely the lightâs âmemoryâ effect where, when turned on, it automatically resumes its previous brightness level.
Sorry, but I canât be of more help because, as Iâve stated several times already, this project requires a fair amount of effort and, despite best efforts, the end-result can be easily derailed. I wonât be dedicating any more time to this project. This community has over 38000 members so hopefully someone else, with more free time and interest, is willing to take up the challenge.