Button controller, toggle options

[middlefraz]

I have a few simple automations in RM, but I am not a Hubitat guru by any stretch.

I recently picked up a couple Sengled Zigbee buttons, and installed the buttong controller app, and for the most part, I am completely happy.

The one thing I would like to add is the ability to have the 'toggle on' occur with zero delay, and the 'toggle off' give me a ten second delay to grab things and exit the room.

I only see one 'delay' box for toggle, is there a way to tie a delay to one direction but not the other?

As I said, I am overall happy, both with the buttons (I bought three) and the app.

Cheers.

[hydro311]

Why not use distinct On/Off commands instead of Toggle? That would be an easy way to add the delay to the Off action.

Toggle simply flips an A/B state from one to the other, so there's not really "toggle A" and "toggle B" per se - it's just "toggle".

[ogiewon]

Building on @hydro311’s suggestion, here is an example of a Button Controller that should work as desired.

[jeff.turner.reid]

Might want to make the delay cancellable and cancel delayed actions when the rule is activated. Otherwise, you may get the light turned off if you decide to turn it back on after turning it off. Please correct me if I’m wrong.

[middlefraz]

First, thank you for the response, I like the community here.

There are three actions available on that particular button, pushed, held, double tap. I already have actions dedicated to 'held' and 'double tap', So I guess I have to run a RM for pushed. I was just wondering if there were possible options in the 'toggle' action. I am using 'held' for a night light mode, 10% on, double tap is 100% on, then toggle would turn it off, or, normally I turn it on to just 40%.

So day to day toggling is just "on at 40%" or "off". That is the base use case. The dim mode is if I need to get up in the middle of the night, I just want 10%, and the other case is when I am cleaning or doing some other work in the room and I want it cranked to 100.

[middlefraz]

Thank you for the reply.

So I can just drop typical rule machine actions in there to run. I wasn't certain, as I said, this is my first encounter with the button app. It was easy to get the initial install and actions set up, but then once I used it a couple days, I started thinking that a delay on off would be nice.

Thanks again.

[middlefraz]

Thanks all, I may look at the cancellable as per Jeff, but this is working.

I always wondered if 'Dim 0' was off or not, but without the explicit 'Off' I was getting occasional 'on' failures. It is all working now.

[middlefraz]

Here is what I have, and it seemed to be working, but today, the logs are showing 'odd' behavior.

If I only single push, toggle on/off, it behaves, with delay, with cancelled delay.

But if I double-click to get it to 100%, a toggle off toggles it off, then when it is done, the logs show it as 'on' even though it is not on at the physical bulb. Then after that, it takes a couple single click toggles to bring it back in line.

Any thoughts?

Logs of toggle off after a single press toggle on.

Logs of toggle off after a double tap to 100%

As a reference, here is a toggle on followed by a double toggle off, to cancel the timer and turn it off immediately.

Not sure why the middle case is internally turning the state 'on' when the lamp is clearly off.

If there is something that catches your eye immediately, thanks, but don't spend to much time. I am going to dig around some more. I swear that two days ago it 'just worked' then yesterday it got weird.

[middlefraz]

Hmmmm. I think it has to do with 'fading' down instead of just turning off.

If I dim it down to 14, then the weird behavior does not happen, but fading down from 100% seems to ramp so slowly that the script actually exits before the dimming completes, and the status comes back as 'on' even though the bulb has dimmed to off.

So it is a sort of race condition between the script actually exiting, and the bulb completely dimming.

I need to think about that.

[middlefraz]

Jeff, thanks for your input, this is my final setup, which is doing what I want.

The recursion issue is such that I can 'slow double click' to avoid the six second timeout on the 'off'. If I accidentally 'triple' the third one is ignored.

I had to add sufficient fade delays to make it stable. I was hoping to use 'wait until dimmer_level <= value' tests to avoid having fixed delays, but wait for expression does not behave the way I expect it to, and I need to work on that a little.

Thanks again.

NOTE: The 'held' and 'double tap' just force the dimmer to a fixed value despite its current state.

[jeff.turner.reid]

I’ve tried to wait for a dimmer to reach a level and it just doesn’t work. Best to assume a thing. Use local variables and move on. I love how easy it is to iterate and test. We’re not testing bombs after all.

[middlefraz]

Enabling 'triggers and action' logging was a huge help figuring out what went wrong and how to fix it. Without those turned on, I was really stuck. Are those logs resource hogs? Now that I have my button behaving, should I turn those off?

[jeff.turner.reid]

Logs are local to the hub I’m pretty sure. The devices provide all the data but the drivers decide to log activity based on debug levels. i’m not of the understanding that the device changes anything based on debug levels. Someone might weigh in on this.