Category Archives: Raspberry Pi 2

Grafana and InfluxDB

GrafanaSome time ago I wrote a blog entry about garden sensors inside of which was buried some information about using Grafana and InfluxDB. At the time the install was not that easy – and when along came STRETCH for the Raspberry Pi (2 and 3) it got worse.

However, reader Antonio and I have been working on this and we have an install for the latest Grafana with Influx.

Continue reading Grafana and InfluxDB

Facebooktwittergoogle_pluspinterestlinkedin

The Real Raspberry Pi

I’ve been using the likes of FriendlyArm boards and similar for so long now, struggling at first with GPIO and I2c and as regular readers will know, finally pretty much mastering it due to hard research and more importantly, the works of people you’ll find links to in other articles in here….. that I’ve pretty much ignored the actual Raspberry Pi for some time.

Until this week when my friend Jonathan sent me a Raspberry Pi 3 to check, as he’s been having trouble with “the script” and I could not help as my RPI2 installations worked just fine.

Continue reading The Real Raspberry Pi

Facebooktwittergoogle_pluspinterestlinkedin

I2C Expansion for Pi and ESP8266

Pi ExpansionWant 64 GPIO pins on your ESP8266 or Raspberry Pi? Read on.

If like me you are not THAT familiar with I2c, you might find the results of my  experiments interesting and perhaps even useful.

If like me you are not THAT familiar with I2c, you might find the results of my  experiments interesting and perhaps even useful.

PCF8574TSo I bought a couple of these i2c port expanders from China – mainly because I wanted something simple to mess with i2c on the ESP8266. It occurred to me that if I could get these working on a Pi, so I was sure of the addresses and commands etc., then on the ESP, I’d then get the confidence to do something more dramatic on the ESP8266 with i2c.

So ignoring for a minute the interrupt capability, these are pretty basic devices – using up 2 port bits (SDA and SCL) on your Pi or ESP, send an i2c start to them followed by an address then a byte to them – and the outputs light up accordingly. Set the outputs to 255 and read back a byte and you get the state of the pins as inputs. It doesn’t get any easier.

Well, not unless you completely mis-interpret the addressing as I did and spend ages chattering away to the wrong address. Anyway, let’s not dwell on that.

I noted that the outputs are HIGH by default.  Also note that in my experiments I have set the 3 DIP switches to ON (NOT as in the photo above).

Armed with the latest version of Raspbian Jessie on a pi2 or Pi3, connect ground on the device to ground on the Pi, VCC to 3v3 on the Pi, SDA to SDA (blue) on the Pi, SCL to SCL on the Pi. Simples. The boards have built-in pull-up resistors for i2c (which could pose an issue if you parallel a bunch of them up of course) so that’s it – no other new components needed other than a LED for testing. I used a 470r resistor in series with the LED.

Open a terminal on the Pi and type:

sudo pigpiod

That starts the new GPIO library daemon running in the background.

Now here is a short file that will set all the outputs to 0 – running Python…

import pigpio

pi1 = pigpio.pi()
pi1.write(18, 0)

b=pi1.i2c_open(1,39)
pi1.i2c_write_byte(b,0)
pi1.i2c_close(5)

Nice but then my pal Peter Oakes pointed out to me that I’d end up loading the entire Python environment  every time I wanted to change an output.. so I started experimenting with C code… just turning GPIO18 (on the Pi) on and off for starters…. see the line that says gpioWrite(18,0);  that turns the port off. Substitute a “1” to get the opposite effect.   All of this worked a treat.. “b” here ends up containing a handle.

#include <pigpio.h>
#include <stdio.h>

void main()
{
if (gpioInitialise() < 0)
{
puts("erm no"); // pigpio initialisation failed.
}
else
{
gpioSetMode(18, PI_OUTPUT);
// pigpio initialised okay.
gpioWrite(18, 0);
}
}

The code above once compiled failed the first time – I realised you must NOT have the daemon running when using this. so a quick reboot later and I was in business.

Oh, here’s how to compile a simple C program like that – make sure it’s a text file, say in your /home/pi directory.

gcc -Wall -pthread -o prog prog.c -lpigpiod_if2 –lrt

See where it says “prog” – change that to the name of your program. Takes seconds.

Anyway, I was just about to set everything up in C for i2c etc. when I discovered… PIGS

sudo pigpiod
pigs w 18 0
pigs w 18 1

Note – no sudo needed for the commands and presumably one would run that daemon (pigpiod) at startup. This looked like a nice simple route – dead easy for Node-Red as you can just issue the commands in an EXEC function and pass the parameters in the payload – so next would be to try i2c….

pigs i2co 1 39 0
pigs i2cwb 0 0 0
pigs i2cwb 0 0 255
pigs i2cwb 0 0 1
pigs i2cwb 0 0 2
pigs i2cc 0

The first command visually returned 0 – hence my use of 0 later in the code as the “handle”. I order, I set the expander to all off, all on, then the first bit only on – then the second bit only on and finally I closed the handle.

Something to note is that I2c lines need pull-up resistors – and this board has them already built in – unfortunately they are 1k pullups – fine if you only have one board, not a lot of use if you want to put several in parallel. After discussion we think that possibly the two relevant resistors might be replaced by 10k in which case you could then run several in parallel (with different addresses) but we’ve not tested that.

Oh, making that daemon permanent… I did that with a command line edit “sudo nano /etc/rc.local” -  and added the line “sudo /usr/bin/pigpiod” – and rebooted…. no problem.

Update November 9, 2016

The final stage of this experiment gives my ESP8266 software the ability to achieve the same thing, losing 2 wires to get 64 new ones (YES, 64), a net benefit of 62 I/O lines, could be worthwhile as the ESP8266 isn’t exactly brimming with IO lines.

I2C

Above you see (blue) our ESP-12 board, fastened to an FTDI for power, and wired by jumper to one of the PCF8574T boards - clearly you'd need 8 of them to get 64 lines and I'd be wary as they have pullup resistors on the data lines. I'd remove them on all but one.

With a typical Chinese PCF8574T board which includes pullups, I’ve added new commands to the ESP8266 Home Control software as of my software version 1.6.52 – the xport command.

Example:

{xport:0,1}

sets the lowest bit of the first (address 39) expander high (the 0 is a mandatory argument above – see future blogs) whereas:

{xport:0}

returns the state of the first (LSB) bit of the first of up to 64 bits.

On power up these devices are HIGH - and the software defaults to high on power up. If you mess with a port bit, you need to set a bit high before you can use it as an input. Here is the datasheet for this chip – and here is a typical Chinese expansion board.  With GPIO4 on our little boards hooked to SCL and GPIO5 hooked to SDA – the new commands work a treat.

In the above photo – address 39 equates to all DIP switches set to ON (that’s high or 7). If you set number 3 to off – that is address 38 (bits 8-15) etc. (simple binary selections – you can make the device work as anything from 32 (all switches OFF) to 39 (all switches ON) but before you go connecting eight of them up – bear in mind the comments about pull-ups above.

I’ve been doing a little more on these as you’ll see in other parts of the blog – but the upshot is – you have to ask yourself if these are worth the money. In my original blog I pointed to an Ebay price of £2.35  - but in fact from AliExpress they are only £1.20 and so I’ve amended the link in the blog accordingly.  However as you’ll see in other blog items – as I’ve learned I’ve realised they are not necessarily the best bet. I’ve now made a simple “Nano i2c peripheral” from a Nano board – and they cost just a few pence more – but you can make  NOT only an 8-bit expander but also get some A/D, some PWM and some A/D thrown in – hell I’m even putting an LCD display driver in just for the sake of it – and I’ll call it the kitchen sink peripheral.

However if you do like the look of these chips, you’ll note they say they work on 100Khz I2c. That of course is true and I’ve not experimented with anything other than close up – lets say less than 250mm away – but I’m currently running them a HELL of a lot faster than that. I’ve only speeded up the clock for writes and reads – note the wide bits around the edges but still – quite nippy.

faster I2c

Hope you found the above useful. For more information on the ESP software – go to the relevant page on the blog. There is of course the main Home Control 2016 page.

Facebooktwittergoogle_pluspinterestlinkedin

Sparkly new Pi

Just a very quick one (and somewhere to park the conversation)– there’s a new Raspberry Pi update out promising a new smoother, simpler look, better video etc. Up to now it looks like the claim is correct.

I have several RPI installations…including TightVNC and so I didn’t want to lose that. I did however, want the Chromium browser. I’m not interested in PI-HATs and similar so here’s all I did to get the upgrade…

sudo apt-get update
sudo apt-get dist-upgrade
sudo apt-get install -y rpi-chromium-mods

That’s it – nothing more –takes a few minutes all in - there is one Y for confirm and a reboot – and Bob’s your uncle. To test things out I went to the BBC website and of course got the usual message about Flash – things haven’t change there much – but with a signup for the BBCs “beta” HTML5 version (it’s a bit late for a beta, isn’t it? HTML5 has been out  for longer than I can remember) all is well, videos no problem!

New Pi Interface

The new interface is to be given it’s own name “PIXEL” – that’ll make searching for information about it a whole lot of fun… they could have picked something unique like “PIXL” or something – however it all seems to work – more modern appearance – slick – file manager is nice and apparently if not faster it is at least no slower than it’s predecessor so really no reason not to go for it.

Here’s the link in case you need more info. Given this new look – with hardware graphics support – which likely means you could be using your Raspberry Pi 3 for a media centre… AND the best backup program out there which can replicate the system even on a different size SD  -something as far as I’m aware NO-ONE else has – one has to ask – what are the other SBC board manufacturers going to do now!!!

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

NOT Rip-Off Britain for Raspberry Pi

Here’s a bit of a reversal.. normally I steer clear of the UK for pricing as we tend to pay over the top… I can’t help thinking I’m reading this incorrectly….

Raspberry Pi 3

However – here above is RS Components latest pricing for the Raspberry Pi 3 – the latest model – at just over £27

http://uk.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/

And that’s fine – compares to what, say the USA would pay. I think I bought a model 2 last year in the USA for slightly less.

But check this out…

Raspberry Pi 2AliExpress who you can normally count on a decent price…

http://www.aliexpress.com/item/Original-Raspberry-Pi-2-Model-B-Broadcom-BCM2836-1GB-RAM-900Mhz-Quad-Core-ARM-Cortex-A7/32661146230.html?spm=2114.40010708.4.11.OMbRzQ

Claiming 65% off and charging £38 for the old model 2 !!!

Am I missing something here?

The funny thing is – after seeing this – I found more – I found a Raspberry Pi 3 all on AliExpress – for £29.29 with free shipping – which is a GOOD price – then the older Pi2 for an amazingly high £53.98 (they are kidding, right~?)  – the two prices sitting right next to each other!!

Oh, here’s the link for the 3 in case anyone’s interested…

Facebooktwittergoogle_pluspinterestlinkedin

Raspberry Pi Node Red Serial Delight

Or – how to get USB serial ports working on the Raspberry Pi

Serial SetupThis originally was a cry for help – I wanted a second serial port on the Raspberry Pi AND I made the mistake of trying out Firmata on the Arduino at the same time – resulting collection of failures had me scratching out my few remaining hairs – but thanks to a lot of work – two lots of changes to the Arduino node itself and some reader insights in here, I can now confidently say that:

1. You CAN add more serial ports to your Raspberry Pi

2. You CAN talk from the Pi (or similar) to Arduino gaining access to ports for things like port on/off, PWM etc. with ease.

It all started when I innocently plugged a USB FTDI into the Raspberry Pi USB connector to give me a second serial port to play with as I was using the first one to talk to a Nextion display.  I checked in Debian in the /dev directory and it up came /dev/ttyUSB0. When I checked in Node-Red it came up with the same – magic. Great start.

I added in the serial node to Node-Red – set up an inject – and a debug node.

I shorted TRX and TX on the serial and… nothing.

(Serial set to a decent baud rate with 100ms timeout).

FTDII could see on the FTDI flashing lights indicating that not only was data coming out  - but also going back in.

I decided to test this and hooked up the internal serial on the Raspberry Pi.  I had mistakenly thought that the graphical control in the new Jessie allowed you to turn the serial login terminal on and off – so I turned off serial. BAD mistake – not only did the serial not work but the GPIO node failed as well!  I turned the serial back on – rebooted, back to square one.

I updated /boot/cmdline.text to remove reference to the serial port… and read THIS -  so now I had serial working.

I tested as you see above.  I shorted TX and RX on the internal serial – and sent some text – smashing – the text shows up in the debug.

So now I connected the serial out from the USB serial – to the serial in on the Pi (ensuring 3v3 output) – MAGIC – that worked.

So all that appeared to be NOT working – was the serial in on the USB FTDI serial – yet there are were error messages.

Is this familiar to anyone? I tried various combinations of the RTS and DTR lines – no difference. All looks fine and connected but the USB0 serial in appeared to do nothing.

Stage 2:

I took out the FTDI - put another one in - that appeared as USB1 (yes, the SAME ONE)... but it worked - I took that out and plugged the ORIGINAL back in - now this appeared as USB2  and worked – but how the hell are you supposed to use a port if it keeps renaming itself. Read on.

I rebooted the Pi (NOT removing power, just rebooted) - it went back to being USB0 - it worked.  I turned the power off, them on - no serial in.

So…. I took the FTDI out - and put it back in - now it appeared as USB1 - adjusted the setting on Node-Red accordingly - it worked.  Rebooted…No USB 1 – looked in the node settings – USB0 was back. Adjusted. All was well on USB0.

I turned the power back off then on (for the whole lot)…. Green connected lights on the in and out nodes, all’s well – BUT – no input. I could again see both lights on the FTDI indicating that it is not only sending but pulling back in – but nothing in the debug window when injecting text.

But this had WORKED after a reboot… but not after power up… so – I tried rebooting again…surely it would work? No.

I pulled the FTDI out – and plugged it back in… USB0 disappeared but USB1 was valid…. I changed the node to work with USB1 – it worked.

So it seems that the only situation when the input would not work – was when both the Pi and the FTDI had been powered down and back up. Which of course is every time you turn the stuff off and on!! And the name was changing – which is just useless.

The Solutions:

Well, thanks to readers in here I managed to split this problem down into sections. The first was this issue of the name keep changing. As it happens this one is RELATIVELY simple.

pi@bedrock2:~ $ sudo lsusb -v | more

Bus 001 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT
232 USB-Serial (UART) IC
Device Descriptor:
bLength                18
bDescriptorType         1
bcdUSB               2.00
bDeviceClass            0 (Defined at Interface level)
bDeviceSubClass         0
bDeviceProtocol         0
bMaxPacketSize0         8
idVendor           0x0403 Future Technology Devices International, Ltd
idProduct          0x6001 FT232 USB-Serial (UART) IC
bcdDevice            6.00
iManufacturer           1 FTDI
iProduct                2 FT232R USB UART
iSerial                 3 A50285BI
bNumConfigurations      1
Configuration Descriptor:
bLength                 9
bDescriptorType         2
wTotalLength           32
bNumInterfaces          1

So looking at the code above created by running the command at the top above – starting “sudo”…

This told me all about the last USB item plugged in – sure enough my Future technology USB FTDI

I made a note as instructed by reader Alex - of idVentor, idProduct and iSerial and put them into a file:

sudo nano /etc/udev/rules.d/99-usb-serial.rules

The one and only line in that file would be..

SUBSYSTEM=="tty",ATTRS{idVendor}=="0x0403",ATTRS{idProduct}=="0x6001",SYMLINK+="ttyUSB-PETER"

Tried it – failed.  Of course I was trying to use vendor 0x0403 – when I took off the 0x it worked a lot better. I’ve no idea why. With further help from Alex the solution appeared as

SUBSYSTEM=="tty",ATTRS{idVendor}=="0403",ATTRS{idProduct}=="6001",ATTRS{serial}==”A50285BI”,SYMLINK+="ttyUSB-PETER"

All of that was great – on power up the unit would come up with my chosen name – also after reboot – and after disconnecting.

pic

All worked well…one problem apparently solved…

But… from time to time I would lose the output – the lights on the FTDI would show up – but nothing would come back in to Node-Red. Another reader – Christopher had suggested that in some cases you need to short DTR and DCD, also RTS and CTS.  if these were floating and if they WERE important – I could see why I’d be getting strange results. I put links on these.

Voila. Reliable serial connection. It would be nice to clarify why the word “serial” and not “iSerial” – and why you need to miss off the “0x” – but it worked reliably.

Pi and Arduino

Though it works perfectly as a serial port in Node-Red – Node-Red cannot see the new port probably because this is just a shortcut or symbol – if you type it in – it worked – but Node-Red could not (and will not)  search for it – not too much of a hassle to put in manually.

But – the ARDUINO node for Node-Red would NOT accept the manual input.

By specifying ttyUSB0 I managed to flash a light with this Firmata-based node – but any attempts to change things around, try PWM on a pin etc. would result in  Node-Red dying temporarily. I talked to the developer of the Firmata node as I noted the serial node NEVER crashed Node-Red.  Result – thank heavens – a bug – now removed.

Reading a reply in the Node-Red Google group, it was suggested for a while NOT to use the Arduino node but to scrap that and use the contrib-gpio node (the yellow one) – as it happened I had that installed. I used my shortcut (may as well go in at the deep end) – and LO – no more Node-Red crashing.

I tested port digital control as well as PWM and they all worked.. BUT – changing mid-stream – i.e. opening the node and changing the port bit FAILED like the Arduino node – but did not crash Node-Red – this let me experiment a LOT more. I killed the Node-Red service and ran it manually. But at this point, making a change to the node and then running deploy would result in the node sitting with “connecting” and just refusing to connect to the serial port. Simply stopping and starting Node-Red fixed the issue every time.

The author was playing with this and could not replicate this – but it turns out he was using Node-Red’s DEPLOY ALL mode – whereas I just deploy all changed nodes (so my house control doesn’t fall to bits when I’m experimenting). I just had a call to say he can now replicate this.

WHICH MEANS the yellow GPIO node also has this issue! I’ll let them know.

So now that it looks like Firmata will work but does not like change.

Dave at IBM who has been working on the Arduino node has now FIXED this issue in Arduino node version 0.09   (npm install node-red-node-arduino).  I have tried port 23 to make sure the MEGA version of this is running – and sure enough – it is running.

Lovely. Multiple Serial ports on the Pi – and LOTS of GPIO cheap add on – what more could you want. My thanks to Dave for quick action and to everyone for their helpful comments which brought us this far.

The node-red-contrib-gpio node has exactly the same issue that the Arduino node HAD – I’ve left an issue in the repository of the latter.

Update September 32, 2016: I have to say that all of this is working exceedingly well, EXCEPT for Firmata on the Arduino. I left my main Raspberry Pi talking to the USB serial and sending commands to flash a light on an Arduino MEGA2560 board via Firmata. Simple enough... we've had power cuts, I've been experimenting with the Pi etc over all this time since I wrote the blog entry and I can see by the FTDI that once-per-second commands are heading out to the Arduino 24-7 - but every now and then, maybe every few days I look up and that light is not flashing. A quick power cycle on the Arduino board brings it back up - but Firmata is simply NOT that reliable.

Facebooktwittergoogle_pluspinterestlinkedin

Background Beavering

You could be forgiven for thinking I’ve gone off the boil as I’ve not written much in here this week… far from it in fact. This week I’ve been working on my ImperiHome setup and the new Raspberry Pi software.

ImperiHomeImperiHome: In case you don’t know, ImperiHome is an app for Android and IOS that enables remote IOT control. It does this by trying to appeal to just about every system out there, none of which I use.  I’ve taken the approach of having IBM’s Node-Red control everything – and thankfully ImperiHome has a generic API to allow control if you don’t have ANY of the devices it supports.

I’ve written more than one item on this subject and I have to say despite a rather lacklustre approach to answering people’s questions by their team and something of a lack of generic controls (such as a momentary push-button), the product actually works and works quite well. I have RGB lights, relays, sensors and a host of gadgets attached to Node-Red. Those which are required to just come on and off at varying times of the day are controlled by my BigTimer (which, recently updated, works a treat – or rather, it does if you remember to set the time zone when setting up the Pi as I found out last night when all the lights were still on at 2am, defying all explanation until my wife said “did you ever set the clock on that thing?”).

Those gadgets which require interaction are controlled by ImperiHome on my HTC Smartphone.

On the subject of Node-Red, we are promised non-volatile global variables in future by the Node-Red team and I for one can’t wait – but for now I’ve just completed a function to save a global object (buffered in time) when any change is made. That global object forms the variables used in my ImperiHome project – so now at last, the phone is always aware of the state of my lights – a handy thing. Essentially the object contains a counter which is set whenever any other variable in the object is altered. This is monitored by a timer which also kicks in on power-up.  If the counter is true, it is decremented – if it hits zero I update the file on SD which contains that object.  I also check to see if the file exists – and if not, I create it. If the file DOES exist and the object doesn’t – I populate the object.  So now, my lighting and other settings can survive power-cycling.

Raspberry PiRaspberry Pi: On 10/05/2016 the Raspberry Pi foundation put out a new release of Jessie (Debian) and with it, items you might expect like better support for Bluetooth etc., but then something I wasn’t expecting – a decent backup program. After (what seems like) years of struggling with arcane Linux commands some of which I never really got to grips with and hence never achieved a satisfying backup solution, at last, a simple push-a-button backup program that not only allows for live backups, but also allows for the use of varying size SDs both larger and smaller.

WHY did this take so long…  I can’t tell you how this has changed things for me – backup time is reduced, no need to shut the house controller down when I’m doing backups, the use of smaller SDs, running multiple copies of the same software on different boards – the list goes on.

But for days I’ve been struggling with upgrades – the backups just did not want to accept upgrades (apt-get-upgrade) and when they did, invariably Node-Red would fall over with missing nodes etc. I didn’t know if it was the backup program or what…  (I knew it was not the SDs as I use only good ones). Well, it turns out that my script was in need of bringing up to date. I still scrap node, npn and node-red and re-install to get the very latest but I’ve done it a different way, more by trial and error, but I got there in the end and now my backups and restores are working perfectly. I’ll publish the updated script soon, replacing the older one and I’ve added some tricks I’ve picked up along the way from readers like you.

Tiny part of my controls

I started this blog entry before our BBQ yesterday and here I am up early on a Monday morning finishing off the job. The lights worked a treat last night now the clock is set correctly – thanks to NTP it will now stay that way.

Coming up this week hopefully – a couple of new boards from Friendly Arm, the new Nextion display and more. But first things first, some supply shopping,  I’ve lost a filling and Maureen’s done her foot in – this should be good – dentist and hospital – in Spain (and not in the tourist areas where they speak English).

Facebooktwittergoogle_pluspinterestlinkedin

Remote checking Home Control Units

Those of you who are aware of the Home Control project (Home Control 2016) will know that the software/hardware combination of a Raspberry Pi (running Jessie, Node-Red, SQLite and Mosquitto) and ESP12 (running the software described in the Home Control project) is proving very reliable – but there are occasions when you may wish to be absolutely sure that units are actually doing something.  One way to do that is simply to put timeouts on every response you expect… but that makes for complicated coding. A simpler way is to regularly ask each unit for the status of one of the outputs. It doesn’t matter what the response is, as long as there is a response.

As it happens I’m having an issue right now – the heating controller part of my system back home in the UK is working perfectly except of an on-going issue with Plusnet broadband. They are denying it is their fault but the broadband fails perhaps once a day, maybe more, maybe once every two days but eventually it will fail. Most of the time the TP-Link TD-9980 router reconnects within a minute or so – but for reasons I don’t yet understand, occasionally it just will not reconnect. The solution to that was simple and two-fold, a standard timer which turns the router off for a minute in the early hours every day. That’s the “belt and braces” approach. In addition, the Raspberry Pi is polling Google every few minutes. If it fails totally over a 15 minute period to contact Google, an ESP8266 unit will reboot the router.

All of this worked perfectly for several days and then… the heating relay ESP8266 refused to log back in after one of these “cuts”. I can only put it down to being right on the edge of signal. The reason I say that is that late last year we had horrendous problems with WIFI here in Spain, some kind of attack. It went away but during that time over several days I was losing WIFI constantly so I made damned sure the ESP units would reliable log back in, in the event of temporary failure of MQTT or WIFI or both etc. And yet just occasionally this particular unit will not log back in – a power cycle fixes the problem but that means I need to know about it and ask someone to pull the plug for a moment.

So – I’ve implemented this for the two most important devices in the building – the main heating temperature sensor – and the ESP that controls the relay to turn the heating on and off.

watchdog

Timeout NodeWhat you see above is as follows: 2 Node-Red “inject” nodes (standard) fire out requests every 5 minutes to MQTT to ask the relay and temperature units for the state of output 0. 

Which command is irrelevant as long as it is a query which returns a result and otherwise has no effect on anything.  So for example with a topic holly1/toesp and a payload of {out0?} the system is expecting a response of OFF or ON (irrelevant here) from topic holly1/fromesp/out0

The two incoming MQTT nodes (left, purple) pick up on the response and feed them into my “timeout” nodes  (node-red-contrib-timeout).

As you’ll see below, the operation is simple – the timeout node doesn’t care what is incoming as long as something is. if it gets nothing for 60 minutes it will time out and send a payload out – in this case thanks to the standard email node (green) an email to me. 

During that time, normally, the MQTT nodes would have responded every 5 minutes – ie 20 times, topping the timeout node up to 3600 seconds even if most of the messages were missing (and there is no reason why any should be missing).  In this case I’ve not put messages for “safe state” or “warning” – so nothing goes out unless the timeout actually runs down to zero.

Click on any of these images for larger versions.

So while this does not solve the problem, it does mean that I’m alerted to the issue and can ask someone to disconnect and reconnect the relay unit. With what has been 100% reliability of Raspberry Pi 2 boards (with a decent Samsung microSD or similar) I can be pretty sure I’ll get an email if something goes wrong.

I hope this proves useful to others.

Facebooktwittergoogle_pluspinterestlinkedin

Visual Interfaces for IOT

Hollyberry BlynkSo much happening right now – the new Raspberry Pi 3 once again sets the bar with improved performance, Bluetooth and WIFI as standard. With up to 10x the speed of the original Pi we can do even more serious work with these devices.

Please note before proceeding – apparently the Blynk team plan to charge for the use of this app – it is not clear if this means using their server, using a local server or both? And they claim that new widgets will be included in a monthly deal – but WHAT new widgets and in what timescales? – as the Blynk app moves from free to paid I think they will find people want more definition of what is included and when. A one-off fee is one thing – an on-going payment is altogether something else.  http://community.blynk.cc/t/blynk-will-introduce-paid-subscription-in-q1-2016/3177

The ESP8266s are looking (depending on which software you use) to be very reliable to – so that is both the central control and peripheral activity side of things more or less in place.

Where we are still falling down IMHO is the visual interface side – that is – remote control by phone. I’m interested only in Android but I’m sure the same applies to IOS.

At the turn of the year it was looking like a neck and neck race between a small number of systems, node-red-contrib-ui for those inclined to doing a spot of programming and Blynk for those who are more concerned with the visuals.  I’ve looked at several other packages but to be honest either the visuals were just pretty poor or the technology not too well thought out etc.

We’re not there yet.  To my mind the one with the most hope was, until recently node-red-contrib-ui but since January there has been little or no sign of the author and no further developments that I am aware of (though I did hear a rumour that it might become a permanent part of Node-Red – let’s hope this spurs major new development) – this is a great shame as there was a heavy conversation going on with big improvements almost there – and then it all stopped. This is not new – I was convinced at one point that NETIO would be the brave future but development on that seemed to stop some time ago despite being commercial.

That leaves us with Blynk and a few others. Blynk is almost there. It works with the concept of a central server which knows the states of various devices, accepts updates and relays that to the APP. I pushed hard on this to make sure that regardless of whether the App was on or off, the state would be stored and the App would reflect changes when brought back to life. This was considered an edge request by the designers but they implemented it anyway and between that, improvements to the local version of the (small Java) server (which can run on a Raspberry Pi) and some sterling volunteer third party work to bring websocket-based communication back to Node-Red, the App is looking like a clear leader – but not perfect yet.

Blynk[4]I recently contacted Blynk and was assured that at some point they will fix the current issue – that being – they expected people to use buttons for ON and OFF scenarios.  I’d not twigged to this issue until recently when I finally started putting together a set of Blynk controls for my various gadgets.

One of the items I use a lot in my Node-Red applications is my own BIGTIMER (node-red-contrib-bigtimer) and that can set, say a light, to come on and off at set times during the day – for example coming on at lighting up time and off at midnight.  But like all timers – one must have an override facility – and so it is with bigtimer – I can inject text “on”, “off” and “auto” into the input to manually override the timer or send it back to auto.

Well as you can imagine – that is simple to implement with 3 buttons – but having them say “ON” or “OFF” just does not apply – similarly for heating control you might have “up” and “down” buttons.

Blynk say they will not only implement variable text in the buttons but also icon graphics… well, can I put a request in now – if these are to be fixed icons – we need a full set of remote control icons – ie stop, pause, start, ff, rw etc.   For text the best option would be freeform…. or NOTHING – text in momentary buttons just doesn’t make sense to me. A change of colour when being pressed is good and they’ve implemented that.

It would be nice if they had a smaller button as well – and the RGB control is just WAY too big – but looking at the alternatives – Blynk are to my mind still ahead of most.

I’ve looked at several alternatives – but right now most just not cutting the mustard. Either too complicated to setup, too limiting, unreliable or just not finished – and that happens a lot. There is just one out there that might just blow Blynk out of the water and you’ll see my videos and this blog commenting in the future – the app is called Imperihome and thanks to a small number of us working together, there is now good support via Node-Red for this App which is available for both IOS and Android – on the surface it blows even Blynk out of the water. Time will tell.

Facebooktwittergoogle_pluspinterestlinkedin