How fast can a trigger be triggered

Configuration
1

I have a zigbee wall switch with 2 buttons: one for dimming the light up and down, the other for changing the color. I’m doing it with an automation that changes the color of a lamp as long as a button is pressed. I’m triggering with a time_pattern of seconds: /1, but 1 second is to slowly. Is it possible to do faster triggering?

- id: colorloop
  alias: colorloop
  description: loop thru colors while button is pressed
  trigger:
    platform: time_pattern
    seconds: /1
  condition:
  - condition: template
    value_template: "{{ as_timestamp(states.automation.lightify_button_4_ol_long_start.attributes.last_triggered) > as_timestamp(states.automation.lightify_button_4_ol_long_stop.attributes.last_triggered)  }}" 
  action:
  - service: light.turn_on
    entity_id: light.osram_cla60_rgbw_osram_00ae2d01_3
    data_template:
      hs_color:
      - '{{(now().timestamp()*10)%360}}'
      - '100.0'
2

sounds like your automation logic is flawed. Post the automation please.

3

I inserted it into original post.

4

post those other 2 automations

5

Why not trigger off the button being pushed?

6

Because the button is only triggered once, no matter how long it is pressed.
I want that the color begins changing as soon as the button is pressed, and when the desired color comes, the button is released and color changing stops. So I want all colors to appear within maybe 4 seconds.

I tried to start an effect:colorloop when the button is pressed and this work. But there is no way to stop the colorloop at the desired color.

7

How many states do you have to go through.?
In 4 secs no way
If you have in internal event say a time being met that will happen with a delay equal to the propagation within the action being carried through to the device say z wave transmission.
From here on we’ll ignore those propagation delays as you know typically what they will be for your devices
So you press a button, it arrives at HA it now depends where HA is it its processing as it only reads and writes on a 1 second scan rate, so assuming it arrived 1ms ago it will start processing 1ms later but if it was 999ms ago …
Now if everything gets processed and outputs are ready then you may get lucky and it’s output straight away… Or it may have to wait a second…
This will not meet your requirements and by the time you see the colour you want, give the signal, ha sees it and responds you ‘may’ catch that exact colour and the second cycle, not likely though

8

Does it have a button released event?

9

Yes, I get the release event.

10

Have you considered using nodered? You can loop within nodered and in the flow every X ms call the change color action in HA.
I guess when you combine human reaction time + non real time function of both HA and NR, it is unlikely that you can do less the half a sec. This is just a guess though!

GV

11

Home assistant has a 1 second resolution for the event loop.

1 Like
12

Ok thank you

13

OK. But, in this option, there is one event to trigger the flow and then, within the flow call to HA services. So, the 1s event loop doesn’t apply, if I am not wrong.
There is one last event when the button is released. So, two events in total, instead of one event per color.
GV

14

He wants to cycle colors while holding the button. There’s no way to escape the event loop in these circumstances.

15

Think about what you are suggesting, nodered runs on the machine that HA also runs on.
Nodered interfaces with HA
HA controls reads and writes, nodered does not as it has to interface through HA
How do you expect nodered to exceed the speed of the underlying state machine ?

You could maybe get round the 1 second scan loop by using arduino based devices (or similar) with there own intelligence and programming and communicating direct (just updating HA with the result) but it’s gonna be a lot of work and imagine having to do it 20 times whilst getting the bugs out and the rewriting the programS (cos we’re talking multiple devices here) and the lights would have to talk to ‘the counterpart’ not HA. So maybe you’d have to throw out the hue lights.

16

Maybe I am missing something or I explained myself badly…
The OP asked for trigger at a sub second interval. Some experts (that I am not) explained that with the event it is not possible.
What I am saying is the following:
In Nodered

  1. Receive button pressed
  2. Turn_on light color 1 (API call to HA)
  3. Wait 1/2 s
  4. Turn_on light color 2 (API call to HA)

If button is released stop the loop.

In this simple example between 2, 3, 4 I wait less than a second between two calls to HA API. Isn’t it possible?
I have just tried with on/off and within 5 seconds I can do 5 On and 5 Off (so 10 calls to HA API). Maybe, I am not getting your point either…

GV

17

@jms3000 still hasn’t revealed his ‘pressed’ vs ‘not pressed’ automation, which has been asked for a bunch of times now. So it’s really hard to say that this will work in NR.

18

GV, that’s quite a compelling argument and I know that for example @tom_l claims to have (well succeeded actually given his post on the matter) to have gotten ‘bips’ from a siren using queued input boolean turn off/on’s to micro manage delays
@123 is (I believe) no stranger to nodered and I believe that @anon43302295 has dabbled (ie knows a ton more than me).
Perhaps nodered has its own interface to i/o bypassing HA’s state machine.

Hopefully the lumenaries above can advise how this is possible because at the moment I don’t see how (but am willing to have an explanation put forth for me to accept)

Phil has definitively stated that HA updates 1/second (and as a great contributor with many essential integrations under his belt, I have no reason to doubt him)
Sorry for tagging you guys but if you can throw any light here, I for one would greatly appreciate it AND you may be able to help the OP with a solution.
Tink is coming so we may get a quick answer

19

You can loop very quickly if you can get a “held” message - that’s how this abomination works (I feel safe to call it that, since I wrote it).

Trying to do it in an automation loop though, that’s going to be painful.

1 Like
20

Nah I had to give up on that. 99 times out of 100 it worked fine. But that one time it does a spazmo and sounds the siren for seconds, confusing me into thinking i’ve set the alarm off and I try to disable the siren with the RFID key making another “bip” that lasts for more seconds confusing me even more while ruining my already bad hearing… yeah it had to go.

1 Like