Search results for:

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

Take a look at:

http://bitwiseshiftleft.github.io/sjcl/

AES is a well tested standard, and has low resource requirements. I can't speak for the safety of that particular library, but they certainly have some good credentials. I think it would be possible to trim down that library to fit on an Espruino, especially since you already have some components implemented (SHA-256).

@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.

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.