Hi Forum,
While this may be better directed at the Ubidots community, I’m wondering if any Particle people have tried to use the Ubidots switch to enable a particle function. I’m thinking something along the lines of the particle “Control LEDs over the net” example as a function. Turn on the Ubidots switch on your dashboard – light the LED on the Photon. If you create a Ubidots variable, with a switch widget – then create an event condition whereby when the switch is on (greater than zero) a url is enabled that includes a POST method payload that will enact the particle function (led, in the example). In the Ubidots Event creator, there is an option for the switch (associated with a Photon as the device) to create a “Webhook” (not a Particle Webhook, right? so a bit confusing) – and when selected it gives me options for the URL, and Payload – it also gives options for headers as JSON – but really out of my league here.
I tried variations of the URL configuration from the LED example as shown in the attached image – but nothing happens. I confirmed I have the code right at the Photon end using the html script and @ScruffR ‘s excellent POSTMAN example – but would really like to use the Ubidots switch.
Anybody done this? Or if anyone can give me some direction, I’d greatly appreciate it. If this is a matter of me doing some homework, I’d be happy to put in the time if someone can point me in the right direction.
Regards,
Chris
Hey @DRCO this is a great idea, didn’t think of this combination of functions before.
According to Particle’s docs your function should work, however it’s not clear to me if the curl command “-d arg=“on” -d access_token=1234” is equivalent to the body you are sending.
Hi @aguspg, Thanks for your response. I tried your suggestion and a few variations of / \ after and before the access token - and removing or including the -d in the body, but no success. It also strikes me that there in that there is no provision to turn the LED off when the switch changes state - though I guess a second event associated with the switch would resolve that problem.
Let’s check the headers…when doing the Postman example, do you have to set a specific “Content-Type” in the header? or does it work without any header?
Hi @DRCO after playing with Postman I found you can click on “Preview” to see how the HTTP request really looks like. Click on it, you will see that the actual body being sent is arg=led&token=12354, this is what you should put in the Ubidots webhook event body.
Hi @aguspg, thanks again for the follow up - but I’m really confused. Firstly, my POSTMAN setup looks nothing like yours, and doesn’t have a preview button. Mine is based on the example by @ScruffR - shown on this post. Also, if the arg=led, what is the parameter for turning it on or off? Lastly, by the Ubidots “event body”, do you mean the field called “Payload”?
I suggested to look at it as a way to learn the concept of an HTTP request and what it sends to Particle.
The “arg” depends on your function. I had just wrote a random string. In your case it looks like it should be arg=on or arg=off
Yes, by event body I mean payload. So look at the “Preview” in Postman, it should read something like access_token=xxxxxxxxx&arg=“on” this is your HTTP Body for the Ubidots event. Once it works, you’d create two events; one to turn it off, another to turn it on.
Hi (again) @aguspg, the preview button you highlighted only strips down the response - not the request. I’d tried it as per your previous advice - and it seems a shortcoming on Postman’s part - as the other “builder” format you were using clearly has a preview capability. I tried reformatting the Ubidots event format as you suggested (see attached image) with variations of a ? after /led in the URL and inverted commas on the arg=“on” without any success so far. Will do some more homework, as this capability on Ubidots would be a great benefit to a project I’m working on. Thanks for your help.
I’m basing my test on the Particle example, “[Control Leds Over The Net][1]” [1]: https://docs.particle.io/guide/getting-started/examples/photon/#control-leds-over-the-39-net which uses “args” - not “arg”. args also works in the Postman example, so I assume it’s correct.
I also tried hurl.it, which better depicts the structure and am getting some progress - if I append the token to the URL with & as follows: https://api.spark.io/v1/devices/deviceID/led?&access_token=MyToken
and add the args=on (and variations with inverted commas) I get through to the Photon, but the response is
{
“id”: “My correct Device ID”,
“last_app”: “”,
“connected”: true,
“return_value”: -1
}
The LED does not come on - as the -1 return value suggests - but I’m getting somewhere. I tried varying the Ubidots Event as above, but no LED - I suspect it’s also returning -1
Just an update, : as per the particle documentation, the & in the URL is not neccessary, I get a connection with https://api.spark.io/v1/devices/MY DEVICE ID/led?access_token=-MY TOKEN
This has become a longish thread and I must confess that I have not followed all of it. If this was my problem, I would create a temporary request bin at
Thanks @bko, I’ve had a go at your suggestion using the Postman service, which does work with the Particle Flash Led example code - and the Ubidots Event API, which (for me) doesn’t. In the request URL (in the example) there is a /led? at the end of the URL. I can’t add this to the requestbin URL as it won’t capture anything (no such server exists, right?) OK - so if I remove the /led? and send from Postman - Requestbin shows the following:
Clearly the RAW body stuff is the same - but the other Form/POST parameters are very different.
I post this to the forum as it may help someone else, I guess this is really something more suited to the Ubidots forum - so thanks for your help - and thank you also to @aguspg. I’ll have some of my collegues look at this and if I get a solution for Ubidots I’ll post it here - otherwise I’ll be looking at an alternative to the Ubidots switch to trigger my Particle function.
All the best,
Chris
Your particle one has “led” before the access_token.
But the problem is likely the missing Content-type: application/x-www-form-urlencoded header in your particle event.
Which is why requestb.in is not parsing the arguments as form fields.
Thanks @MORA, I tested with requestbin, and managed to emulate the same output as my (sorry, @ScruffR 's) successful POSTMAN setup - then added the appropriate header in the Ubidots event builder as you suggested and it works. Yay, I can control a LED using the Ubidots Switch! Greatly appreciate your pointer, the input from @aguspg and the great suggestion from @bko. Mostly, thanks everyone for your patience. For the record - the Ubidots setup looks like this…
And for anyone with my level of internet communications skills (ie: none) - you will have to format the Ubidots event builder as follows:
1)Add the appropriate device information into the URL, ending with /led?
2)Add the Token and Args info as per the image
3)Click the orange coloured “+” button to add a header
4)Manually type in “Content-Type” in the field that has “Content-Type” by default
5)Add the line “application/x-www-form-urlencoded” into the field that has “application/json” in it by default.
And the particle LED code example will work from the Ubidots Dashboard switch widget.
I just got done creating a switch in my Ubidots Dashboard and that switch would control a Ubidots variable which would be 0 when the switch was OFF and 1 when the switch was ON.
Then I used the Ubidots library to do a Ubidots GET request for that switch variable and that GET request would return the switch status of 1 or 0 based on the state of the switch in the Ubidots dashboard.
I used this code to trigger a PIN high or low based on the switch state and that PIN controlled a Relay to switch higher power devices. You could do the same thing to switch the LED.
Here is what the code looked like for the GET request and PIN state change on the Microcontroller.
float value11 = client.getValue(ID11);
Serial.print("Switch State = ");
Serial.println(value11);
if (value11 == 1.0) {
// turn LED on:
digitalWrite(Relay, HIGH);
}
else {
// turn LED off:
digitalWrite(Relay, LOW);
}
Hi @RWB, I think your version is more reliable. Assuming the GET request is part of the program cycle, it is constantly updating the Photon on the status of the Ubidots switch. The advantage is that if power is lost at the Photon end - and then restored the output (LED state) will be renewed. With my version, if power is lost and restored the default state of the LED (off) is returned - so I’d need to firstly know that power had been lost at the Photon end - and turn my Ubidots switch off and on again to restore the LED.Like you, I’m using the output to control a higher voltage power source (using a MOSFET, rather than a relay). So I’ll possibly look at adopting something more like what you’ve done.
