Button app retired? Did I miss something?

My point is simply that the "overhead" is not material in the vast number of cases. Now, I suppose someone could go and measure two exact same button automations in the two apps (once BC is back) and possibly discover some number of milliseconds of difference (I don't know if they would or not, wouldn't waste my time on this), and from that conclude that "overhead" is a motivator to do something one way or another. I suppose it depends on one's motivations and expectations for a given automations, and how concerned one is about some number of milliseconds.

I'm not dismissing this completely. I have a particular button automation using a Pico that the use context is such that I am very aware of milliseconds in the response. It dawned on me a few days ago that the automation was "slow" because I was using the regular Pico driver, so it was waiting for button release to process button pushed -- and I could see this. So I changed the driver to Fast Pico. This one is in RM with a Z-Wave dimmer. It's virtually instantaneous. Gosh, maybe I should move it to Simple Lighting to make it even more instantaneous. :sunglasses:

3 Likes

Ooohhh....or Button Machine....that's even better.

:clown_face:

You probably don't remember but I finally got rid of all those terribly long RM rules that I had for my motion lighting that were causing a ton of POP errors and whatnot. I wrote very specific custom apps. They're written for my exact situation. In the logs I can see from the app "launching" to lights on to the last line of code before app closure I get response times down around 280ms. I think the only way I could get them faster now is if I had Psychic Sensors to tell where I was going before I went there. :wink:

1 Like

I need my lights running at the speed of light!