In my ayok widget, I have a battery. To make it last, I want the high power things to sleep as much as possible.
The Electric Imp is the largest power consumer, followed by the accelerometer, and then the battery-monitoring fuel gauge.
Happily, the Imp has a low power mode. When I say imp.sleep(5.0) to sleep for five seconds, in low power mode. Though it isn’t a very low power mode, for one thing, the WiFi remains powered up.
They offer another mode, a deeper sleep more: imp.deepsleepfor(). In deep sleep, it consumes only 6uA (which is a tiny amount if you are a cell phone and a medium-to-large amount if you are a wearable device).
Foolish me, I thought I could replace my imp.sleep calls with imp.deepsleepfor calls, do a little bit of tweaking (i.e. tell the server I’m going to sleep), and it would work.
Suddenly my system kept crashing.
I feel like that represents my often-rocky interactions with Electric Imp. I still think it is a good platform for hobbyists but it is often deeply frustrating. When I first started working with (playing with?) the Imp, I wrote an in-depth review/rant detailing its shortcomings. I opted not to post it here, instead sending it to the Imp folks in hopes my time and frustration could help them make a better product. Some of those things have gotten better in the intervening six months but many things got worse. Let’s just say I wouldn’t dream of using it in a product and if things continue to be bad, well, there are other options for home hobbyists.
Anyway, back to my crashing system.
It turns out that sleep() returns to where it was but deepsleepfor() restarts execution. This is clear in their examples (but not documented in the text). There is a work-around: if the non-volatile RAM is configured, then the system has been booted before. If it has not, then this is a cold-start so I should configure the accelerometer. (I very sincerely hope that “reprogram the code” is considered a cold-start and erases the nv space.)
As a developer, I understand why this happens this way, my annoyance is primarily because I feel like they hid it from me. No, they probably didn’t. But yes, their documentation should be better.
I did fix the crashing (and not through their nv hack, instead they have a function that can tell me what the reason for the wake up is: hardware.wakereason(). Yes, I did implement the nv hack before finding that.
Now, my Imp isn’t crashing any more. I made some tweaks, trying to get rid of the slightly alarming note in the logs:
[Status] Device disconnected; 585 bytes sent, 0 received, 585 total
I couldn’t find anything about that in their documentation. But it is worrisome so I tried to remove it. My efforts led to my card not updating and the system not running at all. The error I got was unsatisfying.
I fiddled with it for a few minutes, updated this post. My device finally came back. But I think I’ve reached maximum annoyance level for the day. (If I’m going to be this frustrated, I want to get paid for it.)
