Template for changing min-max of input_number from binary sensors or other input number

Configuration
1

I need to change the min and max of the slider for an input_number.XXX When a binary sensor is switched on, then again when a 2nd binary is switched on, 3rd,4th,5th and then back down turning them back off.
I have a slider input_number that turns binarys on and off to change the number of times I water in a day. The binarys use a value template. The vertical stack card adds or removes the card “watering” associated with the binary sensor from the value template based on the condition of on or off.

2

You can’t set minimums and maximums of input numbers dynamically

3

I found someone who added it as a custom component. I still don’t know how to template this.

https://github.com/TonyApuzzo/home-assistant-config/tree/master/custom_components/input_number

4

This custom cinponent hasn’t been maintained for over a year, I doubt that this will still work with all the changes that have been made to the input_number integration in this time.

5

Looks like a deadend for now. Thanks

6

Can I ask why you want to do this ?

There is a work around on limits but the min and max will always be hardcoded requiring a reload on the input_number.

Say your input_number.ranged is created ‘0’ to ‘100’
Automations can always be run that if below input_number.dynamic1 then set input_number.ranged = input_number.dynamic1 and the same for the top end

Your only issue here would be that the slider would still ‘look’ like it was ranged ‘0’ to ‘100’

7

Sorry for resurrecting another zombie thread, but I think I need this functionality too (unless someone can explain a better way for what I am trying to do). Here’s my scenario:
I have several automations that change the ceiling fan speed based on the user defined set points that are set in lovelace via input_numbers. All of the automations rely on the next higher or lower input_number for the above and below triggers. However, everything gets screwed up if somebody sets a temperature lower than the input_number.turtle for input_number.low or a number higher than input_number.high for input_number.medium, etc.

One obvious approach is to use the input_number.set_value service call to just increment the other set points up or down by a fixed step like 1 degree, etc., but this “user error” fix will probably not be obvious to the user, so I am worried about unnecessary complaints when the min and max functionality could provide more obvious feedback about the issue to the user in real time.

My idea if input_number.set_min and input_number.set_max methods/dynamic functionality were implemented would be to use the adjacent inputs to set each other’s minimum and maximum values (i.e. changing input_number.medium would dynamically set the maximum value for input_number.low and minimum value for input_number.maximum. Is that a good enough reason for that functionality to exist, or does anyone know of a better/existing way to inform the user they need to change the neighboring set points?

8

I’m sorry but you stated a requirement (than is easy to accomplish) and then went on to state that you use above/below (even its most vigorous proponents admit weaknesses if used in some situations (like this)).
You should either use templated triggers or binary sensors (from similar templates) to achieve that functionality.
There are lots of examples around the forum and I can’t be bothered to do the search for you as I’d have to use the same tools you seem unwilling to.

9

I don’t understand what you’re doing. Can you explain the whole situation? There might be a way to do this without all the extra complication.

10

Here’s my scenario:

  • I have a ceiling fan with the Treatlife DS03 switch I’ve flashed with Tasmota.
  • I have a Broadlink RM4 Mini w/ Temperature + Humidity sensor in the room.
  • I would like to automate the fan to turn on the lowest speed when the temperature exceeds the user specified temperature A, and turn back off below this temperature.
  • I would like to increase the fan speed to medium-low when user-specified temperature B is exceeded, then return to low below this temperature.
    – Repeat the above for medium-high and high speeds for user-specified temperatures C and D.
  • NOTE: I have an automation that works for the above required functionality, so long as the user inputs valid set points that meet this rule A < B < C < D.

My question in this thread is in regards to constraining the user’s inputs for the input_numbers A, B, C, and D according to the rule above (hopefully with feedback so the user knows what is going on rather than some automation magically changing their set points behind the scenes when they don’t know its because of user error). The issue is that these are dynamic limits according to the set point above and below, so I was hoping that I could use an automation to dynamically set the max and min constraints for each input_number.

11

Rude much? I don’t see why you need to be so vitriolic to a newcomer to Home Assistant. If I knew I needed to defend myself, I could have prefaced my question with the fact that I’ve spent over 4 hours searching for this solution and trying different approaches including numerous Home Assistant community threads, Reddit, and another forum somewhere. Don’t accuse people of being lazy when you’re waging war from a keyboard.

EDIT: FYI @Mutt, I will add to this list as I review my search history so that you can be sure that I did in fact research this question before asking my own:

  1. Template for changing min-max of input_number from binary sensors or other input number - #2 by Mutt
    a. This is thread is the closest to an answer that I’ve gotten. @Warmachine mentioned someone used this as a custom component but I have no knowledge how to use that and was hoping there might be a more viable built-in way to do this. I was hoping the people in this thread might be more accepting to to people that have a genuine question about a mildly complex requirement.
  2. Input Number Slider
  3. Service to change min/max for input_number?
  4. Changing input_number value as a result of other input_number change
  5. How can I use an Automation to increment an input_number?
  6. [SOLVED] Increment Input Number by value of another Input Number

I’ll admit that I was reading these late at night, so I accept the possibility that I may have missed something, but at the time I didn’t find anything applicable to this use case I am describing above.

1 Like
12

Why don’t you ignore the dynamic limits and just sort the input numbers based on value.

{% set t1, t2, t3, t4= expand('input_number.a', 'input_number.b', 'input_number.c', 'input_number.d') | map(attribute='state') | map (float) | sort %}
{% if t1 %}
  …
13

EDIT, now that i’m not on mobile… You can make a template sensor, and then have a simple automation trigger off that sensor to call the correct fan level.

template:
- sensor:
  - unique_id: fan_leveler
    name: Fan Leveler
    state: >
      {% set t = states('sensor.broadlink_rm4_temp') | float %}
      {% set inputs =  expand('input_number.a', 'input_number.b', 'input_number.c', 'input_number.d') %}
      {% set t1, t2, t3, t4 = inputs | map(attribute='state') | map(float) | sort %}
      {% if t < t1 %}off
      {% elif t1 <= t < t2 %}low
      {% elif t2 <= t < t3 %}medium
      {% elif t3 <= t < t4 %}high
      {% else %}super high
      {% endif %}

Then just make an automation that runs the correct service when the fan leveler changes.

It’ll sort your temperature values, and you won’t have to worry about them screwing it up because the order will not matter.

14

Your other option is to have an automation that reacts to user moving the slider, if the slider is outside the other 2 slider positions, reset the slider to the center of the range.

15

Your other solutions look very promising, so many thanks in advance. However, I don’t think any of them will explicitly tell the user that their input is problematic, right?

Upon first glance, your last suggestion appears to be the closest to what I am trying to do:

However, the upper and lower bounds of the slider would still be statically specified (i.e. min = 60, max = 80), right? If I’m following along correctly, that means if they set an incorrect value, the slider will just reset to a valid value in between the other set points (as specified in a background automation) without any notification to the user. I’m just worried about my users annoying me with “it’s broken” comments when the system is in fact fixing their “broken” inputs. If I misunderstood, then I definitely think this is worth a try.

Alternatively, if the above is correct, then your second solution appears to be the most elegant given our current capabilities with the input_number helper:

I think there’s a way to make this work if I abstract the input_numbers on the card in the UI to read something like “Set Point Speed 1”, “…Speed 2”, etc. However, I would want to dynamically rename the card title and sort them in the UI, which I’m not sure if that’s possible? Hopefully I’ll be back shortly with some concrete info about whether or not this is possible in Lovelace or custom cards, etc.

Many thanks for your suggestions @petro !!!

16

My custom component is a derivative of the core input_number that exposes services to set the min and max dynamically. I use it for allowing an Electric Car Charger to be have its charge rate changed depending on whether it is in L1 or L2 mode since there is a 6-15 amp range for L1 and a 10-40 amp range for L2.

I intended to clean up and submit my change to the core HASS but I haven’t had time to do it.

I have a couple of mechanisms to deal with out-of-range values:

  1. Service to update min or max. When changing min or max, disallow min > max or vice-versa and log a warning to HASS server log
  2. Service to update both min and max simultaneously. When updating the range, automatically swap min/max if min exceeds max or vice-versa
  3. When changing the min or max, if the existing value is out-of-range, then update the value to be the min or max as appropriate
  4. If user attempts to set value outside the range, then the value is unchanged and a warning is logged to HASS server (same as core component.)
1 Like
17

@a3a That sounds like great progress, and I’m sure there are others like me that will benefit from your work, especially if you have the time to get it on HACS. I think I fall close to the “late adopters” category, so I’m not sure how to get custom integrations working without HACS (I guess I will be learning shortly :hugs:).

Off the top of your head, do you remember if any of those services you made can support dynamically setting the min or max of another input_number relative to the currently manipulated input?

For example, let’s say I have my set points for low fan speed set at 72 F and medium fan speed set at 74 F. Can I use the input_number for medium to set the max for low to 74 F? Most importantly would be if I lower medium to 73 F (or raise low to 73 F), would it update the max for low to 73 F (or lower the min for medium to 73 F)?

Or would this require a substantial redesign to your existing custom component’s code? Many thanks in advance!

18

I am not sure I understand your request – but if I do understand it, then yes, my component would work to do what you ask.

This setup will adjust the minimum temperature set-point based on the fan speed. If the new minimum is higher than the current setting, then the temperature is adjusted to match the new low value.

I kinda think that in practice you’d actually want the logic reversed since a higher-speed fan could support a lower temperature but that’s not what you asked (and it would be easy to do that too).

Note that label “Temperature Range” in the video clip probably should just be “Temperature” since that value is the requested set-point.

Here it is in action:

Configuration:

/config/packages/smizlesdemo.yaml

---
input_number:
  fan_speed:
    name: "Fan Speed"
    unit_of_measurement: "RPM"
    min: 1
    max: 3
    initial: 2
    step: 1

  temperature_range:
    name: "Temperature"
    unit_of_measurement: "°F"
    min: 68
    max: 80

automation smizlesdemo:
  - id: fan
    alias: Adjust Temperature Range based on fan
    trigger:
      platform: state
      entity_id: input_number.fan_speed
    action:
      service: input_number.set_range
      data_template:
        entity_id: input_number.temperature_range
        min: >-
          {%- if states('input_number.fan_speed')|int <= 1 -%}
            72
          {%- elif states('input_number.fan_speed')|int == 2 -%}
            74
          {%- else -%}
            76
          {%- endif -%}
        max: 80
19

Interesting :thinking:, so your configuration directly links the expected temperature to the user specified fan speed? I don’t think this is what I’m trying to do, but I’m very curious in your thinking and impressed with your effort to help me @a3a!!!

My bad for miscommunication in my stated goal, for I was just looking for a way (that is obvious to the user instead of hiding it in an automation) to prevent a user from misusing one of the set points by specifying a value lower than its lower neighbor and/or higher than its higher neighbor (i.e. in the picture below, Turtle > Low, Low < Turtle / Low > Medium, Medium < Low / Medium > High, or High < Medium).

The automation breaks when the following logic does not hold true: Turtle < Low < Medium < High

I know this can be accomplished in an automation, but I’m not sure how to notify the user in the UI of their misuse (I am forseeing a tired traveler staying with us and waking me up because they’re hot and the fan automation isn’t working because they either set invalid values or the ‘fixer’ automation keeps resetting their values without any notification why).

Also, another complication that arises even with a moderately sophisticated user is how would you bump the set points higher or lower if they’re set 1 value away? (i.e. If you wanted “Turtle” to turn on at or above 72, you would have to start with the “High” set point, then bump up the “medium”, then the “Low” before you could adjust the “Turtle”. The reverse is also true if you wanted “High” to be set to 73 or lower.) I know the actual value for the input_number can be set, but the logical limits for min/max wouldn’t reflect the dynamics of the situation, especially if I switch back to using a slider (which I would like to do but thought it unnecessarily hid the obviousness of the logic set points IMO).

With this latest revelation, I guess I am asking for some sort of “more info” pop-up to ask them if they want to raise/lower all of the affected set points, or if they want to restore the previous setting and try again? I’m open to suggestions if anyone has any idea how to accomplish this or a similar functionality to handle the logic conflict!

20210720-HA_Automation-Fan_Setpoint_UI
20210720-HA_Automation-Fan_Setpoint_UI528×801 35.4 KB

20

So all I can say is that the custom-component service to support changing min/max limits of a slider could perhaps be a piece of the overall puzzle of what you’re trying to achieve but I don’t really have any advice for how you should proceed. It seems that you need something more complex that what the input_number component can do.

1 Like