PiBox » Iron Man

I don't have the current server-side RESTful interface documented nearly as well as I should. I'll put something on the wiki for this later. In the meantime, here is the way it should work for IoT devices based on what is already implemented in the PiBox Media Server.

• The Server accepts user input that specifies a command for one or more IoT nodes.
• The Server issues a wget to the node with a URL of the form: http://ipaddr/im?c=/vers/cmd/args
• The aRest library calls the im function, which parses the commands from c=...
• The command is performed and the result sent back as JSON text.
• The Server parses the JSON response and displays it (or calls Jarvis, etc.)

• im is for IronMan and is the function that gets called via aRest. Other functions would be possible here but we use a top level handler to allow future extension.
• c= is the command we pass to the im function
• vers is the version of the protocol. This allows IoT devices to respond with "unsupported" if not backward compatible.
• cmd is a namespace specific to the device, such as "fins" or "blinds" or "temperature".
• args are what to do within that namespace. They can be any number of name=value[,name=value,...] sets.

The use of aRest is just a suggestion at this point. We could use other mechanisms to do the same thing. aRest appears to make it easier to parse the RESTful API (the c=...) from the rest of the GET request, saving us a little work.

I have a version of firmware that uses ESP8266WebServer that will handle a simple RESTful API (no GET objects required). It also uses WifiManager to allow initial configuration, but I've not tested that yet (it's not actually written, come to think of it - just planned). It does not use aRset after all, as that was giving me problems during compiles.

However, testing stopped when the ESP-01's I'm using stopped booting. The firmware uploads seem to work, but booting fails. Research on SparkFun's IRC says the problem is likely due to the FTDI Basic I'm using, which apparently has a weak regulator on it.

I have some breadboard power supplies on order (due today, if the deliver today). I'll get back to testing once those arrive.

• domain is the IoT domain. This will be "im" for now (for IronMan) but can be extended to support other device types later.
• version is the version of the protocol, allowing us to extend support to other protocol versions later.
• command is the "thing to do"
• args are any data that the command needs. These can be in an valid URL format, including GET variables if desired.

For the proof of concept this will work in one direction: server to IoT device. It will also not carry any authentication or security in the proof-of-concept but will be required for MVP.

It is unclear if we'll have IoT initiated messaging though it seems likely that we'll need it for automated device registration at power up and possibly keep-alive signalling.

Attached is the first version, with stubbed command handling, of the ESP8266 firmware. This builds against the Arduino libraries for this chip.

I tested this to make sure it would run the configuration portal on the ESP8266. It works. I can connect to it with my phone to configure the AP it should connect to. Then I reboot it and it comes up waiting for connections. I then point my browser at it and issue commands. I can see them on the browser and in a terminal window.

It's a decent start. I now need to add the libraries which control the stepper motors. That will be fun too. Of course, there is still registration processing that will need to happen between the IoT device and the server, but that will come later too.

There is a diagram being developed for the data flow between IoT devices and piboxd. It is in the HighLevelDesign dia document which will be added to the wiki later.

Communications between monitor and IoT nodes is now documented on the wiki. These protocols are implemented and working. However the original PoC code won't work with this. The imlightsw code does.

Closing issue.