Mesh devices and Alexa Skill

Any one have any luck connecting Alexa with Particle Argon?

My code apparently works fine on particle photon, but not on Argon? Is this to be expected and something needs to change for it to work on Mesh devices? I am simply exposing a function to the cloud, and the making a POST request on AWS Lambda.

Based on what you describe, it should work, but without seeing your code it’s not really possible to say for sure. Can you post it here?

Hey @ParticleD! Thanks for your reply. Yeah i am a little confused as well on what i am missing. Since it seemed to be working fine on particle photon.

This is pretty much the code used in AWS Lambda

var sparkHst = "";

	var sparkPath = "/v1/devices/" + deviceid + "/caller";
	console.log("[LOG] Path = " + sparkPath);
	var args = 'add';
	makeParticleRequest(sparkHst, sparkPath, args, accessToken, function(resp) {	
		var json = JSON.parse(resp);

function makeParticleRequest(hname, urlPath, args, accessToken, callback){
// Particle API parameters
var options = {
	hostname: hname,
	port: 443,
	path: urlPath,
	method: 'POST',
	headers: {
		'Content-Type': 'application/x-www-form-urlencoded',
		'Accept': '*.*'

var postData = "access_token=" + accessToken + "&" + "args=" + args;

console.log("[LOG] Post Data: " + postData);

// Call Particle API

var req = http.request(options, function(res) {
	console.log('[LOG] STATUS: ' + res.statusCode);
	console.log('[LOG] HEADERS: ' + JSON.stringify(res.headers));
	var body = "";
	res.on('data', function (chunk) {
		console.log('[LOG] BODY: ' + chunk);
		body += chunk;
		console.log('[LOG] BODY: ' + body["error"]);

	res.on('end', function () {

req.on('error', function(e) {
	console.log('[LOG] problem with request: ' + e.message);

// write data to request body

and then i am exposing the function in the particle code.

 void setup() 
Spark.function("caller", controlled);

Thank you in advance for your help.

Sorry, we would need to see more of your code that’s running on the device. Are you running “stock” code that’s available on the web?

One thing you definetly want to change is getting rid of the legacy syntax
Spark.function() have been called Particle.function() for years now - sooner or later the syntax should get deprecated.

Also in your lambda, shouldn’t the definition of makeParticleRequest() be before its first invocation?
Where (when) are deviceid and accessToken defined?
What do you get in your console logs?

Hey @ParticleD, here is the complete code. Not doing anything fancy, just waiting for the slot add, if it comes the servo moves up and down, otherwise stays still.

    #include "Particle.h"
   Servo SlotServo; 
   Servo LockServo;
   int globalInt;

 void setup()  
Particle.function("caller", controlled);

int controlled(String alexa_Input_){

    globalInt =1;

    return -2;
      return 1;

void loop() 

 if(globalInt == 1){


@ScruffR Yeah i noticed the Particle.Function() as well, tried it as well to check if this made any difference, but got the same result. So went back to my original code.

the deviceid and access token are defined right above var sparkHst = “”;.

and for the logs, here you go.

“version”: “1.0”,
“response”: {
“outputSpeech”: {
“type”: “PlainText”,
“text”: “Ok add command has been made”
“shouldEndSession”: true
“sessionAttributes”: {}

Request ID:

Function Logs:
START RequestId: 234b8995-236d-4cf2-b22c-e1a59254d9c6 Version: $LATEST
2019-02-19T11:20:48.468Z 234b8995-236d-4cf2-b22c-e1a59254d9c6 session applicationId: amzn1.ask.skill.b********************************************
2019-02-19T11:20:48.468Z 234b8995-236d-4cf2-b22c-e1a59254d9c6 dispatch intent = Add
2019-02-19T11:20:48.468Z 234b8995-236d-4cf2-b22c-e1a59254d9c6 [LOG] Inside
2019-02-19T11:20:48.969Z 234b8995-236d-4cf2-b22c-e1a59254d9c6 [LOG] Path = /v1/devices/e**************************************************0/caller
2019-02-19T11:20:48.969Z 234b8995-236d-4cf2-b22c-e1a59254d9c6 [LOG] Post Data: access_token=************************************************f&args=add
END RequestId: 234b8995-236d-4cf2-b22c-e1a59254d9c6
REPORT RequestId: 234b8995-236d-4cf2-b22c-e1a59254d9c6 Duration: 714.27 ms Billed Duration: 800 ms Memory Size: 128 MB Max Memory Used: 87 MB

Have you double checked the device ID and also made sure you actually deployed your altered lambda, updated your ARN (in case it changed in the process) and rescanned your Alexa devices?

@ScruffR i created a test case in AWS Lambda. so even if there is an issue between alexa and lambda linking it should not matter…

and yes i have triple checked the device id.

I am guessing it’s an issue with Servo, which by the way I had never encountered before!! I’m like, “where’s the #include for this Servo thing?”

Have you verified that Servo works by doing a “local” test (i.e. with AWS Lambda being involved)?

Ahm …

But of course, you need to use a PWM capable pin (which D8 is).

Hey @ParticleD, yeah like @ScruffR pointed out that should not be an issue.

I have used the same pipeline countless times on the photon and havent faced any issues. So I am not why the Argon is behaving this way.

Yeah I know that now, I’d just never come across it before.

@muneebr1 re: Photon vs. Gen3 – it’s a completely different microcontroller so it’s an apple vs. orange thing. For one thing, the clock speed of Gen3 is just over 1/2 that of the Photon.

What kind of servo are you using?

@ParticleD 9g servo, i have already tested it individually to make sure thats not the issue and it works fine.

@ParticleD @ScruffR

So i luckily had a particle photon lying around so i tested, and everything worked fine. I also tested another particle Argon and it still dosent work.

At this point i feel like it was a big mistake upgrading to the mesh, i had a high hopes, but most of the libraries arent supported, the hardware itself has issues, and now this. :frowning:

I was working on a deadline which has been shattered completely, and now i have to redo everything with a different controller. :frowning: