We made a simple demo for a client that requires to drive a motor from an app over the net and we tough to share it (using a common motor for this demo, not the one from the client) as example of what can be done with few lines of code.
The video: http://vimeo.com/58767158
How it works: the Imp connects to the Internet (trough our office’s WiFi) and wait for data. Is programmed to activate a motor driver while receiving commands from the web. The small app that you can see in the video running on a Galaxy Nexus is a simple web page in PHP. It sends to the Imp the speed to be assigned to the motor, in a range between 0 and 1 with 0.1 steps.
In the planner we created an instance of “http listener” and associated it to the Imp:
Here is the code we used:
What we do here is to tell the Imp that the pin 9 must be set as PWM output, to keep listening the web server for the parameter “speed” and to transfer this information to the motor (pin 9) every time a new value of speed is received.
The simple app running on the mobile as webpage:
Because the http listener from Electric Imp supports only the POST as method to send the data, we used a very simple trick executing a wget command with the parameter passed with the call, so we can actually send the data to the server and at the same time keeping the control of the page.
Because the http listener from Electric Imp supports only the POST as method to send the data, we used a very simple trick executing a wget command with the parameter passed with the call
because the purpose of this demo it was not actually important to deal with security aspects, as the page was required to run just the time of shooting the video.
I think that for simple experiments the shell_exec can be the a simply way easy to afford for almost anyone. It will require to write much more code to obtain the same result with JS and AJAX, I suppose.
With the use of agents it will probably change the whole thing and the approach will be different and more secure I believe.
Regarding the “HTTP in” planner node…
It does actually seem to also support GET requests.
@qunuq, at the time we made this demo apparently the only method accepted it was the POST.
I can actually see from the devwiki (http://devwiki.electricimp.com/doku.php?id=httpapi) that both the methods are mentioned but in the planner I still can see only the POST method in the settings.
Maybe @Peter, that’s also the last one updating the devwiki, can make the things clear to us.
You can easily verify for yourself what’s going on, by making an “HTTP in” node and connecting it to a “Show input” node. Then GET commands, as simple as
will appear on the “Show input” node. (Of course you’ll need to use your own node’s magic URL instead of the “…”.)
Independently of the GET versus POST debate, there is an issue with “same origin policy” that prevents an AJAX solution from working if the html page is hosted on a server. If the html is loaded from a local drive, the AJAX solution works for POST data to the HTTP In node on the planner. I would be interested in possible workarounds that will enable AJAX to work because that is the easiest way to get an “app” on the iphone by using an HTML page to communicate with the imp. Hopefully the new Agents make things easier.
Ajax works from different origin Chrome complains but the request goes through to planner/imp I’ve had it working with JQM on iOS. //Chrome JSconsole
XMLHttpRequest cannot load https://api.electricimp.com/v1/2xxx/xxx. Origin https://xxx.co.uk is not allowed by Access-Control-Allow-Origin.
I can share my JQM & imp code but it’s not very good as am not a programmer!
@controlCloud, I would be interested in seeing what you did.
Try not to laugh too much
Just tried it works on my iPhone. Someone has written some Squirrel that takes a single json value and drives relevant April output.
Nothing wrong with your code, cloudControl!
I also found out that it actually works with Ajax requests in spite of the “same origin policy” error reported. I tested both GET and POST and it works fine with both Safari and Chrome. So I just ignore the error. You can see my code, which uses jQuery to post data, here. But oh how nice it would be with a clean and proper RESTful api.