Monthly Archives: January 2016

WiFithing

A breath of fresh air, or dead in the water? Let’s take a look.

But firstly an update – as of today (Feb 1, 2016) the Kickstarter campaign has been cancelled. Now see my comments below..

WiFithing overall: OrviboSo WiFithing comprises a master board in a nice white box and up to 8 slave boards (in nice white boxes), handling for up to 4 groups of FS20 radiator valves and 10 Orvibo Smart sockets – and flying in the face of many new developments, uses radio – but not WIFI to connect devices.

Kickstarter: The project is on Kickstarter and has 3 days to go to achieve the goal of £15,000. They are currently sitting at £11.8k which is a worry as most successful projects tend to go way beyond the original goals so close to the end date and we’ve already seen a couple of projects in here fail at this late date – but stranger things have happened.

The Orvibo saga: So first things first and a little diversion. I opened up the box and inside was a a WiFithing master, a WiFithing slave and the Orvibo Smart Socket along with some instructions. Even from China the Orvibo units are £17 each (Amazon seem to have stopped stocking them and don’t know when they will be back in) and so not exactly the cheapest solution for mains socket control – but at least they had a proper British plug integrated.  This is the mains socket that WiFithing have chosen to support so it is worth a further look.

Well, I promised a diversion…. I investigated at some of the Apps for the Orvibo device and “still not very reliable” was the first comment I noted (referring to the app). One guy was pleasantly surprised as the app worked “80% of the time”. Nice looking, too expensive and by the look of it not too good on the App side.  I’m looking for MQTT-supported similar devices and of course, Espressif-based devices are coming online now. Espressif themselves during the summer trip to Boston I took with them, showed me  a unit selling in China (sadly not outside) for just a few dollars and the Sonoff board would probably nicely fit into a case similar to this – that device has already been hacked by at least two of us to handle MQTT and is nicely priced as some of you know.

Most of the reviews for the Orvibo-compatible apps achieved poor scores on Android (a shame as it’s a lovely looking device). One app looked promising with a high score… Orvibo AllOne Wifi Alternative.  Well, I got no-where with that as, on installation it spotted my two NOWTV boxes and simply would NOT let me go any further until I set those up.  I scrapped that and instead installed the WIWO app and plugged the Orvibo into the wall. The App found the device immediately and I made a note of the UID.

The App turned the Orvibo on and off. Success. I moved the socket a few feet to a place where I could plug a lamp in – and the App promptly crashed. However thanks to THIS article https://nathan.chantrell.net/20160101/orvibo-s20-wifi-mains-socket-with-node-red I was able to get the unit to work under MQTT – on and off – first time, no problem.

BUT – wait for it…. turn the unit on – disconnect the power, reconnect the power – and …. it does not remember the state it was in.

That for me would be a money-back-requiring deal-breaker for that particular unit.  Imagine using this in an environment with faltering power (and there are MANY such environments, particularly in rural areas ) – this socket would be a non-starter as are many of the cheap and cheerful B&Q mains controller sockets.  It is worth noting that in the modified SONOFF controller software, I (and presumably the other guy who’s done the hack) ensure the power-up output remains as it was before the power cut or brownout!

Of course, one could easily have Node-Red refresh the state of the socket or sockets every minute and that ultimately is what I did. Works a treat.

Anyway, I digress. The Orvibo is just part of the picture. The Kickstarter project for WiFithing makes a big deal of not using WIFI “As you have probably heard by now, IOT devices tend to be very low bandwidth and bursty in their communications. WIFI overhead is pretty painful”.

I’m not sure I follow the argument against using WIFI – I just finished setting up 40 IOT devices and having them talk to Node-Red as some of you know. The overhead in terms of use of the router appeared insignificant and the cost of each unit almost irrelevant – so I must be missing something in the above. They also refer to WIFI only solutions as being heavy on battery – but I know people in here who have successfully put ESP devices to sleep, occasionally waking them up to report back via WIFI. 

The WiFithing product does not use mesh networking and so each WIFITHING slave is paired up with a master. 

Again as many of you know, I’ve been down that route with the very DIRE NRF24L01 – in fact even with a mesh network I spent months on what ultimately was a waste of time so I am very wary of claims about such radio systems – to be fair they are using 800Mhz and not 2.4Ghz. Even at 800Mhz I guess no-one who tests these lives in houses with thick stone walls.

The package I received comprised a WIFITHING master, an Orvibo socket, and a small unit containing a battery connector and a board by panstamp.com So the Panstamp devices uses the CC1101 low power radio. and depending on the model, an MSP430MCU or an Atmega 328p. I’m not sure about the box, very nice and small but there was only room for the board and 2 AAA cells inside. Not entirely sure what you’re supposed to DO with it given no room to fit anything inside.

WIFITHINGThe WiFithing master itself, again a very pretty box but inside was the requirement for a round battery – and I started the review on Sunday when the shops are closed. As no such battery was supplied that brought that to a halt. The master unit will apparently cost $57 which puts it on a par with a Raspberry Pi 2 with WIFI. Ok, this is a finished product which claims you can have control “code-free” whereas Pi solutions tend to involve at least flashing a chip…In the campaign they compare their board to a Launchpad MSP430FD4969 + CC3100 booster + Anaren CC1101 board  - and that’s fine – if I were about to design a controller, those three would  NOT be on my list of candidate boards.

Radiator control: The FS20 radiator valves mentioned seemed to me fine but a little expensive – including postage they seem to work out at £45 each. A handy solution complete with batteries – they have to make more sense than the really STUPID thermostatic valves that most people find their radiators attached to but again I’d rather have a WIFI-controlled stat I could hack or that already used MQTT. Personally I’ve been thinking of hacking one of these… and sticking an ESP to control it – but if anyone has a better idea that is no more expensive – do let me know.

Open Source: The WiFithing project is open-source but the code is not yet on Github. Also the radio certification is not yet complete. See the Kickstarter page for more info.

I noted that they intend to have the product manufactured in the UK. Will that jack the price up? In an ideal world I’d like to see everything manufactured in the UK but I’ve seen enough conversations in this forum to know that many folk head off to China for best prices.

If you want to use the web app they charge £1 (£1.50) a month for unlimited devices per single house/site.  I think I’d rather pay once and be done with it – others may disagree. Many of the features are “goals” which will be progressed following a successful launch. With only 3 days to go and a £3k+ shortfall on already modest goal I would not hold your breath but certainly worth taking a look if you want simple radiator and remote control with uber-security and no code.

Facebooktwittergoogle_pluspinterestlinkedin

Memory sticks/SD and USB3

Check FlashI was just reading an article in a blog where people were slagging each other off over views about USB3 and the speed of memory sticks when a package arrived for me in the post.  A couple of USB3 32GB memory sticks (tiny ones at that).. and it occurred to me that my laptop has a USB3 socket.

So, off I went to the web and picked up CHECK FLASH for Windows – a freeby.

So – the first thing I did was to grab my favourite, fastest 32GB USB memory stick – a Duracell unit. I ran the test which took several minutes – and what did I get? 19 MB read speeds and 13MB write speeds – no errors. I know it is the fastest one I have as I often back movies up to it and when you’re backing up a 2GB movie – you soon make sure you use the quickest drive.

So bearing in mind that this was the BEST I have – and no way the machine will diminish any results as it is a very fast computer… I then went on to try the little mini-32GB USB drive.

Oh, both of these were formatted as Fat32 incidentally and so both complained that “only” a test of 4GB could be done.

Now, bearing in mind that the USB3 unit wasn’t even a super brand name – or ANY brand name for that matter, it is interesting to note that it easily managed 126GB read speed (i.e. SIX times faster read) and 36MB write (nearly THREE times faster write) – I think from now on I’ll be looking around for USB3 – I’m a convert.

THEN I remembered I had a USB card reader and a pal of mine had sent me some Samsung EVO microUSB chips – I read somewhere that these were the best for Raspberry Pi – so – I gave THAT a go too! Strangely the read speeds averaged 41/mb and the write speeds were only 13.4MB – more or less the same write as the USB 2 stick but over twice the read speed – perhaps my expensive USB3 ANKER adaptor isn’t as good as I thought it was - as the EVOs are definitely the fastest I’ve used on the Pi.

Have you come across much faster USB2 speeds that my simple test? What about USB3?

Facebooktwittergoogle_pluspinterestlinkedin

ESP8266 Lessons Learned

ESP-01The Trip: As regular readers will know, I’ve just returned from working on the first stages of a project in Spain to analyse information from ESP8266 chips. Without going into any commercial detail, this is what I brought back from that trip.

The scenario: The tests were done in a rural environment, initially with a bank of 40 ESP-01 boards. These were powered by a single 20 amps 3v3 power supply. Yes, a switched supply. The boards were mounted on Veroboard and power applied. You really don't get a lot worse than this - no linear regulator to smooth out the crap ( I would normally run 5v switched and a linear 3v3 regulator on-board for each device), lossy tracks on Veroboard, signals interfering with each other..  except it DOES get worse - read on.

The Place: The location we conducted our tests was off-grid, relying on solar power and a generator - and the weather most of the time was cloudy - that meant at regular intervals the remote generator kicked in and when it did a couple or so mains cycles were lost as the set-up there uses a combined inverter/charger. The result of that was that at regular intervals, the router reset.

boardsAside from actual power cuts you don't get much worse than this. At first when we switched on the boards - which are running a modified version of my home control software which is in turn based on TUANPMs MQTT code with a boatload of stuff added and a lot of tweaking over time, only some of the boards would report back. A quick check of the router revealed that by default it only allocated enough room for 32 connections on DHCP. That was quickly doubled and lo and behold, all the boards logged in by MQTT to the PC (running Node-Red and MQTT and firing off data to a database).

Useful outcomes: Well, any thoughts I may have had concerning reliability completely vaporised this last 2 weeks as day after day our little bunch of 40 boards (not even all from the same supplier as some were blue, some were not) just sat there constantly delivering information. This is soon to be increased to 120 and with a power supply currently running freezing cold I am confident there won't be any issues. And all of this for far less than the price of a half pint in London.

So if you're just starting up with ESP chips - bear the above in mind before jumping to conclusions about board reliability. The boards used in the test, running as I speak, were the early 512K versions, today I always use ESP-12 boards in my own projects as they have eight times the amount of FLASH which means OTA, big programs (up to 1MB of C code (that's a lot)) and in the case of the "F" version arguably better antennae.

Coming up: I’m sitting in front of a set of WIFIThing kit – and I’ll shortly put together a short review of this equipment including a very nice WIFI wall socket.  Also – is there really an advantage in using USB3 memory sticks? I’m sitting in front of a couple of 32gig units and I’m about to run some tests. Check in later.

Facebooktwittergoogle_pluspinterestlinkedin

UI Update

I’ve been busily beavering away at a commercial project for the last couple of weeks but that ends at the weekend and I hope to soon have some more reviews of new and interesting products for you including some surprisingly cheap SBCs.  Meanwhile, close to the heart of many of use – the IOT user interface remains a challenge. There are several of course – the dashboards are great unless you want to control something – and you will know that in this blog I’ve discussed the Node-Red UI and Blynk to name but two.

I dismissed Blynk because the interface though beautiful was simply too buggy – or rather a combination of that and the Node-Red interface. Well, the good news is that part of that problem is solved. TZAPUs new web sockets code seems to be rock-solid. The only bit of the puzzle that needs fixing is the actual Blynk App. For reasons beyond me no-one seems to have noticed that if you PAUSE the APP and then continue, it knows nothing of any changes that happened while it was paused. Come out of it and go back in and fine – it picks the info up from the server – but simply pausing is an issue – maybe no-one thought that something other than the APP might be controlling your IOT – yes, hard to believe. However this morning I got acknowledgement that this will be fixed on the next sub-release – which means that by the look of it we have a fully working interface.

Meanwhile node-red-contrib-UI is due a facelift and Andrei has been working on that – sadly despite spending ages on this I’ve been unable to get the new upgrade to work – I’m confident however that this will be resolved.. and then we will have at least two decent, easy to use interfaces between Node-Red  (and hence most if not all IOT) and our phones.

Time will tell. This weekend we’re off to visit friends, next week I’m putting my office together and hopefully collecting some PCBs to control Nextion displays and as soon as my new office is in a state to do some R&D, expect to see new reviews and more info.

Facebooktwittergoogle_pluspinterestlinkedin

Home Control 2016

Introduction (Latest update December 15, 2016)

HomeSick of reading about other people’s home control? Want to make your own? Got some electronics and software experience? You’re going to LOVE THIS! Rock-solid home control – low cost, DIY.

If you’ve read my early blogs you’ll know that Aidan Ruff and I have been working in home control since the late 20th century. Together, we ran an electronics R&D company for many years and one of our products was a home control system called APPCON.

That range of products  achieved much coverage in the UK tech press at the time and many loved it but the design involved spouse-unfriendly WIRES – bad mistake. So now we’re back – this time for fun –  with a vengeance!

Home Control 2016

Add to that lot above, the SI1132 unit which returns light values for visible, UV and IR - and a host of other I2c boards around the corner.

By the time you look at the diagram above it will likely be out of date as new features are added – thankfully there’s a manual along with source code and diagrams available online and kept up to date. This is all free incidentally and without warranty. We have software, diagrams, board layouts… and this blog has a range of articles on the subject.

The diagram pretty much says it all – a Raspberry Pi (2 or 3) or similar,  talking to your PC or smartphone via a range of potential technologies – and using a powerful communications protocol called MQTT over WIFI to talk to small yet incredibly powerful ESP8266 units – these can be bought very cheaply and programmed – or you can take our board designs and have some boards made in China if you really want to DIY (we do!).

There are no real limits to the number of boards you can have talking to the central controller – that is down, in the main, to your WIFI network which could cover one room or extend across the globe.

In my own system I have 3 properties talking to each other – one in the UK, one in Spain. No matter where I am I have full access – great fun, great utility, low cost. Who wants to pay £50 to control a light! This is definitely aimed at the DIYer.

In the coming link there is a complete project, suitable for Windows development using the ESP8266 “Unoffical Development Environment” for the ESP8266 – but that won’t stop Linux users from bending the makefile to their will!!

There is a DOC file here which is fully up to date with all commands – this blog entry just shows a selection. Even if you ignore or don’t understand the source and just download the ROMS available – you’ll be able to keep up to date via OTA (over the air updating) – and you’ll need that manual!

You may also need some new – and very useful skills as you’ll see the term Node-Red appear very often throughout the considerable range of blog entries in here – this is by NO means a single item – there’s a Nextion-based, prize-winning WIFI touch display blog and a range of discussions (and there are LOTS of valuable comments) throughout the blog – enjoy learning and please do feel free to share knowledge – there is SO much more we can do with this.

Update on flashing ROMS here:  http://tech.scargill.net/esp8266-home-control-update/  - Blog reader Jay has written a great blog on setting up the programming environment for Windows.

ESP8266-terminalWhat is missing from the diagram above is my first experiments with SPI. Using up GPIO13 to 16, I have a 320*240 display working experimentally as a fast scrolling terminal on the ESP8266. Handy for debugging the system without tying up your PC monitor.

How useful this is depends on how many other pins you need! We need an ESP8266 with many more IO pins – I guess that will be the ESP-32…

Background: I’ve been using ESP8266 chips since they first came out – and I have the development kit for their new ESP-32 –just waiting for some decent software tools to emerge but right now the ESP8266 is a lot of fun and that’s part of what keeps this all going.  In the summer of 2015 I made myself so visible on the ESP8266 front that I was invited to be part of an Espressif-led delegation to MIT in Boston for the FAB11 Conference – demonstrating the ESP8266 with MQTT and Node-Red and how to build this into practical systems. I’ve also recently been involved in a project in Spain for the MOD researching ESP8266 and IOT security and more.  If you wish, follow my ramblings on the subject of control using these chips in THIS blog – and also on Twitter (@scargill), Facebook (esp8266wifi and IOT pages) and LinkedIn.

Nextion DisplayRegular readers will know that for some time now, the ESP8266 boards have been turning the world of IOT upside-down. I’ve long-since scrapped various radio designs (NRF24L01 etc.), blighted by short range or lack of network ability - and have gone “hell for leather” into using these boards.

Home ControlThe original plan involved an Arduino Mega as a “master controller” and Arduino “slaves running over an NRF24L01 mesh network. Here in this link is one of my first attempts at blogging on the subject – along with pictures of the original “Appcon” system from back in the ‘90s.

The original Arduino-based system worked well worked and indeed controlled heating and lighting for a couple of years at my home, but the controller went out of the window when the Raspberry Pi 2 came out which was dirt cheap but with more than enough power to control a house or ten. Now of course we have the RPI3 and other exciting boards such as the tiny FriendlyArm NanoPi Neo.

Hardwired to Ethernet (or WIFI if you prefer), the system allows for a comprehensive wireless home control setup  and to answer any questions about ESP8266 reliability – with the code you’ll see in here,  I can say with a lot of experience, that the ESP8266 units given reliable power, are rock solid – stunning considering the price.

ESP-12The ESP8266 boards provide a REALLY low-cost entry solution into the world of IOT making it possible to create in the simplest sense an Internet-controlled LED for under £2 (it could just as easily be a 2KW heater of course for a little more outlay).

There are a number of variations on the ESP8266 boards, the first shot at this being the ESP-01 – a simple board with power, a couple of IO lines and serial in and out. The thing is – they all use the same chip and that particular board (the ESP-01) is very I/O and FLASH limited – and for no good reason – the ESP-12 and variants for example have access to the A/D converter, several IO lines, have more FLASH memory and cost the same amount!

The only downside to the latter is 2mm spacing pins but for VERY little you can buy adaptors to 0.1” – or of course use a board that will take the ESP-12 or the ESP-12E (which is the same – but with a few extra essentially useless pins) – same price. There are also a number of ESP-12-based boards today which offer 0.1” spacing. For this reason I’m giving up on supporting the ESP-01 with it’s limited FLASH memory though as you’ll see in another blog entry,  with a steady hand and fine soldering iron it is trivial to replace the old 1MB Flash on the ESP-01 with a cheap 4MB Flash making it more compatible with ESP-12 etc (well, you still have hardly any pins to use).

Oh, here’s a link to the various source files. Here are original Board files designed by Aidan Ruff. No guarantees – not even any guarantee they won’t change or disappear if we find bugs. Since this article was started I’ve added I2c and a software serial port (optional) on GPIO4 and 5 to control Nextion serial displays directly. Instructions here may not be fully up to date but always check the WORD document in the repository. You might also want to look at the Nextion WIFI touch display board and links – I discuss another control board in there as it can be used for general purpose. This board has neither a relay nor power supply (other than 5v to 3v3 conversion) on-board but it’s a better job for general use.

Also check elsewhere in the blog to see what we’ve done with the Itead Studio Sonoff boards and their plug-in-the-wall remote mains socket. All of this stuff works together as a whole or you can cherry-pick.

I’ve added i2c to the ESP8266 software which as you’ll see in the picture at the start of this blog as made a big difference to the number of supported devices. What a roller-coaster this has been an a great way to learn all about i2c – I’ve improved the original Espressif offering a lot!  I’ve recently added version numbering to power up info and a powerful debug command and also, the power-up info indicates which GPIO is currently used for Web setup and which pin for the visual LED or RGB LED indicator.  At the time of writing the code is using the latest Espressif SDK version 2.0

tmpA4AFThe later PCB you see here was designed (by Aidan Ruff) for my award-winning (ok I had to get that in) Nextion Serial Terminal which  in April 2016 grabbed second prize at the esp8266.com 1st Annual awards. The latest update to this board includes the option to use an RGB LED as the status indicator – something I see as becoming the standard – once you have a selection of colours an intensities to indicate status, all of a sudden a normal LED looks boring.

The Boards

For the reasons stated I’ll discuss here the ESP-12 (and variations, ESP-12F being the latest with a marginally better antenna) as that is my favourite sub-module - but the same code applies to other variations where pins allow. We have working software – and circuit boards to go with it. For reasons best known to my pal Aidan we called this original the Hackitt & Bodgitt board. We have a new board version with an RGB LED as the status indicator on GPIO13.

If you are in any way unhappy using 240v AC mains power, you may want to give this a miss or fit one of those 12v to 5v down-converters so cheap and popular on EBay – I do this to power them from a solar-charged deep-discharge battery in some cases. This version does NOT tie GPIO16 to reset (the saving in power on this board wasn't really worth the bother – and note that GPIO16 is usable as an output). Again in the latest version we’re moving to using GPIO16 as the default relay output – freeing up GPIO0 to be an input only (programming – and web-setup).

Front view

Here is the rear view. Note the MOSFETS on the back (this is looking straight through hence letter reversal)

rearview

Note that a particularly nice feature of this board is that it can be programmed from a standard, cheap 5v FTDI.

So in terms of “Features”, the diagram at the start of this blog entry says a lot – but for clarity:

  • Mains-powered WIFI controller board
  • FTDI-compatibility
  • Accommodation for solid state or mechanical relay output
  • Temperature sensing using DS18B20
  • Temperature and pressure sensing using the BMP280
  • Temperature, pressure and humidity sensing via the BME280
  • Temperature and humidity using the DHT-22 or DHT-11
  • All signals brought out to edge connectors
  • Uses inexpensive power supply (or DC/DC converter) available on EBay
  • De-bounced input with automatic debounce and messaging
  • Analog in for checking battery state etc., will handle up to 20v
  • Several Outputs expandable via I2c
  • RGB WS2812b output on most pins able to handle 300 or more serial LED STRIP
  • 3 outputs for high definition PWM – with MOSFETS to control LED STRIP
  • Talks WIFI and MQTT - ideal for being controlled by a Raspberry Pi or similar using, say, Node-Red
  • Flashing status (software supports both simple LED and serial RGB LED)  indication that the unit is functioning and has the correct time which it maintains internally in between updates*
  • Second serial output to support Nextion displays (see the Nextion WIFI Touch Display project)
  • Software mono-stable out for use as a watchdog
  • Outputs can be timers for watering systems for example
  • OTA updating from internal or external website
  • I2C support for an ever-increasing range of devices
  • Hitachi LCD and Seeed OLED support
  • 16-channel 12-bit PWM support via I2c
  • 4-channel 16-bit ADC support via I2c
  • A new NANO-based peripheral via I2c
  • A new SPi-based experimental terminal
  • and more to come…

* (The time comes from an MQTT broker, for example using a Raspberry Pi or similar running Node-Red – see below)

** I now use Node-Red on the Pi to do thermostatic control. Consider the thermostat code to be legacy.

And another board: we’ve also put together a board for the Nextion displays - but WELL suited as a general purpose board and it is detailed on the WIFI Nextion  blog entry but I’ve included a picture here for reference. I can see a variation on this one being my main board eventually – just needs an add-on with a couple of relays and 3 MOSFETs to make it a perfect development board.  There is a cap on the reset line so that typically an FTDI is able to reset it automatically. Note: The current revision of the board has extra grounds and  4 way sensor connector (DS18B20, DHT22 etc.). Note that an even later version optionally uses an RGB LED for a status indicator – WAY better idea.

Nextion control board

The Controller

ESP-12We have chosen to commit to a communications protocol called MQTT as reliable code for this is freely available, MQTT “brokers” are also freely available and once you spend a little time on the subject it is both easy and the obvious way to control stuff in a network. Lookup “tuanpm mqtt” on Google.

As MQTT is so central to this, I’ll go into this in a little depth.  There are many ways you could have units talking to each other – a mesh network, a radio network, polling etc…over time I have come to see MQTT as the ideal tool for home control because it is simple, the tools are free and it WORKS.

Essentially an MQTT broker is a piece of software – a server if you like,  available online or (my preference) on the likes of a Raspberry Pi inside your network) which monitors incoming messages and sends messages out according to who they are for. Addresses are simply text. Messages are simply text. MQTT clients (software that receives MQTT messages for one unit and sends messages out to an MQTT broker) are available freely for the likes of Arduino, ESP8266 and in Node-Red. It really is all very simple once you get playing. So MQTT is an incredibly simple yet powerful format comprising a message “topic” and a message “payload” both in the form of simple text. Units can “subscribe” or listen for specific topics. A great way to play with this is to use an online free MQTT broker – and something like MQTT-SPY which is a free “client” which runs for example on a PC.

The ESP-12-based controller has a number of inputs and outputs which can be controlled equally well by MQTT commands or serial data - by the current software.

To talk to the unit wirelessly (WIFI) via the popular MQTT message protocol, a message can be sent to the topic “toesp” to send to all units in the network or to a specific unit by prefixing the topic with the unit ID, or example “kitchen_light/toesp”. The only difference between these two topics is that the former will go to all units yet never elicit a response from any unit, the latter will go to unit “kitchen_light” only and MAY, depending on the context, elicit a response from unit “kitchen_light” – unit ID is simple, programmable text.

Whatever controls these boards(Raspberry Pi?)  should now send

topic: toesp

payload: {heartbeat}

every minute. All the boards will see this - and all will pre-set a counter in themselves - which if allowed to drop to zero will re-initialise the MQTT code. In the event that boards lose the WIFI for some time, they may reset their WIFI  - then reset the MQTT code. Reset is used only as a last resort and the software can handle up to two SSIDs in case you happen to have two access points. If one fails it will try the other.

Hence in theory they should be bullet-proof. In practice they are bullet-proof unless of course the power goes off. Last summer in Spain I endured horrendous WIFI and power issues and the current code stood up to this and has done ever since – learned the hard way. That experience is also why I worked hard to ensure the OTA works so I can update the units remotely.

Each COMMAND or payload starts with an open brace and ends with a closing brace (my choice, kind of like JSON). In the case of MQTT, this information is stored in the message “payload”. For serial, there is no “topic” – just the message (payload) which you can fire into the serial port at 115k baud.

An example of a simple command might be to turn output 4 ON (output 4 goes to pin GPIO4).

{out4:1}

It is possible to send multiple commands at once by separating them with semicolons. i.e.

{out4:1;out4:0}

So to use serial – this is all that is required (newline delimiter) – for MQTT – the topic should be as referred to earlier and the payload should be in the format shown just above.

clip_image002[4]For more on MQTT go here. http://mqtt.org/

I chose to use a Raspberry Pi 2 (you could use 3 but 2 is ok) as my controller – and chose to use Node-Red as the controlling software when this was a project unknown to most  – turns out I picked a winner as Node-Red is now embedded in “Raspbian” on the Pi and is hence guaranteed a well-deserved and bright IOT future. It is also wonderful and really NOT hard to use. Want to play with Node-Red without even doing an install? https://fred.sensetecnic.com/ – enjoy.

The following document details the commands the units will respond to – the actions which will occur along with any return serial message or MQTT message created as a result of the incoming command. But please – read the manual.

The Pins

Here we see a drawing of the ESP-12 board, please note there is a question mark over the positioning of GPIO-4 and GPIO-5 – on many units, these are reversed.

You are looking at the FRONT of the unit with the metal cover visible.

clip_image002[6]clip_image004

Note: Contrary to the diagram, in prototyping I’m using a 1k to pull GPIO15 down as it’s still a grey area (some say the board won’t program unless GPIO15 is held down) – it does NOT have to be fully grounded and as you’ll see in fact I added PWM output on it (March 26, 2015).

Preliminaries

The ESP-12 units operate on 3v3 – NOT 5v. Extensive experience suggests a good 3v3 linear regulator fed from, say a 5v supply provides more reliable results than a 3v3 switched-mode supply – but that will vary with suppliers. I’ve recently been part of a project where we used WELL over 100 ESP-01 units all attached to one 20 amp switched mode power supply – they worked… but I prefer per-unit linear regulation.

We done just that in all our own boards, using a switched-mode 5v supply (or DC/DC convertor for 12v use) with a 3v3 linear regulator. I suspect most complaints about these boards boil down to power supplies. I can honestly say – that having used countless ESP boards since they came out – I’ve not once come across a bad board!!

To talk to these units from any 5v system through serial, you should ensure that inputs to the ESP-12 never exceed 3v3 (resistive divider). Typically the serial output will work just fine fed into, say the serial input of a 5v Arduino – I have NEVER had any trouble with this at 115k baud. Simple resistive level conversion can easily be implemented so that a 5v FTDI will talk to the serial without issue. In practice I’ve yet to see a 5v FTDI destroy an ESP8266 but if you go without the divider, be it on your head.

Certain pins are special and in particular, grounding GPIO-0 on power-up is used to trigger “flash” programming of the chips and also used to put the units into access point mode for setup – so you should be aware of this. When designing outputs I base all of mine on Vcc. So for example when driving a LED…

clip_image006

Why do I do that? Well, when the unit powers up – GPIOs are all input – and if you preset them to “1” on power up you’ll not get any flashing lights as the units boot up.

Below describes SOME of the commands currently implemented.  We have both WEB-based and SERIAL setup, full MQTT integration and the development focuses on using NODE-RED – specifically but not exclusively on Raspberry Pi (I’ve installed Node-Red on many SBCs and consider it as standard as adding Apache and PHP.  We’re using the free and excellent Mosquito for the MQTT “broker” on the Pi (i.e all units connect to this “broker” by address and password” and the broker stores and releases on request stored messages – hence any unit can talk to any other unit as well as making requests of the Pi).

The manual that comes on BitBucket with the code is way more comprehensive than this blog in terms of commands.

Command set

Controlling and monitoring outputs

The potential outputs are GPIO0 (that’s the one on the board with the relay – future boards will not use GPIO0), GPIO4, GPIO5, GPIO12[1]  GPIO13[2] and GPIO16. These are referred to as OUT0[3], OUT4, OUT5, OUT12 OUT13 and OUT16. You can also use GPIO2 as an output via a command – normally it is used with the likes of temperature sensors.

Typical outputs respond to the commands {outX:1} , {outX:0} etc where X is the GPIO number. If requesting the status of an output this form is used {out0?}

There are 3 variations on this:

{out13} (GPIO13) by default should not be used as its main purpose is that of a LED “status” indicator (though you can override that) (see the relevant command).

{out0:X} responds to the following for X:

0 – off (if command “invert=1” then the state of that output is inverted (for positive-based relays) – see the invert command…

1 – on (see above)

2 – on from dusk till midnight (see above)

3 – on from dusk till dawn (see above)

4 – on from dawn till dusk (see above)

5 – under local thermostatic control – see relevant command (see above)

6 – timer for output 0. Another parameter determines ON time in minutes – i.e. {out0,6,100} sets the output on for 100 minutes.

There are a set of related commands for reading the state of outputs – these are {out1?} {out2?} etc. Should unit “kitchen_light”  be asked for the state of out1 – the MQTT message sent back will be in the form

topic: kitchen_light/fromesp/out0

and the payload will contain the appropriate value.

Outputs can be inverted by the invert command by setting bits 0,1 and 2  etc., in the invert command. See the manual.

PWM

We’ve added PWM onto 4,5 and GPIO15 using the latest Espressif library which allows for up to around 95% duty cycle at very high resolution (14 bits) for the cheap 12v serial RGB LED STRIP though we have brought that down to 100 smoothly transitioning levels – but decent ones (i.e. non-linear – with more emphasis at the bottom end for smooth transition). Attached to a logic-level control MOSFET you can drive a 12v LED strip with this – initially off, use the command {pwm:X,Y,Z,I} where X,Y,Z are 0-99 for duty cycle and I is false if you want instant transition, or any value if you want a smooth transition. For example if I =50 (50ms) then 0-99 would take 5 seconds. A lookup table is used to get a reasonably smooth fade (needs work).  Due to the Espressif library, you can get up to around 90% or so duty cycle at value 99 – but you really would not notice the extra on a light. Note also that the PWM even when off i still running – so if you run PWM with a board, don’t expect reliable SERIAL LED operation as the PWM has a minor effect on really critical timing as needed for serial LEDS.

Heating controls

In controlling heating, the unit will generally use the internally connectable (on GPIO2) temperature sensor DHT22 (which also handles humidity) or the Dallas DS18b20 or DS18b20p. These heating commands are deprecated as it is a lot easier to do heating controls in Node-Red.

It is possible right now to set the maximum temperature, the fall-back temperature, frost temperature and 2 on-off times per day locally. Of course using an external MQTT control the possibilities are endless.

Relevant commands are (X is general a value, degrees C or minute after midnight):

{peak:X}

{off-peak:X}

{frost:X}

{on_1:X}

{off_1:X}

{on-2:X}

{off-2:X}

Time settings

The units are able to keep time but clearly do not have a source of time – this can be provided to each unit separately or more sensibly to all units at once.

{time:X} standard Unix time value the number of seconds since January 1970

{dawn:X } number of minutes past midnight considered “dawn” or street lights off time

{dusk:X} number of minutes past midnight considered “dusk” or light up time

{When they power up, units attempt to log on. This is an ideal time to send them the time.

The ADC

The internal analog to digital convertor reads from 0 to 1.024 volts and outputs a signal accordingly. This can be read by the {adc?} command.

Debugging

From the serial console, we can view various settings by using the command {debug}.

Temperature and Humidity

The relevant commands here are {temperature?} and {humidity?} They will send out, by return, for example in the case of unit 999 :

Topic: 999/fromesp/temperature

Data: X where X is in degrees C

Humidity follows the same format but is a percentage.

Expansion

If we want the unit not to respond to a command but to pass everything on to the serial line to control, say an Arduino, use the EXT command followed by a string  – this can be used part way through a multi-line command if required.

{out0:1;out2:0;ext:”out0:1”}

The two outputs will be switched and the command {out0:1} will be send out of the serial port.

Of course, one COULD send these commands off to an Arduino – OR you could send them off to another ESP-12 with it’s WIFI disabled… the logic of that? It’s cheaper than an Arduino and faster!! You can develop in the C language for the ESP boards using the unofficial Eclipse development environment.

http://programs74.ru/udkew-en.html

and you can learn more about my own work at http://tech.scargill.net

clip_image008

Setting up for WIFI

There are commands to set the unit ID (defaults to “999” note this is a string not a number), ssid, ssid2, pass, pass2, mqtt_host, mqtt_port, mqtt_user and mqtt_pass. In each case surround the argument with double-quotes.

i.e.

{id:”123”}

You can also set “desc” for a short description and “attribute” for any short message like “Dallas” to indicate what facilities the board has.

The above can also be set by WIFI.  Turn the device on and immediately short GPIO0 to ground AFTER power up for several seconds. This will put the unit in to web setup mode. Have your laptop, tablet or phone browser log into Hack-setup and go to 192.168.4.1/wifi/wifi.tpl to set everything up.

There are two SSID and passwords – the idea being that if the unit fails to get through to an access point it will try the second one, if that fails it will go back to trying the first one etc.

Reset

If for any reason we want to reset the device, the {reset} command will do that.

Inputs

GPIO14 is an input. We can read the state with the {in14?} command.

It is also de-bounced and you can read (and simultaneously reset) the count using the in14_count? command. The inbounce:X command will let you set the bounce value in milliseconds.

When the state of the input changes (de-bounced) an MQTT message will be send out in the form of TOPIC: XXX/fromesp/in14 where XXX is the unit ID and  MESSAGE: 1 or 0

There is also a bounce value for in2 – i.e. {in2_count?}

Manual Override

If we wish to manually over-ride the status of GPIO-0 – for example wall control of a light – set {override:1} to do this – the input can then be attached to an on-off switch and will over-ride the output for a length of time in minutes determined by “override_time”.

RGB LEDs

One of the more useful features of the board is to be able to directly control an array of WS2812B LEDs. Right now, overall control is implemented including programmable fade-in and fade-out and a “rainbow” effect. However, buffer space is available to implement full individual control of up to 900 LEDs (warning use separate 5v supply for these – current can be up to 5amps for such a run). Note you cannot currently run PWM and RGB LEDS at the same time. Initiating PWM starts a timer that disrupts RGB timing and a reboot is needed between these. I’ve contacted Espressif about this.

The command takes the form of:

{rgb: port,red,green,blue,number,duration}

So if we want to go to bright red over 10 seconds and you’ve attached an array of 20 serial LEDs to the output GPI12, the command is:

{rgb:12,255,0,0,20,10}

And that will happen and we can do other things while it is fading in. The duration is a 32 bit number.

For amusement purposes we can also try {rainbow: port,number_of_leds,duration[,timer speed in ms]}

A neat toy: requires 60 RGB LEDs and can run on a port pin… a clock… {clock: port} if is 255, the clock is not running else runs on the relevant port.

If you want to just light up SOME LEDs in a strip – the command {rgbset: start_led, number, r, g, b} will let you set up various LEDS to various colours and the command {rgbgo: port,number_of_leds} will start the ball rolling. That number should not exceed 300 (not for any reason – I could have made it larger).

If you want to play with animation… {rgbstart: port,number_of_leds} will clear a command buffer so you can interactively add sequences {rgbadd: start_led,number_of_leds,r,g,b,milliseconds} and when you want it all to end, {rgbstop}. These commands can be sent via serial of MQTT.

Other

When the board powers up it sends a message “esplogin” and in the body the the name if its ID with a slash after it.. so “999/”. This can be read to send the board, say, the time. See the next section.

I’ve implemented {sleep:x} where x=microseconds (32 bit number) hence 10000000 is 10 seconds. You need GPIO16 attached to reset and that just isn’t worth the saving on this particular board but it’s in there for completeness. This is deprecated.

Node-Red

BlynkOriginally we’d planned on using something like OpenHab for home control and of course anyone armed with the software can do just that. But for our purposes we like Node-Red as it is extremely flexible and becoming more powerful by the day. If you have a Raspberry Pi2 or better – you can run Node-Red on that but it also runs on Linux, PCs etc.

Node-Red allows one to “program” using visual boxes via a web interface– so an MQTT input box can respond to a particular topic, you can then do something with that and send a message back – or elsewhere – or maybe send a TWEET, or store some info in a database or send an email – honestly it is VERY simple to use and very powerful once you get to grips with it.

If you look at my earlier blogs I’ve written about graphing locally, using data pulled in by Node-Red and stored in a MySQL database with ease. There are alternatives – I’ve written a “node” for Node-Red to let you simply send data to Grovestreams.com and others have written nodes for the likes of EmonCMS which has some very pretty dials.

Here’s a screenshot of my Emoncms data and yes, the battery is really flat – due to this being solar charged out in Spain – and it is 6am in the morning – clearly yesterday wasn’t that sunny.

EmonCMS used at Bedrock in Spain

Node-Red has a timing module… when lets you trigger things at certain times. It also has available a suncalc which sets a flag when it is sunset. I’ve improved this significantly in a node called BIGTIMER (see http://flows.nodered.org/ -  check out my bigtimer, esplogin and grove nodes– my contributions – for example – “npm install node-red-contrib-esplogin”) -  to produce an output directly suitable for the current design – to log the boards in and to tell them about the time, sunset and sunrise.

The esplogin node can send time updates when Node-Red powers up and on a regular basis (every 12 hours)to all boards – but also send to a specific board on request, and all boards will happily send that request when they power up – so typically a few seconds after power-up the boards know what time it is and what dusk and dawn times are.

Here’s what it looks like in action.. MQTT coming in from boards in the form of a json payload (purple), esplogin node in yellow doing the time/dusk/dawn updating and outputting the relevant MQTT back to the board (or in the case of time top-ups – all boards). The outputs from esplogin are, in order..

1. MQTT output

2. Output for a MYSQL database (legacy)

3. Output to a straight text logging file

4. Output to a SQLITE database

 

tmp3A16

All boards subscribe to “toesp” – and to a version of that with their name (ID) prefixed – so for example fred/toesp. That way I can talk to any board – or all of them.

When the board first powers up – it sends…  in the case of board “fred” which has description “my board”

Topic: esplogin

Payload: {“id”:”fred”,”desc”:”my board”,”attribute”:””}

Desc and attribute at not that important but can be shoved away in a database.  So that sets off the esplogin node  putting info to it’s outputs – I only use the SQLITE output and that ends up in a database – that’s up to you but my setup is in the Raspberry Pi script referred to elsewhere.

So assuming the node gets that login – it will send a bunch of time info back to the ESP board in question – and will then do that every day to all boards. This stops the boards from watchdog resetting and ensures they always have the correct time without needing a real time clock etc.

See the time, dusk and dawn commands – the ESPs can be updated though right now this isn’t necessary as the home control software on the Raspberry Pi is doing all the work.

How to get all the software the easy way

In order to use these boards effectively – you’ll need a Linux setup (a Raspberry Pi 2 or 3 for example) with MQTT, NODE-RED and preferably other stuff like PHP, SQLITE etc. Personally I’m not a Linux lover!!! And so I like things to be easy – so we made a SCRIPT. You can grab a Raspberry Pi(2) and put everything on there. The script works with JESSIE version of Raspbian. I made this script for “Jessie”. Follow the instructions precisely or it will not work. You must be user PI and NOT ROOT. Read more about the script here...  and

I use the Pi2 – after testing many boards this seemed a while ago to be the best for the job IMHO and for reliability use a good SD such as Samsung EVO and to make life really easy. If you have a Pi3 all the better.

For controlling and monitoring – I am currently using the Nextion (serial) touch display boards for the wall and vary between using Blynk Android/IOS app for remote control, the node-red-dsahboard and ImperiHome.  All work well depending on your requirements.

You’ll read about all of this stuff elsewhere in the blog – use the search facility – there is a LOT of info.

Notes:

[1] GPIO5 (out5) can be manually over-ridden by the input and the “override” command.

[2] GPIO13 (out13) is generally used as an indicator to show that all is well. It activates on receipt of the correct time either serially or via MQTT and will flash briefly once every couple of seconds from there on. This activity can be disabled by a command. Increasingly we’re using a serial RGB LED on this pin to provide more comprehensive status info.

[3] GPIO0 (out0) is special in that it responds to more than “1” and “0” and can be used as part of a heating control system. Ultimately we will scrap using GPIO0 as an output and merely use it for programming and setup. GPIO16 makes a good relay output as it is not much use for other types of output.

Haptic feedback – when the board is being used in “Nextion” mode – we use GPIO12 as a beeper – simply fasten one of those cheap round haptic feedback devices to it and glue that to the back of the board. Also note that with limits (the line buffer is only 80 characters in length) you can concatenate commands so that for example if you want to turn GPIO12 on and get feedback as to the state at the same time {out12:1;out12?}  - note the two payloads are joined together by the semicolon.

But the REAL source of info on commands is in the WORD manual with the project – that is where you go to keep fully up to date.

 

Enjoy!

Facebooktwittergoogle_pluspinterestlinkedin

A little aside

40 ESP-01 Boards

Some testing of 40 ESP-01 processors – all sending MQTT data data back to a database, powered by a 20 amp power supply.

Just two more of the same to go.

Of interest to those struggling with ESP-01 – I normally have a 3v3 supply on board but this time they are just on their own – so I was using the 3v3 output of an FTDI to power them and I had to have the odd retry at programming – something that normally NEVER happens. All my leads are short and properly formed so I’m hazarding a guess while the USB is able to supply enough current (at 5v) the chip on the FTDI is SLIGHTLY under-powered when delivering 3v3 to the ESPs.   Next batch I’ll put a large cap across the power. Having said that out of 40 flashing attempts I think I only had to retry 4 of them.

All working a treat and looking distinctly spiffy as the 40 blue comms lights flash – sometimes in sequence, sometimes out of sequence.

Facebooktwittergoogle_pluspinterestlinkedin

The Nextion Experiment

Nextion BoardOur latest experiment! The board you see to the right should be with us in a couple of weeks. This little number will sit on the back of a Nextion board, from the smallest to  the largest without adding any height (hopefully) and contains as you see an ESP-12 and supporting components.

The extra connectors are just to give it a more general usefulness.

Having implemented software serial on GPIO4 and GPIO5, the board will allow for sending messages via MQTT directly to the Nextion while still allowing debugging and programming of the ESP using the normal ports. 

Far better I think than strapping a Raspberry Pi onto the things. We’ve not tried to do anything too clever here so this all assumes the display is already programmed up.

My own use for this is a couple of simple wall units to show and control heating and lighting… I already have a display hooked up to a Raspberry Pi for general control but it’s a tad excessive having those plastered all over the house hence this board which we’ve had made as thin as possible.

Can’t tell you much more until we get the boards back and give them a go.

Currently ending my first week of a 2 week contract (well for now anyway) over in Spain so my ability to experiment is severely hampered as you might expect (but that is compensated for by sunshine). 

By the time I get back to the UK  I’ll have some more Sonoffs to play with (hopefully the later types with one of the LEDS attached to GPIO13 on the ESP8266) and some new ESP-related stuff to review.  My new workshop is up – just needs electricity, insulation, desks, shelves – no problem really!

Facebooktwittergoogle_pluspinterestlinkedin

General Update

tmp11DFThe last couple of days has been interesting – we’ve been checking that the Raspberry Pi 2 script works properly – it turns out that it simply won’t work if you have any kind of root access to the Pi. I’d not realised by by giving myself SUDO access in winSCP – rather handy for editing files, I’d given myself the same access in the terminal – and hence all attempts at the script failed. Today after starting afresh with the November 2015 Jessie image from Raspberry Pi (NOT the Noobs setup) – and running as Pi user, the script (despite warnings) operates perfectly, installing Apache, Sqlite, Mosquitto with web sockets and Node-Red with a host of nodes including my own.

In other events, the ESP8266 code referred to elsewhere in the blog has taken a leap (not yet online – I’m off to Spain for a couple of weeks and I’ll get onto that on my return) and now handles (thanks to Richard Burton for his help) OTA.  Still working on OTA from an external site.  We’ve added OTA setup commands to the web interface.

Most importantly on the above we’ve found and modified a library to give a software second serial port able to run at 56k – hence enabling direct Nextion display interaction on an un-modified ESP-12 for example. I already have a display device with buttons controlling other ESPs on the network via MQTT commands – this could be so powerful and will allow for remote control display panels all over the place.

tmp762BThe Sonoff device continues to work well with our software, waiting to find out how much FLASH it has on-board to ensure we’ll be able to work with that,

Sunny SpainRight now I’m packing my bags as I’m off to work on a project for just under 2 weeks on the east coast of Spain near Barcelona – using ESP-12s and Raspberry Pis strangely enough so output on the blog will be somewhat reduced as I can’t take my toys with me. I’ve a new paper-white display and a fantastic new software-defined radio setup – but they’ll just have to wait for my return.

The Facebook page at www.facebook.com/esp8266wifi is seeing more Pi and review related material and I’ve decided it is time to move the non-ESP stuff off onto a page of it’s own – so please if you are a Facebook user, follow www.facebook.com/iotstuff

Facebooktwittergoogle_pluspinterestlinkedin

Obsolete Fixed IP Tutorials

I’ve just spent half the day trying to fix the address of one of my Raspberry Pis. No matter what I did, it kept the address that it was assigned some time ago.

I even tied the IP address to MAC in the router – and THAT didn’t help. Countless resets of the router and the board got me nowhere until I read this:

http://raspberrypi.stackexchange.com/questions/37916/setting-up-static-ip-address-on-raspian-jessie

My /etc/network/interfaces file didn’t look like that so I updated it… turns out in Jessie you have to update the file /etc/dhcpcd.conf

Here’s mine..

 interface eth0
       static ip_address=192.168.0.20/24
       static routers=192.168.0.1
       static domain_name_servers=192.168.0.1

Even getting this far, some tutorials said you needed far more information than this or the Pi would not be able to contact the outside world. Well, mine does now and the address fixing works. Worth keeping that link in your bookmarks.

Facebooktwittergoogle_pluspinterestlinkedin

The not $25 LeMaker Guitar

Lemaker GuitarYou may well not be familiar with the name LeMaker but you are likely familiar with “Banana Pi” – same people (Shenzhen LeMaker Technology). This is NOT like other boards I’ve reviewed in here. This morning a large box arrived in the post from LeMaker.

So the Guitar is a small board with a solid-looking heatsink and an edge connector – that’s it. One button and a slide-switch. Bit of a worry until you see the baseboard into which it makes a smart fit. At this point it really just looked like one board – BIGGER than the Raspberry Pi by maybe 50% and square unlike other boards I’ve looked at recently. The specs are quite impressive and the processor is running at 1.3Ghz.

I’ll list here the specification of the combined baseboard and processor board as one is pretty useless without the other.

  • Actions S500 Soc with integrated quad-core ARM Cortext A9R4 CPU and Imagination PowerVR SGX544 3D GPU
  • 2GB DDR3 SDRAM
  • On-board 8GB eMMC nand flash storage
  • Input 5-12v at 2ADC max.
  • 10/100Mbps Ethernet and 801.11 b/g/h WiFi.
  • 1 microUSB 3.0 and 2 type A USB 2.0
  • HDMI type A and LVDS. (Audio included on HDMI)
  • Camera interface
  • 40 pins including GPIO. SPI.I2C, UART, I2S and PWM
  • MicroSD card slot
  • Power key, reset key, 2 x user-defined LEDs, ADC, IR receiver and battery connector.

LeMaker Guitar

This combination came complete with Android 5.11 running in eMMC. The pack did not have a power supply but the connector is standard so I plugged in 5v, an HDMI monitor, keyboard, screen and keyboard.

LeMaker GuitarSo – a good start, almost everything worked out of the box. I could not get the keyboard to work, instead an on-screen Android keyboard came up, not a pleasant experience when you’re sitting in front of a proper one. I checked out the usual – memory showed only 2.3GB of internal SD left (the eMMC) which was a bit low – I quickly popped in a 32GB microSD and this appeared as an external SD. I’ve not yet checked to ensure that programs will go into external SD but it would be pretty daft if they didn’t.

LeMaker GuitarNot for the first time when running Android on a single-board computer, screen resolution was low. I altered it to 1920*1080 but it still had an interpolated feel about it  -maybe that’s a limitation with Android.

The pack also came with some peripheral boards, one of which provides even more I/O lines and 4more USB 2.0 connectors (for a total of 6 USB 2.0 connectors). The boards are stackable so you can just keep going. The next peripheral board provides 2 10a relay outputs,8 LEDs and even more outputs. A third board provides I2C connector, 2 UARTS and 2 SPI connectors along with a connector for an LCD1602 and more GPIO. All in all there’s something for everyone in this system “kit”.

So Android – the good news is it bang up to date – the first time I’ve seen that – but then with something this sophisticated, for me, Android doesn’t do it. So I went off to their site to see what else was available.

http://www.lemaker.org/product-guitar-resource.html

Looks can be deceiving but this looks like one of the better systems I’ve seen – albeit not the cheapest. As well as Android, they have Ubuntu Mate and what I assume is a variation, Lemuntu, LeMedia (KODI) and Arch Linux. In a future article I will be checking these out.  Having lots of peripherals is one thing – being able to use them is another.

As for pricing – you’ll see $25 out there with no-one sure if that is for the little processor board or the whole lot – well, the only price I’ve seen up to now is £47 sterling and that DOES include the baseboard. Someone on EBay is trying to get £105 for it – I think they may be disappointed. Right now there are more “pre-order” sites than anything else  - but hey – you wouldn’t want a review of an old product Smile

More on this one later – still awaiting the construction of my new office where I can properly photograph this stuff and do video etc… (we moved recently). Installing Ubuntu looks easy. If you put an operating system on SD it takes priority over the one on internal eMMC.

https://www.reichelt.com/?LANGUAGE=EN&CTYPE=0&MWSTFREE=0&CCOUNTRY=447&ARTICLE=162294&PROVID=2788&gclid=Cj0KEQiA5dK0BRCr49qDzILe74UBEiQA_6gA-muDAVap4Yd64aaR-qzrUFGk3xYcqjIMRU9VLOsd_yAaAgxp8P8HAQ

Update 23/02/2016

Turns out that the LeMaker Pro uses the same processor as the RoseApple Pi which is interesting – it should mean that the operating systems would be compatible but I just tried putting the microSD from my RoseApple Pi unit into the LeMaker – no joy – however I did download their media centre image using a stripped down Linux and running Kodi.  I have to say I did notice a slight amount of juddering on 180p videos – but only just – and it could have been because I’m running on WIFI… but otherwise it seemed to work just fine until I got carried away and started messing with the settings – could not find any reference to infra-red remote and you can’t drop to the operating system level…. so no remote? Erm, no. Next stop – Lemuntu which despite the name is not Ubuntu – but Debian!

Facebooktwittergoogle_pluspinterestlinkedin