Amazon Echo to HA Controllers

[pete_c]

Nice to meet you again Zac!
 
Back then I would travel a lot for work stuff but only mostly went to FL for vacation (although work took me to FL for this or for that).
 
Geez now thinking back...went to Disneyworld when it first opened; met my wife (Panama City) and purchased these Disneyworld passports before I even had kids.  Well also got a ticket driving a bit fast (funny too it was a helicopter that caught me ~ 130 or so on 75) . Very cheap multipass per Disneyworld passport.  I did take my kids to Disneyworld every year until they were too old (well teens) - months old to around 15 or so...
 
Yeah here my Amazon Echo is still in the box.  That though I have 4 Securifi devices on my PFSense firewall each with their own internet connection. 
 
I want to connect the echo on its own wireless AP but have not had the time lately.  I do now have 8 Gb interfaces on my PFSense box.

 

[DeLicious]

If I understand correctly, the Echo can control Hue and Wemo directly now, so there's no need to try out the hack.

I subscribed to this topic because I really wanted to get an idea of what people really wanted out of the Echo, and where you think it's ultimate endpoint should be. Haven't seen any of that yet, but an entertaining thread nonetheless ☺

 

[jkmonroe]

The hack isn't to control Hue.  The hack emulates Hue to let you control devices that are not currently supported.
 
I think it uses HTTP triggers, so for something like CQC we could create a fake Hue device for Sonos, have that send an HTTP trigger to CQC to get the Sonos playing.
 
The above information comes from a read of the links; I haven't tried it personally.

 

[DeLicious]

Ah, I see... Thanks for the clarification.

 

[IVB]

I subscribed to this topic because I really wanted to get an idea of what people really wanted out of the Echo, and where you think it's ultimate endpoint should be. Haven't seen any of that yet, but an entertaining thread nonetheless ☺

 
In my humble but accurate opinion, from a user perspective the endpoint for a voice recognition scheme such as the Echo should be an alternative form of manual execution of home automation tasks with far-field mics that are always on.  Any further than that is dangerous from a transferability perspective. It must have the ability to call any home automation system.
 
The reason I say that is for abstraction purposes. You're not locked into the Amazon system, nor required to purchase a device from a single manufacturer (Kinect or Amazon).  You can execute tasks that run in whatever home automation system you have, be it software based (CQC, HomeSeer, Premise, Girder, Elve, other) or hardware based (C4, AMX, Crestron, Cortexa, ...).
 
That would require either a hw or sw based controller/designer of the Echo, or perhaps a built in web server with the configuration stuff built into the unit.
 
Now will that happen? No I doubt it, no reason for a far-field VR hardware manufacturer to do that. But it would be nice.

 

[ChrisCicc]

In my humble but accurate opinion, from a user perspective the endpoint for a voice recognition scheme such as the Echo should be an alternative form of manual execution of home automation tasks with far-field mics that are always on.  Any further than that is dangerous from a transferability perspective. It must have the ability to call any home automation system.
 
The reason I say that is for abstraction purposes. You're not locked into the Amazon system, nor required to purchase a device from a single manufacturer (Kinect or Amazon).  You can execute tasks that run in whatever home automation system you have, be it software based (CQC, HomeSeer, Premise, Girder, Elve, other) or hardware based (C4, AMX, Crestron, Cortexa, ...).
 
That would require either a hw or sw based controller/designer of the Echo, or perhaps a built in web server with the configuration stuff built into the unit.
 
Now will that happen? No I doubt it, no reason for a far-field VR hardware manufacturer to do that. But it would be nice.

 
I'm confused, you don't want to be tied to a Kinect to Echo, but you want to be tied to another device that a different manufacturer makes specifically for home automation voice control? There is a lot of engineering that goes into these types of devices. You can't just stick a MEMS mic on a PCB and call it a day. Between the SNR, the layout of the mic array, beamforming, noise reduction, and other signals processing that all happens before we even start talking about speech recognition, there's a lot to it. 

 

[jkmonroe]

No, he's right; something like the Echo needs to be a drop-in. 
 
Take the Hue bridge, for example - it has native support for any number of mobile apps, full web support, can be easily integrated into third party HA platforms, has an IFTTT channel, bulbs can be controlled locally, and is supported by Echo.  Anytime a change is made to one of my bulbs, every other device that connects will know it.  So who cares where the change is made - I can use a Hue Tap, use the iConnectHue iOS app, use a CQC event, yell at Alexa, use the Philips iPad app, or the Harmony Hub, or test out openH@B without interruption, etc ...
 
But, without the Hue bridge acting as the universal translator for all of the rest, none of the above is really possible.  So I think this is what he is after - if the Echo (or other devices) could natively throw out universally accepted commands like HTTP triggers, then the device itself becomes portable and wholly compatible with any platform that accepts incoming HTTP triggers.

 

[ChrisCicc]

The Kinect can do that, but he doesn't want it?

Plus, the Alex AppKit is coming soon...

 

[IVB]

I'm confused, you don't want to be tied to a Kinect to Echo, but you want to be tied to another device that a different manufacturer makes specifically for home automation voice control? There is a lot of engineering that goes into these types of devices. You can't just stick a MEMS mic on a PCB and call it a day. Between the SNR, the layout of the mic array, beamforming, noise reduction, and other signals processing that all happens before we even start talking about speech recognition, there's a lot to it. 

 
You need to look at this from a user perspective, although looking at something from other than your own viewpoint seems to be an issue. I don't give a rats ass about beamforming.  What I know is that after 10 years of doing HA, and in the middle of a very lucrative career helping companies course correct after other companies change tack, binding ones entire investment to a single manufacturer is foolish.  
 
Technology gets commoditized over time. What once was unique & difficult is now commonplace. VR might be difficult today, but in 5 years nobody knows what problems will have been addressed and available on a single chip. When WiFi came out it was troublesome to get working right. Now we're talking about the internet of things, even some freaking SD cards have built in WiFi. No matter what the market share or units sold of any given device is, the future of any given company is tenuous. Ask Xerox, Kodak, DEC, IBM PCs, Atari.
 
People who align themselves to a single manufacturer are playing with fire. My wife has grown to accept that her beloved iPhone will always be 1-2 years behind my android for functionality, but fortunately Apple has a large enough R&D bucket to keep close. Will that be true for any given VR manufacturer? I doubt it, its not a large enough percentage of revenue to spend a bazillion. iOS/iPhone hardware is AAPL's profit driver they have no choice but to innovate.

 

[IVB]

The Kinect can do that, but he doesn't want it?

Plus, the Alex AppKit is coming soon...

 
I *own* a Kinect. But, I have no way of connecting that to a true home automation controller (see definition above). The question was the end goal, my end goal is to be able to have an abstraction layer between VR, HA controller, devices under control. A many:many:many mapping, so the choice is mine.

 

[ChrisCicc]

I *own* a Kinect. But, I have no way of connecting that to a true home automation controller (see definition above). The question was the end goal, my end goal is to be able to have an abstraction layer between VR, HA controller, devices under control. A many:many:many mapping, so the choice is mine.

 
VR, that is, speaking words and getting the translated text back, is already being commoditized. That's here today. The ability to connect it to, or more specifically, use it with, home automation via an abstraction layer, is exactly what we do. 

Everything is a hardware and software service stack. It's the combined end user experience that's what you care about. But to get there, we need to do this: 

MEMS mic > mic array > beamforming > noise reduction > signals processing > speech recognition engine > dialect detection > recognized text > context detection > command breakdown > automation controller abstraction layer > home automation controller > protocol translation > device command sent

While some components are and will be commoditized, the combined architecture won't be commoditized anytime soon...

 

[jkmonroe]

MEMS mic > mic array > beamforming > noise reduction > signals processing > speech recognition engine > dialect detection > recognized text > context detection > command breakdown > automation controller abstraction layer > home automation controller > protocol translation > device command sent
 
this part needs to be standardized.  it's what (at least) I was trying to say - if that was something universally accepted like HTTP, then VR opens up to the masses.  As it stands right now, it isn't.  
 
I don't disagree that the technology is there, but not many will do a whole platform switchover to gain voice functionality.

 

[IVB]

MEMS mic > mic array > beamforming > noise reduction > signals processing > speech recognition engine > dialect detection > recognized text > context detection > command breakdown > automation controller abstraction layer > home automation controller > protocol translation > device command sent
 
this part needs to be standardized.  it's what (at least) I was trying to say - if that was something universally accepted like HTTP, then VR opens up to the masses.  As it stands right now, it isn't.  
 
I don't disagree that the technology is there, but not many will do a whole platform switchover to gain voice functionality.

 

 

[ChrisCicc]

MEMS mic > mic array > beamforming > noise reduction > signals processing > speech recognition engine > dialect detection > recognized text > context detection > command breakdown > automation controller abstraction layer > home automation controller > protocol translation > device command sent
 
this part needs to be standardized.  it's what (at least) I was trying to say - if that was something universally accepted like HTTP, then VR opens up to the masses.  As it stands right now, it isn't.  
 
I don't disagree that the technology is there, but not many will do a whole platform switchover to gain voice functionality.

 
That's what Thread and Weave etc are hoping to ultimately accomplish. Until then, it's proprietary.

Internally, we're having discussions how far do we want to take it. Should we build plugins Control4 and the like?

 

[jkmonroe]

... My wife has grown to accept that her beloved iPhone will always be 1-2 years behind my android for functionality ...

 
You're like a kid standing next to a fire pit with a bottle of lighter fluid, aren't you?
 
:axe: