Monthly Archives: July 2016

I2C Continuum

Updated August 07. 2016: This article which started off discussing the “new addition” of i2c to the home control software, is now NOT ONLY about an I2c  2/4 line LCD display facility recently added to the ESP8266 boards – but there’s a PARALLEL version as well, making use of GPIO 4,5,12,13,15 and 16. And NOW – I’m adding a pretty crude interface for the Seeeed OLED displays with other OLEDs to follow.

Comments below about format apply equally to the I2c and parallel versions – for the latter, simply use device 255. Note when you do that you lose GPIO13 as an indicator automatically until next power-up.

Success with I2c – once I realised there was something up at the Arduino end which I could work around, my ESP8266 I2c endeavours have been coming on in leaps and bounds!

And here is my test rig – or one of them – I have one for I2c display and another for parallel display  - the latter is just as messy and has more wires:

I2c

So what you’re looking at there from top to bottom – is a prototyping ESP8266 board (the author will recognise it) just because I had it handy – ESP-12 based, running my rapidly developing software (which now has loads of spare RAM thanks to the SDK 2.0). I put a simple set of i2c commands in there then promptly realised that a series of commands sent by MQTT would not be a lot of use. I then proceeded to waste the day, having already talked successfully to an 8-bit port expander, trying to get one of those back-of-an-LCD I2C boards to work – as it was based on the same chip.

Parallel versionAfter several hours of considering taking up brick-laying I realised the damned thing was bust – and went off in search of my  cheap Chinese port expander – that’s the red thing you see in the middle. The only difference is this does not have a transistor to power an LCD backlight so I just hardwired that. At the bottom – the original test 4-line LCD. Over on the right, an irrelevant Arduino-type board which is also talking I2c successfully.

Having decided I liked the idea of plugging one of the cheap LCDs onto the odd home control board for information purposes, I set about doing something I’ve never done before – reading the Hitachi data sheet. These things are quite cute once you get over starting in 8-bit mode then switching to 4-bit to save on wires etc… (so in total you only need 6 signals to talk to the LCD) and after some timing experimenting (clear screen command takes a while – over 1.5ms) as you can see I finally have a working LCD – and by the look of it, rock-solid reliable.

So what is driving that display (which is updating every second virtually instantly)…

This:

node-red

and inside that inject?

Topic: freddy/toesp

Payload: {hitachi:39,"$1MQTT test$2$i$3Time $t$4Date $d"}

That’s all. So assuming you’re familiar with MQTT (if not – look at other articled in here) the destination is the little board “freddy” – and the new command I’ve just added – “hitachi” talks to an i2c board (the expander) device #39 and sends out that string.

Rather than have a boatload of commands which would be unwieldy in the home control setup – or special characters which might cause issues – I used the dollar as an escape character. Here’s what I’ve implemented up to now

  1. $$ -  well that shows a dollar on the screen !!
  2. $s -  setup – sets up a virgin LCD and clears the screen
  3. $c  - clear the screen
  4. $1 – set the cursor to line 1 -  ($2 $3 $4)
  5. $t  -  fire out the time
  6. $d – fire out the date
  7. $i  -  fire out the current ip address

I’ll probably settle on a 2-liner as they are sub-£2 from China – indeed for 20-off just over £1 – and at £1.34 for the port expander – around £3 to add a nice little display to some of the ESP8266 boards – can’t be bad. indeed, using one of the port expanders for an ultra-low-cost i2c keypad isn’t a bad idea. 45p for the keyboard, £1.34 for the expander… Sub-£2 keypad.

Clearly one way to wipe a line would be “$1               $1” which is probably fast enough for most purposes. I’ll likely think of some more commands.

A reminder that the right hand side of this blog contains links to the Home Control 2016 project, ROMs etc.

And now I have this big decision.. whether to spend £1.34 on a PCF-base port expander… which I need to poll regularly if attaching a keyboard – and no spare pins for a beeper – OR to spend £1.68 on an Arduino Nano which can be turned into an I2c peripheral (granted I might need 2 pull-up resistors) with keyboard buffering and a beep facility…..   OR…. go the whole hog and use another ESP8266 to make a completely wireless keypad.

OLED from SeeedAnd on that latter note – if you abandoned serial I/O which would net one more output – that gives up to 10 control pins – enough for a keyboard and beeper and light. Hmm…£1.43 for an ESP12, 17 pence for a 0.1” adaptor board.   Fully buffered keypad…. Big decision…

And finally – device 255 is reserved for  a PARALLEL version of this using 6 GPIO pins – 3,4,12,13,15 and 16 – operation is identical. All in the code – including the OTA ROMS. Documented in the WORD manual.

Update: On the right you see a Seeed OLED – I starting with this library, code intended for Arduino, I’ve heavily modified it to run in the normal ESPRESSIF SDK environment – but I have to say – the original Arduino version was SLOW, so VERY slow and this is still a little slow – especially the screen clear – I’ve pulled that into one function with an inner loop of I2c bytes, way faster than the original  but even THEN it is hardly nippy – but the important thing is that “Hello World” works – so soon I’ll add the above commands and then figure out a way to speed it up. Right now I can manage {seeed:”Hello world”} or similar. Current software and ROMs are on the web.

Facebooktwittergoogle_pluspinterestlinkedin

Node-Red on a Phone

I have to hand ALL the credit to Dave at the Node-Red Google Groups for this – and you might want to pop any questions in that direction because I know even less about running Android at the command prompt than I do Debian!

Running Node-Red on your Android phone or tablet!! Yes you CAN. it turns out that it is dead easy. Using a terminal program (App store) such as Termux.

So basically install Termux as you would any other app.. and run it – you get the usual black terminal screen. I did this just now on my HTC ONE-M8 – might work on yours – might not.

apt update
apt upgrade
apt install coreutils nano nodejs
npm install -g --unsafe-perm node-red
node-red

That’s it -  you’re up and running.

Well, so that is Node-Red running – of course if you close the terminal you stop Node-Red so the first thing to find out is how to press control-C in that terminal!!! Any ideas anyone?

Once I got back in – instead of starting Node-red I did the following..

cd .node-red

npm install node-red-dashboard

npm install node-red-contrib-admin

npm install node-red-contrib-bigtimer

cd

node-red

Once you run node-red – you can go into the browser on the phone and run 127.0.0.1:1880 and lo and behold- node-red  - probably more usefully would be to go to the phone’s WIFI setup and find out what the IP address is – and run Node-Red in a browser on your PC and that same port number. 

Now why on EARTH would you want to do this. Well, if you could get node-red running as a service on an old tablet – along with MQTT (not sure about that one) all as services – you have a home control server base – with several hours of reliable battery backup (you’d have to run a task to stop the thing turning off I guess.

Well, something for the weekend! As answers (hopefully) emerge for the following – also running my phone with SCP from the PC would be good… I’ve no idea what the user is or the password!!!! I’ll update this.

And the first update – control characters on that terminal… here.

Meanwhile – MQTT Broker Pro which will soon have it’s own basic authentication and which already comes up on phone boot – works a treat – here are the two of them running together as seen on my PC browser.

Node Red on a Phone

Be aware – that the MQTT server does not work if you use “localhost” – you need to use “127.0.0.1” or if you want to access the MQTT server externally – the IP address of the phone. And yes I’ve tested accessing the MQTT broker externally – which is another good reason for it to have a user name and password.

All good stuff.

Facebooktwittergoogle_pluspinterestlinkedin

Nextion Update

As you may know the home control software can work with Nextion displays and there is a  project on the blog on that subject – I note that one or two people are having issues here so rather than reply without pictures -  here’s a general  update.

Home Control 2016 startupCurrently with the home control software, version 1.531 (see right) and Nextion Editor version 0.36 (it just updated on my automatically)  and I’m doing this on Windows 10.

After powering up the home control board, you MUST for the first time issue the instruction {set_serial:2} to the ESP8266 at which point the board will reboot and part of the start up serial info will show as on the right – “Initialised software serial to 57600 baud” – this indicates that the unit is ready to work with the Nextion display. GPIO4 and 5 are used for this purpose and the Nextion board can be powered directly from ours. Ground, to_nextion, from_nextion, 5v – that is how our board is marked but of course you don’t need to use our board. Incidentally don’t be tempted to use your 5v FTDI to power any but the smallest of Nextion boards – I tried this on the large 7” model and killed the FTDI…you’ll need a separate (common ground) power supply for that and most likely anything over the 4.2” display. Don’t forget to change that set_serial command if you plan to use GPIO4 and 5 for something else as the setting is stored in FLASH.

In a simple test I have a plain Nextion panel with two buttons on it. In the background to the page – in the Nextion Editor – I have a “preinitialize event” which contains nothing more than “bauds=57600” without the quotes – this ensures the Nextion board powers up at 57600 baud for the purpose of sending data back and forth.

The two example buttons are marked “up” and “down” and the “touch press event” for each is as follows..

get "nodered~up"

and

get "nodered~down"

If you look at my documentation  - this is a notation I created that returns the above – for example the first one, to the ESP8266 and converts that into an MQTT message:

topic: nodered

payload: up

That’s it – press the up button and the message “up” is sent to topic “nodered” – could be any message you like – and any payload. You can use this directly to turn things on and off without even passing through Node-Red – OR you you have node-red intercept the incoming MQTT message and do something with it. So pressing a button might have an effect on the Nextion display for example. If you see the Nextion WIFI touch-display project you’ll see you can get WAY more ambitious than just a couple of buttons.

mqtt-spy

And lo – as I press buttons – you see the messages coming into MQTT-SPY (or whatever you use to test your MQTT).

That just leaves output to the Nextion itself from the board.

Again for the purposes of demonstration I add a text box in the Nextion editor – the default name for the first new text box would be “t0” so I rename this to “mytext”.

nextion text box

Not very pretty and normally I would NOT use their buttons etc. but make up my own imagery using PowerPoint or similar – but it’ll do for demo purposes.

Nextion displayNow I have to say, the worst part of this is the Nextion editor – progress is moving slowly with this – when you come to program it – make sure you have the right port address because it is hopeless at searching – and if it gets stuck you end up using task manager to reset it – comes up as PRJ or something – I’d so like to get my hands on the source code to give it a good shake-up.

Anyway, there it is- you end up with a window in this case with default text “newtxt”.

nextion display[5]Fire out the command {to_nextion:"mytext.txt=\"Hello\""}

You can do this serially or via MQTT- as the example from MQTT_spy shows.

This results in “Hello” without quotes appearing in the text box. Why the backslashes – that is to “escape” the quotes so they don’t end up terminating the string above – in other words so the quotes are passed through.

The WORD manual for my software describes the “to_nextion” and “set_serial” commands.

Have fun.

mqtt-spy[7]

Facebooktwittergoogle_pluspinterestlinkedin

I2C Conundrums

Resolved  - working though still don't know why Arduino single write was causing problems - however - got a way around it.

Firstly why am I doing this i2c thing? Well, the little ESP8266 is a wonderful thing but there are some chips out there that are really neat and work on I2c. More’s the point there are some REALLY cheap and powerful Arduino-compatible boards out there which benefit from the vast wealth of Arduino libraries – but don’t have WIFI..

So it occurred to me to add an I2c interface to my software – to talk to the likes of the Arduino.

And that it does – kind of – but I’m hitting a brick wall on return data. That is, return data over one byte – well, kind of… let me explain.

The ESP i2c is of course bit-banged because the chip itself does not do I2c – but it is fast at 80Mbps so you would expect it would work without issue. I am using the i2c master software that comes in the Espressif SDK – I’m using version 2.00. I’m programming in C.

The Arduino code is  using the latest Arduino IDE 1.69 and straight forward WIRE code. This is the SLAVE.

I can send multiple bytes to the Arduino - no problem - and I can get a byte back into the ESP no problem.

Now bearing in mind that [a] my experience with i2c is minimal [b] the Arduino I2c looks completely different to the ESP I2c....

When I first wrote this – I was getting reboot problems with the ESP when trying to return multiple bytes. Not every time – just every now and then.

I checked my code and I am initialising the I2c every time I use it – for various reasons.  When I put a logic analyser on the 2 i2c lines, I could see what looked like good i2c – but at the start, a whole load of clock pulses. 48 of them in fact. I went into the Espressif code only to find a loop in the initialisation – (it is in i2c.c).

void ICACHE_FLASH_ATTR
i2c_master_init(void)
{
/*
uint8 i;

    i2c_master_setDC(1, 0);
i2c_master_wait(5);

    // when SCL = 0, toggle SDA to clear up
i2c_master_setDC(0, 0) ;
i2c_master_wait(5);
i2c_master_setDC(1, 0) ;
i2c_master_wait(5);

    // set data_cnt to max value
for (i = 0; i < 28; i++) {
i2c_master_setDC(1, 0);
i2c_master_wait(5);    // sda 1, scl 0
i2c_master_setDC(1, 1);
i2c_master_wait(5);    // sda 1, scl 1
}

    // reset all
i2c_master_stop();
return;
*/

i2c_master_setDC(1, 1);
}

I have absolutely no idea why that is in there but it does not appear to be part of the I2c specification – so I cut it out – all that’s needed at the beginning as far as I can see is for data and clock to be high. The main init routine which calls this one (i2c_master_gpio_init()) sets the pins up the right way (pins 4 and 5 by default).

Well, this did not seem to have a lot of effect – except that now I can’t crash the ESP8266.

So – I can send data to an Arduino with I2c slave running – and I can receive a byte back – wheeeeee.

If I return one byte to the ESP - all is fine - works perfectly – but then the rot….
So --- Arduino...

//function that executes whenever data is requested by master
// this function is registered as an event, see setup()
void requestEvent() {
Wire.write(retParam); // *****
}

That works – and now the ESP

i2c_master_gpio_init();
i2c_master_start();
i2c_master_writeByte((arg1<<1)|1);
if (!i2c_master_checkAck())
{
i2c_master_stop();
os_sprintf(strValue, "duff i2c");
}
else
{
uint8_t a;
a=i2c_master_readByte(); //*******
i2c_master_stop();
os_sprintf(strValue, "%d",a);
}

That also works... but add another write for the Arduino where I've put stars *** and another read in the ESP code where I've put stars – even with a i2c_master_send_ack() in between - it does not work – the second byte is returned (not the first) and then a  255  is returned.

So here is the multi-byte return on the ESP side..

      a=i2c_master_readByte();
i2c_master_send_ack();
b=i2c_master_readByte();

      i2c_master_stop();
os_sprintf(strValue, "%d %d",a,b);

Sending 2 bytes from the Arduino…

void requestEvent() {
Wire.write(33);
Wire.write(45);
}

FAILS!!!

This however SEEMS to succeed and since my other change – seems to work reliably.

Wire.write("This is it you know",X);
// where X is how many chars to send out - I've tested 19 chars repeatedly.

In the above I’m just returning the first 2 bytes of course and this can be turned into byte arrays  or whatever..

I2c logic

But the question is – WHY does the first version screw up?

Anyway here is the ESP code that works with the above where X is 19...

i2c_master_gpio_init();
                  i2c_master_start();
                  i2c_master_writeByte((arg1<<1)|1); // send a read command
                  if (!i2c_master_checkAck())
                      {
                          i2c_master_stop();
                          os_sprintf(strValue, "duff i2c");
                      }
                  else
                      {
                            uint8_t buff[40],a;
#define I2CINB 19
                            for (a=0;a<I2CINB;a++) {
                                buff[a]=i2c_master_readByte();
                                if (a<(I2CINB-1)) i2c_master_send_ack();
                            }
                            buff[a]=0;
                          i2c_master_send_nack();
                            i2c_master_stop();
                            os_sprintf(strValue, "%s",buff);
                      }

Lovely – now I need to find some i2c chips to experiment with. I have an ATMEGA1284 setup to respond to i2c for port input, output with PWM and analog in where appropriate – the 1284 you may recall has a lot more pins than the Arduino.  I have a few variations of miniature boards on the way to test. When I really go to town on this I’ll no doubt blog it.

Facebooktwittergoogle_pluspinterestlinkedin

Node Red Dashboard

node-red-dashboardAs regular readers and fans of node-red will know, I’ve been a fan of node-red-contrib-ui for some time – I wrote about adding security to it some time ago and until Imperihome came to my attention I was developing pages based on this.  But, sadly the fellow developing it ran out of time I guess. One day he was working hard on it – the next – nothing.

Some time ago I became aware that the Node-Red guys were developing this and today they announced that Node-Red-Dashboard was available on NPN.

If you have node-red-contrib-ui on your Node-Red installation – and are not using it – simple uninstall.

I stopped Node-Red, in a terminal went to my .node-red directory and..

npm remove node-red-contrib-ui

npm install node-red-dashboard

node-red-dashboard[8]node-red-dashboard[6]That simple really, at least it was for me – unless you’ve heavily invested in the former there is no point in keeping it any more as development has stopped. So – what’s new – well, it is early days, if you don’t like simple light or dark – well, that’s unfortunate because right now you have two  theme options – but that’s a start and the gauge and graphs shown above right took seconds to set up with this simple set of nodes – a couple of injectors firing out 2 numbers – and the gauge and graph nodes – that’s it.

Dashboard looks remarkably similar to node-red-contrib-ui and time will tell how compatible it is but the gauge alone has been markedly improved and is lovely – you can control size, there are four different types of gauge – it  really is easier to try it out than to discuss.  There is now a simple dashboard on the right of the Node-Red web page to allow you to re-arrange items by drag and drop – this is a great improvement.

You’ll be making simple pages of imagery in no time – as for actually making worthwhile dashboards – well I suspect that will be down to how good the documentation is.

node-red-dashboard

Let us know your experiences with this.

Facebooktwittergoogle_pluspinterestlinkedin

ESP8266 Home Control Update

As the blog entry on using my home control code ROMS for ESP8266 is filling up and of course as much of the information is now dating I thought I’d do a new blog to bring everyone up to speed and move the conversation to this blog entry. The good news is  - the code is now running under SDK 2.0 – i.e. bang up to date at the time of writing.

Firstly – yes, everything works – but the procedure for flashing ESP-12 etc has changed ever so slightly. I have updated the binary files to run on Espressif SDK 2.0 and updated the RBOOT code I use for OTA (over-the-air updating) to the latest version.

To backtrack a little

For anyone new in here – some background - I’ve written software for the ESP8266 which has been in operation for some time and is under constant development. It allows the ESP8266 to control things like simple lights, serial LEDs, PWM LEDs and read sensors etc, talking via WIFI and MQTT to whatever central system you have – for example a Raspberry Pi with Node-Red. I’ve written a node to allow endless units to log in and to provide central communications for them. The software is rock solid and runs 24-7.

I use Windows to develop the software using the Cherts unofficial development environment. This provides an IDE using Eclipse for running and compiling C code. It is not necessary to use any of this if you simply FLASH the ROMS which are available – but of course if you do use the IDE you can customise code for your own use.  The projects Home Control 2016  and Nextion WiFi Touch Display both use the same software and are the end result of many years developing home control. Personally I access much of this equipment using Apps like Blynk and more recently Imperihome (see also this article, this and this).  Tools I use in Node-Red include my own BigTimer node.  All of these options were chosen after much deliberation.

So what have I learned and what has changed?

All has been going well until recently when the Espressif SDK for ESP8266 was updated, firstly to 1.54 then very quickly followed by 2.0 and all of a sudden I and other started to have issues starting up ESP8266 boards. This is now resolved incidentally.

Firstly one of my problems was lack of serial output on power-on. Some serial (115Kb) status messages I have on power up, just point-blank refused to show. I figured the code might be starting at the wrong place. But no, a quick port flick at power-up proved that everything was working – but no serial out.

After much debugging, I discovered that there would be no serial output until this function:

  wifi_set_opmode(0);

had been called. Prior to SDK 1.54 this was NOT the case. Simple enough - I put this at the start of my code – I’ve just checked and web updating works just fine - but merely moving this function to the start solved all the serial output issues.

Incidentally much is made of the “garbage” that comes out of the ESP8266 on power up – it is just that Espressif chose to use 78,600 baud instead of a more popular one. If user software is set to this speed rather than, say, 11500 (which is what I use) then things look very different – diagnostic on power up followed by user code – all very seamless. Problem is – not that many serial terminals support 78k.. but I digress.

The second problem was a tendency for the unit to run away with itself, firing out garbage as if the ESP-12 was broken. It would SEEM that post-SDK-1.53 or thereabouts – it is NECESSARY on initial run, to flash location starting 0x3fc000 (end of the 4th page in a 4MB Flash chip) with the default file esp_init_data_default.bin which is found in the Espressif development kit.  If this has already been blown (previous installation) then it is not necessary to redo that, but with a CLEAN FLASH, failure to flash this area results in the continuous rubbish on output. Again this did not seem to be the case before SDK 1.53/4 – I have NEVER flashed that location in the past. Once blown it is not necessary to blow this again for OTA. Still – now we know.

I’ve just had a Skype chat with Espressif engineers to try to dig deeper. They have confirmed the small file at the end is essential (I probably didn’t notice it before as I’d generally be using boards already programmed) – the serial issue we’re still trying to understand – but it all works.

System Data

There are 2 relevant files here. A file called blank.bin sits at 0x3fe000 (top of the third MB in a 4MB Flash i.e. ESP-12) and contains default system parameters produced in the SDK.  NOT setting this initially seems to have no effect on my code.

A file called esp_init_data_default.bin sits at 3fc000 and contains default system parameters stored in the SDK. This is a 1K file. This HAS to be blown when first setting up a chip.

What to do

There is a binary file called esp_init_data_default.bin which I have added to the server at www.scargill.net – this is in addition to rboot.bin and romx.bin

In the Espressif setup there is a file called ESPTOOL – there are exe versions and .py versions of this floating around (see below). This is what I use to flash the ESP8266 chips – there are others – you may use them – but I can’t VOUCH for them!

https://github.com/themadinventor/esptool

https://github.com/metalheart/esp8266/raw/master/bin/esptool.exe

In Windows this works for me – you will have to check for yourself.

To completely wipe an ESP12 – including all data and setup etc and assuming COM3 in this case (not necessary but if it makes you feel better)…

esptool.exe  -p COM3 -b 115200 erase_flash

To initially flash the code from scratch… assuming you have the 3 files mentioned above…

esptool.exe -p $(COM3) -b 115200 write_flash -fs 32m -ff 80m -fm qio 0x00000 rboot.bin 0x02000 romx.bin   0x3FC000 esp_init_data_default.bin 

Obviously you can change port, speed and file locations. I usually double up on that baud rate but this one is safe.

If you insist on trying this with an ESP-01 (no way will OTA work) – that 3FC000 address becomes just 0xFC000 as they only have 1MB of Flash unless you upgrade them (discussed in another blog in here – done – easy).

As an alternative, I’ve tried NODEMCU FIRMARE PROGRAMMER and that seems to work…

NodeMCU

Nodemcu[6]

And so there it is – the source is updated on the web and requires SDK 2.0 or better to run. The ROMS are updated and the new file is up there.

Bear in mind there is some data here NOT being erased (see full erase command higher up) – in my case at 0x79000 – or around half way up the first megabyte – this is USER data – stored passwords etc. it was put here for compatibility with ESP-01 but I’m about to move this way up to 0xf800 leaving the best part of a MB for code – plenty of room.

And why?

Why worry about updates indeed? Well, one good reason – is that recently, updates to the SDK have used LESS precious RAM – the kind that programs (not data) run in – so with 2.0 there is more margin for expansion – which means more features and more room for more features! It is fine having 1MB to put code in but that is generally NOT the limiting factor with the ESP8266. The code ultimately has to run in RAM and there’s a slight bottleneck there – the gains of later SDK updates help a lot.

Update 31/07/2016

Having now  added i2c and parallel LCD displays to the board, I set a parallel LCD running from MQTT and updating all 4 lines of the display, once a second from Node-Red. While this was running (it’s been running all afternoon – I thought I’d try a test)… I set my serial terminal program fire out lots of on-off commands in a row – which is WAY over the top…

I set up 30 on/off commands for GPIO0 – to run at 80ms each – as you can see clean as a whistle.  I dropped that to 50ms per instruction and the board rebooted – I’m guessing that is a buffer overflow – but then – that simply is not going to happen in real life or anything like it.

I figured I’d go for broke - with 390 (I got sick of cut and paste) commands sent at 80ms it lasts almost to the end then rebooted – again a sure sign of the buffer being in trouble either overflow or wrap – backing that off to 100ms gave zero errors so not a wrap issues – Very happy with this – typically the boards get no more than a few instructions a seconds – often MUCH less. For the sake of it I think this coming week I may just take a look at this – firstly to see if at such speed, my terminal is screwing up – and if not – I’ll see if I can narrow that down but it is utterly academic

serial tester

A complete and utter aside

I don’t use the Arduino setup but as I was thinking about user data, I just checked the Arduino EEPROM library SOURCE for ESP8266 and the Arduino environment does NOT use the 3-sector trick employed in the SDK. When you update the EEPROM (which is actually FLASH on the ESP8266), the sector is wiped (even if you have user data smaller than 4k, a 4k sector is still used) and then updated from RAM – not ideal.  I have suggested to the designer that it might be a good idea to change this. Right now he’s busy working on ESP32 code.

So there it is – all working – hopefully I’ll soon get some clarification on the routine I mention above that I had to move. Time to start adding new features!!!

Facebooktwittergoogle_pluspinterestlinkedin

WIFI Smart Socket

Smart socketIt looks like Itead have done it again – another winner – well that’s all down to the price and I’ll leave you to look that one up…the site says £9.76 for the unit which is reasonable – but I didn’t check postage.

The first modern WIFI wall socket I had was the Orbvibo Smart socket. I could not re-program it but I did manage to get Node-Red to talk to it over a websocket interface. I think it lasted a week before losing the info, then I discovered that Amazon had stopped selling them because of some regulation or other.  Not a nice experience – but they DID look nice.

Smart Socket[6]Similarly – the Itead  unit is good looking (though you would not tell it was theirs based on the one I have – there’s no reference to Itead on there at all and there were no instructions in the (very pretty) box. Probably because this is new (but available). This is an EU socket not UK so if you’re in the UK you’ll need a simple adaptor unless you want to live dangerously.

There is a programming button – which handily goes to GPIO0 on the ESP8266. Again a slight gripe here, once again they’ve Smart Socket[8]used a 1MB FLASH -  fine for their purposes but if ONLY they’d used the same as the ESP-12 (4MB) I could have done OTA – I believe there is other software that might be suitable which fits into the smaller space. However – not that big a deal. When my new 4MB Flash chips turn up I may just replace theirs.

pinsThe Smart Socket is designed to work with Itead’s APP – and if that’s what you want – read no further. It makes for a nice cheap WIFI controlled socket.

In my case of course I wanted it to work with our own software and hence remotely over Node-Red and MQTT – I suspect readers in here will want the same. So – out with the screwdriver – it turns out this was to be incredibly simple, once screw then finger-nails in the edge and it pops open  – there’s a 4-way set of holes which you can just shove wires into – ground, TX, RX and VCC.  I applied the relevant wires from my FTDI (obviously RX to TX etc)  to the holes – ensuring that [a] my finger was on the programming button at the time and [b] my FTDI was set to 3v3 – not 5v (important).  I blew the ROMs into the unit – this is covered elsewhere in the blog and is easy) and lo – one WIFI controlled switch I can control over MQTT etc.

I mean – it was that easy  - I’m missing the bit out about making a  change to my program to slow the flashing light down as the lights in this thing are BRIGHT.  So the green light is the general indicator (GPIO13) which I use all the time (thank heavens) and as in the SONOFF they use GPIO12 for the relay AND a nice blue light – so when the unit is running it is flashing green – if the output is on there is also a blue glow. Very nice.

So – there you have it – another winner.   It’s all down to postal charges really… oh, the relay claims 2KW – I’ll leave it up to someone else to see if it is up to that – I’d suggest that putting a 2KW electric heater on it will probably not work too well. It would be nice if a 1KW heater would work… anyone up to testing that ?

Facebooktwittergoogle_pluspinterestlinkedin

ESP8266 Meets Arduino via I2C

If you’ve been reading the blog regularly you’ll know I added I2c to the ESP8266 code some time ago – that is, the ability to send an I2c message either to read or write – originally intended and still working with cheap I/O expanders – so you lose 2 wires (GPIO4 and 5) and gain another 6 or 14 for one or two I/O expander boards.

Well, I’ve updated it as of tonight.

Of course, ESP12 talking to Arduino is nothing new but given what we’ve built up here with the ESP boards and Node-Red I thought it might be useful to have the option to expand further.

What a few hours ago seems like something in the distance – well, it is done – and it works – and it has LOTS of potential. Read on.

ESP8266 and Arduino and I2c

What you see above (the FTDI is just stuck into the ESP8266 board for power) is a 1284 Aiduino boards flashing lights  - controlled by MQTT – that is, the ESP12 board on the RIGHT is taking in the MQTT and sending commands via I2c to the 1284-based board and to the little red expander in the middle (on the same 2 pins).

Hence, I’ve spent the day working on the I2c code adding the ability to send multiple byte parameters and to receive a byte (I could have made it receive multiple bytes but for simple control a byte will do).

ATMEGA1284The next step was to set up an Arduino – or in my case specifically an ATMEGA1284 chip to talk to the ESP – hence giving us the ability to control Arduino ports via Node-Red.  Now as yet another blog entry here will testify, you can of course connect (now that the node is fixed) an Arduino directly to the Raspberry Pi in charge – but puts too many physical constraints up.  I had no intention of developing Firmata on the ESP – and so a simple i2c protocol was develop and SO much more can be done.

Right now I have an ESP8266  on the bench with a 2-wire I2c connection to an I/O expander – and an Arduino-type board using the 1284. I can talk to both from the ESP (and hence from my Arduino wirelessly via MQTT) and can control the following:

  • Any pin as an output (and PWM outputs where appropriate
  • Any pin as an input (and analog inputs where appropriate)

So first things first – I used  the Atmega1284 simply as I have loads of them – both DIP40 and surface mount in our little AIDUINO boards. The 1284 has twice the RAM of a 2560 and is easy to use. However this would work equally well in a normal Arduino or in the massive 2560 boards.. the only difference being which two pins are used for i2c. The red chart above, shamelessly stolen from ManicBug’s website shows the pins (in parentheses the numbering system I use).

So in the ESP8266 (grab the latest ROMS or SOURCE) I have a simple method of communication which can be used by MQTT or serial. The format is similar to that used elsewhere in the home control system.

i2c:  device, return, param1, param2, param3, param4, param5.

Not all parameters are needed.

So – to talk to an i2c expander sitting as device 39, connected to pins 4 and 5 of the ESP board…

{i2c:39,0,3}

device 39, no return value, send out 3 (which lights up the bottom 2 LEDS.

{i2c:39}

This returns the value in the port expander.  this is covered in two previous blogs.

http://tech.scargill.net/sunday-morning-experimenting/

http://tech.scargill.net/i2c-expansion-for-raspberry-pi/

So what has changed is that the code can now send out multiple parameters – and optionally receive information back.

{i2c:8,0,1,20,1}

The above sends out to device 8, expecting nothing back, type 1 means set a port bit, bit 20 in this case (see red table above) – to 1.

{i2c:8,1,4,30}

Above – device 8, 1 means return a byte, type 4 means read analog value and port number is 30 – the instruction will return the value of the analog input.

1 is digital out, 2 is digital in, 3 is PWM out, 4 is analog in – you must use appropriate ports – not all are able to handle analog in or PWM out… and you don’t have to worry about port direction setting – this is checked before any operation and set.

There is SO much more potential here but only so many hours.  I will likely make the settings for outputs non-volatile at some point – and add in all manner of device monitoring and probably also make use of the multiple serial ports on these devices.

For now that’s not bad for a Sunday session.  If you’re seriously interested I’ll make the Arduino code available but right now it is highly volatile – but it works!!

Facebooktwittergoogle_pluspinterestlinkedin

Sunday Morning Experimenting

I figured after a couple of horrendous days figuring out what was wrong with my ROMS, it was time for a morning’s relaxing.  Some time ago I added I2c to the Home Control software but never actually got around to doing anything with it.  The i2c parallel expansion modules I got from Ebay have their own pull-up resistors on them… could I get away with hooking 2 boards up without having to dismantle surface-mount pull-ups on on?

test ledsSo first things first I wired up some test LEDs comprising a some AQUA LEDs I had lying around and 120r resistors. I looked all over for pre-made leads with female 0.1” connectors on them but as usual ended up making up my own. If anyone knows of a good cheap source of these – do let us know in here.

Next stop I needed a test board and the obvious one to use was one of the samples I got from Bob Elmour.

A few extra ground, 3v3 and 5v lines (0.1” connector strip) along with GPIO4 and GPIO5 brought out and I was in business. Ok, not the prettiest layout but good enough for testing.

And… yes, I’m not sure I’d want to go beyond two without removing resistors – but they work. With one DIP switch set to ON-ON-ON and the other to ON-ON-OFF I found I could easily use i2c to turn on and off LEDS on both boards at addresses 39 and 38 respectively.

ESP8266 board

It is worth noting that the output DRIVE capability of the little red boards is not that good (as the outputs are also used as inputs with pull-ups) and so to get a decent output I fastened the LED + leads to +3v3 and used the expander boards to SINK current (which means the output logic is inverted).

Using the come control software, lighting up those 4 LEDS is simple.

{i2c:39,0,3}

{i2c:38,0,3}

(The zero is a recent addition and simply says there is nothing being returned. See future blogs for more extensive use involving multiple parameters and an optional return value).

So for the loss of 2 wires, you get 16 outputs using I2c and at a cost for boards of around a fiver. Not entirely sure how well that compares to sticking an ATMEGA24560 onto the ESP and doing some custom software to let you control the outputs (I have thought about this)… but it is certainly one easy way to get more inputs and outputs.

Facebooktwittergoogle_pluspinterestlinkedin

ESP SDK and RBoot Woes

Remember I did an article entitles Serial Woes? Well that’s been changed to serial success as we found bugs in tools and gained an understanding of the USB FTDI handshaking lines – which altogether led to improvements in the Node-Red Arduino node and a completely working solution for USB Serial on the Raspberry Pi.

Well for the last few days I’ve been at the WOES part of a serious issue with our ESP8266 code.   I’m hoping if Espressif see this and Richard of RBoot fame see this and we can get a little interaction – so that what looks like an issue with Espressif SDK 1.5.4 and Rboot can be resolved. I’ll update this as we go along. 

So – those of you who’ve been reading this blog for a while will know that I’ve put a lot of work into developing my own code (along with a lot of help from others) for the ESP8266 to control ESP-12-based boards designed by Aidan Ruff – the software talking via MQTT back to a central controller – this is all working and is regularly updated. The software is BIG (well over 0.5 meg and hence for OTA purposes needs boards with a 4MB FLASH like the ESP-12 though currently it will work without OTA on the likes of the Sonoff controllers) – and is available as source code and .ROM files.

So a few days ago some guys in the blog wrote in to say they were having horrible difficulty flashing my ROMs and indeed that their boards were apparently broken!!!

I could not replicate this behaviour – I would take my ROMS, blow them – and all was well, my code worked. The code uses Richard Burton’s RBOOT to allow for OTA (over the air updating).

And then… I tried blowing the ROMS into a virgin ESP8266 board (and I mean virgin with no software on it – not one stocked with AT software). DEAD. But not just dead. Dead sometimes… and when it worked – it worked kind of.

Image636042896730738685

Here’s what I mean. Look at the first image above – that’s  a normal boot up of my code. “ESP starting…”  some info on the use of GPIOs etc., software version and right at the end, another function is called which outputs “Web page control enabled” (or disabled).

Now look at the code below.. this is the output when I CAN get the code to work with SDK 1.5.4.1.

Image636042895980185009

Do you see what is wrong – the “web page control enabled” message comes up FIRST – you might say that is IMPOSSIBLE – that code does not run until after the other stuff is all done… and there are bits missing – but more often than not the code does not run at all - and that is what pointed me to the problem – and the “solution”.

Here are sequences of events..

  • Start with an existing ESP
  • Flash my code
  • Output probably ok
  • Start with something like the NodeMCU software rom
  • Flash my code
  • Output seems ok but has the above nonsense (but works)
  • Entirely WIPE the FLASH (yes, there is a quick way)
  • Flash the new code
  • Nothing works
  • Load the NodeMCU rom (works mainly)
  • Flash my code
  • Works sometimes – might not work after reboot – but might.

This is cutting a LONG story short – a story of using various programs to try to wipe the 4MBYTES of the ESP-12 only to find in one case that the final meg would not erase – or in another case that no matter what address you put in it was always ONLY the bottom MB that was being erased – that wasted a few hours I can tell you!!!

Finally I hit on this – more by accident than anything else:

C:\Espressif\utils>esptool.py -p COM3 -b 115200 erase_flash

This took an instant and appears to wipe the entire Flash perfectly.

Even using the official tool would seem to work – but when you watched the addresses go by – it was obvious that only the bottom 1 meg was being erased!!

Wipe the Lot

But I digress.

So when I finally got to analysing the problem (scratching my last hairs out) and realising that something was wrong – maybe a start up vector in RAM not being set properly, I decided to try something – instead of using the latest Espressif SDK 1.541 (which coincidentally I loaded and compiled at about the time people started griping about non-working boards – but of course I was simply OTA-ing my existing, working boards and seeing nothing) – I went back a version to 1.53 – and….

IMMEDIATELY (thank heavens) the problem went away – I could now program the boards in the normal way and they worked (work) perfectly. 

So at www.scargill.net there are some working roms using SDK 1.53

rboot.bin and romx.bin

The above work (for example http://www.scargill.net/romx.bin)

Here is the same compiled under 1.541

rboot_duff_154.bin  and romx_duff_154.bin

These are the ones that were up there until now – and were giving trouble. I’ve just renamed them.  Easy to test – put the first at 0x00000 and the second at 0x2000 (that’s 0x2000 NOT 0x20000) after running that erase procedure above – and one will work – the other will not.

So – the question is now – is there something wrong with the Espressif SDK 1.541 – or have they moved or changed something that is giving Richard’s RBOOT (which has not changed for a long while and which has proven to work perfectly) trouble. Surely it has to be one or the other.   My impression, rightly or wrongly is that the code is starting up in the wrong place – sometimes in the middle of no-where, sometimes almost in the right place (hence the re-arrangement of output).

I’ve pointed both Richard and Espressif to this as it is possible to replicate the issues quite easily on an ESP-12 (my viewable serial output at powerup is 115k baud after the usual 78k debug info).

Hopefully this will become a shorter success story with a fix somewhere. If it is affecting my code – it has to be affecting other code (and no I’m not running out of variable RAM – thought of that). Right now I simply cannot use SDK 1.541

Thoughts?

Facebooktwittergoogle_pluspinterestlinkedin