See update at the end – and warning – this is a long story: 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 one…
The biggy here is that the IOT Cricket, I have it on good authority from 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 microAmp. You can probably imagine how long the battery lasts under those conditions.
The module comes with pre-installed software and can be OTA’d from a smartphone or APP.
That’s the claim – and now I have my hands on three of these devices to see what this is all about.
ThingsOnEdge approached me – nothing new there but maybe this is something out of the ordinary or maybe it is just because the company is based in the UK – I don’t know yet but I’m going to have a look. I have no axe to grind other than having these product samples – so I suggest giving this a second glance.
The product is still in the validation stage ( so that’s NEW, then), the company has been around sinced 2018 and they are a “small start-up”.
In a nutshell, they are going to provide two options: 1) Local 2) Cloud
Local: You won’t need Cloud at all to configure Crickets, the configuration will 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
All sounds good to me. 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 – if this pans out, I want MORE. MQTT back to Node-Red will float my boat. MQTT rsponses come back in Node-Red no problem
AND NOW – after a short break, fighting delivery and mobile phone companies – I’ve had a play. I’m running one of these boards on a single battery and simply checking temperature. I’ve made some suggestions for the future – more on that later – taking the weekend off.
December 1, 2020 Update – Cricket Rev 1.0
There’s a new module now (I have samples to test – two work – one got bashed on the way here) and new documentation to go with it – here’s a photo. As you can see the units look slightly different with a new metal case .. remote OR local configuration – as before, runs on as little as a single AAA battery but with a catch – you need a large capacitor to handle the initial power burst of the ESP8266 or it simply will NOT run reliably.
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 – so do any setup via the local http: interface or remotely via the cloud. See below. Clearly this device spends most of it’s time asleep in super low power mode and can’t respond to MQTT. 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 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"
December 2, 2020 Update – packaging issues
I am 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 £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 today – 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 TA3104 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).
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.
December 3, 2020 Update – Clarity of Thought?
This seems 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 refresh time in the Cricket to 5 minutes – that means the Cricket will turn itself on every 5 minutes (hence saving battery power) and send to the service (which we can avoid for privacy) and to my own local RPi-based MQTT broker (or theirs), 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.
When I’m done I plan to reduce the updates (and hence WiFi powerups) to every 15 minutes and possibly reduce the voltage measuring A/D from 8 bits to 6 bits or even 5 bits – I need to test but the promise is that 1 AAA (+ 680uF capacitor) or 2 AAA batteries will keep this running for several months – you can’t get that out of Tasmota, ESP-GO, or Espurna. Assuming your WiFi will reach to the far end of your garden (or whatever) this could be useful. I just hope they do more with the inputs – I2c and some libraries for various sensors might be good.
All good stuff – 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.
December 7, 2020 Update – Definitely Sorted
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’m leaving the unit with fixed period reporting – and the incoming MQTT is being logged to Grafana and all is well. The image below shows (not very well) temperature and battery readings since mid-after noon on Dec 4, 2020. The battery has not budged from around 2.75v at all in the last few days.
I may yet go back to a single battery, this time with a tiny 680uF 3v3 tantalum capacitor but for now I’m happy to leave the Cricket running to see what happens with the current two batteries as my RPi and Grafana keep an eye on things (the RPi still works after applying last week’s new OS update 🙂 ).
December 21 – Power Rethink
One of my Crickets has been sending battery and temperature readings every 5 minutes since my last update on Dec 7, using 2 (not new) AAA batteries (as I had no tantalum caps handy) until, I just discovered, 2 days ago that it had all stopped. After some testing this morning I decided to temporarily abandon the tiny battery approach, though I’m assured by the design company that a single AAA battery will work when propped up by a tantalum capacitor.
For now however, given the impossibility of getting parts (including battery holders) from the UK (Covid, Christmas, Brexit – what a combination)… so, given that I have umpteen 3v6 Lithium batteries lying around, I’ve wired the Cricket to one of the Lithiums (no capacitor) as the latter even when partly discharged will have lots of peak current capacity. It is all hooked up, no settings were lost when the batteries failed, so Grafana has now resumed taking readings – based on doorbell experience, I thoroughly expect that the logging will continue for several months – though depending on results I may reduce the reporting frequency down to 15 minutes for the sake of it.
The next thing will be to see what else I can get out of these devices.