Category Archives: ESP-02

Hackitt and Bodgitt discover Healthy Lighting

Hackitt and BodgittThere has been a lot of talk in the press recently about the colour of lighting and it’s relevance to health.

As far back as 2012, the BBC reported that NASA were to test “space-sleep colour-changing lights” on the international space station and since then there have been a number of articles in the press suggesting that the colour of light at certain times of the day can affect everything from sleep to prostate cancer.

Of course newspapers have also claimed at one time or another that aliens landed on the moon but there is a certain amount of obvious logic in selecting the right colour for the right time of day. Everyone knows that due to atmospheric filtering, the sun appears shifted toward red at night – and it is quite feasible that our bodies respond to those colour changes. No, I don’t follow my star signs!!

KelvinRecently the papers were full of the news (as it there’s nothing more important going on in the world) that our lighting and our various devices such as tablets can affect our sleep and that you should avoid blue light in the evening and that light shifted toward blue in the morning can aid waking up etc. I subsequently found, thanks to readers, a boatload of APPs that do this colour shifting on phones – not a lot of use when you’re trying to take a photo and you’re mobile has gone all red, but probably a good idea when you’re trying to read yourself to sleep.

And with that in mind I set off trawling the web for more information and finally ended up with a set of RGB values which match “colour temperature” in degrees Kelvin. Now I would not be one to claim 100% accuracy here because for that to work with modern LEDs you’d have to be assured that the RGB values you poked into the LEDs would render accurate colours and I doubt very much that this is the case.  However, I’m going to suggest that what I’ve done here is “near enough”.

In our “Hackitt and Bodgitt” board described in the blog article “Home Control 2015” I’ve added a new command to provide white light from RGB LEDs which can be “shifted” by providing a value in degrees Kelvin from 1,000K (very orange-ish) to 40,000K (very blue-ish).  At 6400K you have a perfect representation of the more garish compact Fluorescent lighting and at 1,100K you have a pretty good match for dim candle-light – with all the subtle variations in between.

Hence with a simple command to alter the hue of white lighting, in our case initiated no doubt in a node-red command, we gain the ability to alter the lighting to the time of day.  Now, WHY would you use more expensive RGB lighting as against simple WHITE LED strip in your home of the future? I have a theory about white LEDs and it’s a theory increasingly backed up by anecdotal evidence that white LEDs don’t last as long as some manufacturers might have you believe. RGB LEDs on the other hand don’t seem to have that problem and have the benefit (we’re talking about modern integrated LED, not separate red, green and blue LEDs) of allowing just about any shade of any colour and in this case, any shade of “white”.

I doubt very much that due to this new lighting interest you’ll read “Peter Scargill becomes the first person to live to 150” but you never know, it might just be an aid to better sleeping and that has to be a good thing.


Accessing ESP8266 Arrays in FLASH

A new challenge – the answer to which I will post in here.

Accessing an ESP8266 C array in FLASH – i.e. never touching RAM until you actually access something.  One suggestion was to ensure you use 4-byte variables.. so I tried this – it compiled – the array is in FLASH – but the access IMMEDIATELY reboots the ESP8266. iprintf is just a macro for printf – no issues there..

static const uint32_t petes[] ICACHE_RODATA_ATTR = {

iprintf is just a macro for a normal printf function…

iprintf(“Data= %ld”,petes[37]);

Result: Immediate reboot….

Thoughts anyone? Why do we need this? Because FLASH is in plentiful supply on these boards, RAM is not.  Ok, you could use tricks from the web page lookup and make functions – but that involves knowing exact addresses etc.. If possible I’d rather let the compiler worry about that.

I’ve posted this on the Espressif forum – I’ll post a working solution in here – but I’m out of ideas….


Lua Revisited

Back in the dark ages when the ESP8266 was something new, I had a go at the nodeMCU software, essentially implementing the Lua language (or a subset of it) on the ESP8266.  At the time I was not familiar with Lua but thanks to some of the excellent resources out there on the web, I quickly caught up.

Sadly, my expectations exceeded the ability of the implementation to match and every time I went past flashing a few lights – CRASH. I gave up in disgust.  I’m not complaining as that gave me the impetus to learn the hard way how best to program these chips – which I maintain is using the C language – and in my case via the unofficial development kit which is just an excellent piece of work by Mikhail Grivorev, leading to a complete Windows environment with a ton of examples. Between that and TuanPMs excellent MQTT code as a starting point  I’ve been happily programming away and even built up a working relationship with Espressif in the process. My home control project is well under way and now just waiting for some new boards – and a function that Espressif have promised to shut down PWM.

LuaMeanwhile this morning, I can’t remember what I was reading that triggered me off, I decided to have a quick look at the node-MCU code again.  I had it sitting in the development environment but figured it would be out of date and so went off to the repository to study any changes – which I duly put into the code. The GIT Makefile is useless for Windows but fortunately there was one in the environment – and as it happens, a good one. I wasn’t about to go backward so I made sure I was linking to the very latest SDK which at this time is 1.1.2 with at least one patch – all available from the Espressif forum.

I checked the settings in the Makefile, adjusted the SPI speed up to 80Mhz, set the FLASH size to 4Mb to suit the sparkly new ESP-210 that is sitting here looking for a job – and started the compile process. Within a minute and without any issues, the code was flashed. I have to say I was expecting at least one or two issues – but no.

I set up a 9600 baud terminal, in the process discovering for the first time that you can have multiple terminals at once in the Eclipse environment – handy (it would be more handy if it always reported the right location of bugs but you can’t have everything). Sure enough – a working Lua board.

I told it about my WIFI setup and sure enough it grabbed that too.  The project has come a long way since the early days and now (apparently) supports json, a file system, timers, pwm, i2c, spi, 1-wire, net, mqtt, coap, gpiio, wifi, adc, uart and more. I’ll believe all of that when I see it.

I was delighted to see that both the integer and float versions are available – that’s a plus! I also noted support for the WS2812b chips – I noted that as I had to make a change to the source code and I’m delighted to note that they’ve made use of a local compiler directive that I was not even aware of to ensure accurate timing. Wish I’d seen that a month ago when I started work on my own WS2812b support. 

WS2812B LEDs on nodeMCU LuaI plugged a (short) length of WS2812b strip (a custom board we had made) into the ESP-210, fired the instruction and… worked first time out of the box. Impressive.

I’m pleased to see the nodeMCU docs have come on a long way – sadly the website was running like a DOG at the time but here’s a few stats I managed to get off the board.

print(node.heap()) returned 20kbytes which is more than when I tried it – but then it used to die when the heap got down to 5K so we’ll have to wait and see how reliable that is.

3 Channels of PWM are available – at 10 bit resolution. Clearly some work to be done here as Espressif have just released a library handling more outputs than that at nearer to 14 bit resolution – and it works as I’ve been using it in my own research and projects. However – handy enough.

There are libraries for sending to displays complete with fonts – now that I’m interested in – if this will do reliably MQTT and report results to a display I have a use for this already – wall thermostats.

So, overall, a very brief test – it is possible with the right environment to get interactive and easy to use nodeMCU up and running in minutes – you don’t need special boards and the software is free. Can’t be bad – how complex a program you can make withou running out of RAM remains to be seen. Here is some more info on nodeMCU.


More ESP8266 Woes

Updated Sunday 22/06/2015 : The thing about the ESP8266 is there is always something new to discover problems with!!

So this week –

The new PWM module appears to have issues and as we don’t have the source, we can’t fix them.  Right now it will only do up to 90-95% duty cycle– and once it starts up there is no way to stop it – that is, attempts to use tight code for, say, serial LED control fail because of the interrupts going on in the background – I’ve asked for fixes and a stop routine. Started a new version of our board with 3 MOSFETS on it in anticipation of getting this working.

SNTP – the sntp routines work – you can get the time from a server – but if you add in from the SDK documentation, the bit to set the time zone first – it will then NOT get the time.  A better example is needed. The default time routine gives the time not at GMT – but GMT-5 ?!!?!?!   So you need to add the number of hours for where you are (*60*60). That leaves just the summer/winter correction which is a whole other ball game.


ESP8266 Debug

Light bulb momentsSo – I’ve learned quiet a lot in the past few days..

Watchdogs on the ESP8266

Since Espressif SDK 1.01 or thereabouts, watchdog timer operation seems to have changed – delays of any length even in init()  are out – or so it would seem? So I got onto Stanza Wang, the business Development Director of Espressif Systems who as always was most helpful and got a quick reply from one of the development engineers on this subject.

It turns out they’d prefer the use of these function:

void pp_soft_wdt_stop();    // close software watchdog
void pp_soft_wdt_restart();    // reset software watchdog

So for example use void pp_soft_wdt_stop();    before your delay and then use void pp_soft_wdt_restart(); 

Delays are not a good idea full stop if you’re using background processes such as WIFI – but you might not be!

Maximum use of FLASH

Thanks to Richard Burton, it is now possible to start programming right down at the bottom of memory – leaving LOADS of FLASH free (though iRAM continues to be a precious commodity – someone needs to do a “how to” on saving RAM. I’ve blogged on this elsewhere with a link.

Debugging and those Pesky Messages

ESP12-EAnd now…. debugging.  I have had it up to here with odd strange output from the Espressif SDK. TuanPM implemented a simple macro called INFO for outputting to the serial port for debugging and general information – but there was no way to control what came out – worse, the SDK kept throwing status information out which wasn’t wanted – so we’ve written our own.

If you’re outputting info to the serial line the best way as we’ve found is to disable Espressif’s messages using


in your user_init function. This turns off all output to the serial – unfortunately that means that os_printf() no longer works – so you’re dead in the water. We wrote our own printf equivalent for the serial port and we call it iprintf().

You don’t HAVE to make it this complicated… if you want you can simply, having disabled os_printf() use ets_printf() where you want text to the serial port – but we wanted more control.

Here are a couple of definitions – bit masking – you might choose to make your own.

This is in our DEBUG.H file

extern int enable_debug_messages; // Needed by debug.h

#ifndef USER_DEBUG_H_
    #define USER_DEBUG_H_

    #define DEBUG 1
    #define INFO 2
    #define RESPONSE 4

#endif /* USER_DEBUG_H_ */

So somewhere in the init, set a variable (see above) to the level of debugging you want….

//int enable_debug_messages = INFO | DEBUG | RESPONSE;
int enable_debug_messages = INFO | RESPONSE;


And here is the function to use that…

void ICACHE_FLASH_ATTR iprintf(uint16_t debug_type, char *fmt, … ){
  char buf[128]; // resulting string limited to 127 chars inc arguments – change if you like
  va_list args;
  va_start (args, fmt);
  ets_vsnprintf(buf, sizeof(buf), fmt, args);
  va_end (args);
  if (debug_type & enable_debug_messages) uart0_tx_buffer(buf,os_strlen(buf));

So basically you have a function you can call with a debug level..

iprintf(INFO,”Starting up the program”);

You can pass parameters to it just as you would with printf….

iprintf(RESPONSE,”The answer is %d”,answer);


Depending on the level of debugging you want you could expand on this greatly.   Someday we’ll convince Espressif to optionally turn off that start-up 78k rubbish and we’ll have totally clean output – for now this is a great start.

A shame you often have to hunt around for this stuff!



As often as not, when I reset an ESP8266 by using the system reset call in the SDK, after flashing – for example.

if (strcmp(token, “id”) == 0) {
                    if (isQuery) RESPONSE(“ID=%s\r\n”, sysCfg.base);
                    else if (strlen(strValue)>=2){
                        strcpy(sysCfg.base, strValue);

The unit does not come out of reset.. the internal startup code will run, maybe there will be a reference to the watchdog – and that’s it. This usually happens after FLASHING the chip.. ie you flash it, you run the code to reset – it won’t.

But otherwise the system_restart works fine.

Anyone have any idea why this should be and how to get around it. I’m not the only one to mention this?


ESP8266 Bliss

You may have seen comments in here from Richard Burton about his bootloader. Well, I have to tell you – what a game-changer. If you look at a previous blog where I showed you how we’d moved code from the fairly normal 0x40000 starting point down to 0x20000 – freeing up LOADS of space for more FLASH code. Well Richard helped with that but he also suggested I give his bootloader a shot. This weekend after clearing out my many other jobs, I decided to get in touch with him.  He pointed me to the source of his bootloader and with a minor tweak to my Windows PATH I managed to get MAKE to work in a DOS box so I could compile it – the upshot of that was a small bootloader .BIN file.

I’m still no use with Makefiles but I managed to generate the .bin file and Richard updated my Makefile. The result.. astounding.


What you see above – the left 2 columns represent the very original code I used with TuanPM’s MQTT as the base. In the middle one I’d moved non-volatile storage up to the top of available FLASH space (which applies to most of the current crop of boards from ESP-01 upwards) and moved the start of code all the way down to 0x10000 giving a massive amount of room for development – unlike the original case where I was running out.

Well, now with the bootloader you can see that virtually the whole LOT is available for programs! No extra cost, no extra work – just getting it right. I’m also now using the non-volatile storage routines in the SDK itself rather than the ones that TuanPM made (pointless having the same code twice). Right now my code (all in including the SDK) finishes at 0x54c00 – not much more than half way up – and that’s in an ESP-01 – the ESP-12 potentially has WAY more FLASH available. All of this is running with Espressif SDK 1.11

All that is needed now is a bit of careful thought as to how to best use the FLASH… there is still a good amount of RAM used up and I suspect that large routines in FLASH will just make matters worse – on the assumption that the whole routine gets pulled out into RAM to be used, I’m think it might better to split large routines up into smaller ones so that RAM can more readily be re-used. Time will tell whether that theory is sensible or a load of old codswallop.

This opens up some possibilities for large FLASH-based lookup tables for light shows – which brings me to the realisation I haven’t a clue how to make good use of that without pulling the lot into RAM – oh, well a challenge for another day. My thanks to Richard and lest we forget – here’s the link to his article on his bootloader..


ESP8266 SDK 1.11

Just a short one for those of you who’ve not tried the new Espressif SDK update yet (SDK 1.11).  I noted a pair of commands “system_param_load” and “system_param_save_with_protect” which appear to replace the need for the load and save functions that TuanPM uses in his code in /mqtt/config.c  – so for the sake of it I gave them a shot – and just to make sure, changed the location a little.  Originally TuanPm was using 3c and I’ve long since moved that up to 7c… well, of course the saving mechanism only uses three 4k sectors, so now I’ve moved it to 0x7d.

With the new base at 0x10000 and the code finishing in my case at around 0x43400, even on the humble ESP-01 that means there is now a WOPPING great 236k of FLASH left… can’t be bad. Tested, works a treat.

As I start to get to grips with the importance of ICACHE_FLASH_ATTR for keeping functions out of limited RAM until they are actually needed, would those who know agree that it is probably better to split up any large functions into smaller ones?  Presumably if not, when any function is called, the whole function ends up in RAM? Yes?


ESP8266 Test Board

I mentioned that Espressif were kind enough to send me a test board to play with – and very nice too. Not had time yet as I’m struggling with learning how to make an installer for my Node-Red package – with some great help from the guys involved with this….

So meanwhile here’s a lovely diagram – which I asked Espressif for specifically so you could see what the board does.

If you double-click on the image you will get a larger version. What’s really nice are the logical groupings. Not TOO keen on the tiny connectors on the right – but the main ones are 0.1” standard stuff. Quite looking forward to having a play.


ESP8266 Development Board


Presents from Espressif

envelope from EspressifLet me start by explaining that Espressif are makers of fine WIFI gadgets.. specifically they have spawned a whole new lease of life for IOT… by producing a marvellous little chip that contains a complete processor, memory and WIFI interface needing only a tiny FLASH memory chip and a couple of “bits and bobs” to make a complete working WIFI router, or IOT device or web server – largely limited to the imagination for, well, a couple of pounds ££…  the price is really what does it – you can buy a little board complete with aerial for less than £2 from China which is just a complete game changer.

Espressif packageAnd for everyone else, well, you know I’ve been working with these chips since day one and am just about to start fitting controllers all over the house etc. based on an overall setup that has been years in the formulation (in English lots of false starts) and currently comprises NETIO for the user control end (possibly soon to be replaced by ThingStudio if all goes well with their current alpha software), Node-Red and Mosquito on a Raspberry Pi2, controlling lots and lots of ESP8266-based boards around the place.

And so… with that in mind I’ve been in contact a number of times with Espressif and they’ve been helpful and keep me up to date. So the other day I received an email to say they were sending me some stuff to play with!  This morning, an envelope arrived in the post.

ESP8266 stuffInside a large cardboard box –  inside that, a package and inside that – a development board and some little modules.

The modules look like ESP-12s but have 2 less connectors – which means no A/D output !! They do have an internal aerial and are marked ESP-Vroom-02 and are “developer only.   The pin-out is not compatible with the ESP-12 which is slightly painful as that means a new rig to program them!  At some point it will be clear to me why they made these, leaving out the A/D – but for now it’s a mystery.

More interesting perhaps is the development board.  It is rather tempting to compare it to another development board that appeared on Ebay a short while ago.

Compare ESP


THe Espressif development board is much smaller and neater but contains a unit that has no less than 24 pins coming out – the most I’ve EVER seen. It does not unfortunately have an internal aerial so I’ll have to go and hunt out a suitable screw-in job. The board is marked ESP8266EX Demo Board and has more connectors than you can shake a stick to. It has an infra-red input, but micro-USB uart and general micro-USB inputs, 5 switches…

and that’s about it  – just got this in the post, thought you might like to see the stuff – not done any experimenting yet, no doubt that will follow soon.


Making ESP8266 Programming Easier

Updated ESP-0109 Apr 2015 – code fix: A little something here from my guest writer and friend Aidan who’s been working with me on the latest home control successes to follow after this blog!

If you’ve successfully written and uploaded a piece of C code for the ESP8266 in any of its’ guises such as the ESP-01, ESP-03 or ESP-12 modules, then you must also be familiar with the process of holding GPIO0 low then applying a reset to get it into upload mode… it’s a PAIN IN THE REAR!!

If you’ve attempted anything more than a simple flashing light program for the ESP8266, then you have probably become frustrated or bored to tears with this process. This goes especially for anyone who is used to programming with the Arduino IDE, where programming the board is a as simple as pressing the upload sketch button. Well, weep no more, salvation is at hand in the shape of another Atmel processor, the TINY85. This chip is a few tens of pennies from Mouser, RS, Farnell or Ebay and we have used it to handle the programming pins for you.

The process is very simple. When you attempt to upload your complied C program using the Espressif SDK in Windows, or I guess Linux (not yet tried), then the DTR line on most FTDI USB to serial units will be pulsed low then high. This is normally used to reset an Arduino which goes into sketch upload mode for a second or two after reset, although you may not be aware of this once you’ve uploaded a sketch.

In our case, the DTR line is used to reset the TINY85, not the ESP module. When the DTR line goes high again, the TINY85 starts up and monitors the serial line coming from the FTDI. If you have started the program upload process using the Espressif SDKs Upload Tool, then it will be attempting to negotiate a connection with the ESP8266 bootloader and so there will be serial data being sent out.

As soon as the TINY85 sees this attempt to negotiate, it drops the GPIO0 line to zero and issues a reset to the ESP8266. Of course, as soon as the ESP8266 comes out of reset, it sees attempts by the ESPTOOL to communicate and the programming process starts.

The TINY85 continues to monitor the serial data stream and holds the rest line high and the GPIO0 line low until the data stream stops. At this point, GPIO0 is brought high and another reset is issued to the ESP8266. This then triggers the normal start-up process in the ESP8266 and your newly uploaded program runs.

Just to keep things tidy, we then turn the reset control and GPIO0 lines into inputs so that you can do whatever you want with them until the next power up or reset events occur.

The code for the TINY85 is shown below and the diagram of the ESP-DEV3 board is here. So, you can see how the lines are connected across between the TINY85 and the ESP8266 if you want to breadboard this. However, the ESP-DEV3 board has all of this already in place, and we’ve put a few other useful items on as well:-

  • Choice of a 10A relay or an optically isolated mains switch with switch terminals
  • DS18B20 or DHT22 temperature/humidity detector
  • LED Indicator
  • Footprints for three of the most popular mains to 5V power supplies to drop into the PCB – we regulate to 3.3V after this as these supplies can be a little bit noisy electrically.
  • A PCB button which we use for triggering a web setup process. If you hold the button down for about 10 seconds after power up, the ESP module generates a WiFi access point (AP) which you can then connect to using a phone, tablet or WIFI-enabled device capable  of viewing a web page. Using this you can also toggle the relay on and off, read the temperature, set the LED etc. We’ll be developing this theme more in the coming months. A really neat addition is the ability to setup a serial, WS2812 LED output.
  • All of the GPIO lines broken out to a 0.1” connector.

MUCH more on that in the NEXT blog entry. We have been mounting the ESP-12 module onto pins and putting the matching 2mm header sockets onto the ESP-DEV3 PCB so that you can just plug a module in and program it. Then it can be removed and added to another project.

If you want to program the TINY85 chip and you don’t have a programmer, then there are plenty of instructions out there on how to do it using an Arduino board.

So, no excuses then…

#define  F_CPU 1000000

#define RST_ESP 3
#define ESP_PROG 1

void setup()
digitalWrite(RST_ESP, 1); // Clear reset }

void loop()
unsigned long st = millis();

digitalWrite(ESP_PROG, 0); //  program mode digitalWrite(RST_ESP, 0); // Reset ESP module delay(200); digitalWrite(RST_ESP, 1); // Clear reset

//digitalWrite(ESP_PROG, 1); // program mode

st = millis();

for (;;)
    if (!digitalRead(SERIAL_MONITOR)) // Got any serial comms?
        st = millis();
    if (millis() > (st + 3000L))
        break; // Comms finished so exit


digitalWrite(ESP_PROG, 1); // Set ESP program pin high – not program mode digitalWrite(RST_ESP, 0); // Reset ESP module delay(200); digitalWrite(RST_ESP, 1); // Clear reset delay(200); // Slight delay to allow ESP module to see GPIO high at power up

pinMode(ESP_PROG, INPUT); // Allow the ESP pin to be used for other things by making the TINY85 pin an input pinMode(RST_ESP, INPUT); // Allow the ESP pin to be used for other things by making the TINY85 pin an input for (;;); // loop forever

For updates don’t forget if you’re a Facebook fan to follow updates on Facebook


An ESP8266 for Arduino Game Changer?

Arduino(updated 2/4/2015)

Here we go again – just as you thought it was safe to start coding, another game-changer comes along.

This time not only do we have an Arduino IDE for the ESP8266 (which isn’t a stunningly good IDE but it’s awfully familiar to many developers) but also what looks like Arduino library integration.

Do you remember way back in the distance when programming life was simple?

void setup() {
  // initialize digital pin 13 as an output.
  pinMode(13, OUTPUT);

void loop() {
  digitalWrite(13, HIGH);   // turn the LED on (HIGH is the voltage level)
            // wait for a second
  digitalWrite(13, LOW);    // turn the LED off by making the voltage LOW

Yes, that long ago.. well that was when programming Arduinos was a doodle, before we discovered the ESP8266-type boards and the unbelievably cryptic commands for port control.

Could all of that be about to change? I just STUMBLED on an article about programming the ES8266 in an Arduino environment. At first this sounded like a backward step, after all the IDE isn’t a patch on the Eclipse environment (IMHO). Anyway I thought I’d investigate. They’ve recently released a new version of the Arduino IDE so I downloaded that and started to investigate. I then found this link

It seems there are a small number of people involved in the development of this – Sandeem Minstry and ivan Grokhotkov – I hope I’ve not missed any names out – but I have to say WELL DONE CHAPS!!!.

In the link above there it seems some had some issues with installation or maybe wanted to use this new tool with their existing Arduino, so a fellow called Roger Clark made a variation – check out his link in the link above. I downloaded the rather large zip file – took out the folder within – and dumped it in the ARDUINO/HARDWARE folder in MY DOCUMENTS.  I restarted the Arduino IDE and went to change the programmer and the device and…

My God it’s Full of Stars

Yup, that worked. I took the standard blink sketch and changed the reference from pin 13 to pin 0 as I was about to test this on an ESP-01.

I can’t tell you how nervous I got as it came to pressing the compile button. I did – and it compiled in about 1 second flat. I put my programming link in, reset the board and…. VOILA – a working BLINK sketch.

But there is FAR MORE to it than this – APPARENTLY it will run the standard Arduino WIFI library – now I CANNOT confirm that as I’ve lost the example code – but if that works – then our struggles with making setup pages are over. And if the MQTT library for Arduino works – well – the SKY is the limit.  I’ve already tried analogWrite(0,128) and that doesn’t work so the NEXT thing is to find some documentation to discover what works and what does not. DELAY() works – at least, it works without setting off the watchdog timer – so those who like LOOPS with DELAYS might be in luck!! No guarantees whatsoever because if you are reading this for the first time, I am only one step ahead of you.

The power, memory and WIFI capacity of the ESP8266 with the vast collection of libraries for the Arduino…  I can tell you… I’m shaking already.

Please do come back with your experiences on this – let’s find out just what we can and what we cannot do with this great new opportunity.

First stop – LCD libraries – I have a GREAT little LCD 240*160 colour display I use for everything but there was no way to convert the library over to ESP8266 – is it even remotely possible I can get this to work in this new environment? The WIFI library works and apparently MQTT works along with simple web page serving – check this out –

Ok so here’s the original link… and instructions as to what works and what doesn’t. They’ve no cracked analogWrite yet but  serial DHT11, onewire, SPI, i2c master… the list goes on.

This just gets better… and better….