16 Unique input_number

[anderbak]

Hello all

I have 16 input_numbers and I want to ensure they stay unique. They will set the order for relays to execute.

input_number:
  number_1:
    name: Sequence
    icon: mdi:reorder-horizontal
    min: 1
    max: 16
    step: 1
    mode: box
  number_2:
    name: Sequence
    icon: mdi:reorder-horizontal
    min: 1
    max: 16
    step: 1
    mode: box
  number_3:
    name: Sequence
    icon: mdi:reorder-horizontal
    min: 1
    max: 16
    step: 1
    mode: box
  etc...

When I change any of those numbers, I need the value for the matching input_number to change to the previous value. i.e.

      {% if 'input_number.number_1' == 'input_number.number_2' %}
          'input_number.number_2' = "the old value from input_number.number_1"
      {% elif 'input_number.number1' == 'input_number.number_3' %}
          'input_number.number_3' = "the old value from input_number.number_1"
      etc...

Not sure where or how this is done - I’d searched for some other examples, but came up empty. If there’s a better way to do this aside from input_number, I’m open to suggestions.

Thanks!

[123 (Taras)]

@anderbak

When I change any of those numbers, I need the value for the matching input_number to change to the previous value.

There’s a potential for this system to perform an endless loop.

If you create a system where it detects a change to the value of any input_number, here’s what can happen:

It detects a change in the value of number_1.
It determines that the value of number_4 matches number_1.
It sets the value of number_4 to the previous value of number_1.

By changing the value of number_4, it immediately causes the process to repeat:

It detects a change in the value of number_4.
It determines that the value of number_13 matches number_4.
It sets the value of number_13 to the previous value of number_4.

By changing the value of number_13, it immediately causes the process to repeat:

It detects a change in the value of number_13.
It determines that the value of number_8 matches number_13.
It sets the value of number_8 to the previous value of number_13.

It will keep repeating until it cannot find a matching value in any of the 16 input_numbers.

Is that how you actually want it to work? (because that’s how it will work if you trigger on a change to any input_number)

[anderbak]

@123 Great point, and you’re absolutely correct. Are you aware of an alternate construct that would allow for such a scenario?

[123 (Taras)]

You will have to explain what you are attempting to accomplish.

You created 16 input_numbers where each one is configured to support a number from 1 to 16. That’s 16 x 16 = 256 possible combinations. EDIT far more than 256

How is all of that supposed to be used to “set the order for relays to execute”?
How many relays are there?
What is the desired pattern of enabling/disabling the relays?

[anderbak]

@123

If you create a system where it detects a change to the value of any input_number, here’s what can happen

I imagine a clumsy way to prevent chaining would be to use a boolean helper that would conditionally prevent a second change.

Detect a change in number_1 and set boolean to true
Determine number_2 matches
Change number_2 to previous number_1 and set boolean to false

This doesn’t seem like a reasonable solution, at least without considering alternates first.

@123

You will have to explain what you are attempting to accomplish.

I’ve got a 16 channel multiplexed relay designed for irrigation. I’ve configured 4 different potential daily schedules for each of the 16 zones along with the ability to disable/enable any of those zones for any particular schedule.

The basic logic for enabling days, zones, determining run times, and triggering the relays is nearly all complete, but I discovered a circular reference in determining the on/off times when the sequence is the same on two or more zones (obvious when looking at it after the fact). Aside from the circular reference, two relays at once wouldn’t work on the multiplexer nor would there be enough water pressure even if it did.
Front end is a work in progress, but getting there.

edit:
I should also mention, that I’v seen Irrigation Unlimited in the HACS apps, but didn’t get the wife approval based on the lack of flexibility to make changes to the schedules etc from the front end.

[123 (Taras)]

@anderbak

16 channel multiplexed relay designed for irrigation. I’ve configured 4 different potential daily schedules for each of the 16 zones along with the ability to disable/enable any of those zones for any particular schedule.

How does that correlate with 16 input_numbers having one of 16 potential values each?

BTW, I was wrong about 16 x 16 = 256 combinations. It’s 16¹⁶ combinations. What is the need for this wealth of combinations?

---

EDIT

It dawned on me that it will be easy to suppress a ‘repeating effect’ without employing the input_boolean you suggested. The automation simply needs to use the default mode: single and that will ignore attempts to execute it again while it’s already executing.

[anderbak]

@123

How does that correlate with 16 input_numbers having one of 16 potential values each?

Fairly basic:
16 irrigation zones - each with it’s own valve controlled by a relay.
The order in which each valve is opened during the schedule and the flexibility to change that order based on desire/need/whatever else.

[123 (Taras)]

@anderbak

16 irrigation zones - each with it’s own valve controlled by a relay

A relay has 2 states so why is it being modeled by a input_number with 16 possible states instead of an input_boolean?

[anderbak]

@123

A relay has 2 states so why is it being modeled by a input_number with 16 possible states instead of an input_boolean?

The input_number only determines the sequence (order) that the particular zone is run during the schedule. The input_boolean is what is being turned on/off at a particular time (determined by the schedule/sequence).

[tom_l]

Do you really need, and would you use, 16¹⁶ ways to run your irrigation?

How about defining a few set programmed sequences?

Would that suit your needs?

[anderbak]

@123

It dawned on me that it will be easy to suppress a ‘repeating effect’ without employing the input_boolean you suggested. The automation simply needs to use the default mode: single and that will ignore attempts to execute it again while it’s already executing.

This is fantastic - I still don’t know how to implement this functionality

[anderbak]

@tom_l

How about defining a few set programmed sequences?

Defined sequences are what I currently have. Just looking for the flexibility to change those sequences. I wasn’t sure if someone would have been able to suggest something other than the 16¹⁶ if statements that I’m aware that would have to be created. It’s unfortunately worse than that anyhow, since there are four different schedules.

[123 (Taras)]

@anderbak

The input_number only determines the sequence (order) that the particular zone is run during the schedule

I don’t see why you need a data structure capable of representing 16¹⁶ combinations to achieve that. It seems all the more needlessly complicated when you take in the fact you only intend to turn on one relay at a time.

@anderbak

two relays at once wouldn’t work on the multiplexer nor would there be enough water pressure even if it did.

Maybe I am failing to appreciate some aspect of your plan that makes 16¹⁶ combinations mandatory. Rather than waste your time trying to convince me of its necessity, I’ll step aside and allow someone else to help you (who needs no convincing). Good luck!

[anderbak]

@123 Regardless, I appreciate you taking the time to consider a potential solution. Much thanks.