Amazon Echo to Oak

[Beenay25]

Has anyone been able to get an Oak to respond to verbal commands given to an Amazon Echo (or a dot)?

I'm pretty new at this and have tried some of the ESP8266 tutorials but usually get some kind of Oak specific compilation error.

Don't suppose anyone would know of a good beginners tutorial on the subject?

[exeng]

Your post triggered a search for possible answers and coming from this (Echo) as a complete noob it opens up a pandoras box. That said, what a great idea. Two places to start are (but only a start)..

https://developer.amazon.com/public/solutions/alexa/alexa-skills-kit/overviews/understanding-the-smart-home-skill-api

and

An example of someone using an esp8266 with Echo:
https://parglescouk.wordpress.com/2016/10/03/using-amazon-echo-and-esp8266-to-add-voice-control-to-anything/

Edit: Another link...
http://lisles.net/how-to-connect-echos-alexa-to-an-arduino/


I'm sure you'll find a plethora (wow haven't used that word in a long time) of information on the web. The trick is to sort the wheat from the chaff. I'm sure all the pieces are out there.

On a side note. I just acquired a polyphonic wav trigger and would like to put all my idle micros (digix, digisparks, oaks and others) plus idle sensor, displays and other devices to work in the form of a multi-sensing, speaking, stationary (for now) Frankenstein robot that is cloud / internet connected. A lofty goal but hey what a great learning experience and I can't stand to see idle parts. Now, you've got me thinking that I need to incorporate Echo.

Again, I'm a complete noob with respect to this application but interested in home automation, voice control and basically AI for dummies or is that dummy AI (oxymoron).

Please post and share what you find/do with us.

Yet another edit:
After doing some more research I've seen reviews that express security concerns with Bluetooth access and possible all the time listening being sent to the cloud. Not comfortable with that. Amazing how we allow these potential "intruders" into our homes for the sake of convenience.

[tcarleton]

I haven't done a direct AWS integration yet (for example, have Alexa read the temperature of the my house back to me).  I do have my oaks indirectly responding to simple verbal commands from Alexa. Perhaps this might be useful to someone.

The first takes advantage of Alexa, IFTTT and Particle integration, and is by far the easiest. By this I mean, if you've already created a particle function, then you are a wizard away from sending a trigger using Alexa. Connect Particle to your IFTTT account (and Amazon to IFTTT if you haven't already) and you can create IFTTT rules using the oaks as the source event or a target.  The available Amazon Echo event triggers are limited in my opinion, but the two I find useful are "Your Alarm goes off" and "Your Timer goes off".  Also, you don't have to depend on a separate event.  You can create a trigger phrase for Alexa that calls a function or sets an event to Particle and envoke by saying "Alexa, trigger phrase you create".

The issue I was trying to address was with multiple Amazon Echos, timers and alarms. If I set a timer, "Alexa, set a timer for 20 minutes", in 20 minutes the timer goes off on the echo that set the timer.  Even if I'm upstairs next to a different echo than the one I set the timer with the only audible response will be from the original Echo device that set the timer. IFTTT can trigger an event when the Echo's timer goes off, like blink a light, but it will only do it for one device, not a group, so I can't blink the house lights out of the box. The same is true for alarms.

But... If I created an IFTTT integration to Particle, Amazon also sends that event to IFTTT, IFTTT triggers a function on Particle, Particle sends that to the oak. Now I have an event on a device on my network in my house (my Oak) and I can control whatever I want. In practice, I've only turned on an LED.

My intention was to light LEDs or buzzers around the house when a timer goes off but I'm in another room. Specifically if the timer is supposed to remind me I've got soda in the freezer or a soldering iron is on.
The idea was to scatter the Oaks around the house to play with SUBSCRIBE/PUBLISH functionality but I haven't gotten to it yet.   

The second way takes advantage of Alexa working Phillips Hue bridges without going to the internet. I'm using Alexa to control the heater on my Radio Thermostat.  Amazon doesn't support it directly but it's REST API is well documented. Since I can turn a light bulb "on", "Off", and DIM it in values that are ranges I'd use for my heater or air conditioning, I have a way to set the temperature.  BONUS:  Alexa doesn't seem to care if you say "Degrees" instead of "Percent".

To do this, I'm using:

• A Phillips Hue Emulator, specifically HA-bridge (https://github.com/bwssytems/ha-bridge)
• A Raspberry Pi to run HA-Bridge on my local network. Nice way to leave this stuff running 24/7 without a full PC on
• An Oak with a red light plugged into it (I know, I'm lighting an LED again, but hang with me)

• I install Ha-Bridge somewhere
• Browse to HA-Bridge and configure a fake bulb called "heater"
• Edit the bulb and create HTTP/HTTPS requests (or run a script) for On, Off and DIM commands including distinct form data for each action including DIM data

"Alexa, Turn heater on"
https request to particle api, turns a red light on letting me know I'm in heater mode. I used to also send a command to place my heater in heat mode but I've found it pointless.
URL: https://api.particle.io/v1/devices/PutYourOaksDeviceIDHere/led?access_token=PutYourAccessTokenHere
Form Data:{"params":"on"}


"Alexa, Turn heater off"
(https request to particle api, turns a red light off)
URL: https://api.particle.io/v1/devices/PutYourOaksDeviceIDHere/led?access_token=PutYourAccessTokenHere
Form Data:{"params":"off"}

"Alexa, set heater to 76 degrees"
Sends an http request directly to my heater, enabling heat mode and  setting the temperature to the DIM value of the bulb ${intensity.percent}
Note that this doesn't actually turn the light on. It is possible to send two separate commands for the same action and turn the LED on at the same time but I'm still brainstorming ideas of monitoring the thermostat's state, especially since there are other ways the settings change (i.e. automatic schedules, iphone app).
URL: http://thermostat-on-my-network/tstat
Form Data:{\"tmode\":1,\"t_heat\":${intensity.percent}}


I haven't gotten to "Alexa, ask Particle what the temperature inside my house is" yet but its on the list. This one looks very straightforward using DHT22.  https://github.com/krvarma/Particle_Alexa

I'm getting a lot of mileage out of playing with Particle functionality. I've had weird some issues using "native" ESP8266 network libraries to use the Oak as a network client (odd temporary dropouts using UDP NTP libraries that work fine on my NodeMCU's, haven't noticed the same using them as web servers) but re-thinking how to trigger tasks using a cloud platform that conveniently integrates with several other cloud services has been pretty convenient. Yes everything stops working when the internet goes down but... I've already embraced Alexa so its kind of moot, and turning my heater on with Alexa was a happy accomplishment, even if the only "Oak" portion was turning a light on.

[tcarleton]

Just a quick follow-up - I modified krvarma's example (https://github.com/krvarma/Particle_Alexa) and setup my Alexa Skills Kit as "Thermostat" with three intents for sensor: "temperature, target and mode". On the Oak (using Particle IDE) I created "set" and "get" functions for each sensor. The values are updated externally so the Oak in this example is just used as Particle cloud target for three variables Amazon can see.

Each particle function's return value returns/represents the integer value of that sensor. In the case of "mode" it returns 0,1 or 2 so on the Lambada side I modified the speech result based on the result code .

Code: [Select]

    if (json.return_value === 0) {
        response.tellWithCard("The Thermostat is set to off", "Particle", "Particle!");
    }
    else if (json.return_value === 1) {
        response.tellWithCard("The Thermostat is set to heat", "Particle", "Particle!");
    }
    else if (json.return_value === 2) {
        response.tellWithCard("The Thermostat is set to cool", "Particle", "Particle!");
    }
    else {
        response.tellWithCard("I have no idea dude, but the json return value is " + json.return_value, "Particle", "Particle!");
    }

At the moment I can ask:

• Alexa, ask thermostat what the temperature is
• Alexa, ask thermostat what the target is
• Alexa, ask thermostat what the mode is (Yes I find that awkward to say)

Couple of things:

• I'm programming the Oak 100% using the Particle IDE for this. As such, I've had issues with basic things like getting Strings to work with Particle Variables (which I'm sure work using Arduino IDE) but the compile/flash times are so attractive I'm sticking it out for now. As such I haven't validated I can get Alexa to read dynamic text but I don't anticipate it being an issue beyond length. I haven't tried to return a double/float yet.
• I don't think I'm going to change how I set the thermostat to Cool or Heat. Using them as bulbs with HA-Bridge is terse. "Alexa, set heater to 75 degrees / set AC to 75 degrees". Two bulbs, two simple separate requests  that just parse the degrees.
  Imagine: "Alexa, ask thermostat to set heater to 75 degrees".  Forget parsing that, I don't want to add three words "ask thermostat to" to a request that works just fine.
• I ended up adding duplicate utterances for the three sensor types on the AWS side, again using krvarma's example as a template. I found myself constantly flubbing my interactions when the intent was "what is the {temperature|sensor} here" and I'd find my self asking "Alexa, ask thermostat what the mode is". In this case, it would launch the thermostat app, give a help menu that I customized and wait for my command. At this point "what is the mode" makes more sense that "what the mode is" so I duplicated them.
  

Code: [Select]

ParticleIntent what is the {temperature|sensor} here
ParticleIntent what is the {target|sensor} here
ParticleIntent what is the {mode|sensor} here
ParticleIntent what the {temperature|sensor} is here
ParticleIntent what the {target|sensor} is here
ParticleIntent what the {mode|sensor} is here


[PeterF]

Hey, sounds like fun! Almost with I had a Echo / Alexa... oh, wait, I don't... I don't need to invite government spies into my home willingly! 

Anyway, more seriously.... nice work on that... sound very useful!

When you say trouble with Strings and Particle variables... in what way... is it trying to get them registered, or to get them to update? I had issues getting them registered until I manually established the particle connection after defining all the variables, which gets around a bug in Particle where the variables need to be reported to Particle within 600ms or such such time frame after the initial connection to Particle. The other issue may result from the fact that variables are updated on demand only, so the frequency you poll for them will determine how quickly they update.

[tcarleton]

PeterF, yeah I'm going on the blind theory of "there's gotta be someone more interesting to watch/mess with".

No I literally mean getting strings to work with simple Particle.Variable examples using the build.particle.io web IDE.

Code: [Select]

int analogvalue = 0;
double tempC = 0;
char *message = "my name is particle";
String aString;

void setup()
{
  // variable name max length is 12 characters long
  Particle.variable("analogvalue", analogvalue);
  Particle.variable("temp", tempC);
  if (Particle.variable("mess", message)==false)
  {
      // variable not registered!
  }
  Particle.variable("mess2", aString);

  pinMode(A0, INPUT);
}

void loop()
{
  // Read the analog value of the sensor (TMP36)
  analogvalue = analogRead(A0);
  //Convert the reading into degree celcius
  tempC = (((analogvalue * 3.3)/4095) - 0.5) * 100;
  delay(200);
}
yields

Code: [Select]

oakstringsample.ino
/workspace/oakstringsample.ino:5:17: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]
 char *message = "my name is particle";
                 ^
Linking /workspace/oakstringsample.bin
/workspace/obj/oakstringsample.cpp.o:(.text.setup+0x24): undefined reference to `bool CloudClass::variable<char>(char const*, String const*, particle_core::CloudVariableTypeString const&)'
/workspace/obj/oakstringsample.cpp.o: In function `bool CloudClass::variable<particle_core::CloudVariableTypeString>(char const*, particle_core::CloudVariableTypeString::varref, particle_core::CloudVariableTypeString const&)':
/oakCore/cores/oak/OakParticle/OakParticle.h:99: undefined reference to `bool CloudClass::variable<char>(char const*, String const*, particle_core::CloudVariableTypeString const&)'
collect2: error: ld returned 1 exit status
makefile:141: recipe for target 'build' failed
make: *** [build] Error 1
mv: missing destination file operand after '/output/firmware.bin'
Try 'mv --help' for more information.
but perhaps that's more appropriate for the particle forums?

[PeterF]

No, that looks like a missing/wonky implementation on the Oak...

1) To get rid of the

Code: [Select]

warning: deprecated conversion from string constant to 'char*'
warning, this line:

Code: [Select]

char *message = "my name is particle";
should look like

Code: [Select]

const char *message = "my name is particle";
(a constant rather than a changeable message - as it really shouldn't change).


2) Now, for the

Code: [Select]

undefined reference to `bool CloudClass::variable<char>(char const*, String const*, particle_core::CloudVariableTypeString const&)'
it would seem that part of the implementation of the C++ variadic templates that allows it all to works is broken... It was mostly fixed back in Feb 2016, but the String handler function was missed... hopefully all it basically needs is to be moved from OakParticle.cpp to OakParticle.h... it compiles at least.

I'll do some testing it to see if it works... and if it does will push the PR in the next day or so so it can be incorporated in the main core, and then will hopefully make it onto Particle in the next release.

Edit: Yes, it appears to work, it just took longer as I must have done something to this Oak that made it not like OTA updates... kept b0rking itself so I did a serial upload instead.

[tcarleton]

Wow! Okay. I should probably rethink the use of variable vs function in that scenario then. I intended to try updating the string with small delimited values.

That said, it was more of an opportunity to work through another example of the example Particle apps and play with the differences.  "WEB-CONNECTED-LED" for example works just fine if you move the function above its first reference.

I did make a post https://community.particle.io/t/particle-variable-example-on-oak-fails-to-compile/28624 on the particle forum FYI.

[PeterF]

Oh, btw, I mean to point out before that the return value from Particle.function (i.e. if (Particle.variable("mess", message)==false) ) is useless... it doesn't actually indicate if the function was registered successfully. IIRC, tt only does a local check of the length of the function name (no more than 12 characters) and that's pretty much it. So it could return success and yet the function isn't actually registered. Just food for thought.