Re-org emulated_hue and fix google home

[balloob]

Description:
This will fix emulated_hue so that it works with Google Home.

In the original Hue api, /lights returns an object of lights. Each key is a stringified number starting at 1 that represents the hub light id. In our emulated_hue we used the entity_id for this. This is something that Alexa supports and will remember between restarts of HASS.

Google Home will try to parse the string key to a number. If it can't parse it it will default to 0. Since we use entity_id it will process all lights as key 0 and thus only remember the last one, which then is unreachable as we don't know that id.

So this PR introduces a new type config parameter for emulated_hue. When set to google_home, it will convert all entity ids to numbers starting at 1. Google Home requests the state of the lights every 10 seconds so when the mapping of id to entity id changes after a restart, Home Assistant will know quick enough.

Note: you will need to set your listening port for the emulated Hue API to port 80 or else Google Home will not work.

This PR also introduces a significant re-org of the code to make it more organized and maintainable.

Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.github.io#<home-assistant.github.io PR number goes here>

Example entry for configuration.yaml (if applicable):

emulated_hue:
  type: google_home
  listen_port: 80

# Defaults to Alexa and port 8300
emulated_hue:

Checklist:

If the code does not interact with devices:

• Local tests with tox run successfully. Your PR cannot be merged unless tests pass
• Tests have been added to verify that the new code works.

[mention-bot]

@balloob, thanks for your PR! By analyzing the history of the files in this pull request, we identified @fabaff, @bah2830 and @vkorn to be potential reviewers.

[balloob]

In the future we could probably work with id persistence so that we no longer have to differentiate between Alexa / Google Home but for now this will already get people going.

[arsaboo]

Super!! Does that mean, if we want to use both Alexa and Google Home, the config will have two emulated_hue entries like you have in the first post?

[balloob]

No, that won't work as upnp will conflict. We need to get to a better solution with persistent ids for entities. I already validated that they accept entity numbers that are not sequential so now I just need to persist them.

…

On Sun, Dec 4, 2016, 08:26 Alok Saboo ***@***.***> wrote: Does that mean, if we want to use both Alexa and Google Home, the config will have two emulated_hue entries like you have in the first post? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4708 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABYJ2gkJEsbCmFyB6mhgHNKOWf-FL9Shks5rEunNgaJpZM4LDiyq> .

[arsaboo]

Got it.
Purely from the user perspective, wondering if it may be easier to just have an option in the emulated_hue entry to enable google_home (defaults to off):

emulated_hue:
   google_home: True

If google_home is true, then create entities for both Alexa and Google Home.

[balloob]

Nah, we can't have both entities be available. It is either one or the other.

[claudioita]

SO for the moment is either Alexa OR Google Home, together both it will not work, correct?

[ronvl]

@balloob how did you get it working on port 80 as on a PI we can't unless HASS runs as root....
See #4737

[ronvl]

Cool got it working with :
sudo setcap 'cap_net_bind_service=+ep' /usr/bin/python3.4

[colinodell]

No, that won't work as upnp will conflict. We need to get to a better
solution with persistent ids for entities.

I already validated that they accept entity numbers that are not sequential
so now I just need to persist them.

Is this being tracked somewhere? (I'd like to subscribe to updates if possible)

[claudioita]

what would be the command for a HASSBIAN installation?