Search results for:

Howdy ... I'm in Fort Worth (about 45 mins away). I'm a huge fan of Espruino and did some work on the ESP8266 port and am working with others on the ESP32 port. Feel free to drop me a line at kolban1@kolban.com if you want to shoot the breeze. There is also a great chat room at https://gitter.im/espruino/Espruino for Espruino in general and https://gitter.im/espruino/esp32 for technical chatter on Espruino being ported to ESP32.

The use case that I'm working on is the notion of bootstrapping network connectivity of an Espruino device. Imagine I have an Espruino device which I take with me to my friends house. He has WiFi and is willing to let me have his SSID and password. However, my Espruino has no screen or input source to allow me to enter that information so it can connect to his WiFi. So when Espruino starts, it looks at the list of found SSIDs, realizes that it doesn't know how to connect to any of them and then the Espruino becomes an access point.

Now .. on my phone, I see the Espruino as a target table access point. I connect my phone to the Espruino and then bring up a browser (on my phone). I am presented with the list of found access points ... I select the one I want to use and enter the password. That is transmitted to the Espruino which says "thank you very much" and now stops being an access point and becomes a station.

All good ...

However, I am trying to think of objections folks may have to that technique (also looking for better techniques myself). One is that the password for the WiFi flows over a network to the Espruino so that it can login. I was thinking that if the browser (on the phone) made an SSL connection to Espruino, there would be an ounce more security. I don't know if WiFi traffic is already encrypted (I would guess not). In principle one could then packet sniff and see the password flowing in the clear between my browser and my Espruino. If the Espruino had HTTPS support, that issue would appear to be moot.

Again ... so far this is all a theoretical story ... but it got me curious about what if anything in Espruino might be presented for server side SSL. I had failed to note that outbound SSL was baked into Espruino and was delighted when it "just worked".

Does anyone know if it is possible to setup an HTTP server on Espruino that listens using SSL? I.e. serves up HTTP traffic for requests that start "https" such that the content is encrypted during transport?

Status: SPI support is now available and I2C should be right behind it as the puzzles are now resolved. Note that the build instructions changed a tad to get the libraries correct for SPI and I2C. Espressif has released the news that their formal SDK at the 1.0 release will be available at the start of December at which time we will have all the proper libraries that we need to complete the build out. Until then we are using libraries that "work" but which aren't final.

My 2 cents opinion on multi-threading in JavaScript is ... well ... not to do it. The dual core that is now the ESP32 is primarily one core for the app and one core for networking (Wifi and/or Bluetooth). This allows us to dedicate a core to the app without ANY worry about starving the networking. This dramatically simplified Espruino builds because we can now use FreeRTOS and berkley sockets. As for trying to leverage both cores of the ESP32 for Espruino ... I personally don't see a need. One core for Espruino (the app) and one core for ESP32 networking feels right. That said, I am always open to listening to discussions and if anyone can put forward a cogent reason for using the 2nd core for Espruino work ... I'm all ears.

Looking at the source code, it doesn't appear to be implemented. This is where it should be:

https://github.com/espruino/Espruino/blo­b/master/libs/network/esp8266/jswrap_esp­8266_network.c#L704

It doesn't look horribly complicated to add. It seems that we would have to add a new property to the configuration of the parameters as an access point. From what I can see, the ESP8266 API does support the functional capability so really what would be required would be exposing that through Espruino.

Just tested the MQTT module on a very early version of Espruino on ESP32 and it worked first time without incident. Nice!!!

Yes ... the ESP32 supplies what appears to be a full implementation of BSD Sockets which, from all sniff tests appears to be working without incident. The ESP32 is a completely new story from the ESP8266. ESP32 is fully based on FreeRTOS, provides sockets APIs and has a whole new hardware interface/driver technology. The system level APIs are mostly distinct as well. If your time permits, it would be wonderful if you could tune in from time to time to the Espruino on ESP32 development gitter channel found here ... https://gitter.im/espruino/esp32 Thats where the day to day technical chat is happening.

As work progresses on the port to the ESP32, we are starting to look at networking. The ESP32 provides an implementation of the BSD Sockets APIs and so far, sniff tests seem to show that the network/linux implementation of the network layer is working out just fine for ESP32. From what I can tell by looking through some code, there was once thought of a network type called "JSNETWORKTYPE_SOCKET" which appears to map to the "network/linux" implementation.

Might this be a good time to think about the broader story? Is this an opportunity to rework the naming across a number of boards?

Status report:
There has been a goodly amount of technical chatter and status updates in the Espruino/esp32 gitter stream ... https://gitter.im/espruino/esp32

The good news is that we have a proto-type build of Espruino running just fine on the ESP32 with lots of room to spare. We have been taking a lot of notes as "we have hacked". Now it is time to put the proto-typing and loose testing aside and start again. The plan is to do as Gordon correctly desires and create a new branch for ESP32. In that branch we will build out the support for the "ESP32" as a new board but do so methodically and with documentation in the form of markdown to capture design notes, ESP32 specific environment setup (for building) and other goodies. To get us started, I'd like to solicit assistance from folks who have confidence in Git and Github. I know the theory but because we are working on a live system and as a community, it is always better to engage those who have experience. Discussions on this in the gitter stream.

When I read the reference documentation relating to file I/O, I get the distinct impression that the files are expected to be hosted on a micro SD card. Are there APIs or technologies associated with Espruino that would allow me to "save" files as data flashed to an area of flash memory?

For example, on my ESP8266, I have 4MByte of flash storage but I seem to see that only 500K is actually employed for Espruino. That seems to me that I have 3.5MBytes of unutilized flash memory (at least on some ESP8266 boards). I am looking to have an HTTP server serve up some relatively simple static HTML page and I was thinking that if I could have them "flashed", and if there were some kind of API, then I could serve up the content of these "files" from within an Espruino environment.

Is there some recommended API I should look at? Has anyone walked this path in the past?

In your Espruino code running on the ESP8266, we might try adding:

socket.on('close', function() {
   console.log("Socket closed!");
});

it may be that there is an underlying socket connection error. Although I don't have any experience with it, another possibility would be to enable the ESP8266 specific debugging with:

require("ESP8266").logDebug(true);

and we can see if additional diagnostics are produced.

I'd also look to see if base connectivity between the ESP8266 and 192.168.0.113 have been achieved using:

require("ESP8266").ping(...)

@CrashingDutchman ... The ESP8266 is primarily designed to be a processor for WiFi based applications. In the ESP8266 everything runs on a "single thread" meaning that there is no real multi-tasking for applications. If an application "keeps control" for too long, then other areas of code are starved for attention. In the WiFi and networking world, such timings are critical. If the WiFi or networking code that is implemented inside the ESP8266 doesn't get control often enough, then it can break its contracts with other networking partners. In an attempt to detect this, the ESP8266 runs a periodic timer which causes a hardware interrupt to occur. This timer is apparently reset each time control is given to the necessary time sensitive portions of the ESP8266 code. If the timer fires, then it means that we haven't given control to the ESP8266 soon enough. The ESP8266 treats this as a problem and basically reboots itself in the hope that what ever was congesting access to the networking code will have "gone away".

In our story here, Espruino is itself the application running inside the ESP8266. Espruino then interprets your scripts to provide the model of running JavaScript. The internals of Espruino must give control back to ESP8266 networking often enough to satisfy its timing requirements.

Now ... imagine a complex function such as "dump()". What mr @tve is saying is that in his understanding, dump() is working through Espruino memory, building a text output and writing that as quickly as possible through the relatively slow serial output. This is a logic path within the Espruino implementation. If that logic path takes longer than maximum time we are allowed to spend outside of ESP8266 networking, the timer goes off and we abandon what we were doing. This timer is also known as the "watchdog timer".

I'm more than certain that there are gross inaccuracies in my description here and please forgive me for that ... but hopefully it supplies a bit of the background that might be useful to you. The bottom line though ... is it isn't your code that is the problem nor can you change anything in your JavaScript code to fix it ... unfortunately it is currently "just one of those things" in the current implementation of Espruino on the ESP8266.

Work is starting up to port Espruino to the new ESP32 devices ... which may alleviate this issue. The ESP32 is a dual core device where (typically) one core is dedicated to networking and the other core dedicated to the user application (Espruino in our story). This will simplify dramatically many of the technical obstacles. However, I would not anticipate a useful build of Espruino on ESP32 nor great availability of the devices until summer 2017 (it may be sooner, but I'd rather lower expectations than otherwise).

A community member suggested a gitter stream for ESP32 development/design discussions. This seems like a useful idea. A new gitter stream has been created called:

https://gitter.im/espruino/esp32

This can be used to chat and record discussions on the ESP32 port and can serve as an informal history of chats we have had.

Would you be able to attach a file of your JavaScript source as edited in the Web IDE. I for one would be interested to load your program and have a go with dump().

I would suggest the following ... this is going to be a long post ... sorry for that ...

I'd like the project to be 110% open with no private repositories and complete and open communication between us all. We bring different skills, experiences and interests to the table. Whether one is a kernel C programmer, a JavaScript tinkerer, a hardware designer or just a consumer of the eventual Espruino on ESP32 ... we all get to play. There will be opportunities for folks to write tests, play with builds, write up notes, guides etc etc. So no-one should feel left out. In addition, if one is merely "interested" in an area, we can make time to chat, discuss or write it up. There need be no hidden knowledge and the more we share, the more eyes on the project ... the better.

The project is a game in two halves. We start with the excellent code and architecture which is Espruino today. This code base has excellent support for alternate platforms (ESP32 is considered a platform here) and allows us to create "code" that is platform specific while the majority of the Espruino iceberg is platform independent and hopefully needs not be touched for an ESP32 port.

The second half of the story is the new ESP32 platform. As I study this device, I find that the documentation is still being baked. As such, there is going to be much to learn in this area and there are no experts we can lean upon at this early time. Much of what was learned from the ESP8266 port can be leveraged ... but also ... much is new. It is appearing unlikely that Espruino for ESP8266 will "just compile" on ESP32. The underlying framework has changed to a real time operating system (FreeRTOS) and the networking APIs changed to be the "sockets" API.

The runtime libraries and compilation procedures have also all changed.

Then there is the elephant in the room ... availability of ESP32s. We don't know how quickly they are being produced nor their prices. They will eventually come down to a few dollars each (guess) but availability and price may not reflect this in the short term. Thankfully, I have an instance and we can "share it" over the network when needed.

What this says, is that the project can be broken down into a wide variety of factors and tasks. Does anyone have any opinions or recommendations on how we manage and track these? The source code control system will be a branch in Espruino Github. That way the source changes and issues we raise will be recorded in history for the project ... but what should we use for discussions and design plans? Maybe a Wiki page at Espruino Github? Maybe gitter chat? Maybe there is some other distributed project tracking mechanism available to us that one of us might recommend.

As for desirable skills and reading ... some of the following would be ideal:

• C language programming - Espruino is written in C
  
• ESP32 APIs and architecture - the ESP32 IDF , the ESP32 tech docs.
  
• Espruino from a user's perspective
  
• Espruino internals (as found on Github)
  
• The Espruino build system
  
• Using Github
  
• Using Doxygen
  
• Project guidelines, standards and overall conformance
  
• BSD Sockets API
  
• FreeRTOS API
  
  

Again, knowing all of the above are not required ... a big project can be broken down into bite sized pieces and learning grows.

I am lucky enough to have received an ESP32 development kit. The ESP32 is a new model of the ESP8266 type device from Espressif ... see:

https://espressif.com/en/products/hardwa­re/esp32/overview

The core differences between it and the ESP8266 are:

• Dual core vs single core (240 MHz vs 160MHz)
  
• 520KB ram vs ~80K ram
  
• 16MB flash vs ~4MB flash
  
• Hall sensor (magnetometer)
  
• 32 GPIO including 3 UART, 3 SPI, 2 I2C, 2 I2S, 12 ADC, 2 DAC, PWM .. more
  
• WiFi and BLE
  
  

It is still very early days in the release cycle of this device.

My question to the community relates to interest, design and execution of a port of Espruino to the ESP32. Ideally, I'd like to think that there would be desire for it. I'd also like to suggest that we make it a community project including design choices, implementation choices, coding tasks and more.

What I'd like to suggest is that if there is interest, we get permission from @Gordon to create a new board in the master Espruino Github (possibly called ESP32) and start building it out from there and using that as the core hub for our work. The most important thing being that any code changes that might be outside of the ESP32 target do not in any way negatively affect the other boards.

My hope is that with so much more RAM available to us, the scope of our JavaScript applications could be so much larger and allow us to take advantage of other functions.

If there is interest, lets see if we can't start communicating with each other to introduce ourselves and start a plan.

I fully realize that the availability of ESP32s is limited right now but a thought I have is that I can take my ESP32 board, a Linux build environment with networking and make that available as a virtual machine. In principle, you should have access to the serial ports etc etc. I'll also set up some WiFi access points for testing with REST servers and web servers (and more as needed). That way you wouldn't have to wait for an ESP32 for yourself and we would have a consistent "ready to code" build environment at our disposal.

My guess would the the compilation flag "-DNO_ASSERT" is the key component. If we look in "jsutils.h" we find that this flag is used to control the implementation of "assert()" statements in the source code.

An assert() statement is a debugging/coders tool that checks the truthiness of an expression at runtime. We want to "assert that some condition is true at this point". The asserts are added by coders who have concern that some condition that they expect to be true at this point actually is ... and if not ... usually stop here and alert someone. One shouldn't use assert() statements to trap "expected" issues ... for example ... if a filename is expected to be passed to a routine and it is found to be NULL, that would most likely be checked via exception and return code ... however if we presume that an internally calculated number will never be zero ... because we "think" the logic should not allow that ... then coding:

assert(x !=0);

is a good programmers statement to catch errors.

In a production/released solution, usage of "assert" statements should no longer be present. When an end user runs a program, it is meaningless to them to see:

assert at line 1234 for file xyz.c: x!=0

Instead we would hope they would see a nice message or a dialog and gracefull degredation of the application. Because asserts should only used during development time, they should be "removed" for a production release. However, because we don't want to go through source code and remove asserts when they might still be useful in the future, what we want is a build time flag that determines whether or not the assert() statements are included in the compiled code.

Espruino seems to use the C definition "NO_ASSERT" to remove them. During compile, if NO_ASSERT is set, then assert() statements are "no-oped". Since an assert statement will be an "injection" of code into the source, switching off assertions ... by setting NO_ASSERT which is set when RELEASE=1 prevents the assert() statements from being inserted. No assert() statements ... smaller compiled code ... smaller resulting image size.

I am fast becoming a fan of "docker" but am still an infant in its details. That said, I used Espruino for ESP8266 as a test to see if we could build a docker image that would provide an environment for building the latest Espruino for ESP8266.

Assuming you have installed a docker engine locally, run:

$ docker -it kolban/espruino

You will end up in a shell prompt inside the container. From there, change into Espruino and run make.

If you want to build your own docker image, here is the Dockerfile I used to build this image:

FROM vowstar/esp8266
MAINTAINER Neil Kolban <kolban1@kolban.com>
RUN git clone https://github.com/espruino/Espruino.git­
RUN wget http://espressif.com/sites/default/files­/sdks/esp8266_nonos_sdk_v2.0.0_16_08_10.­zip
RUN wget http://espressif.com/sites/default/files­/sdks/esp8266_nonos_sdk_v2.0.0_patch_16_­08_09.zip
RUN unzip esp8266_nonos_sdk_v2.0.0_16_08_10.zip -d /opt/esp-sdk
RUN unzip -o esp8266_nonos_sdk_v2.0.0_patch_16_08_09.­zip -d /opt/esp-sdk/ESP8266_NONOS_SDK/lib
RUN rm -f esp8266_nonos_sdk_v2.0.0_16_08_10.zip esp8266_nonos_sdk_v2.0.0_patch_16_08_09.­zip
ENV ESP8266_BOARD=1
ENV FLASH_4MB=1
ENV ESP8266_SDK_ROOT=/opt/esp-sdk/ESP8266_NO­NOS_SDK
ENV ESPHOSTNAME=espruino:88
ENV RELEASE=1

If you play with this and like it, then we'll see if we can't get a Dockerfile for ESP8266 added into the github repository for Espruino. I see that there are a couple there already so we will want to examine, merge or simply use.

I fully expect that most of y'all are way ahead on your docker journey than myself, so apologies if this is no news/value.

Setting RELEASE=1 allowed me to build. I don't know what that means or did or whether that is a permanent change that is required for building.

I built Espruino from the current committed source at the Espruino github repository.
For a compilation environment, I used a Docker image called vowstar/esp8266 (see: https://hub.docker.com/r/vowstar/esp8266­/)
I downloaded and installed the SDK 2.0.0 plus Patch1 directly from Espressif.

I'd like to now suggest a discussion topic if I may ...

As I understand it, our common ESP8266s have 1MByte of flash storage. I believe (and I could be wrong here) that our current Espruino builds want to contain our compiled Espruino image to fit within 512K. The reason for this is that the ESP8266s have a technique called "Over The Air" (OTA) flashing ... where one can push a new binary image to an ESP8266 via WiFi. The way this works is to consider an ESP8266 as having "two banks" of 512K instead of one bank of 1024K. At a given time, the ESP8266 runs a program in one bank while the other is unused. Should we wish to reflash an ESP8266, the new program is loaded into the unused bank and ONLY if the transfer completes, will the ESP8266 swap to using the newly loaded bank. If something goes wrong in transfer, we don't end up with a corrupted environment that would (essentially) be a brick.

While this makes absolute sense to me for an industrial/commercial solution which is deployed black box in a consumers house who has no interest or skills in "flashing ESP8266s", I question the need for this in our Espruino project.

If we are starting to over-reach the 512K constraint of an ESP8266 OTA flash size but if we fore-go the ability to use OTA but instead require that the only way to load Espruino onto the ESP8266 is via a serial connection ... I believe that would allow Espruino to grow to 1024K in binary size.

Does this summary sound right?

Would there be interest in providing an Espruino compilation option to allow a build that allowed 1024K images? Is anyone actually using the OTA flashing capability?

I do fully realize that for us developer types, having to upload Espruino via USB/Serial takes time ... for me its about 10-20 seconds as compared to what might be only a few seconds via WiFi.

Looking at the following merged pull request:

https://github.com/espruino/Espruino/pul­l/925

My assumption is that we now support SDK 2.0.0. patch 1.

On a fresh environment, I cloned the latest committed Espruino (https://github.com/espruino/Espruino.git­) and set the environment variables:

• ESP8266_BOARD=1
  
• FLASH_4MB=1
  
• ESP8266_SDK_ROOT= // Path to SDK 2.0.0 root
  
  

When I try and run a make, it fails at the end with:

... other succesfull output ...
CC /esp8266/Espruino/gen/jswrapper.o
LD espruino_esp8266_partial.o
LD espruino_esp8266_user2.elf
LD espruino_esp8266_user1.elf
/opt/xtensa-lx106-elf/bin/../lib/gcc/xte­nsa-lx106-elf/4.8.2/../../../../xtensa-l­x106-elf/bin/ld: espruino_esp8266_user1.elf section `.text' will not fit in region `iram1_0_seg'
collect2: error: ld returned 1 exit status
Makefile:1947: recipe for target 'espruino_esp8266_user1.elf' failed
make: *** [espruino_esp8266_user1.elf] Error 1
make: *** Waiting for unfinished jobs....
/opt/xtensa-lx106-elf/bin/../lib/gcc/xte­nsa-lx106-elf/4.8.2/../../../../xtensa-l­x106-elf/bin/ld: espruino_esp8266_user2.elf section `.text' will not fit in region `iram1_0_seg'
collect2: error: ld returned 1 exit status
Makefile:1955: recipe for target 'espruino_esp8266_user2.elf' failed
make: *** [espruino_esp8266_user2.elf] Error 1

Can anyone spot what I might be doing wrong?

I like to think of the ESP8266 as "bundling" WiFi and TCP/IP libraries as part of an executable and those libraries having "reserved" flash areas into which they save their configuration for subsequent restart and operation. This area of flash is private to those libraries. While in principle if we "poked" those addresses with values, they would be honored, I'd suggest avoiding that. Those are not what are considered "clearly defined programming interfaces" and there would be nothing to prevent the library authors from changing their content, location or even existence from one SDK release to another. The expected mechanism is to invoke the ESP8266 APIs and have them perform their saves and restores.

As such, I'd suggest that we not try poke to their storage. Can we take a step back. What is the puzzle we are trying to examine?

I am imagining it is that we have a standard Espruino binary that we flash to an ESP8266. When the ESP8266 then boots, it doesn't know which access point to connect to nor what password to use to connect to it.

A couple of thoughts on that puzzle.

The first is that the ESP8266 can be an "access point" ... meaning that it can listen for incoming WiFi station connections. We could have a virgin loaded Espruino know that it is first boot and set itself up as an access point that could then be connected to from a WiFi station (eg your cell phone) and configured with the identity of the desired target "real" access point. At that point it would be bootstrapped.

A second thought would be that on first boot, there is a piece of logic that we embed in Espruino that has the semantics:

if (first Espruino boot) {
   retrieve data from an area of user program flash;
   use that data to configure WiFi station access;
}
// Normal Espruino boot ...

By the inclusion of this logic, we CAN then provide legal/clean command line options to set the desired station access configuration ... we would load that data into "user code" flash space during the upload of Espruino into the ESP8266. This would appear to solve the puzzle without internal knowledge of ESP8266 mechanics that are "forbidden" to us.

Again ... just musings ... hope this helps some.

@Gordon
Thank you, thank you, thank you ... that explains it all ... based on your pointer, I found the following excellent document on how Node.js handles HTTP transactions:

https://nodejs.org/en/docs/guides/anatom­y-of-an-http-transaction/

What you say makes perfect sense now and is (in my opinion) the correct implementation. I'm making notes for what might be a programmer's guide to using Espruino and will cover this area. I had mistakenly assumed that Espruino would have received the whole HTTP transaction before invoking the HTTP server side callback ... but now I understand all it would have to do is receive the HTTP headers before invoking the callback and then the callback has a "stream" reader on the rest of the data. That data may or may not have arrived at the time when the callback is made.

... later ...
For completeness, and it is likely most users will know this ... but if we want to process a complete transaction of data, then we can register a callback for the "close" event of the request at which time both available() and read() will be honored to return the total length and all the data. For example:

  var httpServer = http.createServer(function(request, response) {
    console.log("Received a server request!" + JSON.stringify(request));
    request.on("close", function() {
      console.log("The request has completed sending its data!");
      console.log("Available data is: " + request.available());
      var data = request.read();
      console.log("The data is: " + data);
    });
    response.write("Response data!");
    response.end();
  });
  httpServer.listen(80);

My goal is to write a script that sets up an HTTP server and when I post data in from a client, I want to see that data within Espruino. To that end, I set up the following script:

var wifi = require("Wifi");
var esp8266 = require("ESP8266");
var http = require("http");
wifi.startAP("ESP8266", {
  "authMode": "open"
}, function(err) {
  var httpServer = http.createServer(function(request, response) {
    console.log("Received a server request!" + JSON.stringify(request));
    if (request.available() === 0) {
      console.log("No data");
    } else {
      var receivedData = request.read();
      console.log("Data = " + receivedData);
    }
    response.write("Response data!");
    response.end();
  });
  httpServer.listen(80);
});

I then send in a POST request using:

wget http://192.168.4.1/hello  --post-data="hello" --quiet --output-document=-

when the request is received by the ESP8266, the message logged is:

Received a server request!{"type":1,"res":{},"svr":{"type"­:1,"port":80,"sckt":9},"sckt":10,"header­s":{"User-Agent":"Wget/1.16 (linux-gnueabihf)","Accept":"*/*","Host"­:"192.168.4.1","Connection":"Keep-Alive"­,"Content-Type":"application/x-www-form-­urlencoded","Content-Length":"5"},"metho­d":"POST","url":"/hello","hdrs":true,"dR­cv":""}
No data

From this note two things. The first is that the amount of available bytes is flagged as 0 while the HTTP header says that 5 bytes (what I would expect) was sent.

If I change the code to include:

request.on("data", function(data) {
   console.log(data);
});

I do in fact see the data. What is puzzling me is the notion that I had expected available() to return 5 for the amount of payload data and response.read() to be able to read that data. Can anyone spot what I might have mis understood?

I spent the bulk of the day trouble shooting my issue and think I found it ... here is the story and the then the conclusion. With so many variables in my story, I wasn't sure where to start. Was it timing with Espruino, interrupts in ESP8266, bad pixel strips, bad power, bad comprehension on my part .... so many possibilities.

What I did was broke out an Arduino and used it to drive my NeoPixel strip through an Arduino sketch which was an implementation of my JavaScript sketch but this time in C. It worked fine and all the pixels lit properly. I watched it for a long period of time. My confidence in the NeoPixel strip was now high. I captured a low level timing through a logic analyzer and saved the results. Then I went back to the ESP8266 and Espruino using the same strip. Again, same issues as before. I captured the input timings into the NeoPixels and generated by Espruino/ESP8266 and compared them against my "reference set" which I took from the Arduino. Although not identical, they were within tolerance of what I have been reading from NeoPixel theory.

Next I had an idea ... the output of one NeoPixel feeds into the input of the next. Now I decided to capture signals from the input to the first NeoPixel to the output of the next ... and ... Aha!! We got something. When the pixels started not showing correctly, I saw that the input to the first NeoPixel looked "good" but the output from the first NeoPixel was poor ... i.e. a lot of missing high signals on the DOUT line. What this was telling me was that the first NeoPixel was not forwarding its correct sequence of pulses.

Now we get to cut to the chase ... I knew that powering a NeoPixel strand from the 5V output of ESP8266 wasn't going to fly so I was using an MB-102 as a power source for the NeoPixel strand. I was delivering 5V from the MB-102s to the NeoPixels with a common ground to the ESP8266 (NodeMCU dev kit). This had been my test environment. Knowing that the Arduino was a working test environment, I took the MB-102 out of the story and powered my NeoPixels from the 5V/GND of the Arduino ... i.e. I am using the Arduino ONLY as a source of power to the NeoPixels. I obviously continue to have a common ground ....

and the result ... perfection. I have been running the strand for about 10 minutes now with it right in front of me and not a single glitch. What this is telling me is that power output of the MB-102 is not sufficient/clean enough to power the NeoPixel strand. I don't have nearly enough skills in electrical or electronics to know why ... tomorrow I'm going to start studying up on MB-102s ... and also see what I have in my box of bits for a power source that is neither MB-102 nor an Arduino ... but what I have now is an ESP8266 running Espruino driving a NeoPixel strand in exactly the fashion I had hoped for and that others had said they had achieved. I'd be really interested to hear from you what you are using to power your NeoPixels/ws2812s?

To my understanding, bonjour/zeroconf is the notion that one can find the IP address of a device on a TCP/IP network using "multicast DNS". The idea being that the device may have a dynamic IP address obtained through DHCP but we have client applications that wish to connect to it. Since it doesn't have a static IP address, we need a mechanism to determine its IP address at runtime. Multicast DNS allows a client to broadcast a request to locate a specific named device. If ESP8266 supported multicast DNS (which it does), then it would determine that a request to locate it was being made and it would broadcast a response with its own current IP address. This would be received by the original requestor (and as a side effect .. possibly other devices) and a normal TCP/IP connection could progress.

While the raw ESP8266 provides support for multicast DNS, I can't remember whether or not that was exposed through Espruino. If it was, then we are good to go. If it wasn't, then a change request would have to be made through Github to see if it could be added.

As for implementing a Web Service, I'm am assuming you mean a REST client or server ... using JSON over an HTTP request. That can be achieved using Espruino today.