**** Features in this release ****


1. We fully support a BSD socket API implementation (the standard Python cross-platform API).  MicroPython, to the best of our knowledge, is the only scripting language for ESP8266 which provides a standard reusable socket API and not an ad hoc, proprietary API that's not reusable on other devices.  The MicroPython distribution provides HTTP protocol examples which work the same way on CPython, MicroPython Unix version, and on MicroPython ESP8266: https://github.com/micropython/micropython/tree/master/examples/network

2. We have a filesystem with long filenames and subdirectories (based on FatFs library). Again, to the best of our knowledge, MicroPython is the only scripting language which provides a "real" filesystem and not 1970ies era style filesystems without directory support, etc.

3. An almost-complete MicroPython hardware API is implemented for the ESP8266. There's support for GPIO (with attached interrupts), I2C, SPI, UART, PWM, ADC and deep-sleep. It may be still rough at edges and some features may be missing, but these will improve over time.

4. Beyond the standard hardware API, 1-Wire bus support is implemented, with driver for DS18B20 temperature sensor and OLED I2C driver.

5. WebREPL, an interactive prompt in a browser, is provided for easy wireless interacting with a board. We are proud that we resisted temptation to cut the corners and make WebREPL ESP8266-specific, and instead made it portable and suitable for reuse by other MicroPython ports. However, on ESP8266, WebREPL is in alpha/beta status and many known issues (see below) are related to it.

6. We have an automated initial board setup process that works across various board models and which proved to be robust and was designed to be user friendly.

7. There is much improved documentation for MicroPython overall. Since the original Pyboard was delivered, and documentation for it was authored, many new modules and functions were added, which went largely undocumented. We took the ESP8266 release as a chance to restructure and refresh it so it's now much more complete and consistent across ports. (Of course it can always be improved further and work in that direction will continue.)

8. There have also been many other small fixes and improvements which are too long to list here. Most of them also benefited not just ESP8266 port but MicroPython as a whole.


With many achievements and a quite advanced and workable port there are also things which we initially planned to do within this short 2-months development period but haven't been able to finish completely, or which don't work as well as expected.  All these issues are slated for further work and improvement.


**** Known issues ****


1. Basic SSL support is available, but it works only with relatively short data length (few kilobytes). This is similar to most other SSL solutions for ESP8266. The problem is that standard SSL implementation requires quite large buffers to handle encryption/decryption. The latest TLS standards support optional extensions to negotiate smaller message lengths (and thus buffers), but turned out that they are not supported and ignored by the current de-facto SSL implementations (OpenSSL, GnuTLS) used on the majority Internet sites.

2. Due to the issues above, WebREPL over SSL is not supported.

3. There's currently a limitation of how many WebREPL sessions in a row can be handled. After about 5th connection (plus/minus), ESP8266 board starts to misbehave and requires a reset. WebREPL should be quite suitable for initial acquaintance and prototyping/development, but is not suitable for production usage on remote devices.

4. File transfer over WebREPL has additional issues, usually triggered when transferring large files (tens of kilobytes and more). WebREPL file transfer is suitable solution to transfer scripts of the normal size to the device, but may be not suitable so far to transfer large data files. (Note that file transfer is affected by the WebREPL connections limit mentioned above).

5. Only one concurrent WebREPL connection is supported. This is by design and won't change (changing this means grabbing more resources from user application, and there're not so many resources in the first place). This means that web-based WebREPL terminal session and command line file transfer client can't work at the same time.

6. Soft reset (Ctrl+D in REPL) doesn't offer complete "soft reset" implementation, in particular, network stack is not reset completely.  Soft reset via WebREPL will terminate the session (by eventual timeout).


**** Preinstalled scripts and modules ****


Known issues is not how we'd like to finish this email. You can install various script and modules on your board as described above, but we pre-packaged a bunch to give you a quick start. All modules below are importable using "import <name>". Sources are available for all modules, so for more info you can look them up.

1) http_client
This and following 3 scripts come from examples/networking/ in MicroPython source repository. http_client issues an HTTP GET request to http://google.com and prints the result. Don't look for anything too fancy in it - it's just a redirect to https:// version with bunch of internal info. The point? It works!

2) http_server
This is more interesting, you can connect to your module from web browser (http://192.168.4.1:8080 is you connect to ESP8266 access point as we recommend), and see incrementing counter in a browser. We don't provide more fancy HTTP server example so far, but that one can get you started!

3) http_client_ssl
You guessed, this connects to https://google.com . Just another weird redirect will ensue, I'm afraid, it's not like 1990 with web being simple and clean. The point? SSL works!

4) http_server_ssl
If you connect to https://192.168.4.1:8443 with Firefox you can see how heavy a number crunching game the SSL is - it takes several seconds to establish a connection. Definitely needs an optimisation.  Don't even try with Chrome - it overloads poor ESP8266 with multiple requests so it can't catch up.

5) urequest
This is http.urequest module from micropython-lib (https://github.com/micropython/micropython-lib), a micro version of the standard http.request module. This is how you'd actually issue HTTP requests in your apps.

6) urequests
Also comes from micropython-lib, and is a micro version of getting more popularity "requests" module. Can do even more magic in one line.

7) ntptime
NTP support was voted #3 in the module survey, so was off list as a stretch goal. But thanks to our users who did a research how to do it in Python easily on the forum, here's surprise out-of-band stretch goal implemented, first! ntptime.time() will get you time in seconds since MicroPython epoch (which is 2000-01-01). You can even do ntptime.settime() to set system time from NTP, and you can even put it in your boot.py for your module to always have actual date/time. Caveat: it's all UTC now, no timezone support yet. UTC time is a standard for Internet servers (if it processes requests from around the globe anyway, why bother with specific timezone, just use the default). You can now try that at home (it feels great!).

8) onewire
9) neopixel
10) ssd1306
These are preinstalled drivers for corresponding hardware components, so you can start using them right away.