Category Archives: ESP12E

RFLink and Node-Red

RFLink Board and MegaA couple of weeks ago I went to stay with my pal Jonathan and he had some Byron doorbell pushes to play with.

This article updated 22/03/2017

He showed me a universal RF 433Mhz receiver board he purchased which could look at the signals from the various kids of 433Mhz standard transmitting units.

This was interesting as I have an Acurite weather station with the most appalling interface which requires a PC to be on constantly in order to remotely access the information.

I don’t know what planet the designers were on – but it was a gift from my wife, solar powered and including rain level, wind speed and direction etc.. a nice job other than the software. It has been sitting outside the wall on my office for months doing nothing.  I thought it might be interesting to get that going.

RFLink

The unit my friend was using was rather expensive but he suggested I try the RFLink software along with a DIY unit comprising an Arduino Mega2560, a little board called an RFLink V1.1.4 (now updated) and an antenna – you see the lot here.

tmpC75DThe kit arrived days ago and I put it together with a soldering iron easily enough but had to wait for a Mega board to arrive which it did this week. I downloaded the software – very simply install program for the PC – couple of button presses really – and that was that. I plugged the little RF board into the MEGA, plugged the Mega into my PC and… out of the blue, information from my Acurite board appeared out of no-where, as did  more one-liners from my Byron button presses and even our doorbell. It took no time at all with help from a fellow enthusiast who’s used this stuff before to figure out how to send a signal back to the doorbell to make it work.

All very nice but I needed this into Node-Red.

I took my latest Raspberry Pi using DietPi and after adjusting comms permissions, simply plugged the USB device into the Pi and set up a serial node for both transmit and receive.

From there on it was easy. Far from complete - but thought you might be interested – the combination of the two boards and that software seems to work really well up to now for receiving from 433Mhz sensors and for sending out commands to 433Mhz boards.

I had a slight concern about how long you have to leave the Byron SX35 pushbuttons before pressing again (3 seconds). But I  mentioned this to the author and within an hour he came back with an update which made the delay much more practical.

Valid input instructions from the various sensors is in this link along with the Arduino software download….

http://www.nemcon.nl/blog2/protref

I bought a bog-standard Arduino 2560 (cheap Chinese version)

I bought this board… the RFLink 433 kit – requires a little soldering…

https://www.nodo-shop.nl/en/21-rflink-gateway

10 minute soldering (take note of version numbers – important), 10 minutes max to blow the software. Test the board (56k baud) to ensure when nearby sensors are sending results – they are coming in and then I wrote this test… it isn’t very elegant yet.

My SERIAL node is set to split input on character “\n” so the code has to get rid of return characters as you’ll see in the “replace” line below. Note also that when you send out serial (to actually control something) it should be followed by both “\r\n”.

RF433

// So firstly a generic means of getting incoming items into an object

var the433 = {};
msg.payload = msg.payload.replace(/(\r\n|\n|\r)/gm,"");
node.warn(msg.payload);
var parts433 = msg.payload.split(";");

the433.p1 = parts433[0];
the433.p2 = parts433[1];
the433.name = parts433[2];

var a = 3;
while (a < parts433.length) {
    var bits433 = parts433[a].split("=");
    switch (bits433[0]) {
        case "ID": the433.id = bits433[1]; break;
        case "SWITCH": the433.switch = bits433[1]; break;
        case "CMD": the433.cmd = bits433[1]; break;
        case "SET_LEVEL": the433.set_level = parseInt(bits433[1], 10); break;
        case "TEMP": the433.temp = parseInt(bits433[1], 16) / 10; break;
        case "HUM": the433.hum = parseInt(bits433[1], 10); break;
        case "BARO": the433.baro = parseInt(bits433[1], 16); break;
        case "HSTATUS": the433.hstatus = parseInt(bits433[1], 10); break;
        case "BFORECAST": the433.bforecast = parseInt(bits433[1], 10); break;
        case "UV": the433.uv = parseInt(bits433[1], 16); break;
        case "LUX": the433.lux = parseInt(bits433[1], 16); break;
        case "BAT": the433.bat = bits433[1]; break;
        case "RAIN": the433.rain = parseInt(bits433[1], 16) / 10; break;
        case "RAIN": the433.rainrate = parseInt(bits433[1], 16) / 10; break;
        case "WINSP": the433.winsp = parseInt(bits433[1], 16) / 10; break;
        case "AWINSP": the433.awinsp = parseInt(bits433[1], 16) / 10; break;
        case "WINGS": the433.wings = parseInt(bits433[1], 16); break;
        case "WINDIR": the433.windir = parseInt(bits433[1], 10); break;
        case "WINCHL": the433.winchl = parseInt(bits433[1], 16); break;
        case "WINTMP": the433.wintmp = parseInt(bits433[1], 16); break;
        case "CHIME": the433.chime = parseInt(bits433[1], 10); break;
        case "SMOKEALERT": the433.smokealert = bits433[1]; break;
        case "PIR": the433.pir = bits433[1]; break;
        case "CO2": the433.co2 = parseInt(bits433[1], 10); break;
        case "SOUND": the433.sound = parseInt(bits433[1], 10); break;
        case "KWATT": the433.kwatt = parseInt(bits433[1], 16); break;
        case "WATT": the433.watt = parseInt(bits433[1], 16); break;
        case "CURRENT": the433.current = parseInt(bits433[1], 10); break;
        case "CURRENT2": the433.current2 = parseInt(bits433[1], 10); break;
        case "CURRENT3": the433.current3 = parseInt(bits433[1], 10); break;
        case "DIST": the433.dist = parseInt(bits433[1], 10); break;
        case "METER": the433.meter = parseInt(bits433[1], 10); break;
        case "VOLT": the433.volt = parseInt(bits433[1], 10); break;
        case "RGBW": the433.rgbc = parseInt(bits433[1].substring(0, 2), 16);
            the433.rgbw = parseInt(bits433[1].substring(2, 4), 16); break;
    }
    a++;
}

// SO - the above is general... here is my specific setup for temporarily displaying
// the Acurite info
if ((the433.p1 == "20") && (the433.name == "Acurite") && (the433.id == "c826")) {
    if (typeof the433.temp !== 'undefined') temp = the433.temp;
    if (typeof the433.hum !== 'undefined') hum = the433.hum;
    if (typeof the433.bat !== 'undefined') bat = the433.bat;
    if (typeof the433.rain !== 'undefined') rain = the433.rain;
    if (typeof the433.winsp !== 'undefined') winsp = the433.winsp;
    if (typeof the433.windir !== 'undefined') windir = the433.windir;

    node.warn("Temperature: " + temp + "c");
    node.warn("Humidity: " + hum + "%");
    node.warn("Battery: " + bat);
    node.warn("Rain: " + rain + "mm");
    node.warn("Wind Speed: " + winsp + "km/h");
    node.warn("Wind Dir: " + (windir * 22.5) + " degrees");
}

Put that in a Node-Red template – attach a Node-Red serial Node set to take serial input from USB0 at 56k – character /r as a separator and deliver ascii strings…and that – is just the beginning…  note also that the designer of this free software has also added GPIO control both input and output – on several pins (recently expanded so check his docs).

Tests: Right now for my tests  - I have the K10000 phone acting as a server running Debian and running Tasker and the MQTT client Tasker plugin with the same phone running as a resource…. and I can now fire an MQTT message at the latter to get a doorbell message out! Meanwhile a Raspberry Pi is running that RFLink unit and when one of the Byron doorbell pushes is pressed – a message is sent out to the phone to play the doorbell – yes, I know, somewhat over the top – but I’m just experimenting for now… and sure enough – press the button and pretty much in real time the doorbell sound appears.

433Mhz to MQTT GatewayIn the comments below you’ll see reference to an ESP8266 to MQTT Gateway – and this would be ideal as it would be all in one little box – whereas I need to stick something like a Pi on the end to generate a wireless MQTT signal…. so – I grabbed the software and (disregarding several wasted hours due to a duff FTDI) put together one of these – as you’ll see in the photo on the right-  the antenna is due to kind feedback below – and as you can see, it is a precision job (it is accurate however).

Well, I have a 4-way remote control for a cheap Chinese remote and indeed this little system does pick it up and sends a unique number for each key off as MQTT – lovely – however – even with a decent little aerial the unit does not pick up (or recognise) my weather station of any of my BYRON pushbuttons – and the data coming back is crude compared to the RFLink software so at first glance, not impressed.

Costs:  Ok of course the hardware for the little ESP board is DIRT CHEAP compared to what I’ve put together – which in turn is cheap compared to one of these all in one boxes – but you pay your money – I’m sticking with https://www.nodo-shop.nl/en/21-rflink-gateway – at under £20 plus £9 for the aerial plus a Mega2560 (cheap from China) I think it is worth it (no I don’t know the company and no I didn’t get samples etc).

The transceiver they supplied costs  £16.51 on Ebay so the board with connectors and the transceiver really is a good deal.  You can of course use cheaper receivers – but the software writer suggests these might be naff. I’d like to hear back from someone who had had GOOD results just using the Mega board (they’re only a fiver from China) and other boards. There is information here on that subject. RXB6 board seems cheap but don’t buy from the UK as they seem to be a rip here – on guy wants nearly £8 inc postage – China for same board – under £2 all in. I’m kind of stuck for testing one of these as I’m off to Spain in a few weeks and chances are it won’t get to the UK in time for me leaving!! Shame as I’d like to have given one a shot on my spare MEGA board.

Summary: Already the RFLINK setup has made my day by turning my otherwise useless weather station into another working part of my home control – and I’ll soon have buttons all over the place. It also has good range though I think aerial design and positioning could be improved.  I can’t do a range comparison with the ESP project as it only recognises one my my 433Mhz devices and even then gives out a number, no proper ID and name… still – worth keeping an eye on for future developments.


If you like this post – please share a link to it by social media, by email with friends or on your website.
More readers means more feedback means more answers for all of us. Thank you!

Facebooktwittergoogle_pluspinterestlinkedin

Grove LCD RGB Backlight

tmpD3E6Now, before anyone says anything – no I’m not advertising Seeed or their Grove stuff. It just so happens that over the weekend my pal brought some of their stuff over to have a play with and I was particularly taken by the LCD display. This is a typical Hitachi-style 16-character by 2 line LCD of the type that have been floating around since last century but which still are popular today I guess because of price. Anyway, this one marked “Grove-LCD RGB Backlight v1.0” is not particularly cheap but it has an RGB LED background and runs off I2c.

We tested it using the Seeed Studio WIO boards (more on that later). Lovely – want a pink background, or how about aqua, or mint -  well, you have full control over the RGB background with values 0-255 for each colour. It occurred to me that this really transforms the otherwise boring LCD display as you can use colour to indicate alerts etc.  For example on a thermostat display you could use orange for on, green for “reached set temperature” and blue for standby.

tmp52FBAnyway, as the WIO modules are little more than an ESP12 I thought it might be more useful to incorporate a driver for this display into my own ESP8266 code. Those of you familiar with the home control project will know that I keep updating the code for the Home Control 2016 project. So – I took a look at the Grove driver for this display – sadly it is in Arduino C++ format so I ended up doing quite a bit of changing to make it do what I wanted and in C – but ultimately it is in there and works a treat. Here are the new commands you can fire out in MQTT to the board with the new software on, using as usual GPIO4 and 5 for I2c.

{rgb_lcd_setup}

{rgb-lcd_clear}

{rgb_lcd_cursor:X,Y}

{rgb_lcd_background:RED,GREEN,BLUE}  // values 0-255 in each case

{rgb_lcd_write:”Your text”}

And that’s all there is to it. A nice addition to the code. I could add more if needed but I figured this minimal set of commands will do for most purposes.

I’m sure there will be other, compatible boards out there – if you know of them – do let us know.

So on the subject of the Seeed WIO boards, I’ve made a separate blog to follow on that – turns out that if you want to have a play, you can blow their code into an ESP-12 – but read the article coming soon.

Facebooktwittergoogle_pluspinterestlinkedin

VT100 Terminal for HC2016

rear view ESP8266 VT100Well, I had to give it a go, didn’t I – porting the code for the cheap VT100-type serial terminal into the main ESP8266 home control software.

BOY was that difficult but… after 2 days of head-scratching – check out the home control manual in the source code repository for Home Control 2016 – this  uses up four precious port bits (GPIO 13,14,15,16).

I have the terminal code up and running (minus baud rate controls… and the bottom line is now a general status line) and I have to say, fast doesn’t start to explain it.

As you can see in the image above, all we have here is the display with a slim ESP8266 board behind it – a WEMO D1 does the job superbly and you can use double sided tape to fasten the ESP8266 to the flat part of the board.  I just used a board I had handy The FTDI you see attached to the back is merely there to provide 5v power and, erm, stand the unit up!!!

At this point I’ll add what I seemed to have missed out of the original article – the pins!

Connections:  Connect VCC to 5v, ground to ground, light to 3v3.   GPIO16 to D/C, GPIO15 to CS, GPIO14 to SCK and GPIO13 to SDI (MOSI).  Connect RESET to RESET.  Leave the SDO (MISO) on the display unconnected.  The whole thing should light up.. and when you give the {ili_set:1} command and reboot the ESP, the display should clear and put up the header. That’s it.

ESP8266 VT100 front viewI did some tests to see if how fast I could make it -  I’ve already optimised the SPI and character routines – the board will not operate at all under ESP8266 at the fastest SPI speed so that is probably a dead-end, I tried caching the ROM reads (which are 8 bits – meaning you have to read 32 bits at a time and select the right 8 bits.

Caching that info actually very marginally slowed things down – I tried all sorts, writing 16 bits at a time to SPI – and finally after being able to obtain no more speed improvements, I stopped – not sure why I needed any of this as it was already blazingly fast.  Now, writing an X to every location on the screen (that’s 1600 character writes) takes 330ms so that is 200us per character (5*7). I think that is fast enough for now. Clear screen is near enough instant and scrolling is instant.

See this demo video of the ESP8266 version – the 328 version isn’t  quite THIS fast but it is still fast.

https://www.youtube.com/watch?v=YXqLVmoyKPE

So I’ve added some commands in the HC2016 project code

{ili_set:1}
The above will setup the display and make it available to accept data – once set the display will set itself up on power up of the unit.  Setting that command to 0 stops any data and from there on the display will NOT initialise on powerup.
{ili_text:"\e[35;40mHello there \e[32;40mmate\r\n"}
{ili_status:"All working exceedingly well"}
{ili_title:"\e[37;40mESP8266 Status Monitor"}

In addition to the above, {ili_rssi} puts the time and date down in the status area AND puts a nice phone-like RSSI indicator on the bottom right, showing the current WIFI signal strength of the ESP board. {ili_reset} resets the display after clearing it – to show the header and the LED rectangles on the top.

If you want to experiment with lines – and remember this is going via MQTT so don’t plan on making complex objects…  {ili_line:x1,y1,x2,x2,colour} but YOU WILL need to clear the screen first -  you can do that with  {ili_text:"\e[2J"} and when you’re done you can return the display to normal with {ili_reset}

{ili_pixel:x,y,colour} will draw a dot. {ili_rect:x1,y1,x2,y2,colour,background_colour} will draw a filled rectangle.
{ili_string:x1,y1,string} will position a string at an arbitrary location
{ili_fore:colour} will set the foreground colour for future strings
{ili_back:colour} will set the background colour for future strings

All of the above require that you clear the screen – you cannot do the scrolling terminal – and arbitrary text and lines at the same time but this does add a lot of flexibility (which I thought of much later than when I wrote this article originally).

The manual that comes with the bitbucket download is updated with new commands.

Hence by firing serial or MQTT commands at the board, I can get stuff onto the display.  To monitor all MQTT traffic was easy – over to the Pi and MQTT..

In Node-Red – a simple MQTT node picks up all traffic, passes it to a function – which then passes the result to the board which in this case is called “thisone”.

tmpPayload=”  “ + msg.payload;
tmpTopic="
\\e[36;40m"+msg.topic+"\\e[32;40m\r\n";
if (msg.topic!="thisone/toesp")
{
msg.topic="thisone/toesp";
msg.payload="{ili_text:\"" + tmpTopic + tmpPayload + "\r\n\"}";
return msg;
}

DisplayHence the board gets all traffic except for traffic destined for the board (which could end up in an infinite loop).

And now thanks to a conversation with reader Bob Green –  a WIFI signal strength (RSSI) indicator for the board and the time in the bottom left. I deliberately left the seconds out as this would typically not be refreshed that often – maybe every couple of seconds...

Bob suggested that by plugging the board into a battery pack you have a simple range tester and he’s absolutely right of course. Now, how to teach it to make coffee…

On the subject of terminals

No need to talk about VT100-type terminals for PCs – they’re coming out of our ears – but…

Android

I’d put this all together and I thought…an 80 line or 132 line version of this would be nice – I’ll put one on my Android phone. Well, you may well write in and tell me I’m wrong but I cannot find a VT-100 compatible serial modem for Android anywhere (I did find one but it was not clear if scrolling regions worked and it had a limited range of serial settings). Surprising considering that it can be done on a  relatively simple unit like the ESP8266

Linux

And that led me to Linux - or rather - I was thinking about the various single board computers I have lying around - a Pi would do but I have a rather nice FriendlyArm NanoPC T2 which was not quite fast enough for Android but runs a nice Debian.  I started looking for fancy graphical terminals - not a lot - nothing to anywhere near TOUCH some of the stuff on Windows - however I had this T3 with a little 7" LCD touch screen lying around and was determined it would not go to waste.

It turns out that the humble LX terminal does at least some VT 100 - but that pulls up a command line and lets you interact with it  -was there any way to get it to talk to serial instead - preferably one of it's own rather than a USB serial as it has FOUR serial ports on it.

Well, yes. I discovered this..

cu -l /dev/device -s baud-rate-speed

It looked as if this would let me use the terminal with serial instead of a keyboard- but of course when I tried it using:

cu -l /dev/ttyAMAT3-s 115200

I got zilch. The system didn't have a clue what CU is (neither did I for that matter).

Anyway, just for a laugh I tried SUDO APT-GET CU

And it worked. I tried again. THIS time all was well - but it could not contact the serial port - as it was "busy" - yeah right.

I added user FA (the user in control of that terminal session) to the relevant group - no difference - so as is often the case I just gave 777 permissions to the serial port and VOILA.

Terminal on Debian running serial

I tested some colour escape sequences from my PC Serial Terminal I wrote some time ago (and just recently updated to let me put ESC in there) and all worked well but for some visible representation of the ESCAPE sequences (which still worked). I continued experimenting and the UX terminal that comes with Debian LDXE does not suffer that particular issue – so it has the job!!!

Facebooktwittergoogle_pluspinterestlinkedin

HC 2016 Experiments

Throughout the development of the Home Control 2016 project I’ve constantly had the software tied a via a serial umbilical to my PC to monitor passing messages, make sure all is well etc. and to periodically check on RAM space to make sure nothing I’m doing is running away with precious memory.

You may have seen elsewhere that I’ve been working with a prototyping board which is basically an ESP12 with a prototyping area in which I’ve put rows of pins for ground, 3v3, 5v and the two lines I use for I2c as I add various peripherals culminating in the recent idea to use an Arduino 328 chip as an “ultimate peripheral”.

Well, we’ve taken that one a stage further and we’ve been discussing making our own prototyping board (Aidan’s a whizz at PCBs and of course we use the likes of Dirty PCBs in China so it is quite cheap to knock up a few boards) and the last few days I’ve been formulating a planas Aidan puts together the schematic. What I’ve realised is that I always run out of the power and ground lines no matter what I do. Add to that the FTDI so I can monitor serial Comms and it all gets a bit messy.

Display for HC2016

So right now we’ve been discussing a board with the ESP-12 module with lots of pins and additionally a 328 SMT chip with Xtal. Of course that means 2 serial monitors. I’ve been playing with the old QDTech 128*160 displays since I discovered that they work pretty well when driven from the proper SPI pins on Arduinos (don’t even think of using software SPI on them) and ramping up the SPI speed – and so it was that in conversation, we were saying “if only you could scroll them” – that led to thoughts of having a RAM buffer larger than the total available on the ESP8266 or Arduino and… well, I thought I’d use our friend Google to go take a look. It turns out – I was completely unaware of this and VERY pleasantly surprised to find – that the QDTECH chip has the ability to scroll up built in – all that is needed is to scroll up an area then paint a fast horizontal black line after each scroll. 

There is a version of the driver for the board here and at some point in 2014, it turns out that an M J Sage added this scrolling ability. Well done.  I wonder if he or she realised what a useful addition this could be.

So now we have a display, easily driven by the 328 which can scroll constantly (I’ve had it on several night’s test) and hence provide a boatload of status info. Top and bottom can if needed remain static.

First Stab

We’re going to incorporate the display onto the prototyping board and it won’t take any additional space as it will sit neatly over the other components! The image above probably bears no relation to the final board but I’m just trying to convey an idea here. The prototyping area on the right of the board will be chock-full of PTH holes but there will be long runs of connected holes for power and I2c as these end up being needed the most with connector wires. All 0.1” of course.

With the QDTech display you can connect the reset line to the 328 reset and hence here are my first thoughts at the use of the 328 which will have access to A6 and A7. I’ve pretty much got this working – just need to add in the temperature handling code I already have for Dallas and DHT chips.

D0-7 – general purpose port extender – inputs or outputs or any mix
D8     D/C for QDTECH
D9     16- BIT PWM out
D10  16-BIT PWM out
D11   MOSI for QDTECH
D12   MISO
D13   SCLK for QDTECH
A0      CS for QDTECH
A1      Temperature
A2      Temperature
A3       Debounced input
A4      I2C to ESP
A5      I2C to ESP
A6      Analog in 1
A7      Analog in 2

Aside from losing GPIO2 and GPIO14 inputs (as they’ll run the I2c) the ESP use will remain the same.  The only restriction being that we cannot run ESP PWM at the same time as the I2c due to timing interference– a pain but not something I can see away around. The I2c 16-channel PWM controller does seem a good way around this as it offloads all PWM work onto a cheap board – for single colour PWM lighting the new 16-bit PWM on the 328 works fabulously.

Given that the 328 can handle inputs for the main board we can do away with our normal GPIO2 and GPIO14 and they can have the job of I2c, leaving all normal outputs as for the existing system.

I guess the end-game here will be the smallest possible board that contains both the 328 and the ESP wired to this spec for general use. But that comes later after we see how well all of this works in practice. First the prototyping board. Watch this space.

Sadly in the link I’ve enclosed, the author refers to Banggood who used indeed to offer these displays for under £3 at a time when there were no software drivers for them – (I think we paid £2.60) but I’ve noticed recently that Banggood have been getting greedy and jacking their prices up – a cursory check of the link shows they now want £5.48 for these simple LCD displays – well good luck with that Banggood.

The only ones I’ve found up to now – and the price is good – as usual – is AliExpress.

Someone have another link?  the board has an 8-way connector at one end and a larger connector at the other – with a full size SD socket on the underside. See the AliExpress link.

This blog entry could well change dramatically as we spot fatal flaws in the plan above Smile

Facebooktwittergoogle_pluspinterestlinkedin

Faster ESP I2C

Experimenting with I2c on the ESP8266? I am – and I’m having a great time with it. If you’re using my code you don’t really need to think about it but if you’re hunting around for better I2c for the ESP – or maybe interfacing the ESP8266 to Arduino – then you’ll love the stuff I’m doing right now – and yes, I AM looking for I2c experts to tell me if I’m doing something wrong because it is all going rather too smoothly.

I decided to take the end from the info from the last blog entry and separate it off as I learn more about I2c (which to recall is a simple 2-wire multi-drop serial communication protocol with separate clock and data).

Why read this? Well, up to now because I spotted a howling issue in the WIRE library for Arduino, found an improvement on the ESP8266 SDK I2C code in the ESPRUINO changes to the Espressif I2c code - I think I found a mistake in it, fixed it then SAILED past the original speeds, reducing a 15ms package best case to well under 3ms  while adding clock stretching into the bargain.  I should clarify at this point that I am NOT an expert in I2C but hey – I can’t get this to fail so I might be onto something! Read on!

So firstly let’s recall -  I’ve been trying to make an Arduino peripheral for the ESP8266 Home Control 2016 project.  I started with the WIRE library in Arduino, working on a small NANO device. I discovered that there are two buffers in WIRE that are 32 bytes in length and hence limit packages to less than that  - I replaced them with a couple of 128 byte buffers and solved lots of issues I’d been having – that is detailed in the last blog.

Where we left off, I’d made a test setup to send a message to the newly-created NANO peripheral which right now on my bench handles a QTECH display and some IO. The ESP8266 I2C is also talking to a BME280 temperature/pressure/humidity sensor and a PWM expander board – so there are 3 devices – some input, some output.

In the last blog entry I’d added a test command for the ESP which could be sent to the board serially or by MQTT and went like this…

{nano:9,7,"how are you today and the weather is nice - NO REALLY it certainly is.",0}

Simple enough – send a message to device 9 (my chosen default address for the NANO peripheral), command 7, a string – and a dummy 0 on the end to tell the device not to bother sending any return info.

As you can see below, this operation takes, using the standard Espressif Ic2 Master code, 15ms in total – not stunningly fast but ok.i2c_thumb2

Flush with the success of finding that buffer issue, I decided to go into the ESP I2C library and have a tinker – changing all the delays into ‘'#defines so I could mess with them. So without any real effort I could reduce delays from 14ms to 6ms – a very worthwhile improvement. bear in mind however that the ESP code has no clock-stretching and hence no way for the peripheral to slow things down. I am told that the call-back routine within WIRE holds the clock down until it is finished, in order to slow things down – this would do nothing but cause havoc for the Espressif code.

Below is a read operation which I got to work properly after reading  this video – as I had no idea what a re-start was – see the little green circle just after the third byte.

read_thumb2

As you can see in the image above I address device 9 (18 as it is shifted left by one – i.e. 7 bit addresses but the bottom bit is reserved to indicate a read or write) – I fire command 2 to read port 4 – then with an I2s restart (start without a preceding stop), I  resend to the device with the LSB set (ie 19) and get a value 0 back (from a pin)  All in a matter of a millisecond.

I was at this point getting worried about lack of clock-stretching – in which a slave can hold the clock low to “stretch” things out a bit – about the only control the slave has!

It looked as if this forum might have some answers as their modification of the ESPRESSIF code certainly had clock stretching in it. It involved some changes and I decided to pick the best bits from their modification.

So they’ve simplified the code a little – while adding in clock-stretching – by replacing a simple delay with a check for clock low – easy enough when you look at it… but they also seemed to have completely messed up master_start – at least, they had it the opposite way to Espressif – and accordingly, repeated starts – as I use in getting data out of a Nano above – simply failed. The logic probe said this was all wrong.

So I reversed master_start back to the way Espressif have it  –so I ended up with a mix of the old and new – and the result – well, up to now everything works – and that long 15ms string send was now reduced to under 5ms from 15ms.

5ms string_thumb[2]

I tested the code with the PWM chip I’ve been playing with and the BME280 – so that is both reading and writing and up to now both were working perfectly. 

It was notable that the clock low period was now much longer than the clock high period and I wondered if there is any way to shorten that.  You know when you get deeply into code and all of a sudden it all becomes clear.  I realised that setting and checking ACK signals was a function – with all that entails – I changed that to a macro. I realised that delays in loops were really un-necessary as the loop itself would cause delays.. I took them out.

At this point I had backed everything up expecting my experiments to fail miserably. I tested the new code and everything worked. I got the logic probe out again.

3ms

My original test string at 15ms was now down to 3ms and according to the probe – all is well. I DID get it down to 2.5ms but the probe said I was doing restarts in the middle of the string – I’ll find another way around that one. Current state of the art – 2.9ms

As for reads – my original byte read was taking somewhat over 1ms – it now takes 0.25ms.

fastish read

And of course I’ve concentrated on the read and write routines leaving the inter-byte handshaking pretty much along so maybe there’s another 10% improvement to make here without dipping into ESP assembly language.

https://bitbucket.org/scargill/esp-mqtt-dev/src 

The driver and firmware libraries in the repository above contain the modified Espressif i2c_master code – and also other I2c wrappers for sending packages – they are fine – any further optimisation needs a good solid look at the one file (and it’s header) for i2c_master.   Open to ideas (that don’t involve converting Arduino assembly language to work with the ESP SDK – been there, failed).

I have just noticed that in the write cycles, there is still more off-time than on for the clock – and so I just took a delay out – which SHOULD mean the off-time is way too slow but because of the time taken to call and process the function – we still end up with 0.9us on time and 1.3us off time – everything continues to work on the tests I have – yet the total time for that read drops from 0.25ms to 0.21ms and the string write time from 2.9ms to about 2.2ms – again – worthwhile improvements.

That simple change was made in the write routine…

void ICACHE_FLASH_ATTR
i2c_master_writeByte(uint8 wrdata)
{
    uint8 dat;
    sint8 i;

    for (i = 7; i >= 0; i--) {
        dat = wrdata >> i;
        I2C_MASTER_SET_DC(dat,0);
      //  i2c_master_wait(I2C_DELAY_5);
        I2C_MASTER_SET_DC(dat,1);
        while (!GPIO_INPUT_GET(GPIO_ID_PIN(I2C_MASTER_SCL_GPIO))) {}
       I2C_MASTER_SET_DC(dat,0);
    }
}

Logic analyser says yes, 3 test items say yes… how low can it go!

Facebooktwittergoogle_pluspinterestlinkedin

I2C the Easy Way

I2c on IOTBEARIf you’re going to experiment with I2C – may as well do it the easy way. Having spent the past few days with a desk that looks remarkably like a bowl of spaghetti, I’ve finally gotten around to making a special IOTBEAR board up for the job. 18 each of ground, +3v3 and +5v lines – and 16 each of GPIO4 and GPIO5.

This gave me the opportunity to tackle that long string problem in Arduino Wire. A brief attempt with the logic analyser suggested that my ESP i2c was sending out at least one byte more than the Arduino was receiving – impossible to tell if more because the ESP would stop sending as soon as the Arduino would stop receiving.

And that brings me to a question – is anyone aware of a nice, pretty I2c and other protocol analyser based on a Raspberry Pi? Seems to me that would be a good use for an old RPI2?

Anyway I digress… I’ve had issues with I2c experiments in the past – usually when sending strings. I’ve looked up the issue on Google and found nothing. I was convinced it was a timing issue and at that point I Skyped my friend Peter Oakes in Canada – just as with Aidan who you’ll have read about in here, I often find that “two heads are better than one” when I’m getting bogged down.

We started sending I2c strings to the Arduino who’s receive buffer I’d put a Serial.println() statement in – to see how many characters it THOUGHT it was receiving.

29…. 30… 31… 32… 32   - EH

As I increased the length of string sent from the ESP (using ESP software I2c) to the Arduino (using the WIRE library) at 33 characters the Arduino thought it was getting 32 – at 34 it went to meet it’s maker.

VOILA – the WIRE library clearly has a buffer to store stuff – I did not believe at first that 1. the buffer would be so small and 2. this would result in a crude crash.  I went into the Wire Library (that’s a long story – I have dozens of WIRE libraries and it took a while to find the right one) – updated the buffer size in wire.h and… nothing – made no difference. I introduced an error into the .h file to make sure I had the right one – sure enough  - but no joy on fixing the problem.

I don’t know if Peter or I twigged first but in my ESP SERIAL buffering which I wrote myself, I have a 256 buffer for incoming characters – which fills until it gets a CRLF then transfers that to an output buffer of the same size – so that incoming characters can continue to arrive while processing the buffer. It occurred to us that maybe the Wire library has the same setup – SURE ENOUGH. Not only is there a buffer definition in arduino/hardware/arduino/avr/libraries/wire/src/wire.h but also in arduino/hardware/arduino/avr/libraries/wire/src/utility/twi.h

And yes, the directory structure IS that complicated (I’m on Arduino 1.69) – sure enough two separate 32 byte buffers are created.  As I have never seen this covered so I assume I’m the only person in the world who’s ever sent 32 bytes via I2c… but if you’re about to try the same – and you’ll need to if you want to try my peripheral software, then I suggest despite the deep hole this will leave in RAM (all 2K of it) – making both of these 128 bytes.

Since amending and re-compiling – I can now send long strings to the Arduino absolutely to my heart’s content!

{nano:9,7,"how are you today and the weather is nice - NO REALLY it certainly is.",0}

Around 15ms in total – not stunningly fast but fast enough not to interfere with the running of anything.

For more on I2C – see the blog entry “Faster ESP I2C”

Facebooktwittergoogle_pluspinterestlinkedin

Arduino Peripheral for HC2016

As many of you know, I don’t have a great deal of time for Arduino – I cannot tell you how many months I wasted on those daft cheap Ethernet boards for them which never really worked reliably no matter what I did – so I probably have a mental block by now.

However, there can be no arguing that a board costing £1.28 inc. postage has to be worth at least a second look. The picture below shows where this all fits into the scheme of things…

Home Control 2016

And so it was today, I’d just finished putting some polishing touches on the I2c code, fresh from having gotten the BMP280 working – and I was looking at A/D boards to add to the arsenal when I remembered that Arduinos have A/D in… not stunningly high definition but good enough for checking batteries and light levels etc.

Nano[6]At that point, mid-coffee I remembered I’d bought one of these little critters from AliExpress. Be careful – not all of these bring A4 and A5 out, some have micro-usb connectors, others don’t. Some have 3v3 regulators, some don’t.  I find the most useful ones just have the FTDI connector on them and no USB – but then I have FTDI connectors coming out of my ears.

For the purposes of this item – a 3v3 regulator is not needed as presumably if you’re fastening I2c devices to the ESP8266, you’ll feed 3v3 to the whole lot. Anyway, use whichever suits you best. I’m also assuming pullups are in place – the Arduino has pullups but I doubt they are strong enough.

SO – the point of this is – it is quite easy to make an Arduino into an I2c slave – so for £1.28 you can make a port extender, more inputs, some analog inputs, PWM outputs – just about anything really as long as whatever it is doing doesn’t take up any time as the board needs to respond to I2c commands quickly. I have a MUCH more powerful device on the way from China with lots more pins etc. but for now, the humble Chinese Nano gets the job.

The simple WIRE library with a little code turns the Nano or similar into a device – I’ve chosen to make it DEVICE 9 by default  – don’t REALLY want to use up ports making that programmable but then because the board has EEPROM I’ve made a hopefully reliable method to store the device number in EEPROM!

In the simplest example, sending I2c commands to this device from the home control software discussed elsewhere in this blog – let’s say to turn output 13 on…

{nano:9,1,13,1}

And indeed that was the very first command I made it respond to as an I2c slave – mainly because on these boards, port 13 has a LED attached to it!!!

Clearly turning it off would be:

{nano:9,1,13,0}

Or how about reading the state of input 10?

{nano:9,2,10}

So here I’ve chosen to create the command nano – command 1 is set ports (2 is read ports)… port is 13, last parameter is 1 or 0 for on or off.  Immediately we have a port expander with several useful ports. For ease, the software I put into the Nano checks to see if the port has already been setup correctly and does that if not – hence avoiding annoying setup code at the ESP end.

With the simplest code and assuming A4 is used as the SCL and A5 is used as SDA, you end up with a “nano i2c peripheral” able to offer (if you get the right board offering A0-A7):

  • 6 8-bit PWM channels
  • 6 8-bit ANALOG inputs
  • 6 DIGITAL INPUTS or OUTPUTS

i.e. ALL of that. You could instead choose to have 18 general purpose I/O lines etc.

I’m sure it would not take most of you too long to figure out ALL SORTS of other configurations but for the sake of this project and this board example– there are ports 2-21 where Arduino A0 is 14. Now,  if your board DOES have A6 and A7, note that they can ONLY be used as analog inputs – they cannot be used as ordinary inputs OR outputs – that’s just a simple feature of the board, not the software.

The point being – they are SO cheap and with this code make good general purpose I2c peripherals – you have to ask yourself – in some cases, why you would use anything else!

So before we start – this will only work for short strings or series of numbers with the standard WIRE library for Arduino – see the blog where I learned the hard way this weekend that WIRE has a 32 byte incoming buffer AND a 32 byte transfer buffer and if you try to send more than that – the Arduino crashes – I’ve updated my WIRE to 128 bytes (so that’s 192 bytes more than before ) and it is working a treat with long strings – the reason I want that is because though you won’t see it in this basic code, I’m now working on running QTECH 160*120 displays in the Arduino peripheral.

I’ve updated the code and here is the current state of affairs – evolving rapidly, for the Nano - expect this to change – again  -  this time tomorrow it will no doubt have changed - again.

 

//
// A simple i2c SLAVE - default device number 9 - reads instructions from
// master and either sets outputs or returns inputs accordingly.
//
// 
#include <Wire.h>
#include <EEPROM.h>

#define MAXPORTS 21
#define ADDR_LOC1 0
#define ADDR_LOC2 1

#define SET_OUTPUT  1
#define READ_INPUT  2
#define READ_INPUT_PULLUP 3
#define SET_PWM     4
#define READ_ANALOG 5
#define SET_ADDRESS 6

byte ports[MAXPORTS];
byte params[6];
byte paramp;
byte retParam;
byte bigcount;
byte device=9;

void setup() {

  byte eeprom1,eeprom2;
  eeprom1=EEPROM.read(ADDR_LOC1); eeprom2=EEPROM.read(ADDR_LOC2); 
  if ((eeprom1^eeprom2)==255) device=eeprom1; // programmable address
  bigcount=0;
  Wire.begin(device);           // join i2c bus with address #9 by default
  Wire.onReceive(receiveEvent);
  Wire.onRequest(requestEvent); 
  for (int a=0;a<MAXPORTS;a++) ports[a]=0;
  paramp=0;
  retParam=0;
}

void loop() {}  // not used yet

// function that executes whenever data is requested by master
// this function is registered as an event, see setup()
void requestEvent() {

  Wire.write(retParam); // respond with message of 1 bytes as expected by master
  //Wire.write(34); // respond with message of 1 bytes as expected by master
  //Wire.write(45); // test
  //Wire.write("This is it you know",19);
}

// function that executes whenever data is requested by master
// this function is registered as an event, see setup()
void receiveEvent(int count) {
int tcount;
tcount=count;
paramp=0;
// no time consuming in here or the routine to send a byte back will be missed.
  while ((tcount--)&&(paramp<128))
   {
    params[paramp++]=Wire.read(); 
   }
  switch (params[0])
    {
    case SET_OUTPUT:
          if (ports[params[1]]!=1) { ports[params[1]]=1; pinMode(params[1],OUTPUT); } 
          digitalWrite(params[1],params[2]? HIGH : LOW); params[0]=0;
          break;
    case READ_INPUT:
          if (ports[params[1]]!=2) { ports[params[1]]=2; pinMode(params[1],INPUT); } 
          retParam=digitalRead(params[1]); params[0]=0;
          break;
    case READ_INPUT_PULLUP:
          if (ports[params[1]]!=3) { ports[params[1]]=3; pinMode(params[1],INPUT_PULLUP); } 
          retParam=digitalRead(params[1]); params[0]=0;
          break;          
    case SET_PWM:
          if (ports[params[1]]!=4) { ports[params[1]]=4; pinMode(params[1],OUTPUT); } 
          analogWrite(params[1],params[2]); params[0]=0;
          break;
    case READ_ANALOG:
          if (ports[params[1]]!=2) { ports[params[1]]=2; pinMode(params[1],INPUT); } 
          retParam=analogRead(params[1]); params[0]=0;
          break;    
    case SET_ADDRESS:
          EEPROM.update(ADDR_LOC1,params[1]); EEPROM.update(ADDR_LOC2,params[1]^255); 
          // update address - will take effect on next powerup of the device as you 
          // can only call "begin" once
          break;      
    default: break;  
    }
}

Facebooktwittergoogle_pluspinterestlinkedin

BMP280 for HC 2016

I have just added a working BMP280 implementation into the Home Control 2016 code (see right menu in blog) returning temperature and pressure.  Add that to the (already implemented) BME280 code, Seeed display, 16,channel PWM, port expansion and more, it’s not been a bad development week really! Manual updated.

The BMP280 as you know does not have humidity – but is cheaper than the BME280.The manual is updated and has details on addresses etc.  Just waiting now for the A/D board to turn up from China.  I’m quite getting into this i2c expansion.

This little picture attempts to show the current state of play for Home Control 2016. No doubt I’ve missed loads off but as you’ll see quite a bit has been added recently.

Home Control 2016

Facebooktwittergoogle_pluspinterestlinkedin

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"}

For clarification - that is a string - which starts and ends with "{" - it is not JASON or ann object. So if you want to send this from, say a Node-Red function you'll have to consider escaping strings.

You might wrap the whole thing in single quotes for example.

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

Christmas at Bedrock

Well it certainly feels like Christmas here at Bedrock (while I’m here, check out this unrelated item – the Ameba – looks interesting).

I got up this morning to a large bag of post – including a new battery for Maureen’s Samsung laptop (though why I mention that in the context of Christmas I don’t know as it is me that has to put it together!!). It’s our 31st anniversary today, incidentally!!

Anyway, there was a parcel for me from Bob Elmour.  He’s been working with ESP8266 boards and like Aidan and myself, making his own boards up. We had a chat a while ago and he said he would send me some samples to play with and write-up.

WELL, I’m very excited – so this morning the package turned up and inside were these VERY professionally packaged and assembled boards as well as some spare parts etc. They are called IoTBear and you’ll be seeing them on EBay and elsewhere soon. I urge you to take a closer look.

IoTBear

These (at least this version) are brand spanking new. There are two boards here – firstly the little IoTBear board with in this case an ESP-12F board – but as you can see they’ll handle everything from ESP-07 upwards.

Essentially the boards have little more than an ESP-12 with a regulator, a reset/programming circuit (on one button, short press to reset, long press to program),, a connector for an FTDI at the end (exactly the same as we would do – why waste putting a USB chip on the board) – and all the pins brought out at convenience 0.1” centres. On the underside, the relevant pin names are printed and there is a cut-able link to disable the one-button programming.

undersideThe other board is similar but with a micro-USB connector for power – and a nice prototyping area – AND though not using the USB pins other than power, he’s brought them out onto 0.1” holes – now THAT’s handy for experimenting.

So this is not a slick commercial operation, just a private individual as far as I’m aware who like use started doing this stuff for fun – his website www.iotBear.com is not up yet but I’m putting it here for future reference. You will find Rob on EBay as user Majikthi5e and if you are interested in any of this stuff I suggest you contact him from there. I’ll not put his email address in here but he’s welcome to share it if he wants in the comments. It is my understanding that he plans make everything from bare boards upwards available. There is some stuff on EBay already.

with FTDII’ve a fair experience of the ESPs and issues with boards and the 3v3 regulator he has used is a good one and the SMT parts are a reasonable size for hand-soldering (with a fine bit – none of yer gas soldering irons please). The only thing that would worry me assembling myself is that micro-USB adaptor but then my eyes are getting old.

The prototyping are is GREAT for all sorts – sticking displays on, relays – all sorts. From what I gather the cost will be reasonable so you could have a bunch of these lying around.

As you might imagine, the very first thing I did was to get out the soldering iron, solder up the 6-way connectors for FTDI programming and program up the boards. I held the little button down and flashed my software into them – no problem first time. I’m looking forward to doing some prototyping with the larger one in the coming days.

OH and there’s a nice 4-sided documentation comes with these board, simple and well presented.

My only gripe so far is that the board is relying on DTR and RTS for programming without pressing a button. TWO issues with that. DTR is fastened straight to GPIO0 – and that leaves me to wonder, what if someone is using GPIO0 as an output – conflicts?  Also – it is assuming two things – that you have control over RTS – and that RTS is available on your FTDI – and that leads to two things – firstly RTS is NOT available on all FTDIs and indeed many – on that matching 6 way connector, bring out CTS – which is an input – not an output. Indeed ALL the FTDIs that I’m aware out have CTS next to the ground pin.  For these reasons – I think I’ll be experimenting with these boards using the programming button and GND/VCC/TX and TX only connected to the board.

Anyway, over to you – if you’re interested get in touch with Rob.

Facebooktwittergoogle_pluspinterestlinkedin