search

bwssytems / ha-bridge

Home automation bridge that emulates a Philips Hue light system and can control other systems such as a Vera, Harmony Hub, Nest, MiLight bulbs or any other system that has an http/https/tcp/udp interface. This is a compact impl to run on small format computers. This is impl started from this project https://github.com/armzilla/amazon-echo-ha-bridge.
Apache License 2.0
1.45k stars 198 forks source link

Request: Trigger different URLs based on requesting device #131

Closed brandoncorry closed 7 years ago

brandoncorry commented 8 years ago

I have a couple echo devices in my house, and I've set up things like 'lights' as items in ha-bridge. It would be great if I could have a different item triggered based on the requesting device somehow (maybe user agent?). This would enable me to be in my living room and say "turn off the lights" (and the living room lights would go off); however, if I say the same thing "turn off the lights" while in my bedroom - where the other echo is, it would turn off the living room lights.

bwssytems commented 8 years ago

One way to handle this is to run multiple bridges and sync a certain bridge with a certain echo and then the device names can be the same. Just a thought to start with.

brandoncorry commented 8 years ago

I had originally thought of that and was going to give that a try, but I believe it has a downside... Every time I make a change, I'd have to turn off one of the bridges, connect devices with echo1, then turn off the first bridge, turn on the other, connect devices with echo2, etc. Is there some other way to prevent an echo from seeing both bridges?

bwssytems commented 8 years ago

This is something I can put in the backlog of enhancements to work on. Just trying ti give you a quick solution until I get to it.

brandoncorry commented 8 years ago

Will give it a try. Appreciate you taking it into consideration. Thanks a ton for this project - must have for any home automation with the Echo.

brandoncorry commented 7 years ago

So now that Amazon is releasing the new Echo Spatial Perception technology so that people will have multiple echo in their house. I think this feature may become more valuable. I was thinking that in the short term just providing a variable (like the dim value) in the on/off/dim commands that would provide an identifier would be sufficient as I could then use HomeSeer to handle the if/else logic of which decide to turn off on.

Example. In HA Bridge I would have a device called light

In the on/off commands I'd have it call http://server/lights?command=on&echoDevice={echoIdentifier}

In my software I would have a function that would respond to the lights on command and logic to say turn on lights A if it is my living room echo, and lights B if it is my bedroom.

This would enable me to just say turn off lights and let my automation software handle the logic to turn on the lights based on which echo sent the command

Hope this makes sense.

As always keep up the awesome work. This is my favorite project for home automation on github!

bwssytems commented 7 years ago

I saw that announcement too. Will be looking into this.

taddat commented 7 years ago

Whoops, I see now that I created a duplicate issue on this.

This would be a GREAT feature. It would also eliminate the (relatively recent) issue with the Echo voice recognition where it has trouble recognizing which device you're referring to when both two devices start with the same word (e.g., kitchen lights and kitchen music) by allowing the names to be simplified to just lights/music/lamp etc.

bwssytems commented 7 years ago

The way I will be implementing this is there will be an address field available on a device, if it is empty, all echo's will get it in their discover. If there is a specific address in the field, it will only be given to that specific echo/device. So that any echo/device has only the devices that you want to control.

brandoncorry commented 7 years ago

I like that idea. Really excited for this feature to show up. I'd be happy to take private drops and help test it. This really sounds like a nice way to integrate this feature in to the architecture. Couple quick questions:

  1. By address do you mean IP/MAC Address?
  2. Will this also work with Google Home? (I am assuming yes since it is all 'address' based)
  3. Will HA-Bridge have any issues with having multiple items of the same name. i.e. 'lights'? I plan to have one 'lights' light per room I have a smart assistant device in.
bwssytems commented 7 years ago

Please test. So, it is a field that is available when you edit a device. It is an empty field if it is for all requesters or a comma separated list of IP addresses if it is to be filtered. Also, this version has the logic commands for count and delay available.

Grab it here: http://bwssystems.com/files/ha-bridge-3.2.2a.jar

audiofreak9 commented 7 years ago

@bwssytems, I loaded 3.2.2a on my RPi B+ and restricted one device to one IP:

  1. I did discovery with the Alexa app - all Echos (3) can control the "Requestor" restricted device. NOTE: all ha-bridge devices show as "offline" in the app, but controllable.
  2. I did discovery with each Echo individually - all Echos (3) can control the "Requestor" restricted device. NOTE: all ha-bridge devices show as "offline" in the app, but controllable.
  3. I forgot all devices in the Alexa app, then I did discovery with the Alexa app, no ha-bridge devices were discovered.
  4. I then tried discovery with each Echo individually (3), no ha-bridge devices were discovered.

The ha-bridge webpage is accessible and useable.

Downgraded to 3.2.2 on my RPi: All ha-bridge devices were discovered.

I can reload 3.2.2a on my RPi and turn on whatever logs you'd need. Let me know.

bwssytems commented 7 years ago

Hmm, I'll need to double check the requester filter logic

taddat commented 7 years ago

Thanks for all of your hard work on this.

I encountered similar issues - Alexa is unable to discover devices using this 3.2.2a.

Here is the output I got when I asked Alexa to discover devices. She discovered no devices.

2016-11-11 20:56:32,699 [main] INFO com.bwssystems.HABridge.HABridge - HA Bridge (v3.2.2a) starting.... 2016-11-11 20:56:32,933 [main] INFO com.bwssystems.HABridge.BridgeSettings

On Fri, Nov 11, 2016 at 6:28 PM, BWS Systems notifications@github.com wrote:

Hmm, I'll need to double check the requester filter logic

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/bwssytems/ha-bridge/issues/131#issuecomment-260079310, or mute the thread https://github.com/notifications/unsubscribe-auth/ARDd4G7JmPqk3CjoLL7hmZTajE3FeQslks5q9PoGgaJpZM4I9civ .

bwssytems commented 7 years ago

Yes, there is a bug. Thought I tested it better.

bwssytems commented 7 years ago

Fixes for requester filtering.

Grab it here: http://bwssystems.com/files/ha-bridge-3.2.2c.jar

audiofreak9 commented 7 years ago

@bwssytems, I loaded 3.2.2c on my RPi B+, the ha-bridge devices stayed online in the Alexa App. Then I restricted one device to one Requester Echo IP.

I forgot all my devices, then I did discovery with the non-Requestor IP Echos. They indeed were not able to discover the restricted device in the ha-bridge. It did not appear in my Devices in the Alexa App. None of the Echos could control the restricted non-discovered device (of course).

Then I did discovery with the Requestor IP listed Echo, it did find the restricted device during discovery. The Requestor IP restricted device now appeared in my Devices in the Alexa App.

However once discovered, ALL Echos could control the Requestor IP restricted device. The non-restricted Echo allows the other ones to control the restricted device, because it is now included in the discovered devices.

I think your approach may need to be one of restricting Echo commands by IP rather than during discovery.

bwssytems commented 7 years ago

That's unfortunate, that there is now a hive mentality as having the same name across different echos means there has to be different urls for the same name and id for the devices.... much more to implement. This may go on hold for a bit.

audiofreak9 commented 7 years ago

To name the lights in each room, I use the name of the room: Kitchen, Bedroom, Living Room, Dining Room, etc., so my command is "Alexa, turn on the ROOM NAME".

I do foresee an operating issue with naming devices the same name in each room, restricted by Echo IP. Right now I can turn on/off the Bedroom lights with ANY Echo in my home. If I moved to a generic device name, and restrict by Echo IP, I would only be able to turn on/off the Bedroom from select Echos. That would be a pain if I'm leaving my home, forgot to turn off my 2nd floor bedroom lights, but now I have to go upstairs so the Echo with the ability to turn them off can hear my command.

@bwssytems: BTW, as you already know, I greatly appreciate your continued unselfish work and support for the ha-bridge!

bwssytems commented 7 years ago

So, the idea for this is you have a device lights where there are multiple urls tied to an IP, when you tell the echo to turn on or off "lights" you would want to be the ones in the area of that echo. Then another device such as "room name" as you suggest that is visible to all echos to turn off that room from another.

audiofreak9 commented 7 years ago

Understood and agree. I would just need to run another instance or two of the bridge to have enough device limits.

spencerryan commented 7 years ago

I would imagine a somewhat simple way of doing this is to give your Echo devices DHCP reservations so each Echo has a known LAN IP, and then use the IP address of the request to map that to which Echo it came from. Maybe not the most elegant solution, but pretty straight forward and the logic shouldn't be difficult at all.

bwssytems commented 7 years ago

@spencerryan The idea is to be agnostic on the name of a device such as all rooms could have a ceiling light and you would call that "Ceiling" as the device name. Since all the echo's talk to each other about devices, we need to execute a different URL for the device based on the IP for the given name. THat is the issue. IF the echo's didn't have a hive mind, it is easy enough to have multiple devices of the same name and only introduce the device to an echo based on the IP when it discovers.

spencerryan commented 7 years ago

@bwssytems Right, I think you're looking at this from the wrong way. Have a single device ("Lets call it "Ceiling" as in your example). When the Echo's make the requests to the ha-bridge the request comes from whichever Echo is answering the voice request, and thus you see a unique IP address as the source of the request to ha-bridge. Then in ha-bridge you would say "If the Echo request came from IP 192.168.1.90 --->Use this On/Off URL, If the request came from IP 192.168.1.91-->Use On/Off URL 2" etc.

I hope that makes sense.

bwssytems commented 7 years ago

@spencerryan LOL... We agree! It is quite a bit of work that I am postponing for now. Trying to get other features in. Almost done with MQTT support.

taddat commented 7 years ago

@bwssytems it sounds like the approach you described would work very well (and would be ideal). Another (less elegant) option would be to simply allow the requesting Echo's IP address to be appended to a command, but at least with Vera it doesn't look like there's an easy way to parse out additional parameters from a scene control command (doing so apparently requires a custom http handler on the vera). That said, it would be easy enough to write a basic http server script to run alongside the ha-bridge to parse out the IP address and then send the appropriate command to vera (or other platform).

We're really looking forward to the point when we can just say "Alexa, turn on the lights" or "Alexa, turn off the music" in any room. With the new, cheaper echo dots, this is close to a reality.

brandoncorry commented 7 years ago

Agreed. I think this would be a good short term solution until the more complex options can be looked at further.

bwssytems commented 7 years ago

Hang on, It's coming in the next version. As it is the best way to have real "home automation".

bwssytems commented 7 years ago

So, have a way to do the filter by ip in the url description. Will be building a new UI due to this. For testing purposes, here is the format:

[{"item":"do this if echo A","filterIPs":"192.168.0.1"},{"item":"do this of echo B","filterIPs":"192.168.0.2"}]

for all callers, do nothing

if you want a list to be interpreted. (Do not mis this with individual filters if the ips are in that as it executes as a multi command.

[{"item":"do this if echo A or B","filterIPs":"192.168.0.1,192.168.0.2"}]

Grab it here: http://bwssystems.com/files/ha-bridge-3.5.1b.jar

audiofreak9 commented 7 years ago

3.5.1b won't start on both my test and prod RPi's

Active: failed (Result: exit-code) since Wed 2016-11-30 20:23:00 EST; 47s ago
  Process: 470 ExecStart=/usr/bin/java -jar -Dconfig.file=/home/pi/habridge/data/habridge.config -Djava.net.preferIPv4Stack=true /home/pi/habridge/ha-bridge.jar (code=exited, status=1/FAILURE)
 Main PID: 470 (code=exited, status=1/FAILURE)

Nov 30 20:22:05 raspberrypi systemd[1]: Started HA Bridge.
Nov 30 20:23:00 raspberrypi java[470]: Error: Could not find or load main class com.bwssystems.HABridge.HABridge
Nov 30 20:23:00 raspberrypi systemd[1]: habridge.service: main process exited, code=exited, status=1/FAILURE
Nov 30 20:23:00 raspberrypi systemd[1]: Unit habridge.service entered failed state.
taddat commented 7 years ago

I was able to run 3.5.1b without an issue, but I'm getting some weird behavior. I have on/off URLs defined for two rooms, using the IP address of the echos in those two rooms as the respective filter IPs.

When I say "turn on the lights" or "turn off the lights" in each room, sometimes it works (i.e., the lights in that room turn on/off), sometimes the lights in the other room turn on/off (the rooms are on different floors of my house -- so it is not an issue of one echo picking up the command vs the other), and sometimes nothing happens at all.

I dug through the DEBUG logs and it appears that the bridge is receiving a different "from" IP address, even when the command is spoken in the same room. I have four echos in my house. When the turn-on command is spoken multiple times from the same room, sometimes the ha-bridge thinks the command comes from one echo's IP address, sometimes it thinks it came from another, despite the commands being spoken in the same room, the same echo showing as received the command in the "history" section of the Alexa app, and the same echo saying "OK" in response to the command. All four of my echo's IP addresses have been logged as the "from" ip address in the ha-bridge logs on different instances, despite the command being spoken in the same room.

For example, the same command "turn on the lights" was said in the same room three times with the following responses:

Here, the "on" command did nothing, because the bridge thinks the command came from 192.168.3.160 (instead of 3.159, which was the actual receiving Echo) 11-30-2016 22:28:16.095 DEBUG hue state change requested: 2CxSmNslPIzpe2X8PAi5isvDXmtGlSOh0CYLm0u3 from 192.168.3.160 body: {"on": true} com.bwssystems.HABridge.hue.HueMulator 11-30-2016 22:28:16.124 DEBUG filter for requester address not present in list: 192.168.3.159 with request ip of: 192.168.3.160 com.bwssystems.HABridge.hue.HueMulator 11-30-2016 22:28:16.131 DEBUG filter for requester address not present in list: 192.168.3.166 with request ip of: 192.168.3.160 com.bwssystems.HABridge.hue.HueMulator

Here again, the "on" command did nothing, because the bridge thought the command came from 192.168.3.157 (again, instead of 3.159, which was the actual receiving Echo) 11-30-2016 22:25:27.728 DEBUG hue state change requested: 2CxSmNslPIzpe2X8PAi5isvDXmtGlSOh0CYLm0u3 from 192.168.3.157 body: {"on": true} com.bwssystems.HABridge.hue.HueMulator 11-30-2016 22:25:27.752 DEBUG filter for requester address not present in list: 192.168.3.159 with request ip of: 192.168.3.157 com.bwssystems.HABridge.hue.HueMulator 11-30-2016 22:25:27.759 DEBUG filter for requester address not present in list: 192.168.3.166 with request ip of: 192.168.3.157 com.bwssystems.HABridge.hue.HueMulator

Here the on command worked (spoken from the same room as the above examples, and well out of range of any other echos) 11-30-2016 22:26:53.102 DEBUG hue state change requested: 2CxSmNslPIzpe2X8PAi5isvDXmtGlSOh0CYLm0u3 from 192.168.3.159 body: {"on": true} com.bwssystems.HABridge.hue.HueMulator 11-30-2016 22:26:53.128 DEBUG executing HUE api request for network call: [{"item":" http://192.168.3.71:3480/data_request?id=action&output_format=json&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&action=RunScene&SceneNum=15 ","filterIPs":"192.168.3.159"},{"item":" http://192.168.3.71:3480/data_request?id=action&output_format=json&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&action=RunScene&SceneNum=50 ","filterIPs":"192.168.3.166"}] com.bwssystems.HABridge.hue.HueMulator 11-30-2016 22:26:53.133 DEBUG executing HUE api request to Http GET: http://192.168.3.71:3480/data_request?id=action&output_format=json&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&action=RunScene&SceneNum=15 com.bwssystems.HABridge.hue.HueMulator 11-30-2016 22:26:53.135 DEBUG Making outbound call in doHttpRequest: GET http://192.168.3.71:3480/data_request?id=action&output_format=json&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&action=RunScene&SceneNum=15 HTTP/1.1 com.bwssystems.HABridge.hue.HueMulator

It almost seems random which echo's IP address appears as the "from" IP address in the ha-bridge logs.

Is there any more info I can provide to help debug further? I hope this isn't an issue with the echo "hive" mind...

On Wed, Nov 30, 2016 at 8:24 PM, audiofreak9 notifications@github.com wrote:

3.5.1b won't start on both my test and prod RPi's

`Active: failed (Result: exit-code) since Wed 2016-11-30 20:23:00 EST; 47s ago Process: 470 ExecStart=/usr/bin/java -jar -Dconfig.file=/home/pi/habridge/data/habridge.config -Djava.net.preferIPv4Stack=true /home/pi/habridge/ha-bridge.jar (code=exited, status=1/FAILURE) Main PID: 470 (code=exited, status=1/FAILURE)

Nov 30 20:22:05 raspberrypi systemd[1]: Started HA Bridge. Nov 30 20:23:00 raspberrypi java[470]: Error: Could not find or load main class com.bwssystems.HABridge.HABridge Nov 30 20:23:00 raspberrypi systemd[1]: habridge.service: main process exited, code=exited, status=1/FAILURE Nov 30 20:23:00 raspberrypi systemd[1]: Unit habridge.service entered failed state.`

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/bwssytems/ha-bridge/issues/131#issuecomment-264050934, or mute the thread https://github.com/notifications/unsubscribe-auth/ARDd4NugiQKLO7kQEaQFYv50pa3N0HZwks5rDiHngaJpZM4I9civ .

bwssytems commented 7 years ago

Well, unfortunately, this looks to be "hive" mind in a sense. I'm wondering if when the phrase is "parsed" back at the amazon servers, it just selects round robin from the list that is registered. One way to find this out is to see if there is a pattern when you say turn on and off in the same room does it flip back and forth between the echo IPs consistently.

bwssytems commented 7 years ago

I wonder if Google Home's do this differently?

bwssytems commented 7 years ago

@audiofreak9 Works fine from the command line, check your file rename.

funkyac commented 7 years ago

@bwssystems, I can confirm that with alexa the issue above seems to flip IP's of registered devices back and forth in a consistent manner. out of curiosity I see other posts on this functionality going into v4.0, has the implementation of filtering out source changed on the SW in the latest beta?(have not tried it) or is this "issue" expected to be there with alexa until they change their implementation?

bwssytems commented 7 years ago

The impl has drastically changed to filter on the actuall call to the ha-bridge, rather than what devices are presented to the echo.

bwssytems commented 7 years ago

Mulitple Echoes, Amazon's take: https://www.amazon.com/gp/help/customer/display.html?nodeId=202013740

Using Multiple Alexa Devices

Alexa voice service works together with all of your Alexa-enabled devices. Some content and settings are shared across devices registered to your account.

Amazon Alexa devices are controlled with your voice or through the Alexa app. If you have more than one device using the same wake word, Alexa responds intelligently from the Echo you're closest to with ESP (Echo Spatial Perception), and performs the requested task. You don't need to say the wake word before your request on Amazon Tap, Fire tablets, and Fire TV devices.

To interact with a single Echo, Echo Dot, or Amazon Fire TV device, you can use the compatible Alexa Voice Remote (sold separately for Echo devices) or you can change the wake word.

Note: You cannot connect multiple Alexa devices to each other and play the same requested audio at the same time.

If you'd like, you can give each Alexa device a distinct name. To change your device name, go to Manage Your Content and Devices

Shared Content and Common Settings

If you have more than one Alexa device registered to your account, some of your content and settings are shared between the devices. In the Settings menu of the Alexa app, all of the content under the Account section is the same for all your Alexa devices, including:

Music and media Household profiles Smart home devices Flash Briefing Shopping and To-do lists Some content is not common between devices on the same account, including:

Alarms and timers Sounds Bluetooth connections Note: At this time, you cannot customize which content is available on specific devices. For example, music, skills, shopping lists are available on all Alexa devices registered to the same account as the content.

bwssytems commented 7 years ago

And another take, multiple homes and multiple echoes....

https://www.reddit.com/r/amazonecho/comments/494mx7/two_echos_two_houses_one_prime_account/

to differentiate with an Echo, you will need separate Amazon accounts for each echo.....

bwssytems commented 7 years ago

Closing as the code has been in place and the issue #386 considers the Amazon echo issue.