Anyone interested in discussing building DIY Home Automation software and hardware?

[NeverDie]

I hadn't realized just how fast an ESP8266 is until I saw it raced against other arduino compatibles:
https://www.youtube.com/watch?v=U6rfE-uFxxI
I was quite surprised that it even beat an Arduino Due by nearly 3x!
The low cost and the wi-fi make it quite interesting.
 
I think the guy who did the youtube video may have reached the wrong conclusion about the energy draw.  He's saying that because the ESP8266 draws 8x the power of the 3.3v Arduino Mini, the mini is better for low power applications.  However, for the given task, even though it draws 8x the power, the ESP8266 finishes 12x faster.  So, doesn't that imply that total energy consumed to do the task is actually less?  If the ESP8266 immediately went to sleep upon completing its task, maybe it is actually more energy frugal than the 3.3v Arduino Mini.  Anyhow, with all that as background, I'm finding the ESP8266 a lot more interesting than before.  I suppose what may decide the matter one way or the other is the amount of power it draws while sleeping.
 
Anyhow, I'd be curious as to how it compares with the EFM32 and some of the other MCU's mentioned above by tattema.  Is there a good repository of MCU benchmark scores somewhere?  All I've managed to find so far is just this:  http://www.eembc.org/ulpbench/

 

[deandob]

ESP8266 is definitely an interesting module due to its price and popularity however the SDK isn't as mature as more established products like TI's CC3200 (although most TI smart radios use an expensive toolchain to program the CPUs - you can use the GCC toolchain for the ESP). There is an active community around the ESP8266 so improvements in the SDK and interesting new modules and applications based on the ESP are being developed.
 
The problem with the ESP8266 power draw isn't its CPU speed but the time it spends awake communicating on WiFi. Typical sensor management activities aren't demanding on the CPU & usually short duration. For battery use the ESP8266 will want to push the sensor data out to the hub so it can be asleep for as long as possible, rather than a pull mode waiting listening for the other end to contact it which keeps the link alive. So if you are in deep sleep saving power then there isn't an active link when the device awakes - so establishment and transfer time will be much more than the time needed to measure a sensor value (typically a couple of seconds especially if using DHCP).
 
There are a number of threads on this here: http://www.esp8266.com

 

[tattema]

Anyhow, I'd be curious as to how it compares with the EFM32 and some of the other MCU's mentioned above by tattema.  Is there a good repository of MCU benchmark scores somewhere?  All I've managed to find so far is just this:  http://www.eembc.org/ulpbench/

 
Hi NeverDie
 
I enjoyed watching the video so thanks for posting it. I'm inclined to run a similar benchmark on my EFM32G sensors and LPC1788 gateway just to compare but because neither device runs the arduino SDK, I'm not sure we'd be comparing apples with apples. Crunching his tt =5000.00 /aa *i; formula would be more representative I think but then again, we're not really comparing energy consumption per MHz v.s. time.
 
I'll do some benchmark experiments and if they yield something interesting/useful, I'll post them.
 
The ESP8266 is quite an impressive chip and has made IP on a chip affordable for the average DIYer. As DeanDob mentioned, it isn't as mature as the CC3200 from TI but it isn't nearly as expensive either coming in at 6.95 for the ESP8266 on spark fun(for an assembled board) v.s. $18 for the CC3200 on digikey just for the chip.
 
​According to the Espressif website, the esp8266 draws 1mW when sleeping. 215mA max current consumption when transmitting. The TI cc3200 is even more power hungry. 229mA transmitting (highest power output).
 
I really like these devices and they're so well suited to realtime video/audio streaming and reasonably high bandwidth applications where range isn't an issue. They're great for experimenters and DIYers like us because they interface directly with our router and can talk to software/apps via TCP/IP thereby simplifying the development. Unfortunately, they're not so well suited to low power battery powered applications were long life is required.
 
Regards
Trev

 

[tattema]

Hi NeverDie
 
Here are  some benchmarks between the EFM32G running at 28MHz and the benchmarks from the video you posted above.
 
Be warned, these benchmarks are not a fair comparison because we're not considering number crunching power per MHz and the EFM is running bare metal without anything Arduino. For example, every device in the video and the EFM32 run at different clock speeds and the crunching speed varies depending on so many factors so in short, it's interesting but questionable!
 
The EFM32G crunches "tt = 5000.0f * 10 / i;" 100,000 times (double) in 796 milliseconds. Float is faster, but not much.
 

 
When I have time, I'll provide some accurate current consumption figures but as an estimate, current consumption is 180 µA/MHz @ 3 V and the device was running at 28MHz so that's 5.04mA.
 
Regards
Trevor

 

[tattema]

The ARM 32bit LPC1788 running 120MHz has been added. It comes in at 127ms
 

 

[deandob]

ARM 32bit is a bit of overkill for a sensor :blink:
But a good choice for a HA hub.

 

[tattema]

ARM 32bit is a bit of overkill for a sensor :blink:

 Would you like to substaniate your claim?
 
8bit v.s. 32bit debate rages on: http://community.arm.com/groups/processors/blog/2012/09/24/8-bit-versus-32-bit-mcus--the-impassioned-debate-goes-on

 

[deandob]

If there is a 32bit MCU that is as small, as low power, as simple to use (eg. solder) and as cheap as garden variety 8 bit MCU, then great - possibly I'm just out of touch. Nothing necessarily wrong with using 32bit but the raw speed of these devices won't be needed for most sensor applications (typical design pattern - setup registers, poll sensor for value, communicate if change, loop).
 
Having said that, my base level sensor platform is a top of the range 8 bit sensor (64pin TQFP) with embedded Ethernet, so its not a simple chip.

 

[tattema]

I'd love to hear more about your platform and devices. What MCU are you using?
 
I agree with you, the design pattern needs to match the device. Factors such as cost, familiarity, toolchain, individual experience, solderability (if that's even a word), supporting drivers, community support, BOM cost if manufacturing in bulk and possibly dozens of other factors need to be considered when making a selection so that the problem can be solved in the best possible way.
 
For my home project, I chose the EFM32 for many reasons but a major factor was low power and fine grain control over power consumption. I've been happy with the results but I'm sure a more experienced developer/DIY engineer would have chosen a different device.
 
Unfortunately, as you've pointed out, 32bit is more complex and that for me was a hurdle. It was difficult to understand the 32bit world and the complex ARM architecture but it's been worth it I feel. The serial wire debugging is incredible useful and I'd buy a full trace adaptor if I could afford it. For now, debug via selective use of fprintf.
 
Regards
Trevor

 

[deandob]

Trevor
 
The 8 or 16 bit devices aren't necesarily simple and each MCU architecture has its quirks. I have stuck with the Microchip 8 and 16 bit devices only because I started on them years back and learnt the architecture, quirks and toolchains - the experience makes it faster / easier to develop. But I'm sure as you have put in the effort to understand and use the EFM32 you now have the benefits of a more sophisticated MCU. I like the Microchip devices as they are easy to source, come in a wide range of sizes & power, excellent peripherals and have a lot of community around them. Same could be said of the Arduino but I just took the Microchip route before Arduino hit.
 
I'm currently using the 18F66J60 as it is the cheapest & simplest chip with embedded Ethernet as I prefer wired sensors versus wireless ones and also want to run power over Ethernet. Previously I used a very simple & cheap 16F628A which had 2K of memory that I squeezed in my DIY network protocol, speech recognition, LCD display, IO control (eg. from a motion sensor), light sensor, amplifier control and other functions as part of a room controller. To optimise all that functionality into 2K was an intellectual challenge (using BASIC not assembler) and took a lot of optimising.
 
Here is the link to my blog on hackaday explaining the design & build process for the current Ethernet platform: https://hackaday.io/project/3380-iot-ethernet-sensor-using-power-over-ethernet
 
I do want to build a similar wireless platform for sensors after prototyping NRF and BLE devices but haven't put much effort into it - will likely leverage the experience from you & others like NeverDie who have investigated RF options.

 

[NeverDie]

I'm starting to "get it."      Rather than get distracted trying to decide whether I "need" 32 bits or not, I should also look at the whole package and see if it is or isn't more evolved and just generally better.  For example, in the case of the LPC810, here's how the JeeLabs guy sums it up:  "The real value of the LPC810 is that it’s so small yet easy to use in different projects, and extremely flexible due to its extensive hardware peripherals and total programmability. Or to put it differently: six pins of 32-bit µC goodness in a tiny 8-DIP package, powered from 1.8 .. 3.6V (yet 5V-tolerant), capable enough to run at up to 30 Mhz, yet efficient enough to go to sleep using less than 1 µA of current (i.e. over a decade on a coin cell)."  Compared to the Attiny85, it just seems generally better, and with twice the RAM.    
 
The arduino platforms are getting long in the tooth, but it didn't dawn on me that they're teetering on obsolescence until I saw them get creamed by the ESP8266 in the speed races (above).  It's not so much that the ESP8266 is awesome as much as it is that overall the state of the art has progressed and gotten so much better.
 
For simple folk like me, Adafruit has a starter kit for the LPC810, as well as a tutorial on how to use it.  I like the specs on the LPC824 a whole lot more, and (strangely) on Digikey it's nearly half the price of the LPC810.  However, the LPC824 looks like it needs a board, even if only a minimal one, to go with it, whereas the LPC810 can be used practically standalone without a board of any type, if so desired.  If the LPC824 were in a DIP package, I'd probably buy one (and quite possibly later a lot more than one).
 
So, I may look a little further before pulling the trigger, but I'm now feeling the pull away from Arduino that tattema was mentioning (above).  Thanks, tattema!

 

[tattema]

Hi NeverDie
 
Arduino have really shot themselves in the foot through an international corporate war that's raged between their Italian and USA offices. Sad really, because the community has suffered and while they could have spent their time improving the platform, especially their crappy IDE, they wasted time in litigation.
 
I just checked out the LPC810 kit yo mentioned on Adafruit and it's pretty good (excellent value for money too) but I suspect you'll outgrow it very quickly. I see from the JeeLabs site that he's also moved onto the LPC devices having spent many years developing on 8 bit devices.
 
When you outgrow the LPC810 device and want something different, check out the mbed API's. It's like Arduino for ARM 32 but a whole lot better. They offer an on-line compiler so that you can just build programs in the cloud and then download them to your device over USB. No complex tool chains required coupled with huge community support fo sensors means it's a DIY HA place in heaven. If you then decide you want more control, they give you the source code too so you're not locked into their model. They have a HUGE array of supported devices as you can see here: https://developer.mbed.org/platforms/
 
I started using their LPC1768 which was their first board (ethernet enabled) and even though it was more expensive, I never regretted the choice. Since then, they have so many IoT related boards (many provided with schematics) that there's probably too much choice. I notice that they also have a range of EFM32 boards that support the mbed API.
 
I think this device would be of interest to those thinking about nordic RF devices: https://developer.mbed.org/platforms/Nordic-nRF51-Dongle/
 
Regards
Trevor

 

[tattema]

Here is the link to my blog on hackaday explaining the design & build process for the current Ethernet platform: https://hackaday.io/project/3380-iot-ethernet-sensor-using-power-over-ethernet

Hi DeanDob
 
VERY nice indeed!!! What power of Ethernet issues did you face? If I wanted to understand the problem domain without futzing around, where should I begin? Tell me more about your speech recognition solution? How did you do that?
 
Regards
Trevor

 

[deandob]

The Power over Ethernet wasn't as easy as I thought it would be. But I do think PoE is overlooked in the IoT space as there are a number of solutions where a wired sensor is just better, and having the sensor/MCU powered over the network is a definite benefit.
 
There are a number of constraints to worry about (higher voltage to get reasonable power over thin cat5/6 wires, different standards, complex hardware required for handshaking etc.). In the end I selected an integrated solution from Si Labs as outlined in the blog so that the switcher and handshake features are in one solution. Had to futz with soldering the QFN Si chip as a couple of the initial boards didn't solder too well with my DIY reflow hotplate and also learnt the hard way when I blew up my programmer as the switcher on the Si3402 is earth referenced to -48v (so devices connected to it need to be isolated from the source, normally not a problem in the field). All the usual stuff I suppose - managed to work through it all but took longer than it should. I'll do a v2 of the PCB to fix up a few errors and reduce the size a little more. I can send you some links if you want.
 
Regarding speech recognition, that was one of the 'first principles' projects where I studied the theory behind speech recognition and experimented with a number of different approaches. Having a very constrained MCU and memory (had about 300 bytes to implement the speech recognition module in) made it more of a challenge. Basically I recorded the speech in 20mS segments after analog and digital filtering, breaking up the speech into number of zero crossings for low frequency (500 Hz) and high frequency (3K) and comparing them against pre-recorded templates. The analog part was critical, I designed an automatic gain control and limiter gate, which meant that you could speak close or far away and get a similar result, and ensure that no noise would trigger the recognition when no one was speaking. The algorithm used was Dynamic Time Warping, which finds the shortest path through a matrix of differences between spoken speech and the template, the smaller the path the more accurate the recognition. It worked remarkably well, with 90+% recognition rate and very low false triggers, although not as good as the Amazon Echo or Microsoft Cortana that I have been playing with lately. Also this was only used for the trigger word (to wake up & start listening for commands), once the trigger word was recognised, I switched the mic input from the local unit to a central PC Server that used Microsoft speech recognition running on the hub for HA commands. This setup worked well and all the things that people are amazed that the Amazon Echo can do, I was doing 5 years back (eg. voice control of lights, playing music, asking general questions - via Wolfram APIs).
 
I'm redoing these modules now with Raspberry Pi and Windows 10 IoT so that I get better speech recognition, have a nicer 5" LCD screen which will display my HTML5 widgets and be generally more extensible than the old system. The room modules will also incorporate a class D amp that drive in-wall speakers for music and speech synthesis, IO for motion detectors and the 5" screens will replace existing in-wall light switches for a truly 'built-in' HA system.

 

[deandob]

Thanks for the links on mbed for ARM, the online compiler is a good idea to remove the toolchain headaches. Definitely a good place to start with for ARM.
 
The devices are a bit expensive however, $45 for the cheapest isn't competitive with the Raspberry Pi or Beaglebone black that are much more capable devices. By comparison, the PIC 18F66 (although not as capable as the ARM M3 still in the ballpark for sensor use) with PoE and PCB has a BOM of about $15 although of course I had to do the design work and get a PCB made.
 
Oh - I forgot to mention with PoE write up above that you need a special RJ45 jack with PoE support if you want integrated magentics as the PoE filters are different to standard Ethernet.