randuhmm/rad-esp8266

An IoT framework library for ESP8266 modules.

rad-esp8266's Issues

Reduce networking and ota boiler plate

https://github.com/randuhmm/rad-esp8266/blob/master/examples/TestExample/TestExample.ino

Your examples include a lot of networking and OTA boiler plate that have to be implemented in each sketch. It would be useful to move all this to the RADConnector or a new networking class.

Make API more RESTful

I've been playing around with this properly now and really loving the work you've been doing.

One thing I've noticed is that a RESTful api would make the code a lot simpler and easier for users to parse. Right now a SSDP response looks like

{ EXT: '',
  'CACHE-CONTROL': 'max-age=1200',
  SERVER: 'Arduino/1.0 UPNP/1.1 RAD-ESP8266/9001',
  USN: 'uuid:38323636-4558-4dda-9188-cda0e608ea67',
  ST: 'urn:rad:device:esp8266:1',
  LOCATION: 'http://192.168.1.20:80/' }

When parsing this you have to "know" the URL schema and append the /features, /commands URL. Also you end up doing a lot of parsing of the delivered JSON in your handlers as you need check in for instance the commands handler for get or set to know which command to make.

Instead I would suggest that you modify the schema slightly commands to address the feature directly eg for switch_1 use:

POST /commands/switch_1`
GET /commands/switch_1

You can then in your features response add the commands response

[
  {
    "feature_name": "switch_1",
    "feature_type": "SwitchBinary",
    "description": ""
    "commands": {
      GET: "http://192.168.1.20:80/commands/switch_1",
      POST: "http://192.168.1.20:80/commands/switch_1"
    }
  }
]

In your SSDP response locations changes to LOCATION: 'http://192.168.1.20:80/features and now whoever is reading the SSDP response can browse your schema dynamically.

I believe your code will also get a lot simpler as you will just need to add extra handlers for the GET/SET commands and would be able to remove a lot of your parsing code.

Simplify the SimpleBinarySwitch Example

I just realized that I am complicating the example by trying to use the GPIO as a drain rather than as a power source. Most users will better understand the connection diagram and code if setting the GPIO to HIGH turns on the LED and setting to LOW turns it off.

Split classes into their own files

This would be easier to maintain, extend and submit PRs (less chance of conflicts/easier to see what is being updated)

Update Documentation

The documentation represents an older version of the API.