Hue motion sensors + remotes: custom component

imisanthrope · April 3, 2018, 8:35am

@robmarkcole thanks a lot for your work, just updated to 0.66.1, modified component, everything works.
But could you please help me to solve two little problems:

at this moment IP and Key of hub are in hue.py. It’s normal, but… a little bit unsecure) I like concept of putting all sensitive stuff like ips, keys, passwords to secrets.yaml, without publishing it to GitHub. Hope in future sensitive information will be excluded from component.

more important problem is state changes. I don’t like to multiple entities and always try to make as few automations as I can, using templates. Now my automation for Hue dimmers looks like this:

alias: Hue dimmers
trigger:
  platform: state
  entity_id:
    - sensor.roomswitch
    - sensor.kitchenswitch
    - sensor.hallswitch
 action:
   - service: scene.turn_on
     data_template:
       entity_id: >
         {% set theRoom = trigger.entity_id.split(".")[1].split("s")[0] %}     # getting room name (room/kitchen/hall) from switch entity
         {% if trigger.to_state.state == "1_click" %}
           scene.{{ theRoom }}_bright
         {% elif trigger.to_state.state == "2_click" %}
           scene.{{ theRoom }}_dimmed
         * * *
         {% endif %}

So, one automation covers all three dimmers I have and fires appropriate scene in appropriate room according which button on which dimmer pressed. But it’s unusable, because state change event is being triggered even on attributes changes (battery level, etc). And if I, for example, turn light on with first dimmer button, than turn light off via Siri/another automation/HomeKit than after some time lights up again, because some dimmer attributes have been changed and automation triggered.
I tried to solve by adding condition:

condition: template
value_template: '{{ trigger.to_state.state != trigger.from_state.state }}'

but now if I triggered lights by 1st button, than lights turned off by something another and I again press 1st button - nothing happens because to/from states are the same.
So… Is there any way to watch only press button events, not every state change?
I know I can use to: option in trigger block, but than I need automation for every button of every dimmer, 4 x 3 = 12 automations istead of 1.

Mariusthvdb · April 3, 2018, 10:16am

HI Rob,

Im not sure i should upgrade… reading all issues with Hue in the first place, rgb_color and brightness issues, and secondly losing all switches and sensors your CC creates so beautifully ?

Been reinstating my rest and json sensors just to be sure i dont miss out on the functionality just in case, but still. What should we do?

robmarkcole · April 3, 2018, 1:36pm

Somebody solved the button problem previously on this thread, please have a look through. As a note to all, this component will be written correctly using the async hue, and the remotes implemented as remotes.
Cheers

marthocoo · April 3, 2018, 4:03pm

@robmarkcole - Yesterday I opened a PR on aiohue to add sensor support. Once that’s merged you can begin migrating this custom component to aiohue.

Zepixir · April 3, 2018, 5:14pm

Really like your data_template, shows the power of templates
I recently found out about the service_template, which also makes automations like this possible.

This is one way that works if you want to use both click and hold function of the buttons:

 - alias: "test"
   trigger:
    - platform: state
      entity_id: sensor.dimmer_hue_template_last_updated
   condition: 
    condition: state
    entity_id: sensor.hue_dimmer_switch_gang
    state: '4_click'
    for:
      seconds: 1
   action:
     - service: switch.turn_on
       entity_id: switch.lys_taklys_kjokken 

 - alias: "test2"
   trigger:
    - platform: state
      entity_id: sensor.dimmer_hue_template_last_updated
   condition: 
    condition: state
    entity_id: sensor.hue_dimmer_switch_gang
    state: '4_hold'
   action:
    - service: light.turn_on
      data:
        entity_id: light.lys_spotter_kjokken  
        brightness_pct: 100

The sensor.dimmer_hue_template_last_updated is as it’s name says a template for last_updated:

 dimmer_hue_template_last_updated:
   friendly_name: 'Hue Dimmer Last Updated'
   value_template: '{% if states.sensor.hue_dimmer_switch_gang %}
     {{ states.sensor.hue_dimmer_switch_gang.last_updated }}
   {% else %}
     n/a
   {% endif %}'

Then the automation get triggered by the last_updated attribute, so it will trigger anyway if the state of the switch is the same.
If you don’t want to use the hold function, there is no meaning with the for: 1 second part.

You could probably implement this function inside the data_template, so please share if you can make that work, since that can reduce my automations too

Zepixir · April 3, 2018, 5:34pm

That is fantastic! Can’t wait for the hue sensors to be implementet in homeassistant without being a custom component. Will this also fix the problem with the alert messages we now have if we set the update_interval for the sensors too low?

imisanthrope · April 4, 2018, 8:07am

Thanks a lot for code. But won’t action be triggered on every state change? If battery level (or any other attribute) changes, it should cause state update => sensor state “last_updated” should be changed too, right?

I’ll try to cobine it with my automation, check if it works and post result code here.

Zepixir · April 4, 2018, 9:54am

No, at least for me, I had no changes to last_updated except when the buttons have been pressed. But I have never seen the battery level changed from 100% either.

Lukas_m · April 4, 2018, 7:07pm

Since the update to HASS version 66.1, hue won’t be recognized by HASS unless one deletes all custom components which are related to hue.

Does anybody has some ideas how to get the state of hue’s motion sensor and the dimmer switch without this custom component?

Mariusthvdb · April 4, 2018, 7:13pm

according to the author, it should still be usable.

several have reported successful migration.

If not, you can use (json)rest sensors. and template the desired values out.

  - platform: jsonrest
    resource: !secret hue_sensors_resource
    method: GET
    name: Philips Hue Sensors
    scan_interval: 1

  - platform: rest
    resource: http://ip/api/key/sensors/2
    value_template: '{{ value_json.config.battery}}'
    name: 'Battery Dimmer switch'
    unit_of_measurement: '%'
    scan_interval: 30

john1 · April 5, 2018, 5:22pm

Hey,
I fixed the state command issue which you were having. Instead of using the command_line platform, I used the rest platform.
Here is my configuration if you are interested in this:

  - platform: rest
    resource: http://ip/api/key/sensors/sensor_name
    method: put
    name: "Hallway Sensor Switch"
    body_on: '{"config": {"on": true}}'
    body_off: '{"config": {"on": false}}'
    is_on_template: '{{ value_json.config.on }}'
    scan_interval: 1

Mariusthvdb · April 5, 2018, 5:50pm

nice, will try that.
No such thing as coincidence, ive just changed my cl switches like this, and they work like a charm:

corridor_motion_sensor_switch:
  friendly_name: "Corridor motion sensor switch"
  command_on: >-
    curl -X PUT -d '{"on":true}' "http://ip/api/key/sensors/5/config"
  command_off: >-
    curl -X PUT -d '{"on":false}' "http://ip/api/key/sensors/5/config"
#     command_state: curl http://ip/api/key/sensors/5/
#     value_template: '{{value_json.config.on}}'
  value_template: >-
     "{{ is_state_attr('sensor.corridor_motion_sensor', 'on', true) }}"

main difference the value_template, which now is reading the on/off state of the with correctly (before it read on/off of the trigger…)

have several in a group which makes it super easy to switch the house in motion sensor mode (when away) or not (when dancing in the auditorium… )

would be really interested to hear which of the two would be preferable and why (resources , reliability, etc)
Cheers,
Marius

---- edit-----
@john1: yours are better…

its not that mine don’t switch, they do perfectly. Its the state picking up that yours do more reliably. If the sensors are switched elsewhere mine dont show the correct state, the template must be off somehow. Yours follow the correct state, also when switched off/on by other controls, like the Hue App.
So, changed setup, with a little customization:

switch.corridor_motion_sensor_switch:
  templates:
    icon: "if (state === 'on') return 'mdi:toggle-switch';
                            else return 'mdi:toggle-switch-off';"
  assumed_state: false
  group:
    group.philips_motion_sensor_switches:
      friendly_name: Corridor motion

Cheers,
Marius

olloe · April 5, 2018, 8:35pm

Great project! Finally some nice, responsive remotes!
I’m getting alot of updating errors in the log. Right now I’m just testing with one and tried http://IP/api/KEY/sensors/26, but no success.
Could it help if I only poll the remotes I want? If so, is it possible?

robmarkcole · April 5, 2018, 8:54pm

All of the sensors/remotes are polled in a single request. No more targeted polling would be more efficient

imisanthrope · April 7, 2018, 6:50am

Thanks. I modified my config, now it works like it should to, no problems with double button press and no false triggers.
Here is a code:

Template sensors for each Hue dimmer (maybe it’s possible to combine them into one, but I decided that 3 is acceptable).

platform: template
sensors:
  switch_room:
    value_template: >
      {% if states.sensor.roomswitch %}                   #sensor.roomswitch is entity_id of Hue dimmer from custom component
        {{ states.sensor.roomswitch.last_updated }}
      {% else %}
        n/a
      {% endif %}

  switch_kitchen:
    * * *            #same as roomswitch
  switch_hall:
    * * *

Automation for dimmer buttons (one for all three Dimmers).

alias: Hue dimmers
  trigger:
    platform: state
    entity_id:
      - sensor.switch_room            #
      - sensor.switch_kitchen         # template sensors, created above
      - sensor.switch_hall            #
  condition:
    - condition: state
      entity_id: input_boolean.children_lock     # a little hack against children's love to switch light :)
      state: 'off'
  action:
    - service: scene.turn_on
      data_template:
        entity_id: >
          {% set theRoom = trigger.entity_id.split("_")[1] %}   # get room name from template sensor (i.e room, or kitchen, or hall)
          {% set theSwitch = "sensor." + theRoom + "switch" %}  # forming name of corresponding Dimmer (i.e 'sensor.roomswitch' or 'sensor.hallswitch', etc)
          {% if is_state(theSwitch, "1_click") %}
            scene.{{ theRoom }}_bright
          {% elif is_state(theSwitch, "2_click") %}
            scene.{{ theRoom }}_dimmed
          {% elif is_state(theSwitch, "3_click") %}
            scene.{{ theRoom }}_night
          {% elif is_state(theSwitch, "4_click") %}
            scene.{{ theRoom }}_no_light
          {% endif %}

Hope my implementation will be useful for someone)

jdbrookes · April 7, 2018, 10:16am

This might not be the appropriate place to ask, but how do I customise the state of various motion sensors?

The hue custom component motion sensors display as On or Off in the UI, but the Xiaomi motion sensors I have display as Clear or Detected. See below, the Downstairs and Sitting Room sensors are Hue.

Ideally I would like these to be consistent. ie Clear or Detected for all, or One or Off for all.

Additionally, the hue component sensors don’t highlight in yellow when motion is detected, do we have any control over that, is there a setting I can change somewhere? Thanks in advance

motionsensors

robmarkcole · April 7, 2018, 12:20pm

The issue here is that the motion sensors are implemented as vanilla sensors rather than binary_sensors. I actually use a template_binary to detect motion at home (in binary_sensors.yaml):

- platform: template
  sensors:
    motion_at_home:
      value_template: >-
        {%- if is_state("sensor.hall_motion_sensor", "on")
        or is_state("sensor.living_room_motion_sensor", "on")
        or is_state("sensor.bedroom_motion_sensor", "on")
            -%}
        True
        {%- else -%}
        False
        {%- endif %}

I hadn’t given this much thought, but IMO motion sensors should be implemented as binary sensors. Added to to-do list.

mcfarlde · April 7, 2018, 2:01pm

Hi, any progress since 0.66? The HUE refactor at 0.66 caused me to loose connection to a couple of Tasmota Sonoffs that were pretending to be HUE bridges. I changed them to pretend to be Wemo, but they are now limited to one output. I also lost effects from the faceplates of any bulbs that have effects but can still call the service with other methods. I ask as I saw in another thread, that you were thinking of helping with the platform and then the thread went private by the author of the platform.

jdbrookes · April 7, 2018, 3:15pm

Ah ok, I can see that the Xiaomi sensors are indeed listed as binary sensors, didn’t realise that was the difference.

It’s not a big deal but I appreciate you putting it on the todo list.

Mariusthvdb · April 7, 2018, 3:30pm

guess you could customize like this:

 templates:
    rgb_color: "if (state === 'on') return [251, 210, 41]; else return [54, 95, 140];"

ive asked the people at MDI for a motion-sensor-off icon, which is now in the making.
If and when, you could probably also change the icon:

icon: "if (state === 'on') return 'mdi:motion-on';
                            else return 'mdi:motion-off';"

for now use mdi: run-fast and mdi:human-male/female … (might have to take out the line in the CC for the icon) is this possible @robmarkcole ? or maybe add the possibility for the on/off in the CC itself?

cheers,
Marius