Alexa-Hue Bridge Plugin (old locked topic)

[tjm000]

Well, after reading the previous posts and figuring some thing out I was able to get Alexa to discover my two devices and I was able to use them successfully.

This is what I had to do:
1) I used the new version of the plug-in and reran discovery to find out that another App was using the UPnP port (thanks Jay), which was confirmed with the terminal command.
2) Based upon an earlier post, I turned off my Squeezebox Media Server and re-ran the discovery process. This time I did not get the in-use error in the log window but the Alexa discovery process still failed.
3) I turned off the firewall on my MacMini and repeated the process which finally resulted in a successful discovery.
4) I was able to execute an Alexa device command (basically turn on/off a light in my house).
5) I turned the firewall and the Squeezebox media server back on and Alex was still able to control the light.

Thanks for everyone's help. Now for some fun in figuring out what things I want Alexa to control.

[simplyahobby]

My setup is working now. Alexa is properly managing the devices that I have made available via the bridge.

Thanks for the great work on this plugin and your assistance here.

[eme jota ce]

...

Yes, it will. Download and install the latest version of the plugin that I just uploaded - I expect you have some other app on your Mac that's using the UPNP port. If you use the Sonos plugin, you'll need to disable it only during discovery.

Thanks Jay! That worked!

Turned off Sonos (and used the terminal command lsof -i :1900 to double check nothing else was using Port 1900.

Just added a few lights and a fan as a test, worked perfectly for light, fan, and a Virtual Device that controls multiple lights simultaneously.

[Redrocker]

Not sure how I missed this thread 3 days ago, but I'm happy the initial bugs have been worked out. Downloaded the plugin and added 4 new devices to my already existing 12 Hue devices. The first couple tries produced no results. I told Alexa to forget all devices and groups, reran the plugin discovery, and got her to find the plugin devices.

I'm happy with the plugin, thank you all that worked on this.

[nathanw]

I'm not clear on how the "Managing Devices" UI interacts with the Echo's discovery process. Is the Echo discovering just the bridge? When does it re-enumerate the set of devices? Equivalently, if I add/remove things in the "Managing Devices" list, do I need to re-run Discovery to update it, or is the Echo supposed to do that?

[jay (support)]

This is what happens (roughly):

1. You start the discovery process, which starts broadcasting out on the network that a Hue Hub exists (Indigo pretending to be one that is). It also starts a specific responder thread (that binds to port 1900) that will listen for processes interested in the advertised service (i.e. the Alexa device - Echo, FireTV, etc.).
2. You tell Alexa to discover devices (either verbally or via the Alexa app) - it looks for broadcasts and pings the hub (plugin) on port 1900 for information.
3. It then uses that information to request a list of available devices from the hub (plugin)

So, the plugin needs to know how to talk to Alexa in the format it knows about and the plugin is the intermediary between that and Indigo.

Because of that unfortunate 27 device limit in the Alexa implementation for Hue Hubs, we can't just publish all Indigo ON/OFF devices because many people have more than 27. Also, Alexa doesn't like non-ascii characters in device names and some users name devices in a way that isn't conducive to speech recognition. So the purpose of the Manage Devices UI is to 1) tell the plugin that a given Indigo device is to be made available through the bridge and 2) optionally a different name to use.

Because adding/removing devices from the list is synonymous to adding/removing lights on a Hue Hub, whenever there's a change you (almost always) have to rerun discovery on your Alexa device (it doesn't get any messages from the Hue Hub about device changes, it's a manual process) - there should be a message in the Event Log whenever the plugin thinks you need to rerun discovery. In the case of an add, you can just rerun discovery either verbally or using the Alexa app - either way though requires you to start the discovery from the plugin first.

In the case of a delete, you can use the Alexa app to "forget" the deleted device or you can tell Alexa to forget all devices and then rediscover. The former approach doesn't require you to turn on discovery (because it's just deleting the device from Alexa's list) but the latter, because it's a full discovery, requires that discovery be started from the plugin.

[eme jota ce]

Jay,

Thanks again. This is the coolest addition / plugin that I've added to my Indigo system in a while.

A few comments:

1. Pleasantly surprised how quickly the commands can be executed. Seems a little inconsistent in terms of speed, but never slow. Often, she has lights turned ON or Off before she says, "OK."
   
   Alexa's integrated command set can conflict with naming of Devices in the Plugin. For example, I had an Indigo Virtual Device that executed a Sonos Plugin to play news. Naming it "just about anything with the word "news" in it, started Alexa's daily briefing. Similarly, using radio station call letters started Alexa's playing of that station through her own speaker, not executing the Indigo Action.
   
   In Indigo's log, the Devices are referenced by number, not name. For example, it says "Set on state of device 309155737 to False" instead of "Set on state of Kitchen Lights to False". This is the only of the three points that is a request for update to the plugin.

Thanks for this great plugin. Have been hoping for Alexa integration into the Indigo system and greatly appreciate that it works well and easily.

BTW, as a side not, not sure if any other Alexa owners have discovered the "problem" we've discovered with Amazon Echo ... If guests have a little too much celebration in the evening, there is a temptation to start whispering in her ear, "Alexa, set an alarm for 4am." Maybe, the Sonos plugin can have Siri announce "Alexa, clear all alarms" automatically after guests leave...

[jay (support)]

Pleasantly surprised how quickly the commands can be executed. Seems a little inconsistent in terms of speed, but never slow. Often, she has lights turned ON or Off before she says, "OK."

Yes, it's much faster than the cloud based alexa skills because it's just talking on the local network from the Alexa device to the plugin. The other automation plugins require a trip out to the internet and back so there's some delay there.

In Indigo's log, the Devices are referenced by number, not name. For example, it says "Set on state of device 309155737 to False" instead of "Set on state of Kitchen Lights to False".

This is just an optimization - at the point that the method that turns on/off the device is called, all I have is the ID. So I'd have to get the device from the server to get it's name, all just for the purpose of inserting it into the log. While that's not a huge deal, it seemed a bit wasteful just to show the name rather than the ID. Especially since the majority of devices that would have been controlled would have immediately shown the change in the log anyhow. For instance, I have a Virtual On/Off device that has ON and OFF action groups that executes an Insteon scene that turns on/off two lights. When I turn on that device, I see:

Code: Select all

  Action Group                    Turn on Kitchen Lights
  Virtual Devices                 sent "Kitchen Lights" on
  Sent INSTEON                    "PowerLinc Interface" on (scene 27 - Kitchen Lights)
  Sent INSTEON                    "Kitchen Sink Lights" on (scene 27 cleanup)
  Sent INSTEON                    "Kitchen Island Lights" on (scene 27 cleanup)

This one's actually a bit chatty because it's a PowerLinc group, but I think most devices, regardless of protocol, when being controlled will insert the name and command into the log.

[tedco]

I seem to be in the same boat as mjc. I am using the hue-lights 1.3.4 plugin for about 30 hue bulbs, and I've configured the Alexa-hue bridge plugin to only broadcast a few of these grouped bulbs and other z-wave devices, but when I go to discover, it seems to find the first 27 single bulbs, not the bulbs, groups, and z-wave devices that I have published with the plugin. I've checked port 1900 and I am not running anything on that port (I was, Plex and Sonos, but those are turned off now) and I've tried discovering a few different times (even with the hue-lights plugin disabled) and it still seems to find the 27 first 27 bulbs. I tried unplugging the actual hue-hub while attempting discovery and it wont find any bulbs (so that's where the 27 lights are coming from - although I am not hitting the sync button when attempting discovery, but am using the Homekit compatible hub) Any suggestions?

Thanks,

Ted

[jay (support)]

mjc solved his problem - he had the Sonos plugin running (see a few posts up). So far, the only two things causing failed discoveries were port conflicts and the odd Alexa app bug I describe above - force quit the Alexa app and for good measure restart your Echo then try discovery again.

Are you using the latest plugin? Turn on both debug and thread debug, then start discovery and try to discover - that will show what's going on with the discovery processes. Copy/paste the resulting event log lines in code tags in a reply here.

[webdeck]

Okay, I decided to do a little digging. Maybe it's MythTV Backend or Squeezebox Server. I looked for anything using port 1900 (ssdp):

Code: Select all

# lsof -i :1900
COMMAND     PID   USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
perl5.18   1558 server   31u  IPv4 0x7eda578b7125f07b      0t0  UDP localhost:ssdp
perl5.18   1558 server   32u  IPv4 0x7eda578b7125ee23      0t0  UDP home.webdeck.com:ssdp
perl5.18   1558 server   33u  IPv4 0x7eda578b5bd3852b      0t0  UDP *:ssdp
MythBacke 59715 mythtv   66u  IPv4 0x7eda578b7126114b      0t0  UDP 239.255.255.250:ssdp

Do I need to stop all of those services to get the discovery phase to work? Can I resume them after I've completed the discovery?

Yes, there can only be one process that successfully binds to port 1900 - which begs the question of how you have two different processes using the same port (are those running on different IP addresses maybe?). But, in any event, any app that's bound to port 1900 will have to be shut down for discovery to work. I'll have another look at the code - I believe it should be showing an error when it tries to bind to port 1900 when there's a conflict.

Just to close the loop on this, I configured both MythTV and Squeezebox Server to not use uPNP (I wasn't using it anyway) and that fixed the problem. Alexa discovered my devices and it's working like a champ! Thanks for adding this!

-Mike

[tedco]

Thanks Jay for the suggestions, here are my results from the following steps: thread debugging:

Alexa-Hue Bridge Debug getMenuActionConfigUiValues: published device count is 3
Alexa-Hue Bridge Debug Validating action config for type: startDiscovery
Alexa-Hue Bridge Starting discovery process
Alexa-Hue Bridge Debug Validating action config for type: startDiscovery
Alexa-Hue Bridge Debug startDiscovery props validated
Alexa-Hue Bridge Debug broadcaster thread is not alive, starting it
Alexa-Hue Bridge Thread Debug Broadcaster.__init__ is running
Alexa-Hue Bridge Thread Debug Broadcaster.run called
Alexa-Hue Bridge Debug responder thread is not alive, starting it
Alexa-Hue Bridge Thread Debug Responder.__init__ is running
Alexa-Hue Bridge Thread Debug Responder.run called

It seems the hue can't find the server, if I leave the real hue bridge on it finds the >27 devices. If I power it down it finds none. The Hue is 192.168.1.197, the Macmini server is 192.168.1.99 they are on the same subnet and same wireless SSID.

from the other suggestions, I typed these from terminal:

www:~ teddie$ lsof -i :1900
www:~ teddie$
www:~ teddie$ python
Python 2.7.10 (default, Oct 23 2015, 18:05:06)
[GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.59.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> socket.gethostname()
'www.colgates.com'
>>>

Before I had quit sonos, It was listening on port 1900
www:~ teddie$ lsof -i :1900
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
Sonos 40004 teddie 25u IPv4 0x5fe813f32fd0796d 0t0 UDP *:ssdp

but I had quit it.

Is the host name messing it up? DNS might have a different IP for www.colgates.com - as I am not using it anymore. Might that be the issue? I too am running OS X server.

Thanks for all your help.

[tedco]

After much tinkering and a few restarts and updating my OS X server app (and giving my mac a .local hostname) everything seems to work. Thanks Jay for this! I'm very excited.

[jay (support)]

Is the host name messing it up? DNS might have a different IP for http://www.colgates.com - as I am not using it anymore. Might that be the issue? I too am running OS X server.

As you found, yes, that's the problem. The plugin uses one of the recommended ways of getting the local IP, which first gets the host name then gets the IP for that host name. Since yours wasn't resolving on the local network, essentially the binds were doing nothing.

[jeffgtx]

been using this for a week. very awesome. its so great to just ask alexa to do something than hunt for my phone.