Hue motion sensors + remotes: custom component

cool, thanks.

fwiw, next to the Rest_sensors I asked you about earlier,

- platform: rest
  resource: http://192.168.xxx.xxx/api/[apikey]/sensors/1
  value_template: '{{ value_json.state.daylight }}'
  name: 'Daylight Corridor'
  unit_of_measurement: Day
  scan_interval: 30

ive now created several jsonrest based template sensors.
code:

- platform: jsonrest
  resource: !secret hue_resource
  method: GET
  name: Philips Hue Equipment
  scan_interval: 10

hue_resource: http://192.168.xxx.xxx/api/[apikey]

- platform: template
  sensors:
    philips_hue_sensor_1_daylight:
      friendly_name: 'Daylight Corridor'
      value_template: "{{states.sensor.philips_hue_equipment.attributes.sensors['1'].state.daylight}}"
#      unit_of_measurement: 'Name'
    philips_hue_sensor_1_lastupdated:
      friendly_name: 'Update Corridor'
      value_template: "{{states.sensor.philips_hue_equipment.attributes.sensors['1'].state.lastupdated}}"
#      unit_of_measurement: 'Name'
    philips_hue_sensor_2_buttonevent:
      friendly_name: 'Button Dimmer switch'
      value_template: "{{states.sensor.philips_hue_equipment.attributes.sensors['2'].state.buttonevent}}"
#      unit_of_measurement: 'Name'
    philips_hue_sensor_2_lastupdated:
      friendly_name: 'Update Dimmer switch'
      value_template: "{{states.sensor.philips_hue_equipment.attributes.sensors['2'].state.lastupdated}}"
    philips_hue_sensor_2_battery:
      friendly_name: 'Battery Dimmer switch'
      value_template: "{{states.sensor.philips_hue_equipment.attributes.sensors['2'].config.battery}}"
      unit_of_measurement: '%'

etc etc.
just to see if this will be less of a burden for the processor, and generate less errors or warnings in the logs.

nothing automatic as your custom component of course, but very interesting to build, get to understand the system, and create different ways for the same result :wink:

Cheers,
Marius

1 Like

Hey - just a question. I see you’re using Hue gear. Can I ask if you have a template configured to measure lux/brightness of the sensor?

@robmarkcole is saying what I posted was correct, but it’s not working.

Appreciate any help!

@commandcontrolit you can use the dev-state tool to check the attributes of your motion sensors, for example:

To access the lux I just used:

- platform: template
  sensors:
    living_room_light_level:
      friendly_name: 'Living room light level'
      value_template: '{{states.sensor.living_room_motion_sensor.attributes.lux}}'
      unit_of_measurement: lux

And get:


Cheers

1 Like

hi,

this is derived from the sensors created by your custom component?

if one reads out the Philips devices, no Lux is displayed anywhere, and it must be calculated on the light level attribute like this:

value_template: ‘{{ (10 ** (float(value_json.state.lightlevel - 1) / 10000))|round(2) }}’

a sensor doing so:

- platform: rest
  resource: http://192.168.xxx.xxx/api/[apikey]/sensors/6
  value_template: '{{ (10 ** (float(value_json.state.lightlevel - 1) / 10000))|round(2) }}'
  name: 'Lux Corridor'
  unit_of_measurement: Lux
  scan_interval: 20 

Cheers,
Marius

OK - so my formatting was wrong. Seems to be generating a value now! Thank you!

For others maybe looking for the same help.

Incorrect


  - platform: template
    sensors:
      main_hallway_light_level:
        friendly_name: 'Main Hallway Lux'
        value_template: '{{ ((float(states.sensor.main_hallway_lights_motion_sensor.attributes.lux) }}'
        unit_of_measurement: Lux

Correct

  - platform: template
    sensors:
      main_hallway_light_level:
        friendly_name: 'Main Hallway Lux'
        value_template: '{{states.sensor.main_hallway_lights_front_motion_sensor.attributes.lux}}'
        unit_of_measurement: lux

You had an extra ( in there

1 Like

Yes, because I sort of copied and pasted from the templates I was using for temperature :slight_smile:

  - platform: template
    sensors:
      main_hallway_sensor_front_temperature:
        friendly_name: 'Main Hallway Front Temperature'
        value_template: '{{ ((float(states.sensor.main_hallway_lights_front_motion_sensor.attributes.temperature) * 9) / 5) + 32 }}'
        unit_of_measurement: '°F'

not as much as i would have liked though…

is there a way t figure out if it is the time setting causing the issue, or the updating itself. Maybe another factor is frustrating the operation?

1 Like

I think it’s due to the phue library. On my to do list to address but not high up the list

1 Like

I have mine set to 0.1 and I notice the same errors in my logs. I don’t notice any performance issues though. Should I stagger this back to 0.5?

#Hue-sensors
hue:
  bridges:
    - host: 10.1.30.162

sensor:
  - platform: hue
    scan_interval: 0.1
2018-02-03 10:45:53 WARNING (MainThread) [homeassistant.components.sensor] Updating hue sensor took longer than the scheduled update interval 0:00:00.100000
2018-02-03 10:46:23 WARNING (MainThread) [homeassistant.components.sensor] Updating hue sensor took longer than the scheduled update interval 0:00:00.100000

cool, hope you find anything.

Its just that i suspected one of my Hue lights, because it was not responding properly. Seemed to correlate with this error-log.
Of course the challenge lies in finding which causes what :wink: the light causing the delay in updating, or the delay causing the response of the light.

Worth browsing the Hue API docs. Phue has internal rate limiting so doubt it would be upsetting the lights

1 Like

Not sure if someone mentioned it already, but would it be possible to extract ON element from motion sensor to HA switch?

  "config": {
    "on": true,
     ...
  },

Sometimes it’s handy to turn off the motion sensor.
Thanks a lot @robmarkcole

+1. Would be useful.

@foxys and @Cain I have added the ‘on’ and ‘reachable’ attributes in release v0.5. You can see the changes required to the code here are minimal so I would encourage people to submit PR’s for such requests. That will be fastest and guarantee your requirements are met.
Cheers

1 Like

Nice!
since you ask: would be possible to have the last_updated display the time first and then the date/year? that way at first glance, without clicking for the more-info, we would see the actual time, and not 2018…

Cheers,
Marius

@Mariusthvdb you could break out last_updated in the format you want using a template_sensor. If dropping the date by default that could be a braking change for others. However if you have a nice solution, please submit the PR?
Cheers

well, im not a big python programmer, so wouldn’t resume to have a solution.

it’s just I would find it more convenient to have the last update time displayed in the sensor first, rather than the year:

48

I’ve put them in a group, so this is less of an issue, and you’re right, I breakout the date/time in a separate sensor, and will figure it out there :wink:
i use: "{{states.sensor.philips_hue_sensors.attributes['23'].state.lastupdated | timestamp_custom ('%H:%M')}}" or

value_template: "{{ as_timestamp(value_json.state.lastupdated) | timestamp_custom ('%H:%M') }}"

As a general rule, if there is a way to achieve the desired outcome using existing HA functionality, then that is the preferred approach. Adding unnecessary complexity to components is a recipe for headaches due to unintended consequences.

Btw python is easy to pickup, and you will get a lot more out of this platform with a little python experience. I recommend experimenting with python_scripts as a way to get your feet wet.
Cheers

1 Like

well, i trying. having more ideas than capabilities for the time being though :wink:

would love to automatically find the scenes and lighting schemes the Hue offers, so one can set them from within Hassio. As it stands now, i find myself going back to the Hue-app to find the correct settings for scenes.
One could hard code these i believe, by issuing the rib settings in an automation. But what would be so much nicer is when these settings popped up as available options, or at least as templatable states attributes.

Another effort would go to reading the programmed scenes from the button switches, the so called schedules and scenes in the Api. We now can see which button is pressed, but in the Hue Api the name of the scenes belonging to that button is available also. Might that be an enhancement for your component maybe?

Groups could be another cool set to extract, but there Hue itself offers some support, though a bit cryptic .

Well enough to be excited about and to look forward too.
Hope to be able to extract some of the above from the sensors.

cheers,
Marius