[Feature] Keep awoken for x seconds after key press

[hilsonp]

I fully understand why the device needs to stay asleep as much as possible to reach this awesome 18 months battery life.

Nevertheless, I would like to benefit from the screen and not have it just like a nice clean label.

Most of the interaction happen just after the user presses a button. I would therefore suggest to have the device stay awoken for a configurable account on seconds after a button press.

Here is my usecase:

I use the Home Buttons to control 3 windows and 3 covers.

• Btn1 displays "Cover 1 closed"
• User press Btn1
• HA starts opening Cover1 and changes the label to "Cover 1 opening" (I know the text it too long - this is just to explain, while awaiting the midi icons 😉)
• Btn1 gets the label over mqtt and update the screen.
• HA sees the cover is opened and updated the label to "Cover 1 opened"
• Btn1 gets the label over mqtt and update the screen.
• x seconds (configurable as I know how long each action takes at max - you could even make it configurable for each button as one may be a slow garage door and the other one, a light) after the button press, the device goes to sleep as usual and restart the long sleep cycle pattern to save battery.

This way, we get the best of both worlds. Long battery life and updates following user interactions (when they are obviously in front of the screen).

I would be ok if that decreases battery life by 3. This behaviour would be optional.

As of now, I have buttons with a screen but need to wait 10" to see the cover state which is useless. A simple zigbee button would allow the same kind of control.

What do you think about it?

[Zixim]

sounds interesting, what should happen when Cover 1 is opened or closed by another mechanism in HA ? The state onscreen would be out of sync & showing wrong info, or the display will be waiting for the timed wakeup and update at that time.

[hilsonp]

The way I saw it was: If the state is changed by other means (automation, action), chances are low that a user is monitoring the label. I find therefore acceptable to have the label incorrect until the next wake up cycle.

For sure, for this to work, I will need to have an automation triggered by the cover/window state to change the label accordingly.

[nplan]

Staying awake is really costing a lot of battery life. Maybe something like this would be better:

1. User presses button
2. HA sets the label to "opening..." and sets a special mqtt command "check_back_in" to 10s for example
3. Home Buttons goes to sleep
4. Action finishes and HA sets label to "open"
5. Home Buttons wakes up after 10s, updates label to "open" and goes back to sleep with regular wakeup interval

There are 2 options you could use with the current firmware:

1. Reduce the sensor interval - the minimum is 1 minute
2. Plug the USB-C or DC 5V and turn on Awake Mode. In this mode the label updates are instant since the device does not sleep.

[hilsonp]

@nplan This is a neat way of doing it ! Indeed, for each action, I have a good idea of the maximum time it takes.

Between 2 and 3, will HB change the label on the screen to opening ? If yes, you have to keep HB awoken long enough for HA to complete 2.

Instead of setting a "check_back_in", we could set statically in HB configuration, for each button, a "check_back_after" that would accept a comma separated list of delays. For example, for button1, I know that after a press on the button, it takes about 3s for the cover to start moving and HA to update the label to opening, then it takes another 10s for the cover to fully open and have HA change the label to opened. I would then set on the HB configuration, the button1 check_back_after to "3,10" then goes to sleep with regular wakeup intervals.

It achieves the same goal, is easier to explain and setup (nothing to be done on HA, everything is set on HB config, staticallly). The cost on the battery would be 2 smaller sleep periods after each button press.

The check_back_after is a list and could contain n values only limited by the string length ;-)

[nplan]

Between 2 and 3 it depends on how quickly HA sends the new label. HB waits around 500 ms before going to sleep.

I'm not sure I understand the use case you have in mind. Do you want a confirmation that the action was triggered? For example if the cover in your example is in another room?

[JunghaJungha]

I love this proposal, I face the same issue. I need to wait to see the actual status.

For me I immediately send back a new text to a button after it has been pressed, but can image there is fixed delay time.

[hilsonp]

@nplan The use case is the following:

• The HB is located downstairs and controls 3 motorised roof windows (one button/label for each window) and 3 covers attached to those windows (one button/label for each cover).
• The windows+covers are located upstairs.
• In my automation, each windows and each cover has 4 states:
  • closed (stable state)
  • opening (transcient state - around 30s)
  • open (stable state)
  • closing (transcient state - around 30s)

Let's imagine that cover1 is managed by HB button 1.

If a cover1 is closed and someone presses HB button 1, and if I could setup HB button 1 wake-up times after being pressed to [1000, 30000] then:

• User sees the "close" label on button 1
• User presses button 1
• HB sends the event for button 1 to HA
• HA starts opening the cover 1 and changes the label 1 to "opening". I don't know how long this will take so 500ms might be too short.
• HB should wake up after 1000ms to get the label => it displays "opening" for label 1
• User sees "opening" on the button 1 label
• ... cover continues its motion ...
• Within 30 seconds, the cover ends its motion and HA sets the label 1 to "open".
• HB should wake up 30000ms (30s after the time it last went to sleep) to get the label => it displays "open" for label 1.
• User sees "open" on the button 1 label
• HB goes to sleep for the normal sleep period (default: 600000ms)

The cost is 2 extra wake-up for HB. The benefit is a sense of almost real-time feedback for the user.

[stevecampion23]

I also like this proposal. I have automations that update the icon after a button is pushed, and like others here I need to wait before the new icon appears. I think the process that @hilsonp describes would work very well indeed.

[nplan]

Added this functionality in v2.3.0. @hilsonp Please test.

There was also a bug that prevented a label change, if triggered within the same wake-up period, after a button press. Should work now.

[antonpiatek]

I have a similar need - I change the display after the button is pressed, but some actions are taking a fraction longer than the device does so it goes to sleep before the new label is published - I'd love it if I could add a delay or sleep after the publish to give the processing more time to complete. Could this be a configurable delay?

[nplan]

@antonpiatek see here: https://docs.home-buttons.com/original/user_guide/#schedule-wakeup

I think it's what you're looking for.

[antonpiatek]

@antonpiatek see here: https://docs.home-buttons.com/original/user_guide/#schedule-wakeup

I think it's what you're looking for.

Wonderful, thanks!