Action Item #496

Establish communication protocol between server and nodes

Added by Gale over 2 years ago. Updated about 2 years ago.

Status:In ProgressStart date:03 Feb 2016
Priority:NormalDue date:
Assignee:Hammel% Done:

70%

Category:-
Target version:-
Severity:03 - Medium

ESP8266IoT.ino - Currently named "ESP8266IoT" but will be changed later. (10.1 KB) Hammel, 21 Feb 2016 17:17

Associated revisions

Revision c95cd757
Added by Hammel about 2 years ago

RM #496: First pass at working IoT device code.

History

#1 Updated by Hammel over 2 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10

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.)
The URL includes this: im?c=/vers/cmd/args
  • 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.

#2 Updated by Hammel over 2 years ago

  • % Done changed from 10 to 30

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.

As for the API, it will now look much simpler: /domain/version/command/args
where
  • 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.

#3 Updated by Hammel over 2 years ago

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.

#4 Updated by Hammel about 2 years ago

  • % Done changed from 60 to 70

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.

Also available in: Atom PDF