WiFi controlled LED

Prototype: https://www.youtube.com/watch?v=gLNyAVaspyo

What:

• Espruino Pico
  
• ESP8266
  
• WS2812B (Neopixel)
  
  

The Espruino Pico is seriously awesome. I was able to develop a working proof of concept in maybe 10 minutes(?) thanks to pretty good documentation, and spent the next few hours iterating on the design.

I originally used HTTP on the Pico, but I felt that the 400-700ms latency hurt user experience too much, and incomplete requests would cause the system to freeze. I ended up using raw sockets (with Node.js as an intermediary), which significantly improved reliability and response time, and I'm pretty happy with the performance.

There's still a lot of work left to do. I plan on making the interface stateful, and want to configure WiFi host AP on the Espruino, so it'll be easier to change the WiFi client credentials later. I also need to find a more elegant way to present the lights.

Other notes:

• I had to connect CH_PD to v3.3 and add a 1µF capacitor in order to communicate with the ESP8266
  
• I later bought a ESP8266 breadboard adapter (in video) for convenience, and it came with a 10µF cap.
  

Wow - yeah, the response time is incredible!

I'd love to see how you do the sockets...

Really cool!

Are you planning to publish the code? Is it just HTML5 in a browser on the mobile or did you do some native fiddling?

Wow, that looks great! I guess it shows how much difference having to open and close HTTP connections all the time makes... I suppose this is another reason for WebSockets :)

Did you find about the cap and CH_PD in the ESP8266 page? It seems that when breadboarding the ESP8266 really needs the extra capacitor - I'll add something about it.

@DrAzzy For the sockets, I kept it pretty basic. I established a simple format where the Espruino listens for a certain pattern: D:RRRGGGBBB, where "D:" is the header and R G and B are 000 - 254 for the color values.

The Espruino code is very similar to how a HTTP server is set up:

      server = require("net").createServer(function(socket) {
        socket.on('data', function(data) {
             parseData(data);
        });
      }).listen(9000);

After listening on an arbitrary port, 9000, the data is parsed and sent to the LEDs.

function parseData(data) {
  var idx = data.indexOf('D:', data.length - 11);
  tRGB[0] = data.substr(idx + 2, 3);
  tRGB[1] = data.substr(idx + 5, 3);
  tRGB[2] = data.substr(idx + 8, 3);
    
  console.log('r: ' + tRGB[0] + ' g: ' + tRGB[1] + ' b: ' + tRGB[2]);
  initColor(); // This fades the color a bit, and sends the pattern through SPI to the LED controller.
}

The Node.js code. Here's the crucial parts:

• Note that in this implementation, the Web front-end is sending AJAX HTTP GET requests to Node.js, with the arguments in the URL looking like: ?r=#&g=#&b=# , where # is the color value.

  // Helper function to format the string that we'll send to the Espruino
  function padNumber(num) {
  return ("0000" + num).slice(-3);
  }
  
  var url = require('url');
  var net = require('net');
  var esp = net.connect(9000, '192.168.1.15',
      function() {
        console.log('Connected to Espruino!');
  });
  
  var http = require('http');
  http.createServer(function (req, res) {
    var q = url.parse(req.url, true).query;
    esp.write('D:' + padNumber(q.r) + padNumber(q.g) + padNumber(q.b));
    res.writeHead(200, {'Content-Type': 'text/plain'});
    res.end('OK');
  }).listen(8888, '0.0.0.0');
  

@allObjects It's all standard HTML 5 in the browser. The code above contains all the main pieces, and I'll eventually post the whole thing on https://github.com/m6ao when I have time. I think I'll also rework the color picker as a standalone module. I tried a lot of existing color pickers before deciding to make my own, and I think mine might be better suited for light control.

@Gordon I wanted to use WebSockets initially, but saw that the ticket for WebSocket implementation on the Espruino is still open :P. While it would be really cool, I was debating on whether or not it would be practical, not knowing the limitations of the ESP8266, and what the performance penalty might be on the Espruino. It looks really promising though, since it looks like there's a SHA-1 hash implementation in hardware, which is required for the WebSocket handshake.

I found out about the cap and CH_PD via Google, which incidentally led me to this post (thanks DrAzzy for your comments). I'm not sure if they're always required, but adding a note about it would be useful. I picked up some hints on that ESP8266 page -- the wiring table shows the original Espruino board with CH_PD connected, and mentions of adding a cap was pretty consistent on dedicated ESP8266 forums too.

Ahh, the SHA-1 implementation is sadly only for the STM32F2 (which isn't in either of the 2 Espruino boards). ST do provide a set of cryptography functions that could probably be used though. Espruino already has SHA256 built in, but it looks like that wouldn't work for WebSockets!

Once that was done, I don't think there would be much of a performance penalty for Websockets on Espruino/ESP8266 though (they're relatively lightweight after the initial setup).

Oh well. It's probably not that big of a deal; I think it's only needed once per connection anyways.

Yeah, the Espruino is actually quite powerful, and I don't imagine there would be any performance impact when using WebSockets.

I was a bit curious on power consumption, and measured:

brightness   	Color/# updates     mA
0.00%	          black	            21
100.00%	          white	            25
100.00%	          blue	            26
100.00%	          red	            25
100.00%           green	            25
100.00%	          4 req/second	    65
100.00%	          10 req/second	    65
100.00%	          100 req/second	66
0	              black	            21
50.00%	          white	            61
25.00%	          white	            61
75.00%	          white	            47

Interesting... that's not really too bad I guess, given you've got WiFi on.

Unfortunately you can't easily use Espruino's setDeepSleep, because it's still got to be able to wake up on Serial data from the ESP8266. Hopefully at some point in the future I'll add the ability to change Espruino's clock speed - which should let you save quite a bit more power without setDeepSleep