Rummys Blog An world of endless Monday

Friday, 30 November, 2018

An IoT Mousetrap Part 3 – wake-stub polling

Filed under: ESP,ESP32 — Andrew.Rowbottom @ 1:00 pm

The current investigation state of my IoT Mousetraps, iteration #3.


My mousetraps are currently

  • running “directly” off 600mAh batteries
  • using a “replaced” Voltage Regulator that draws ~70µA
  • sensing the status of the actual trap using an input pin in “pull-up” mode (drawing ~70µA)
  • waking fully up at a configurable interval to send quite a lot of status and debug information via espNow to an esp8266 connected to a RaspberryPi and Node-Red
  • fully on for approx 300ms (excluding time-to-wake-up and re-enter deep-sleep)
  • lasting only about 3 months between recharges

Ignoring the 70µA drawn by the Voltage Regulator for the moment, about half of the current drawn during deep-sleep is from using the inbuilt pull-up capabilities of the GPIO used for sensing state.

Now, I could use external pull-up resistors, and that is probably the most sensible approach! But for the hell of it I am investigating “polling”.

Using a WakupStub

There are quite a few things required to use a wakeup stub, for reference see deep-sleep-stub.rst, I’m sure I’ve not covered all of the requirements here, but some of the major points are

  • If you call it void RTC_IRAM_ATTR esp_wake_deep_sleep(void) then you don’t need to explicitly set it as the wakeup stub
  • It needs to be marked as RTC_IRAM_ATTR (or in a specially named source file) so the code is stored in the RTC RAM.
  • The RTC fast (and probably slow) RAM need to be kept enabled when entering deep sleep
    esp_sleep_pd_config(ESP_PD_DOMAIN_RTC_FAST_MEM, ESP_PD_OPTION_ON)
    esp_sleep_pd_config(ESP_PD_DOMAIN_RTC_SLOW_MEM, ESP_PD_OPTION_ON)
  • Everything you want to call needs to be either in ROM, or in RTC_IRAM, and that happens to be a *LOT*, so you’ll have to find the equivalent code and copy it into your project (renamed and marked RTC_IRAM_ATTR)
  • You can re-enter deep sleep, but the calculation is moderately complex, though I have simplified this by computing a “per-second” scale factor in my “setup()” and storing it for easy use in the wakeup stub.
  • If you want to wake up fully you must call esp_default_wake_deep_sleep()
  • If you want to go back into deep sleep you do not need to call esp_default_wake_deep_sleep()

Current Draw and Timings

Playing around with excessive delays in the wake-stub so that I can use a simple multimeter to measure milli-amps gives me a current draw of a little over 12mA (with the built-in LED off).

Comparing that with a constant 70µA means that my polling code can be “awake” in the wakeup stub for approx 0.07/12 of the time .. i.e. 0.5% of the time .. or roughly 5ms every second at a 1 second poll rate, more at a slower poll rate.

Using my oscilloscope initially I had some very disturbing timings, my wake stub was taking 47ms!

The output was:

ets Jun 8 2016 00:22:57

set from pre-set=0x70A72
calling my_rtc_sleep_set_wakeup_time with 3053670 + 461426 Wake count 2
with GPIO22 LOW GPIO15 is 0
with GPIO22 HIGH GPIO15 is 1
about to call ledStateIRAM with 1

gpio15 and 22 are connected
about to sleep from wakeup!
sleeping, awake between 3053650 and 3056738 rtc ticks, expected to wake at 3515096
sleeping, awake between 18882309 and 18901404 micros, expected to wake at 21735670

I noticed that it was going back into deep-sleep immediately after the serial output was complete, so I massively reduced the output and had a wake time of about 10ms. Still Too Large!

ets Jun 8 2016 00:22:57

Wake count 2

Then I completely removed the code that was flushing the buffer and I now have 0.5ms (Different scale!)


ets J

This is approx 0.5 ms! Tidily under the 5ms computed budget, and this could be improved dramatically by polling at an even slower rate.


For sanity checking rather than just monitoring the serial and state of an output pin I also tagged the current through a 1 Ohm resistor. This gave a 1.5ms “on time” though admittedly a fair bit of that seems to be die down.

I have a very noisy scope, but I think you can see that the current starts to be drawn a reasonable time before the serial output starts.

I’ve measured from the increase to the end of the current draw, you can see the exponential decay on the serial line which would match the deep sleep starting I think.

The Sensible Solution!

Obviously the sensible (easy) solution would be to do a full wake-up every 1 hour, and accept that the trapped mouse isn’t going anywhere. That would have been sensible!

Monday, 8 October, 2018

An IoT Mousetrap Part 2

Filed under: ESP,ESP32,World of Warcraft — Andrew.Rowbottom @ 11:35 am

The Mousetrap code has gone through several iterations, this iteration Number 2  has changed the code quite a lot..

The aim of this iteration was to significantly reduce the “ON” time from 3seconds to reduce the consumed watts in this phase.


I have switched from connecting to WiFi (about 3 seconds on time!) to using espNow sending to a “receiver” permanently connected to my Raspberry Pi, this is to reduce the “On” time during the regular status updated. I’ll try to post some information about using espNow in another post.


The “On” time is now reported as approx 300ms (mainly due to the huge number of status messages I send), well down from the roughly 3 seconds connecting to WiFi and sending using MQTT/HTTPS takes.

Unfortunately this has not made a huge difference to the overall battery life which is still running at around 3 months for a fully charged “600mAh” LiFePo4.

Further investigation is showing 2 major current draws:

  1. the LDO at approx 70µA
  2. the pullup/down current approx 70µA

Iteration #3 will look at how to reduce this .. until I un-solder the LDO Voltage-Regulator I’m limited to removing the pull-up/pull-down current. There are a few options:

  1. switch from using the internal pullup/down to an external resistor
  2. use the wakestub and poll the switch/mousetrap state regularly but not too frequently
  3. use the ULP and poll using that.

An IoT Mousetrap

Filed under: ESP,ESP32 — Andrew.Rowbottom @ 11:23 am
NOTE: this has been sat waiting to post for many months. I am posting it because I have updates incoming.


IoT! Who needs a mousetrap on the internet! Turns out I do.

We occasionally have some mice visiting our cupboards, so we tucked a mousetrap in a dark corner of a cupboard.

But the old adage “out of sight out of mind” really applies to us! And, after checking daily for a week only to find nothing we got lazy and started checking only when we remembered. Predictably one day we found a particularly smelly little corpse! Finally a potential use for those ESP boards I’ve got lying around!

Thus is born yet another IoT mousetrap!


  • Mousetrap
  • ESPea32
  • A replacement LDO voltage regulator
  • A bit of Soldering skill to replace the LDO
  • Edge Connector
  • Wire
  • Tin Foil salvaged from a tea-light
  • Battery Box
  • Internet

Modding the trap.

My mouse trap comes in three parts a white top and a base and a red “tongue” which is the lever that triggers the top part.

When its armed the top is tilted “backwards” and makes contact with the lever.

To wire it up for IoT all I needed to do was to put a contact on the top part and and one on the tongue, and then detect when the two are (or aren’t) in contact.

For the contacts I have used the tin-foil cup from a tea light, originally I used cooking foil, but it proved too thin, the foil cup on a tea-light is thick enough to hold its shape and still easy to trim with scissors.

The top contact is cut to fit neatly onto the top section. I left a couple of tabs of foil to fold over and tuck under the metal spring. I shove a piece of wire under the spring to complete the connection between the ESP and the top contact.

The bottom contact is nothing like as tidy, it’s a strip of foil, soldered at one end, and placed lightly over the tongue so it makes contact with the upper plate when the trap is armed. A bit of tape at one end stops it moving around too much without interfering with the action.


Using an ESP32ea (any ESP32 should do) I wire one plate to GND, and the other one to a GPIO, it doesn’t matter which way around, the voltages are low and it’s only “contact” that is important.

The GPIO is set to “INPUT_PULLUP”, so when the two plates are in contact it is pulled “LOW”, and when separated it goes “HIGH”.

The ESP is put into Deep Sleep (to conserve battery), set to wakeup (esp_sleep_enable_ext0_wakeup) when the GPIO goes into the opposite of what it currently is (ESP32 feature) It will wake up when the trap is closed, or when I open it ready for the next mouse.

When the ESP wakes up (either GPIO state change, or Timer), it checks the wakeup cause, and if the GPIO state is different from what it was when it went to sleep, it sends a whole bunch of messages.

I have a timer wakeup so I can sample the battery and send a “battery needs charging” message.


Modding the ESPea32 for low deep-sleep current

I only have a couple of esp32 boards, several cheap ESPea32’s and a more expensive FireBeetle-32. The firebeetle, although it has much better deep sleep current draw as supplied is slightly too long to fit in an AA battery box, so I’m using an ESPes32.

The ESPea32, though nice, is not really good for running off a battery in deep sleep.

The CP2104 seems to be correctly wired so that it is only powered when the USB is connected, something I checked on the schematic before I bought it.

But the voltage regulator is a bog standard AMS1117 with a quiescent current draw in the order of several mA, far too much for a deep-sleep battery powered device. Fortunately it’s a nice large (for SMD) SOT-233 package than can be reasonably easily un-soldered and replaced with a much more efficient device. Once that is done my ESPea32 now draws under 0.2mA in deep sleep, a 100 times improvement, though a “naked” esp32 can draw even less. NOTE: the LDO draws approx 70­µA

Headers / Terminals

I didn’t use standard headers for this project, instead I’ve used 2.54mm screw terminal blocks. This is the first project I’ve done this way, and so far I’m liking it! The wires don’t come loose as easily, the overall height (8.5mm, 11.5mm including pins) remains small enough to fit in the battery box. I can squeeze 2 wires into one terminal (for example GND to battery + a wire to the mousetrap), reducing the component count.

I did think about using the supplied PCB headers and dupont jumper wires, but the overall height is way too large to fit in the box. A standard PCB header is about 11mm overall, including through hole pins. The jumper wire pins add an extra 14mm onto that . And then the wire has to be bent. Lets call the overall height 25mm. An AA battery is only 14mm in diameter.

Wiring up the Mousetrap

My mousetrap is not your traditional wire one, which complicates things a little. Its a plastic module, so it needs some sort of conductive layer applying. I originally used cooking foil, but its thin, tears easy, doesn’t solder well and looks really horrible. The current version uses tin-foil taken from a “tea-light” which is thick enough to retain it’s shape with minimal gluing.

One piece is folded around the top, with a “tag” slid under the spring. Also slid under the spring is one of the “detector” wires.

Another piece is a lightly bent strip placed over the lever, and stuck to the bottom of the trap, a “detector” wire is soldered onto this strip.

Hardware choices


I have a stock of LiFePo4 batteries lying around, they’re not your usual LiIon batteries, they have a lower voltage, between 3.6 and 2.8v with a long flat stable period at 3.2v. A perfect voltage range for powering ESP devices directly without needing a voltage regulator. They’re less prone to catching fire, though I doubt they’re 100% safe in that regards – certainly you can short circuit them, and 10A even at 3.2v can cause a fire in thin wires.

In theory this means I should be able to remove the Voltage Regulator from the circuit, and if I had a supply of “naked” ESP32, that’s the path I’d have gone down.


I like these boards, they’re not ideal for this kind of project by a long shot, but they’re not bad. I managed to snarf some cheaply, and they fit tidily into my switched 4x AA battery box. They also seem to have a “correct” implementation of the USB/UART which reduces battery drain. Unfortunately they use the horrible LMS1117 in a comparatively large SOT-233 that has to be replaced or unsoldered if you want low deep sleep battery life. Perfectly you would unsolder it completely but then programming via Arduino would be a pain, unless you add a jumper.

My ideal board would look pretty much like the espea32 have a disableable/bypassable Voltage Regulator to remove quiescent current drain when powered by a LiFePo4. And had a Gnd pin immediately alongside the 3v3 connector .. perhaps a layout like 5v,GND,3v3 (or a second GND). And had an ADC pin connected to a voltage divider (and also 3v3 via a breakable PCB wire)… yes I know that would lose an ADC channel, but you’d gain a battery meter!

I’m actually a bit 50/50 about a LIPO connector/Charger, they’re extra cost, and you have to check carefully to see if they’ll fit in a cheapo project box.. 4xAA switched boxes are dirt cheap 🙂 !


Setting up the hardware

Break the dividers in the battery box so there’s room for the board and 1 battery.
Solder in the 3 screw connector so it covers 5v, Gnd, and a GPIO. I’d rather have used 3v3 direct, but it’s not besides the GND connector. Screw in the battery connectors, and the 2 detector wires.
Job done.. no extra components required


This isn’t a traditional “looping” arduino program, it does all of its work in setup, and goes to Deep Sleep before it enters the loop.

It will
Store the boot count in RTC memory, not strictly needed, but “tidy”.
Store the last state of the GPIO in RTC Memory, so it can tell if something has changed between wake-ups.
Store whether it successfully sent the notifications (in case there’s a WiFi or internet connectivity issue) [Distributed Computing Fallacy: The network is reliable]
Sample the battery voltage, so I can get low battery alerts.

Set the ADC to input (it’s input only anyway)
Set the GPIO to INPUT_PULLUP so it goes high unless it’s being pulled to ground by the mousetrap wiring.
Read the wakeup Cause
Read the GPIO state
Read the ADC
Set the deep sleep trigger to wake if the GPIO goes to the opposite of its current state.
Set the deep sleep to wakeup in 30 minutes in case the GPIO doesn’t trigger or it fails to send.

Decide if a status message should be sent, this will be sent if
it’s first boot (PREVIOUS GPIO level is -1).
the GPIO level is different from what it was last time it was checked.
the message didn’t get sent successfully last time.

Store the GPIO State for the next wakeup.


Current consumption in deep sleep is approx 0.12mA, NOTE: I *did* replace the abhorrent AMS1117 with a much more efficient LDO. I think that having WiFi connectivity enabled at all raises the deep sleep current by about 0.04mA, but I guess that’s something I’ll have to investigate further. Forgetting to turn off WiFi before going into deep-sleep [WiFi.disconnect(true /*means wifiOff*/)] changes the deep sleep current by a LOT more I measured 1.33mA!

Wednesday, 21 February, 2018

Tile Sport and CE Mark

Filed under: World of Warcraft — Andrew.Rowbottom @ 10:42 am

Is it me or is the “Tile Sport” not actually European CE marked?

The Tile mark looks like (forgive the potato quality):

You decide!

Friday, 8 September, 2017

Kerv Contactless Payment Ring Review

Filed under: General — Andrew.Rowbottom @ 1:20 pm

Edit 2018-12-29

Well, that’s taken the shine off things a bit! It looks like my Kerv Ring has died after less than 18 months!

Edit 2017-12-08:

This post on my Kerv ring has attracted a few comments, some of them not so great!

The most worrying ones are the ones from the original KickStarter backers, it seems that a fair number have not received their rings and have great difficulties getting acceptable responses to their inquiries. Read the comments and you’ll have to decide for yourself if this business should receive your money – I’ve already paid and it would be cutting my nose off to spite my face to stop using it!

Ring in the changes!

A while ago I bought a kerv ring, which is a ring you wear that lets you (usually) make a contactless payment without needing to pull out any cards/phones/watches. I thought I’d post some of my experience with it. To see what it looks like visit the site, it’s glossy!


The ring costs £100 which is a fair bit, though it does occasionally go on sale for £80. Its worth noting that that cost is not strictly a one-off – it’s going to expire in 4 years according to the FAQ. I think of it as £25 a year / £2 a month, which doesn’t hurt as much.


Frankly this wasn’t a great experience, I ordered mine at the end of June and it took nearly a month to arrive, which to be fair was pretty much as long as they said it would take. It would have been nice if they’d said 4 weeks and then delivered in 2 weeks. After 3 weeks I did change my “colour” choice to speed things up a bit too.


I have to say, the kerv team were very responsive to my emails, getting back to me within a day.

Using it

When it works, and it does work a lot of the time, it’s great.

Occasionally I have to do the “fist bump” twice, and sadly not quite *every* payment terminal accepts it. There’s a terminal in my local Maplin’s that doesn’t like it, so you won’t leaving your wallet at home – not that every shop accepts contactless anyway.

It is a pre-pay system, so you have to make sure you top-up regularly, or you can enable the auto-topup system. Which believe me after you’ve suffered the embarassment of declined payments you’ll seriously think about.

Oh, and you get a “virtual card” if you need yet another card!

What’s good

  • Its always with me
  • Decentish range of colours
  • Easy to use and keep topped up.
  • It’s tough, I’m hard on things I wear, very hard. And it’s not showing signs of scratching.
  • It’s comfortable, it’s not “square”, it has a rounded inner profile that works very well.

What’s not so good

Because I do gripe!

  • It doesn’t always work first time, and for specific terminals, not at all. Probably not the ring’s fault.
  • Longish delivery time.
  • The Statements only show when and how much you spent.
  • The ring sizes probably don’t go low enough – only as low as a UK M. I bought a size N for my little finger (I have small hands), and that is loose on all of my girlfriends fingers.


I like my ring, it’s convenient and has a certain cool factor. I feel a little smug every time I see someone fiddling with their phone to pay for something.

Would I buy another one in 4 years, yes I would!

Could I live without it? Yes, it’s not a critical part of my life, I usually have a wallet on me.

Sunday, 18 June, 2017

ESP8266 and Artik Cloud, Part 2 – Integration

Filed under: ESP,ESP8266 — Andrew.Rowbottom @ 5:27 pm


This entry is long, and a bit complex. I wrote it in quite a hurry (same goes for the code), so it’s as good as it should be!

So what does Artik cloud do?

I don’t really know in any significant detail, because I’ve been focusing entirely and only on getting GHome integration working, without that it’s useless to me, so I’ve not done any exploring. I do know it can

  • record data (for 30 days)
  • send actions – aka commands
  • do simple IF statements, and as a result send actions, yup multiple actions as a result
  • Let you define and control your own “custom devices”

Custom Devices

Custom devices is where I’m interested,  ARTIK Cloud lets you create custom devices, you get to define the data it makes available and the commands it can receive. Support is available for the devices to :

  • post data using https REST (fairly simple to do)
  • send and receive commands via secure websockets/wss (simple to do on an ESP)
  • Supports secure mqt  (mqtts) (untried)
  • Supports secure CoaP untried

I can tell you that my implementation was using secure websockets (wss) – for me this has an advantage that the connection is initiated from INSIDE my house (no inbound holes in my firewall), and it can still receive commands.


Defining a device in ARTIK Cloud – Step by step

Creating a device is fairly simple, though it only defines what a device can do, we’ll actually create an instance of it once this is done.

First off: login to the ARTIK Cloud developer pages

Select “Device Types” in the menu to get to the device types pages

Click on + New Device Type

give it a “name”, don’t be too specific, e.g. ESP8266-Light
give it a unique name such as your domain name and some extra bits

and “Create Device Type”.

So now you have a device type, and it will appear in the list of device types on the left.

So far it’s kinda empty, and needs a Manifest which lets you define the data it can send (e.g. state, level, batteryLevel and so on), and the actions you can perform on it e.g. setLevel, setOn, setOff – these 3 are significant because according to this is what’s needed to make it appear in Google Home Control. You can add plenty more, but these three are what I have added.

Click + New Manifest to enter the Manifest editor, since the stuff we’re adding is pretty basic, we can use the “standard” fields. Don’t worry you can update the manifest later to add more stuff.

So, add 2 standard fields, “state” and “level”

Move onto the actions, we want 3 – setOn, setOff, setLevel

And Activate the Manifest


So now we’ve defined data about our device and defined what it can do in our manifest, but the device itself doesn’t actually exist yet. We do that in a different part of Artik Cloud

Adding a Device to Artik Cloud..

This is done in a different section of Artik Cloud, probably because in a real world IoT development you’d be creating lots of devices owned by lots of different users, but only a limited number of “types”. For us there’s only the one user, ourselves, and we’re defining the device and implementing it. So…

Login to

Select Devices..

My personal devices screen is full of rubbish, but you’ll need to click 


Pick the one you created in the previous section.. there’s a lot, so start typing the name “ESP8266-Light” and select it when you can.

Then press “Connect Device” .. this device will now appear in your devices list..

At this point you can simulate it and send actions to it using the “…” and “lightning bolt”, hardly worth it without any hardware attached, but well, there it is.

We’re pretty much done here for the moment, Now we need to hop over to our GHome control on our Android Device

Connecting to Google Home

  • On your Android open Assistant / Google Home
  • use the three dot menu on your Google Home device, and select Settings
  • Press “Home control”
  • Press the circled Plus
  • Scroll down and Press  Samsung ARTIK Cloud
  • Sign in with Google, this bit can be a bit flakey , but persist!
  • Back on the Add Devices Screen Samsung ARTIK Cloud should be in the “Linked Services” section
  • And in the Devices section you should see “ESP8266-Light”, you will probably want to give it a nickname, I called mine “MCU Light” because saying “ESP8266-Light” is both a pain, and GHome wants to call it “eight thousand two-hundred and sixty-six spanish pesetas Light” which is a serious mouthfull!

NOTE: adding new devices in artik cloud doesn’t seem to refresh the devices seen in Android, I usually have to “unlink” and “link” again

OK, so now we’ve

  • created the metadata for a device in ARTIK Cloud
  • added one of them to our personal list of devices
  • Integrated ARTIK Cloud into Google Home
  • Seen the device appear on our phone and given it a more sensible name

Perhaps we can do something with it even now, lets see…

Try saying “OK BOO BOO, turn on the MCU Light”, you might have to try a couple of times, my nicknames always seem to take two attempts to register after I’ve just renamed.

GHome believes it exists, but of course there’s nothing on the other end of the “Wire” .. for that we need a “real” ESP!

Programming the ESP

I’ve put a first draft of the code for my ESP up at ..

It is very flakey code, truly a first draft / Mininal Viable Product, it doesn’t even check the fingerprint for the wss:// connection!

To get it running

You’ll need to supply your WiFi SID/password at the top of the file: wifi.cpp,
AND comment out #include “nogit_wifi.h”!

You need a device type and token to supply to ESP8266-ArtikIntegration.ino

To get this ..

  • go to
  • click on the text “ESP8266-Light”
  • COPY the long number under “DEVICE ID” and replace “YOUR_DEVICE_ID” in the #define
  • Click on “Generate Device Token … ” and replace “YOUR_DEVICE_TOKEN” with this string in the #define
  • delete the line #include “nogit_artik.h

Compile, upload, watch the serial output.. it should

  • connect to your wifi
    • connected with XXXX, channel YY
      dhcp client start...
      WiFi Connected
      WiFi Connected
      please start sntp first !
  • connect to artik cloud
    • WSc] Connected to url: /v1.1/websocket?ack=true
      [WSc] get text: {"data":{"code":"200","message":"OK","cid":"1234567890"}}
      Type is empty
       "data": {
       "code": "200",
       "message": "OK",
       "cid": "1234567890"
  • receive the odd “ping” eveey 30 seconds
    • WSc] get text: {"type":"ping", "ts":1497806528357}
      Ping Received
       "type": "ping",
       "ts": 1497806528357


Now the LED on your Wemo / ESP should be be controllable by voice!

A quick demo of the limited control is on youtube at


Thursday, 15 June, 2017

ESP8266 and Artik Cloud

Filed under: ESP,ESP8266 — Andrew.Rowbottom @ 11:57 am

The Quest to Control an ESP8266 using Google Home

I’ve been looking into how to control an ESP8266 from google home in the UK.

I have several “requirements”.

  •  The first is that it works without needing a “third party” app, primarily because these aren’t available in the UK, but also I’d like to be able to say “OK Boo Boo, turn on the ESP thingy”.
  • The second is to reduce the number of extra boxes I have to use, more boxes == more things to fail.

It looks like this level of integration is available through “services” more specifically the “Home Control” stuff.

My first approach was to put some kind of emulation in place.. only 3 seem to be readily available:

  • IFTTT integration
  • Philips Hue Hub Emulation
  • Wemo emulation


This is just built in, not part of Home Control, is definitely a possibility, but, well, I’ve had issues with it in the (long ago) past where it was silly slow, like minutes! And anyway, how can you call yourself a hacker if you don’t write any code?

Philips Hue Hub Emulation

If you don’t have a Philips Hue Hub, then this is probaby the route to go down, hub emulation is fairly mature and probably works with the Google Home.
BUT, I already have a genuine Philips Hue Hub, and I don’t see a way to add a second to Google Home. It would also require a separate *ix device to do the emulation, and then I’d still ahve to hook it up to the ESP8266.

Wemo Emulation

Again there’s a Wemo emulator, and apparently it works with Amazon Echo, but I think it doesn’t work with Google Home.


I continued scanning through the available Home Control Integrations, and one particularly caught my eye … ARTIK Cloud, there may well be others, but the sign-in page for the Artik Cloud had hints on it that suggested it might be what I was looking for.

This is the route I’ve been going down.

My First Steps with Artik Cloud

Well, unsurprisingly you need to create an account (its been a while, I think you have to create two accounts, a normal one, and a developer one), because I’m using a Google Home, I just used the “sign in with Google” buttons.

I created an account, and a developer account, and heaven knows, I may have created other accounts!

In the ARTIK Cloud “dashboard” I added a device “Philips Hue”, authorised it etc.. and found that I got a whole buncha lights shown in the dashboard.

Then I enabled Artik Cloud in the Google Home App  / Google Assistant, lo and behold! All of the new lights became available in the Google Home! Unsurprisingly every single one was duplicate for ones that it already knew about, though fortunately with slightly different names.

I added the new ones into a new room, I called it ARTIK just so I could keep them separate, and what do you know? I could actually control them!

“Ok Boo Boo, turn off the ARTIK lights”

Onwards and Upwards

My next trick is to find out what ARTIK can actually do, and how to get my ESP8266 to link in.

Teaser: I’m making good progress so far!

Sunday, 18 September, 2016

wharncliffe test

Filed under: World of Warcraft — Andrew.Rowbottom @ 6:50 pm

Autoselect Routes to display : simply use bounding boxes

Alongside raw route information, stash expected update frequency? So that long straight stretches where the rider isn’t expected to go wrong dont update as often, but as they approach corners the refresh rate goes up.

Segment the compass/bearing rotation so that there aren’t as many refreshes (depends on how strongly google redraw the map)
Allow the blue dot to move up the page a way before bringing it back to “below-center” .. again google may already do this

Tested code with a 15 second recording interval.
A couple of bug revealed themselves.
One where the code seemed to resurrect itself and then fell over because it had cleaned itself up.
One where the map stopped updating after I had accidentally “dismissed” the program while it was recording. Hopefully this will be reproducable.
One where it took longer than 15 seconds to get a good lock, rx and consequently the next 15 seconds boundary was fairly far away,
though I feel that this may not actually be wrong.

Battery consumption was
Before run: 6% in approx 1h20m = 4% per hour
During Recording: 25% in 2h 10m = 11.5% per hour
While Running: 35% in 3h 5m = 11.4% per hour

so @15 second intervals (actually a little less) = 7.5% per hour
pretty decent .. would give about 7 hours recording on 80% battery .. and I think it could be improved by deleting some background apps from my watch..

Friday, 16 September, 2016

Still testing

Filed under: WearRoutes — Andrew.Rowbottom @ 11:40 am

Things are slowly getting better.
GPS Tracking is nor working reasonably well at 30 second intervals, it generally takes about 15 seconds to get a decent quality fix, though I have to throw away 2 or three dodgy fixes before then.
I’m still getting the odd crash when I try to use it in reality .. most seem to be related to what happens if the app gets pushed off-screen by a notification or whatever… still improving here too.

To be honest things are beginning to approach the point where I might consider it usable, though there’s still some iffyness and missing features.
The current bugbears are:
The map isn’t always showing with direction of travel upwards – I think this is something to do with getting “bearing” direct from the GPS
It is recording elevations of ZERO to the GPS log .. I should trim these.
I’ve seen cases where the blue-blob in the map doesn’t seem to have a “history-path aka breadcrumb” joining it, which is weird.

Wednesday, 31 August, 2016

More testing

Filed under: WearRoutes — Andrew.Rowbottom @ 7:18 am

I have tried to fix a couple of the issues.

Duplicate Locations

The duplicate locations was due to very very poor management of the “android lifecycle” of my application meaning that the second time it was started there was a LOT of old code still running from the last time, in effect I ended up with 2 location listeners and so on.

This has been partially fixed, though there is still a fair bit more to do to get it perfect

Deep Sleep

Apparently deep sleep doesn’t just affect “running” code, it also affects code that wants to wake up at a certain time.
Resolved by learning yet another android API!
The code now seems to reliably wake up every 30 seconds to take a sample.


The “Fused Location API” ass recommended by google is not nice, it doesn’t tell me the “true source” of the data, so I have to deduce it through other means. What I’ve seen so far is..

  • Locations with really large accuracy errors seem to be cell tower locations, and don’t come with elevation
  • There are quite a lot of locations with an accuracy from 24m upwards .. these *seem* to be WiFi locations, when plotted on a map they are often off track and near houses. Potentially they have some value (I could for example snap the location to the nearest track), but would require coding to get usable.
  • In order of “goodness” for points with moderate accuracy (>24m) it seems to be no elevation = poor, “velocity” look to be good, as do points with “bearings”

The sequence of locations seems to be ..
wakeup, ask for location updates, get a rough location in about 5 seconds, get a better (32m) location within about 10 seconds, get a pretty good (10m) location about 15 seconds after wakeup.

So .. my options appear to be:
I can wait for better accuracy this would be a simple code change
I can force the GPS to be running full time on the phone so that it doesn’t have to wait ~15sec to get a good fix (though this might be reduced if I got a good fix in the previous request)
I can get the phone to wakeup before the watch, and start to pre-emptively get a good fix so that a good fix is already there for the watch when it wakes up — I could probably even insist on a GPS fix .. in effect transferring the battery drain from the watch to the phone.

I’ll work on this albeit at my usual slow pace.

Older Posts »

Powered by WordPress