A reminder - the Cricket is a small ESP8266 board with built-in temperature sensor and real time clock (RTC). It's a fraction larger than an ESP8266 01 - and there are two things that make it very special.
Its power management allows it to run for months on a single AAA battery. With just two AAs, you're set up, literally, for years. No more 18650s and charge controllers, no solar panels or other added circuitry. The Cricket takes care of it all.
Programming Cricket is done Over the Air (OTA). There's no fiddling with the Arduino IDE and updating libraries. No struggling with sketches, and missing serial ports. A one-second button press is all that's needed. You're ready to roll with your new setup in less than 10 seconds.
As I explained in my original post, the price paid for this convenience is the limitations of the board; you can only do what is sent Over the Air. However, many IoT applications need something quick, simple, and reliable, and this is where Cricket comes into its own.
I alluded to some of the limitations back in my first review - which apparently registered with the developers - because they sent me Version 2 (called "Revision 1") and they've fixed most of the things that bothered me.
One of the criticisms of all IoT devices is their security vulnerability. More often than not, when you set up a commercial IoT device, you need to register with the corporate developers' cloud service. The moment you do this, you're opening doors - and who knows where it will lead...
The first generation of Cricket did the same. To use the device and reprogram through OTA, you needed to register with ThingsonEdge and your updates were sent from their servers.
Version 2 is designed to alleviate this problem. If you choose, programming of Cricket is done directly from inside your local network so that your IoT devices are never exposed to the outside world. Personally, I'm not acquainted with any commercial IoT device that allows you to do this.
Of course, you can still reprogram Cricket from the ThingsonEdge servers if you wish.
There's always a but...
There is one caveat to this. While you can reprogram Cricket 2 from your local network, if you want to update the firmware, this is done from the ThingsonEdge servers. (This is only logical; new firmware can't come from inside your home network, it must come from them.) You don't need special registration at their site - the existing firmware knows where to look. All you need to do is set the app to automatically update firmware when it's available.
Just what I want
For me, the new setup does just what I want. No more exposing my IoT devices to less-than-trustworthy foreign services. Meanwhile, if a 3rd party that I work with (say IFTTT) changes a protocol, Cricket firmware can be updated automatically from the mothership to meet the new parameters without complicated re-programming.
The first iteration of Cricket had a couple of interface pins. The second has three, one of them digital/analog. In addition, the board has a 3.3v output pin - useful if you intend to power an external sensor. I tried the analog port with a Light Dependent Resistor (LDR) attached to the 3.3v output, and it worked like a charm.
The discerning reader will have noticed that I didn't call them I/O pins. It was while I was working on a small project that I suddenly realized something: all the pins are input. I can't, for example, trigger a relay. This hadn't bothered me with Cricket V1, but when I have three pins, it would have been nice to be able to use one as output. However, this would likely screw up Cricket's outstanding power management, so I suppose I'll just need to make do with what there is.
New Developer Interface
When I received Version 2, I assumed all I needed was to register the board with the Developer Portal that I used for Version 1. Turns out I was wrong; there's a new portal for Version 2 - which I only discovered post-RTFM. I could have avoided all the hassle if I'd just read the new Quick Connect Guide that came with the board.
Logic Board on Github
One of my complaints about Version 1 was that a closed switch attached to the wakeup pin would continuously call home, eventually depleting the battery - and if you were using IFTTT, it would quickly use up your daily quota of notifications. When I received Version 2 for review, the developers sent me a prototype board that alleviated this problem. It also incorporated a battery clip in a single, neat package.
The photos you see above (and in the heading) are the Cricket 2 and the Battery Logic Board. The Cricket itself remains just a little larger than an ESP8266 01.
For nearly six months, every hour, this setup has been feeding my room temperature to a graph running on Node Red on a Raspberry Pi - and I'm delighted with its performance. It's small, reliable and neat, and does exactly what it's supposed to do with very little effort. Through the board's internal firmware, it only connects to WiFi if it detects a change in temperature from the last reading. The fact that I've only changed the AAA battery once in that time is testament to the Cricket's superior power management. (I have a BME280 sensor in another room, so don't be confused by the graph. Of course, the BME is powered by a 5v USB. It wouldn't last more than 2-3 days on a battery).
I was so excited about the prototype battery board, I asked the developers when they were releasing it. They told me they won't be producing it - but they've placed it on Github with all required files so that users can make their own.
Personally, I had problems using the Github files, so I commissioned a guy to do it for me. On my version, instead of a clip for a single AAA, I used a terminal to connect two AAs. By so doing, I'd increase the battery life - maybe even by years.
Making a Mailbox Notifier
So now that I have the Cricket Version 2 and the accompanying battery board, it simply couldn't be easier to make a mailbox notifier. Attach a reed switch to the wakeup port, plug it in, and you have a mailbox notifier, or a window/door alert within seconds. You can forget about changing the battery for a long, long time.
This is the Cricket attached to the battery board sitting on a 3d-printed AA battery housing.
Getting an alert with the battery needs changing
One of the firmware's in-built mqtt parameters is the battery level - so with a tiny bit of Node Red wizardry, it's easy to get an alert when the battery needs changing. As you can see from the table below, several other parameters are also available - including a DS18B20 which was just added recently.
It's easy to create a battery alert.
Custom battery boards available
I have a few extra battery boards so if anyone wants one (or more), I can send it to you at cost + shipping. The board has components in place. All that's needed are two AAs, a switch, and four blobs of solder. (BTW, there's no step-down circuitry, so your batteries can't exceed 3.5v - the maximum the Cricket can handle).
Ease of Use
When I first heard about the Cricket I was as skeptical as everyone else. I didn't really understand who would want it. But it's now a year later and I've come to love its simplicity. Yes, I know it's possible to rig up an ESP8266 01 to send data when a switch is triggered. I know about deepsleep and other techniques for power conservation. However, all of them require a certain knowledge and skill. The Cricket, on the other hand, is ready to use in five minutes, with no programming or electronics experience at all. Now that it can be re-flashed with no exposure to the outside world, it's one step further to becoming my board of choice. It remains a little pricey, but it's still way cheaper than many of the commercial IoT devices it can easily replace.
I wrote this before I used a Cricket to create my Remote On/Off switch described in my last post. The switch has been sitting next to my bed for about two months. It's a cute little box with a pushbutton on the top.
I'm adding it to this post because something occurred to me when Significant Other turned off the reading light a couple of nights ago. You see, unlike all the other battery-powered ESP stuff I have in my house, I know that this switch works. It works every push, and it will continue to work for months, maybe even years, without any intervention from me. I don't need to worry about some technical failure - or depleted battery. It's just reliable - probably the most reliable piece of IoT in the house. For me, that's why I love the board. It just does what it's supposed to do, every single time.