Remote needs a "standby" state

[mjoshd]

The remote control works great but really needs one of two things to make it perfect.
Either:
A) a default state that the remote can return to after the click/hold event has been processed (return to "standby" after some period of time)
or
B) faster click recognition (it is difficult to get a second click on the same button to register and not have it think I'm trying to do a 'hold')

[johansmitsnl]

Did you solve this?

My situation is that I have a motion sensor that triggers me entering the room and turns on the lights. But when I want to leave and don't want to wait for the motion timeout I want to press the TAP. This only works once, because the second time I do this the TAP is already in that 1_click state and does not fire again.

In the past I had used a rest trigger that set the state after 1 second to idle again based on the update_time. Now it works confusing.

[yottatsa]

@johansmitsnl which version of the component do you use? Could you please show the state of the sensor straight from the API before and after clicking the TAP.

In 1.0 I've changed the sensor behaviour, so it only updates the sensor state if the API state changed. AFAIK this means you could create an automation that triggers only on To. I have neither TAP nor remote, so I couldn't debug it.

[johansmitsnl]

@yottatsa here some details:

First click

{
  "state": {
    "buttonevent": 34,
    "lastupdated": "2019-01-28T11:31:36"
  },
  "swupdate": {
    "state": "notupdatable",
    "lastinstall": null
  },
  "config": {
    "on": true
  },
  "name": "Hue TAP Badkamer",
  "type": "ZGPSwitch",
  "modelid": "ZGPSWITCH",
  "manufacturername": "Philips",
  "productname": "Hue tap switch",
  "uniqueid": "00:00:00:00:00:46:69:d2-f2",
  "capabilities": {
    "certified": true
  }
}

Second same button:

{
  "state": {
    "buttonevent": 34,
    "lastupdated": "2019-01-28T11:32:13"
  },
  "swupdate": {
    "state": "notupdatable",
    "lastinstall": null
  },
  "config": {
    "on": true
  },
  "name": "Hue TAP Badkamer",
  "type": "ZGPSwitch",
  "modelid": "ZGPSWITCH",
  "manufacturername": "Philips",
  "productname": "Hue tap switch",
  "uniqueid": "00:00:00:00:00:46:69:d2-f2",
  "capabilities": {
    "certified": true
  }
}

My automation is like this:

- alias: Lights ON
  trigger:
    - platform: state
      entity_id: sensor.hue_tap_badkamer
      to: '1_click'

This goes the same for the other HUE dimmer remotes when I only trigger on the 1_click_up

I use master (6a4b711)

[johansmitsnl]

Any updates for this? I do use it correctly or is there another way to trigger on this state?

[yottatsa]

Found it. Because the state doesn't change between presses, and the only change is in attributes, you need to use bit different way to trigger:

- alias: Lights ON
  trigger:
  - platform: state
    entity_id: sensor.hue_tap_badkamer
  condition:
  - condition: state
    entity_id: sensor.hue_tap_badkamer
    state: '1_click'

With this, every event with '1_click' state will be picked up.

There's also a bug #55, when the remote is triggering by itself if the attributes are changed. Proposed fix will reset the state to None after a while. You could try this version after changing the automation.

[yottatsa]

The better way to fix it is to emit an event instead of state change.

[mjoshd]

What I have been doing is kind of a dirty hack, but I have not had any issues with false triggers and it seems to be working very well. Ever since the custom component gained the ability to manually set the state (1.0.3, I think) I have been issuing a rest command to manually change the state to standby after 1_click_up is received and processed in an automation...

# rest_commands.yaml
#################
hue_remote_standby: 
  url: http://localhost:8123/api/states/sensor.hue_remote
  method: POST
  headers:
    authorization: !secret hue_remote_standby
  payload: '{"state": "standby"}'
  content_type: application/json

!secret hue_remote_standby contains a long lived access token and looks like the following in secrets.yaml where ABCDEFGH is the token generated on the user account page:

# secrets.yaml
##########
hue_remote_standby: Bearer ABCDEFGH

[johansmitsnl]

@yottatsa You proposed change will work but I have several automations combined some some states.
I have for example the turn home off for 3 remotes on a long press. When I have all 3 remotes combined there might be one in the same turn off mode and that will get triggered if on of the remotes is used.

Having a stand-by state looks like a muts if you don't want to do stange state management with bools.

Expanded your example:

- alias: Lights ON
  trigger:
  - platform: state
    entity_id: sensor.hue_tap_badkamer
  - platform: state
    entity_id: sensor.hue_tap_bedroom
  condition:
    condition: or
    conditions:
      - condition: state
        entity_id: sensor.hue_tap_badkamer
        state: '1_hold_up'
      - condition: state
        entity_id: sensor.hue_tap_bedroom
        state: '1_hold_up'

[johansmitsnl]

Any update on this or a testing branch?

[alexthomsen]

Im using node-red to control my dimmers. Using the RBE component "The node blocks unless the incoming value changes" and looking at the last_updated attribute. Maybe it´s possible to implement that in homeassistant directly.

[rafaelbiriba]

Any new about the standby idea? I can click to turn on the light, but can not click again to turn it off, since the state of 1_click_up did not change, that is sad 😢

[claytonjn]

Per https://www.home-assistant.io/docs/automation/trigger/#state-trigger

If only entity_id is given trigger will activate for all state changes, even if only state attributes change.

So it doesn't matter if the state doesn't change, you just need to make sure you don't include to: [...] in the automation trigger and then if you want the state to be 1_click_up you can add that as a condition.

[robmarkcole]

Please summarise and reopen on remotes repo if still of interest