Playing around with Amazon Echo (technical interface discussion)

Have you watched the movie “Midnight Express”?

“Honestly, officer, I was just carrying this bag someone gave me. I never looked inside it and don’t even know how to open a jar. I know nothing!”

Cue sound of jail door slamming shut…

:wink:

I installed the bridge on an old Raspberry Pi and ran the Java command to start it from a terminal window remotely, my echo picked up the new devices and worked great. I closed out the terminal window and everything still worked (I think) but when I tried again later to use it it could not find my devices. I checked the app and they all showed offline. I rebooted the Pi and started the Java command again and they still did not show as being online. I then re-ran the device discovery and all is good now.
I guess my questions are:

  1. if the echo bridge goes down shouldn’t the device automatically go back online when it’s restarted without having to discover them again?
  2. what would cause them just to go offline like that after a certain period of time?

I thought it was maybe because I issued the command remotely through a terminal window and then closed the terminal but if I remember correctly it still worked after I closed it the last time.

I’m still very new to Linux and the PI for that matter so any input you can give will help.

Thanks,
Scott

Try to say ‘Alexa tell smartthings to switch sunroom to on’ let me know if this helps? I’m still trying to figure out the best way to say things…

Yes, I have taken my raspberry offline several times with no issues.

I don’t know but I did find on one occasion my Echo suddenly had 5 devices I never configured that must have been from someone else’s config. I don’t know if glitch on their cloud side of things or what but I used the echo “Forget” to clear all and just rediscovered. That was a month ago and things have been stable since.

What do you see when you look at connected devices in the echo.amazon.com site ?

If you find any junk in there like your old configured devices then clear them and rediscover.

Are you using my code which is integrated with the Smart App or armzilla’s original POST version ?

If mine then is it possible you opened the Smart app and changed the approved devices ?
Actually thinking about it that would affect armzilla’s version also.

1 Like

@Ron, thanks.
I am running armzilla’s version. On the Amazon site I saw both my devices but they showed Offline. When I re-ran the discovery I expected it to duplicate them but it did not and just connected them back up.

Another problem I am having is running it at startup. I am a linux newbie and the command I used to start manually is:

java -jar -Djava.net.preferIPv4Stack=true amazon-echo-bridge-0.2.0.jar --logging.level.com.armzilla.ha.upnp=INFO --logging.file=ha.log --upnp.config.address=192.168.1.101 >log.txt &

I am having a heck of a time getting it to load at startup. I tried rc.local but it does not seem to be working. Can you give me an idiot guide to that :smile:

My version of the code has an install script which installs the program for startup and an uninstall script to remove it. I programmed it on the raspberry. So you can look at that or switch to my version. I just added the ability to talk to the smart app so you don’t have to use the Post method. You do need to port forward to your raspberry for this to work which is done on your router. After you configure it you can then shut down the port forward.

The script I wrote should work with armzilla’s version also. So feel free to just borrow the install script if you like. :smile:

2 Likes

I did find out that manually starting it and then closing the terminal was ending the jar that was running, I’m still learning :smile:
I wound up creating a bash script with my Java command in it and put the script path in rc.local. This did get it to run but for some reason launched the jar file twice and when I checked the bridge configurator it did not show any of my devices.
I had to leave so I will try again when I wake up.

I had a similar issue when I was running on my Apple Mac, closing the lid, sleep, nothing works :smile:

Is you look at the install script here https://github.com/gouldner/amazon-echo-ha-bridge/tree/smart_things_raspberry_mods

checkout the installService.sh

If you configure things like this shell you can check the server using the following
/etc/init.d/echoStBridgeService status
/etc/init.d/echoStBridgeService start
/etc/init.d/echoStBridgeService stop
/etc/init.d/echoStBridgeService restart

1 Like

I think I am going to just “forget” the devices I have and install your code basically just to start over from scratch.

Ok, I think I may have gotten it. I tried one more time with what I had.
I now have a bash script (bridge.sh) in /home/pi/echobridge with:

#!/bin/bash
java -jar -Djava.net.preferIPv4Stack=true /home/pi/echobridge/amazon-echo-bridge-0.2.0.jar --logging.level.com.armzilla.ha.upnp=INFO --logging.file=ha.log --upnp.config.address=192.168.1.101 >log.txt &

and in /etc/rc.local right before the “exit 0” line I have :

 /home/pi/echobridge/bridge.sh

before I had:

sudo /home/pi/echobridge/bridge.sh

which caused duplicate copies of the java process to run. Not sure why as I am still learning but it works now :smile:

The only other hiccup I had was once I started using the script at startup my “data” folder was recreated in the root instead of /home/pi/echobridge (which is where the jar file is). Im sure there is a reason and a way to fix it but im not worried about it since its working :smile:
I am posting all of this on the off chance it helps someone else.

Thanks for all the help and guides.

Scott

That’s because this is where it was run from. Add a cd into the directory where your data file is and that would fix it.

#!/bin/bash
cd /home/pi/echobridge
java -jar -Djava.net.preferIPv4Stack=true /home/pi/echobridge/amazon-echo-bridge-0.2.0.jar --logging.level.com.armzilla.ha.upnp=INFO --logging.file=ha.log --upnp.config.address=192.168.1.101 >log.txt &
2 Likes

Great…thanks. I knew it was something simple.

What “words” can be used with the hue bridge hack? I know “Turn” is one of them like Turn on light but can any other words be used like switch on? I tried searching for this but could not find it, I was looking for a list of acceptable commands. I also see the “deviceType” is switch but I assume that is the only device type that can be used since it a hue bridge, correct?
I have my lights currently on this and added my central music system (windows PC) to it using EventGhost to catch the url. So basically I can say “Alexa, turn on livingroom music” and eventghost will simulate a CTRL+P to start playing the playlist I already have queued up and turn on the living room speaker. I also have the off/stop command, pretty cool.
Combining this with Eventghost opens alot of possibilities! I guess until they shut it down :frowning:

I am just trying to get other ideas of what else I can do.

1 Like

I’ll bet there’s help on the Echo Dev Forums, but these work for me:

  • turn x [on / off]
  • switch x (it defaults to on, not toggle)
  • x [on / off]… This is nice short phrase!
  • various dimmer phrases…
1 Like

I didnt even think of this one, thanks!

Ill check the dev forums too.
Thanks,
Scott

1 Like

Thanks a lot for proving the code and all the hard work. How does the dimming command work for lights, and how about fan will the dimming command work similarly on the fan too?

Just be aware that it’s likely that that method will be shut down sometime in the future, perhaps as early as the fall.

You’ve mentioned this a few times in a few threads. I know you’re pretty well connected into these sorts of things - do you have any reason to suggest that this is true? I ask because “Clean room” reverse engineering is well-tested both in practice and in US law. There have been Hue emulators of one flavor or another going back at least 2 years now with no sign of a reaction from Philips.

No developer needs to abide by a TOS to reverse engineer a communications protocol and the DMCA specifically allows for emulation for compatibility purposes. This has been tested over and over again, and the courts have agreed that reversing a protocol for interoperability is fair game.

Finally, if Philips decides that they want to change their API in some radical way such as to prevent existing systems from working with their hub, they’d be destroying the entire existing ecosystem of applications and integrations.

So - are you basing this on some inside knowledge, or is this just a guess? I do not see any feasible technical or legal approach for Philips to put this cat back in the bag.

2 Likes

Just guessing based on work for the new “trusted WiFi” stuff that’s being done in preparation for iOS9 and HomeKit. A lot of loopholes are being closed in preparation, and the emulator is a huge loophole.

It doesn’t require any legal action to shut the emulator down: just some kind of undisclosed ID exchange between a real Philips bridge and Echo (or anyone else Philips has arrangements with).

The physical Hue Bridge will be modified in preparation for HomeKit, that’s already been announced by Philips. They’ve also said there will be some kind of upgrade path for existing devices, but no details on that yet. It’s certainly a perfect opportunity for Philips to change their identifying method should they choose to do so–and not to release it.

It’s important to remember that the Hue emulator hack is not reverse engineering of any kind. Philips created the emulator code and gave it away, with restrictions, for developers to use. But specifically not to use to spoof.

Philips doesn’t have to continue to provide an emulator–at this point they have enough marketshare to tell developers to just buy the real thing to test with.

It’s very likely the emulator won’t work for HomeKit anyway, obviously.

So no secrets and no certainty, but with publicly announced changes to the Hue Bridge already coming this fall, the emulator’s future path does seem unclear. We’ll see.

2 Likes

Lets get #AmazonEcho #EchoSmarthingsIntegration trending on Twitter :smile:

It seems like outright disabling existing APIs (or adding an auth key requirement) will also simultaneously break all the 3rd party applications and device intergrations. I understand that future versions will have mFI for all the reasons Apple has stated (mostly, “pay us”). I also understand that Apple has said that they are going to somehow allow for existing Hue units to work, presumably due to the fact they’ve been hawking them in their own stores for a few years. So we know some sort of change is coming that will satisfy Apple from a security standpoint, and we also know that they aren’t easily satisfied. Having said that, do you really think they are going to tear down their entire existing ecosystem only to jump on the HomeKit bandwagon?

Finally, let me add that I am asking for your input here because you know more about this topic than anyone I have any contact with. Basically everything I know about Homekit internals comes from reading your posts and I’m always interested to hear about what you’ve seen and tried. Thanks!

1 Like