See May 25, 2021 Update at the end!
Of course we’ve all seen this form factor before – ESP8266 on a board with power and antenna, FLASH etc.. The ESP-12 is only one of many and now we have a new option – with a difference… also – this is an update of my late-2020 original blog. And the update includes a link to their new CRICKET setup page with DS18B20 support (I’ve asked them if they will look into DHT22 support soon.. See also the end of this entry.
The small IOT Cricket device, I can verify after many conversations with Sylwester Bala from thingsonedge.com, is designed to run on AAA and AA batteries – and has a deep sleep mode consuming as little as 0.5 microAmps., WAY lower than the kind of standby current most of us associate with esp8266-based devices. You can probably imagine how long the battery lasts under those conditions – but with decent batteries it is months – I can verify that.
The module comes with pre-installed software and can be OTA’d either locally or remotely as you prefer – see below…
ThingsOnEdge approached me late in 2020 – I followed up their contact partly because this is something out of the ordinary and partly because the company is based in the UK. I have no axe to grind other than having these product samples to play with – so I suggest giving this a second glance.
The company has been around sinced 2018 and they are a “small start-up”.
In a nutshell, they provide two options for operation of the IOTCricket: 1) Local 2) Cloud
Local: You don’t need Cloud at all to configure Crickets, the configuration can be done entirely locally on the Cricket module from the local network – this demand is mainly driven by hobbyists and DIYers.
Cloud: There is a Cloud option to configure Crickets remotely – this demand is mainly driven by companies and IOT solution providers
Supposedly we’re looking at 15000 “events” on 2 AAA batteries… MQTT and REST API support, status LED, RTC, temperature sensor, 3v3 out, ESP8266 running at 160Mhz… digital and analog input.. in fact, here’s a copy of their data sheet – MQTT back to local Node-Red floats my boat and MQTT responses come back in Node-Red no problem.
By April 2021 I’d had a while to play with these devices. I long ago abandoned using a single battery as, for me, there were issues with impedance (cheap batteries).
I’ve learned a lot while testing these units – my initial attempts with a single battery did not go well as you need a decent tantalum cap to handle the ESP8266 WiFi power surge. I settled on two AAA batteries for my test units. One of my first batch of three samples (which arrived here in Spain in a simple envelope) worked immediately on one AAA battery out of the box – another intermittently – the third (bashed in transit) not at all.
I’ve made recommendations for future shipping so we can ignore the third sample – now in the bin. Both of the others work fine but as I have limited capacitors to hand, I simply series’d up two AAA batteries.
You cannot MQTT to the Cricket as clearly this device spends most of it’s time asleep in super low power mode. – so do any setup via the local http: interface or remotely via the cloud. See below. However, at regular (or irregular) intervals YOU define, it CAN and does sent out MQTT to either an external MQTT broker or your own – I have MQTT brokers on my Raspberry PIs (and why not, the software is free). My (long term tested) samples are currently firing back the battery state and temperature to the Pi regularly – Sylwester at ThingsOnEdge wrote to me as follows:
"With regards to reading the temperature with the onboard sensor. I think it should provide you quite an accurate temperature value when you set the frequency no lower than 5 mins. The temp sensor is on a chip and it requires some time to dissipate heat."
"There is no way to send a MQTT message directly to Cricket. It is one way communication from Cricket to client devices only. However you can switch on/off temperature as well as other configuration parameters by using http://cota.thingsonedge.com. You can set Cricket to fetch the remote configuration with intervals and once you change settings in cota.thingsonedge.com then Cricket fetches it on an aligned wake up interval and adjusts behaviour accordingly. Please see this section how to do it: https://docs.google.com/document/u/1/d/e/2PACX-1vSLMmeT7LHo52Tu5rUoHpomhnLPz2Lr2JFKQCZevg8mKUv2M87bdbqb_7Al5pN9mxoxY2aqX-CRyLHk/pub#h.ol7i0xnxewrf"
Original packaging issues
I’ve been very pleased with the speed of response from ThingsOnEdge. Like most new companies UK and European companies they have to be careful with shipping charges. After the first lot of samples arrived here in Spain (cost them £3 post in case anyone is wondering) in a simple envelope (no padding) which as I said above, dented two and destroyed one of the units. another couple of these tiny modules arrived – again in a simple envelope, both slightly dented. I’ve commented that it might be worth considering a very thin cardboard addition to the packaging.
Meanwhile, back to the battery question
After wasting much time trying to monitor battery voltage on my digital meter – I did what any self-respecting engineering-type would do and pulled out my handy Owon 8″ 800*600 LCD, TA3104 14-bit 100Mhz battery-powered tablet scope.
See the Cricket bottom right of the image below and my 2 series AAA batteries on the left (covered in tape for lack of a suitable container at the time).
It is worth pointing out here that with the Cricket battery monitoring set to max resolution (8 bits) the formula to get actual battery voltage is:
Vbatt = (3.5/pow(2,res)) * val
Of course in this case I simply read the incoming voltage on the scope (set to 500mv/div). Even with my experience of ESP8266 devices I’d not really thought of the power up surge and WiFi surge mainly as I’ve not done much with battery powered ESP8266s before. I usually power ESP12 and similar modules with 5v USB supplies. I have had ESP8266 issues in the past with start-up using thin power leads (something I cracked ages ago but didn’t at first apply that experience to the Cricket).
So, despite the key advantage (indeed point) of Cricket being ultra low power, enabling the use of these devices in situations where a power supply simply isn’t practical, it seems you DO have to apply a little common sense in terms of short battery leads etc as the (extremely short) massive voltage drop you see in the scope shot above followed by lesser drops until the WiFi shuts down. Note also the comments from ThingsOnEdge about capacitors.
By December 2020, everything seemed to be all coming together. Using the online service (a simple web page who’s frequency of automatic updating is determined by the Cricket itself) I set the RTC update time in the Cricket to 5 minutes – that meant the Cricket would turn itself on every 5 minutes (hence saving battery power) and send data to their COTA service (which we can avoid for privacy) and to my own local RPi-based MQTT broker (or theirs) and the battery voltage (or that which is easily converted into voltage) and the temperature of the Cricket (assuming updates so infrequent (5 minutes or more) as to not unduly skew the reading).
See image below: The function block does nothing more than the simple voltage conversion I mentioned earlier. The temperature is straight out of the Cricket. That ID number can be gotten from the Cricket itself.
So, by now anyone still reading might be thinking – and the point of this is? As well as the info you see here, the Cricket can return input values…. and what’s so special about that? Nothing much EXCEPT for the low-power aspect. At first, my batteries (AAA * 2) were getting hammered as I was updating every 10 seconds.
Here’s the content of the function block in the image above:
msg.payload=Number(msg.payload)*3.5/256; return msg;
As for temperature, don’t be misled by the fractional temperature values – actual accuracy is maybe one degree C.
In the photo above, back in February I reduced the reporting rate for my main tests to every 5 minutes and by April 2021, the batteries are still looking new after 2 months of continuous operation. I’d planned to reduce the updates (and hence WiFi powerups) and reduced the voltage measuring A/D from 8 bits to 6 bits or even 5 bits – I need to test the promise that 2 AAA batteries will keep these boards running for several months or even a year or more – you can’t get that out of Tasmota, ESP-GO, or Espurna – right now I’m still using 8 bit resolution. Assuming your WiFi will reach to the far end of your garden (or whatever) these units could prove to be useful.
See image above of an original IOTCricket unit – all good stuff – but late evening, after leaving the board running all night while watching TV, I returned to find that on one battery and 1000uF 15v cap (because it was handy), the Cricket had failed after a short time, maybe an hour. The offload voltage of the battery was 1.35v. I left the cap in place and re-fitted the original 2 batteries – who’s voltages were low (2.76v combined) but should have still offered reliable operation. After connecting the batteries I pressed the Cricket button briefly to start it up, 5 flashes in a row – no MQTT reporting – nothing – 15 minutes later – nothing.
I wondered if maybe the electrolytic SMT capacitor I’d fitted was reversed – so I removed it with the battery pair in place. At 23:00 that night, the board was correctly updating every 5 minutes – by 6:30am when I got up the next morning it was down to updating maybe once an hour. I turned up the office heat which had dropped from 23c to 16c overnight – I turned on the air-conditioning which in half an hour took the room back to 22c and the Cricket seemed to be getting back to 5 minute intervals but with the odd missed interval. With several readings in a row correctly 5 minutes apart I noted the two last readings – 7:53am and 08:03am – a 10 minute gap.
THEN I realised there’s a FORCED UPDATE setting which I’d completely missed, so the Cricket was only sending updates on significant change of temperature. Now I leave the units with fixed period reporting – and the incoming MQTT gets logged to Grafana on my RPi4l. The image below shows (not very well) temperature and battery readings since mid-after noon on Dec 4, 2020. The battery did not budge from around 2.75v at all after several days.
December 21, 2020 – Power Rethink
One of my Crickets continued to send battery and temperature readings every 5 minutes since a previous update on Dec 7 2020, using 2 (not new) AAA batteries (as I had no tantalum caps handy) until I discovered that it had all simply stopped. After some testing I decided to abandon the single battery approach, though I’m assured by the design company that a single AAA battery will work when propped up by a tantalum capacitor to handle the surge of current whenever the ESP8266 WiFi starts up.
I decided to stick with 2 batteries, no capacitor. For 11 days I had a Cricket sitting on my shelf, running on a pair of new Kodak AAA batteries – no cap – nothing added, just the board and the 2 (Amazon-supplied) batteries in a holder – collecting temperature and battery data – 8-bit resolution – starting with an offload voltage of 3.29v and ending at 2.46v when the unit finally stopped dead. A future step might be to drop the resolution to say 6 bits and reporting period to 15 minutes – I expect that will lead to a considerable battery life improvement – but my Kodak batteries failed after 11 days… I spoke to the guys at ThingsOnEdge and battery choice ended up being the issue.
SO, I started with a new set of Kodak batteries on the original unit – and a second unit on test using Amazon BASICS AA batteries…. which would take a while to prove anything and I was determined to get several months out of IOTCricket. It is worth comparing AA versus AAA, it seems AA (all things being equal) has a capacity ratio of 2.4 to 1.
So on the surface of it, we’re looking at probably a similar ratio between battery life of rubbish to good batteries – my AAAs were Kodak Xtralife Alkaline and my AAs Amazon BASICS alkaline.
I left both boards running next to each other on a shelf and with a little investigation it appears I could not have made a much worse choice than the Kodak batteries. I ended up with Energizer Alkaline and Energizer Lithium and looking at the specs, both are better suited to low-current, long time application than the Kodaks. The Energiser Lithium AAA in particular appear to have a claimed 3600aH capacity.
By February 2021 I became convinced that the move to Energiser batteries made all the difference…
The reading above, indicating 2.99v and 2.84v for the Energiser Alkalines (their top of the range) were taken after 15 days of operation at the end of which they were showing 2.82v and 2.71v respectively – but check out the pair of AAA Lithiums. Starting at 3.49v they showed an amazing 3.46v – I think the latter are going to last forever! Ok, the Lithiums worked out at nearly €1.50 each at Amazon.es (Prime so no postage) – not cheap but it IS looking like these boards could be left doing duties in the garden, wirelessly. It’s not a big stretch to consider lowering the sampling rate from 5 minutes to 15 minutes and using the saved energy to add in some kind of moisture sensor or similar.
I’ve seen capacitive moisture sensors that could last for ages. I had a couple of the Bluetooth MIFLORA sensor units but honestly – the range of Bluetooth isn’t a patch on my WiFi – I don’t know about anyone elses. I already have 12v-powered ESP8266s in the garden picking up WiFi no problem but when I tried the MiFlora units I had to fit a USB Bluetooth extension from my Raspberry Pi controller right up to the window and even then the result wasn’t that reliable.
So the current state of affairs on April 11, 2021 is that three units have been running since february 5, 2021, two on Energiser Alkaline (Ultimate) and one on Energiser Lithium, with reporting periods of 5 minutes – in all cases the battery voltages look just fine at a combined well over 3v for two batteries.
I now have a practical use for a fourth unit – testing my car battery. I’ll leave the test interval at 5 minutes and will run the analog input at default 3v3 8 bits…. this will need a resistive divider to take a reading off my car battery – this will give me 24-7 battery voltage checking and logging. I want temperature, analog input and Cricket battery testing. Let’s see how this goes.
Update April 14 – 2021 – “Sadly”, my wife decided that it was time for me to go get a new car battery yesterday – so that interesting snd successful Cricket battery monitor project was a tad short lived. AS anyone any ideas for DC voltage detection of external devices that requires self-powering – and NOT car batteries 🙂 It isn’t the only now dead project thanks to the new battery – I now have redundant car quick-starters… https://tech.scargill.net/carku-64b-versus-d28a-portable-car-jump-starters/ – oh, well. Oh, here’s a compatible Adafruit light sensor for Cricket.
Meanwhile – this is interesting – see graph below: In the setup instructions – you can check the Cricket’s own battery voltage in anything up to 8-bit resolution – which is what I’ve used up to now. For an experiment I tested dropping down to 6-bit resolution to save a little power. This works exactly as you might expect. I used COTA (online updating) to change the internal battery monitoring res down to 6 bits – note how my calculated voltage (2 Lithium AA batteries in series) dropped from around 3.5v to 25% of that – so if I want to use 6 bits I just change the divisor I use to 25% of it’s current value… easy – and do I really need 256 levels of accuracy while monitoring the Cricket’s power supply? No… probably not.
Update May 25, 2021
Cricket1 – 2 Lithium AAA batteries started Feb 5, 2021 – ran out of power May 24, 2021
Cricket2 – 2 Lithium AAA batteries started Feb 5, 2021 was working on May 25 but I stopped as it will run out soon
Cricket3 – 2 Lithium AA batteries started April 12, 2021 (dividers on the A/D – other side open ended) ran out of power May 24, 2021.
Mixed feelings about this – I would have expected the AA version to last WAY longer than the other two and Cricket 3 only ran for 5 weeks – all 3 experiments using fresh Energiser Ultimate batteries. I was using 8 bit accuracy on all three units – they were at room temperature (Cricket3 was for a couple of weeks un the car under the bonnet – measuring car battery voltage – the other two constantly in a room temperature cupboard) and 5 minute interval reporting. All three reporting their battery voltage and temperature.