Migrate to Hue-sensors-phue about hue-sensors-hass

[robmarkcole]

Created branch dev-phue.

Currently I have copied setup_platform() from hue.lights but I don't understand how the bridge_id is being returned by discovery_info since it appears discovery_info is empty. @andreacampi could you offer advice?
Cheers

[andreacampi]

Sure: in 0.60 the hue component handles both discovery and configuration; then it calls discovery.load_platform that invokes hue.lights setup_platform passing the bridge_id.
Does that help?

---

Now that I look at this again, I suspect this block is not called any more after that bridge_id change. Oops. That means that is auto discovery fails we never tell the user that they need to change their config. I should fix that.

[andreacampi]

In other words, you have to change this:

   discovery.load_platform(
            self.hass, 'light', DOMAIN,
            {'bridge_id': socket.gethostbyname(self.host)})

should become something like:

    PLATFORMS = ['light', 'sensor']

    for platform in PLATFORMS:
         discovery.load_platform(
            self.hass, platform, DOMAIN,
            {'bridge_id': socket.gethostbyname(self.host)})

[robmarkcole]

@andreacampi thanks for your suggestion, I've made the changes and the component is now functional.

I understand now that your HueBridge object is a wrapper to the phue bridge, so I end up with some awkward syntax of response = self.bridge.bridge.get_sensor_objects('name') since there is no method on HueBridge for get_sensor_objects(). I am also seeing slow response to update the sensor state in HA, and in my logs:

2017-12-21 06:58:34 WARNING (MainThread) [homeassistant.components.sensor] Updating hue sensor took longer than the scheduled update interval 0:00:01

My question is, what changes do you recommend to improve performance? Cheers!

[technicalpickles]

Awesome! I took a quick look but didn’t see anything obviously slow. I’d take a look at the API call’s timing, but you might not be able to do much to speed that up much. You can at least log the time it takes to get a sense of it.

I was wondering if the hue component does any of the API calls, but it doesn't look like it. At most, it has instance of the phue bridge object that gets passed to the light platform.

[andreacampi]

Yeah I don't think you can do much about performance, other than reducing the polling interval (can't remember how from the top of my head).

[andreacampi]

BTW I agree with you self.bridge.bridge.get_sensor_objects is a bit ugly. I would do the same I did for the light platform, i.e. set up a proxy method in HueBridge. See the set_light method as an example.

So for example

def get_sensor_objects(self, key):
  return self.bridge. get_sensor_objects(key)

It's not a big deal but it encapsulated HueBridge better and it gives us a central place to e.g. log etc. if we ever wanted to.

[robmarkcole]

@technicalpickles & @andreacampi I believe the slow performance may be an issue with the way phue queries the API using get_sensor_objects(). There are rate limits and this issue highlights that the polling by phue is inefficient. One solution is to use get_sensor() with no id passed, which returns the full API data. However then I am using phue just to make a single request. Could you guys take a look and let me know what you think?

If this is the case then I see no good reason to use phue as directly calling the API as I implemented previously performs well.
Cheers

EDIT: OK perhaps its parsing the phue object which is slow..

The following is parsing the json from the API, much faster..

EDIT 2: In ba6d923 I'm using the phue bridge object, calling get_sensors() and parsing with hue_sensors, and with scan_interval = 0.1 the updates are nice and fast :-) Note that these changes are required to the hue hub component - should submit a PR to update.

[robmarkcole]

Complete in c01de37