How fast can a trigger be triggered

Yes, I get the release event.

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

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

1 Like

Ok thank you

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

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

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.

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

@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.

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

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

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

I forgive you but I steer clear of strategies that rely on sub-second looping (which is why I haven’t posted in this thread). Over and out.


EDIT
If I was interested in achieving the desired action of making the bulb cycle though its colors, I’d investigate if the bulb supports that behavior using a built-in effect.

For example, Hue bulbs support a ‘colorloop’ effect so I wouldn’t bother with sub-second looping techniques and simply activate/deactivate the bulb’s ‘colorloop’ effect (button-press = activate, button-release = deactivate).

2 Likes

Tinkerer, I never, ever got a delay this short:

    light_bright_pause:
      sequence:
        - delay:
            milliseconds: 1

Calling the delay function takes way longer than 1ms.

Yup, under one second HA operates on a eh whatever basis. You’ll get a delay of at least that long, up to one second.

When I wrote that it worked fairly well, but I haven’t tried it since.

1 Like

This is a pretty interesting discussion. For the record with Node RED, it may be possible to write this but @Mutt’s points are totally valid, I don’t really know whether you’d actually get the desired response time. I personally avoid any kind of event loops at this speed as well.

To give this a shot I think you’d want to find out exactly what event is fired on the event bus when the button is pressed and released. You’ll want to listen for those events directly rather then listening for any kind of changes in state otherwise it sounds like you’ll definitely be limited to 1/s. I don’t know what those events are but the easiest way to find out is drop to drop in an Events: All node with the event type blank that links to a Debug node set to log out the the complete message object. Deploy this, press the buttons quickly, then immediately disable it. Listening to all events unrestricted for long can create problems (as the node tells you), you just need to capture the event.

Once you have it you can do a setup like this:

Code to import
[{"id":"2ad21885.a7bea","type":"server-events","z":"a74fee2d.ac9068","name":"START_EVENT_TYPE here","server":"cc03735a.94933","event_type":"start_event","exposeToHomeAssistant":false,"haConfig":[{"property":"name","value":""},{"property":"icon","value":""}],"x":170,"y":1740,"wires":[["c73c61db.eb751"]]},{"id":"b81f7547.8fed7","type":"traffic","z":"a74fee2d.ac9068","name":"Start/Stop messages","property_allow":"start","filter_allow":"^s$","ignore_case_allow":false,"negate_allow":false,"send_allow":true,"property_stop":"stop","filter_stop":"^e$","ignore_case_stop":false,"negate_stop":false,"send_stop":false,"default_start":false,"differ":false,"x":580,"y":1800,"wires":[["6426c326.c7fcec","a2c4fa54.3197b"]]},{"id":"c73c61db.eb751","type":"change","z":"a74fee2d.ac9068","name":"Set start","rules":[{"t":"set","p":"start","pt":"msg","to":"s","tot":"str"},{"t":"delete","p":"payload","pt":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":380,"y":1740,"wires":[["b81f7547.8fed7"]]},{"id":"ecc71b4b.f0bef","type":"api-call-service","z":"a74fee2d.ac9068","name":"Change light color","server":"cc03735a.94933","version":1,"debugenabled":false,"service_domain":"light","service":"turn_on","entityId":"light.osram_cla60_rgbw_osram_00ae2d01_3","data":"{\"hs_color\":[\"{{ color }}\",\"100.0\"]}","dataType":"json","mergecontext":"","output_location":"","output_location_type":"none","mustacheAltTags":false,"x":950,"y":1740,"wires":[[]]},{"id":"6426c326.c7fcec","type":"change","z":"a74fee2d.ac9068","name":"Set color","rules":[{"t":"set","p":"color","pt":"msg","to":"$millis()*10%360","tot":"jsonata"}],"action":"","property":"","from":"","to":"","reg":false,"x":780,"y":1740,"wires":[["ecc71b4b.f0bef"]]},{"id":"28212b4e.69a13c","type":"link out","z":"a74fee2d.ac9068","name":"Loop","links":["eb12fb1c.846ae8","5c4a84de.82dee4"],"x":910,"y":1800,"wires":[],"l":true},{"id":"5c4a84de.82dee4","type":"link in","z":"a74fee2d.ac9068","name":"Loop","links":["28212b4e.69a13c"],"x":190,"y":1800,"wires":[["804f901d.799b08"]],"l":true},{"id":"a2c4fa54.3197b","type":"delay","z":"a74fee2d.ac9068","name":"500ms","pauseType":"delay","timeout":"500","timeoutUnits":"milliseconds","rate":"1","nbRateUnits":"1","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":false,"x":770,"y":1800,"wires":[["28212b4e.69a13c"]]},{"id":"f3ecc5df.7e05","type":"server-events","z":"a74fee2d.ac9068","name":"STOP_EVENT_TYPE here","server":"cc03735a.94933","event_type":"stop_event","exposeToHomeAssistant":false,"haConfig":[{"property":"name","value":""},{"property":"icon","value":""}],"x":170,"y":1860,"wires":[["93daffdd.a3128"]]},{"id":"93daffdd.a3128","type":"change","z":"a74fee2d.ac9068","name":"Set stop","rules":[{"t":"set","p":"stop","pt":"msg","to":"e","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":380,"y":1860,"wires":[["b81f7547.8fed7"]]},{"id":"804f901d.799b08","type":"change","z":"a74fee2d.ac9068","name":"Remove start","rules":[{"t":"delete","p":"start","pt":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":360,"y":1800,"wires":[["b81f7547.8fed7"]]},{"id":"cc03735a.94933","type":"server","z":"","name":"Home Assistant","legacy":false,"addon":true,"rejectUnauthorizedCerts":true,"ha_boolean":"y|yes|true|on|home|open","connectionDelay":true,"cacheJson":true}]

What this should do is the start message will come in and enable and pass through the traffic node, allowing the loop to proceed. It’ll then change the light color and wait 500ms (configurable) before looping again. When the stop event comes in then the traffc node is disabled thus ending the loop until the button is pressed again. Also by forking the path we don’t have to wait for the light to actually change in addition to 500ms, they happen in parallel.

By listening on the HA event bus and forking the service call I think this might be closer to what you want but there’s still a lot of X factors here, I don’t know how close it will actually be to the desired loop time and behavior

Also I feel obliged to ask, is this really easier then just opening your phone and using a color wheel to pick the color? I know, that’s completely counter to the core HA message (using your phone to change the lights is only useful for showing off) but I feel like this is one of the few cases where its actually easier. Picking a color from a normal color wheel sounds a lot easier and faster here.

Or alternatively, if you just have like a set of 5-10 colors you want to use in practice, maybe just make it so clicking the button repeatedly scrolls through the wheel? I just feel like this kind of loop maybe isn’t the most practical way to change the color of your lights. Just my two cents.

[EDIT] Whoops, forgot to remove the start field haha, now its good

1 Like

@Burningstone I know you don’t use nodered but you do use appdaemon.
You also have hue bulbs.
Do you have a view on this ?
Any way you can see to achieve the OP’s aim ?

I would have thought python (appdaemon) should be able to do anything nodered can

Dunno, I find it interesting that this subject has not been covered in depth previously (maybe it has, I’ll go do a proper search)

I have the same view as @123 on this.
I have an AppDaemon app that smoothly increases brightness. This could probably be done with some kind of loop or some async code, but it’s not really a “clean” solution in my opinion. In addition if you want a smooth transition, there will be lots of commands sent to the device, which can lead to delays or missed commands depending on the device, network etc…
Fortunately, deconz (the software I use to integrate ZigBee devices like the Hue bulbs into Home Assistant) provides a method to smoothly increase/decrease brightness and to stop the dimming.

@jms3000 you may take a look at this app, I think it provides the colorloop you want.

2 Likes

Hi @jms3000,

As @Burningstone said ControllerX (an AppDaemon app available in HACS) allows you to do that out of the box with less than 10 lines of YAML code. You can see an example in here. However, this solution uses a loop and sleep to do this. The sleep is done to not overload HA with requests, however, you can change the delay with a single parameter configuration. Although a loop might not be a good option for most of the people, it is the most versatile option to all controllers and lights since the loop is the responsible to call HA calls to change the brightness or color for every loop. You must also know that ControllerX uses async code, so the sleep does not block the main thread of AppDaemon.

If you have any questions, just let me know :slight_smile:

1 Like

my lights support colorloop, but as soon as you stop the loop, the original color is restored.
from the zigbee specs:
If the value of the Action field is set to 0x00 and the color loop is active,i.e. the ColorLoopActive attribute is set to 0x01, the device SHALL de-active the color loop, set the ColorLoopActiveattribute to 0x00 and set the EnhancedCurrentHueattribute to the value of the ColorLoopStoredEnhancedHueattribute.