I'm loving my Espruino Wifi. However, I'm currently trying to do something very simple but can't see why it's not working. I'm simply trying to create a server and listen on port 80. I've written a simple script based on the examples:

Mmm. Just tried that, and then commenting out the whole getIP bit. Now I just get a non-loading page that times out in the end. I popped a console.log in the createServer callback function and it's definitely not being called when I make the request.

But you don't get an error now? Can you try updating the firmware to 1v92 just in case?

I just tried that exact code here (the original code and my suggested change) with a Wifi board running 1v93 and both of them are working perfectly for me, so at the moment that's the only difference I can think of.

Is it possible that your PC and the Wifi are on separate subnets, or there's some firewall software or something that might be stopping you accessing it? Is it possible you're trying to access https://192.168.1.111 and not http://192.168.1.111?

A couple more observations. On the other Espruino WiFi when I hold the button down an add power the green light goes on, then the red light flashes, then they both go off. I can't then update it.

Once I've uploaded my software the Espruino should run it without the computer connected I assume? I'm finding that if I plug my device in to power then the script does not run. If I connect it to my computer and connect to it in the IDE it does run. Am I missing something here too?

For some reason my Mac and PC refuse to connect to the Espruino. Neither Chrome or curl requests get through on both machines. However, other devices such as my iPhone and iPad connect fine. The Mac and PC are on the same WiFi/subnet as the other devices.

Maybe it's down to my BT router? Perhaps the laptops are on 5GHz and the other devices on 2.4? Would this cause a problem? I've tried http and https. I'll try to work out why, but for now I'm happy to test on my iPad.

Despite this problem I've managed to create a webpage with a canvas on that lets you draw on a 16x16 LED matrix in just a couple of hours. It's very odd (in a good way!) writing JavaScript for both the user interface and microcontroller backend.

I'm using http for now and have noticed that not all requests seem to get through when I'm drawing quickly. How many requests per second should the Espruino be able to handle? I'm only POSTing 20 bytes or so, but there can be 20 per second. I'll explore sockets next,

Great! That's really strange... I guess it could be a firewall issue? It's possible it's some new 'feature' that block connections to other devices on the local network? I imagine if you're connected to the public BTWiFi rather than BTHub then that'd do it?

I think realistically Espruino will struggle at much past 5 requests/sec. It's not just the 20 bytes, but the headers that get sent are usually pretty huge each time (plus there's extra for opening/closing the socket) - and the connection to the Wifi is usually only around 11 kBytes/sec.

I guess you could actually rate-limit your HTTP requests to 2 a second or so, but send the whole frame each time?

Or yes, websockets would be the way to go - you should be able to push packets of data through that pretty fast.

Also, I don't know if you're doing it or not, but you can use 'template strings' that use the backtick character for HTML: `

They can be multi-line, so it gets really nice and easy to write actual HTML alongside the JS code

Most of my communications problems seem to be down to my BT router. I've created a separate wifi network for running the Espruino set-up on on and everything is working as expected. There must be some 'security' settings in the BT router that are messing things up.

My permission problems when POSTing via XHRs in the webpage to the Espruino WiFi were fixed by including. Access Control info in the response header:

I'm happily making websocket connections from a page in Chrome (not being served by the Espruino) to the Espruino. It's much faster than using HTTP, but I still get some packet loss. How many messages per second should the Espruino ws server be able to handle? Also, can my client tell when a packet hasn't got through? Would I have to send a message back from the Espruino to do this?

I find that some of my packets are coming through mashed up though. I'm expecting 2 digit hex chars in my message (four pairs, like "0FEFDE99") but sometimes the Espruino ends up with:

How fast are you sending packets out? You could check E.getErrorFlags() to see if you're getting any kind of buffer overflow errors that'd be a sign that you're losing data... That would explain the hex errors and unknown opcode errors.

Espruino's connection to the WiFi is only 11kBytes/sec - and there's a bit of overhead, in websocket packets as well as actual send data commands. So if you're sending 100 bytes, realistically I'd say it's 50 packets absolute max, and probably less.

I've actually just looked at this and there is a big gotcha though. Right now, in order to get reliable neopixel output, interrupts are disabled while outputting to the neopixel strings. Normally it's quite quick and wouldn't be a problem, but you are sending quite a lot of data to neopixels, and that means that realistically if the Wifi sends any data to Espruino during that time, it could get lost.

Thanks, I'll give this a go. My next experiment is to change the topology of my network so that rather than sending data directly from the web browser to the Espruino via Websockets I will use Websockets to send data from the browser to a node.js server running on a Pi and then use standard sockets to send data from the Pi to the Espruino Wifi. Do you think I will see a change in performance? This will solve my Safari problem as well I think without needing to do the HTTP/1.1 hack.

I also need to get DMX light control working (as an alternative to neopixels). Can you foresee any issues here?

Another thought. If a network packet is lost during the update of the neopixels is there a way of the sender knowing? At the moment I'm not getting an error message. Should I implement some sort of "acknowledge" on the Espruino so that the sender knows when to resend a packet?

I've tried the alternative firmware and - you're right - it makes the neopixels act a little randomly, with flashes and unpredictable colour changes!

I've improved my script quite a bit since my earlier post. I now use a node.js server to batch up my colour changes and only release them to the Espruino via MQTT after a predetermined time. I've currently set this to 250ms to give the Espruino time to update the neopixels.

This mostly works very reliably, however I sometimes get errors in my packets. The basic neopixel packet is 12 hex characters, with multiple packets being grouped together. Here is a run of correct packets:

However, every now and then I get some erroneous data in the packet. It appears to be the MQTT topic, eg. "biosphere/ecology/matrix/color", preceded by text in the form "+IPD,0,70:0". As you can see from the example below, this erroneous data is stuck in the middle of a packet.

Can you check E.getErrorFlags() and see if it reports anything? The flags get reset each time you call it so you should be able to see if something's causing a problem.

It sounds to me like data from the Wifi module is getting lost again - IPD is part of the data sent when data is received - usually it should be stripped out but presumably it's got out of sync somehow. Are you using the old firmware when you get that, or the new one?