Rummys Blog An world of endless Monday

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 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.

Monday, 22 August, 2016

wearRoutes more testing

Filed under: World of Warcraft — Andrew.Rowbottom @ 3:25 pm

I’ve been occasionally testing wearRoutes “recording” during my drive in.
I’ve found a number of problems, so far all seem to be related to the watch going into “Deep Sleep” which means that the normal way of asking for code to run in e.g. 30 seconds often means it *doesn’t*.
Even when it does run the damn watch will go back to sleep while it’s waiting for some location data and so not get the data it wants.

I’ve worked around the second problem by acquiring a partial_wake_lock – aka forcing the watch to stay awake while it’s waiting for a decent GPS reading. Fortunately it looks like this won’t kill the battery (too much) because a usable location usually arrives within 10 seconds, meaning the watch can sleep for 20 seconds out of every 30. Not perfect, but not bad either.

The first problem manifests like so…
a) I schedule in some code to run in 30 seconds (this code asks for the Location)
b) The code actually runs anything upto 5 minutes later (varying considerably though usually about 1.5 minutes)

I’m going to have to delve even further into android and use the Alarm Manager — nothing seems to be trivial, or perhaps I’ve covered all the trivial stuff 🙂

Tuesday, 9 August, 2016

wearRoutes real world test #2

Filed under: World of Warcraft — Andrew.Rowbottom @ 1:12 pm

I’ve done some tweaking to try to reduce the battery usage and ran wearRoutes on my watch for 2 hours in “record” mode, almost entirely on the “stats” screen, so no map burning, though I suspect that the stats screen actually burns more CPU than the map screen, since it has “bigger” updates.

This version differed from the previous version in may ways, but mainly the stats screen updates roughly 4 times a minute – though not actually at 15 second intervals due to this ‘n’ that.

The results were, interesting.

First the battery which drained pretty constantly at about 7..8% per hour – 14% in 2 hours (98% to 84% ), this is about half the rate at which the battery drained in the last test, so I guess I’m probably doing something right, though I was deliberately not “poking” it.

A few interesting features showed up in the location handling.

  • The “distance” travelled was at 2km before I even reached the end of the first field, and the logs show that it had briefly locked onto a cell tower with an appalling accuracy of 1.4km. So I need to discard poor accuracy points. A “feature” of these points is an elevation of exactly ZERO which is a nice little indicator.
  • The second feature is that it looks like all of the points are duplicated in the gpx log!I can’t tell if this is my code messing up or if it really truly did receive duplicate points! I’m really not sure where these are coming from, but there’s a fair chance they’re causing extra useless screen updates.
  • The “instantaneous” speed was mostly though not entirely missing from the data collected, it was present on the data with good accuracy

On the plus point I’ve separated the location gathering code from the rest of the system so it should be fairly easy to sort out.

To Do

  • filtering to exclude the “elevation = 0.000” points, a quick test produces a track with no particularly noticeable speed spikes, though there are a few “gaps” in the logs that way.
  • See if I can rework the location gathering to be “persistent” about getting quality data, this should have a side effect of getting more valid “instant-speeds”.

Tuesday, 1 October, 2013


Filed under: World of Warcraft — Andrew.Rowbottom @ 11:38 am

Long silence, skincare broken by me droping Guild Wars 2 and taking up Final Fantasy XIV A Real Reborn, drugs FFXIV for short.

I’m enjoying it, it doesn’t have quite the same “suck-in” that GW 2 had, but it is a slower paced game. Slower suits me well, I’m not as twitchy as I used to be.

There are quite a substantial number of improvements in this re-release over the previous version, for starters it’s quite playable.

Two things I miss from the old game though;

  • The dialog has been toned down, it used to be slightly risqué, but there seems to be a lot less of that, I suspect that what is still present in the game is a case of cut&paste from the previous version.
  • The cut scenes are more first person, in the previous version, as far as I played it at least, I was given the impression that I was a lowly adventurer overhearing, and being caught up in, bigger things. I felt that this quite suited a role-playing environment. Our characters aren’t special, at the low levels, even humble sheep could give us a run for our money! I find it a little immersion breaking when I’m greeted by NPC’s as if I were the saviour of the world.

I was really surprised to discover that I had to do dungeons to progress my personal story-line. A surprisingly nice idea. It’s a big jump for me to group together with other players and do group content,  being forced into it is exactly what I needed to get me over the initial reluctance. On the down side the “Duty Finder” (automatic LFG”) is not world specific, so there is little chance of making any real-friends.

Will post again soon about how broken the economy seems at the moment.

Older Posts »

Powered by WordPress