Another development update on Timechief. See video below.

Note the sound at the start of the video is produced by sound synthesis through a passive buzzer (PC Speaker). This unit has REAL imitation 80s sound effects.

I have solved many issues related to the device. Namely these, I quote from a previous post:

• Generate disk images
• Client update mechanism
• Hardware RTC support
• Client side database, currently everything comes through the web, which gives a poor UX experience on startup as we wait for first data
• Client side configuration GUI i.e. for Wi-Fi keys

Are all done, alongside many other features.

I even had time to iterate on aesthetics and added a new design and a CRT filter.

The look and feel of the device is very much 90s hacker. Kanji loading spinners, oh my! I do intend to add more themes before launch.

I was thinking one theme could be “scrap booking”. Particularly the ultra-neat super-detailed type of scrapbooking done by people like @MeganRhiannon.

I can imagine the widgets that I have created already would correspond well to a kind of virtual scrapbook. They are squares. I have squares. I have not experimented yet, however.

My other plan was silent movie era. You know those cards you get between scenes? With the art-deco squiggles?

Let’s see how things work out!

However, for now, I’m turning my attention back to the configuration app and API. Things have gotten a bit of a mess, particularly as I started with the API for this project and was not sure what I was building at first. So I want to tidy things up, integrate something like Auth0 so I can register users, and set up a shop front.

Once enough boxes are ticked off to make practical for someone to order one, then we start a beta program and get proper feedback. I am aiming for early next year.

By the way, one of the interesting things that came out of this was me learning to create custom Linux distributions. I ought to devote a blog to the topic. It’s a lot easier than you might think!

I have added a Google Calendar integration to Timechief. See video below.

Things have been a little slow for the past few months. My father died. On the positive, I have a new job at a brilliant company. Unfortunately, these events left me with little time for the business of smart clocks. However, after some adjustment, I am now back on to developing this project.

The slow period gave me some time for reflection on where I want to go with this project. I think I’ve made something cool and I do want to share it with the world, but I’m determined to package it up into something usable for the average person first.

Here is a roadmap for what I want to create before release. It looks like I have a lot to do. I’d really love some more help, or perhaps more time to do things myself, but I have to work a job to pay the bills.

Maybe I should do some networking and see if someone can give me a hand!

Deep client support

Raspberry Pi is not the ideal hardware to ship a project. However, it’s what I’m using now. And since we want to deliver this to users ASAP, it is what we will use to go into initial production.

The shape of the initial production will be an open source client smart clock, and a website that you can use to configure the smart clock.

The client will be be distributed through pre-built Raspberry Pi disk images. I would like to sell kits, too, so people can get one pre-made.

Anyway, since we are going to target Raspberry Pi, we need deep support for the system. Outstanding items:

• Generate disk images
• Client update mechanism
• Hardware RTC support
• Client side database, currently everything comes through the web, which gives a poor UX experience on startup as we wait for first data
• Client side configuration GUI i.e. for Wi-Fi keys
• Decide on standardised kit parts

Web store

The web site that you see in the videos below is functional but there is no way to onboard new users. I would like to incorporate an off-the-shelf authn framework.

• Onboard users
• Shop to sell kits
• Sell users licenses

Deep features

I think the clock needs more features before I can lure users in. I would like to find the most popular modules on magic mirror and make sure we have the top 3, perhaps. Here are some things in the area:

• Facebook event integration
• Apple calendar integration
• Traffic
• Pollen count

Platform and extensions

I think the clock could be more pretty. I’d like to hire a web designer to create several different retro themes. Perhaps this should happen earlier, because people like pretty things, and then I could generate hype and perhaps get some help. It would be nice to have a way for users to hack in themes too, especially if this could be done with CSS only.

I have designed the system around open APIs but none of these are documented so far.

• Official themes
• User themes
• API documentation

We have a little smart clock called Timechief and a website to control the smart clock. Sounds good, but how do we link the hardware to the APIs that drive it?

We use pairing codes. It’s pretty much like when you link your smart TV to your Netflix account.

See the video below for a demo.

It’s a little bit funny but I already have some tech debt on my new Timechief project.

I started a development iteration on the weekend and decided to begin by fixing some of this crud. The most interesting thing I’ve fixed up is probably the handling of weather conditions.

Previously I took the weather condition pretty much as given from the OpenWeatherMap API.

There are some problems with this:

1. My user interface is only going to support one icon per time slot, that is, one icon for the current time, or per daily forecast
2. Open weather map returns more than one weather conditions, so I had picked the first one and ignored the rest
3. Not all possible weather states seem to be represented by conditions returned by OWM
4. After using my clock for a month, I realised that the conditions were sometimes not accurate to my lived experience

Number 4 is interesting. I have total faith that OpenWeatherMap are providing a scientifically accurate forecast. They return codes for things like “scattered clouds” or “broken clouds”.

If you’re a weather nerd, you’ll know that cloud coverage is defined in terms of Oktas. It seems like the open weather map API is based on this. Being in a different Okta is the difference between few, broken, scattered clouds.

While strictly accurate, this level of info is not correct for a casual user. I only want to look at my clock and know what clothes to wear when I go out. See below for redundancy: what is light rain?

On number 3, the OpenWeatherMap weather conditions list does not include conditions for concepts like “it’s windy!” The wind speed is returned by the API, but it doesn’t seem to be returned as a condition.

How did I make it better on my clock?

For weather icons I am using font-awesome. It only has so many that I want to put on the clock.

That makes the job a lot easier. We have so much scientific input data, but only a limited choice of output. It’s about squeezing it down and choosing something sensible to display.

I solved by creating a boolean scoring system that relates to each icon I can display. For example, if the precipitation is high, I score rain. If a OWM weather condition says “lightning”, I score lightning. I look at both raw weather data like wind speed, and also at the list of conditions.

After scoring I do a priority based pass. For example, if we have scored both “rain” and “lightning” then we return “lightning” because that’s probably going to impart most information to our users. I think a casual user could look at a lightning bolt on a cloud and think “that’s nasty weather”.

I also gave the clock UI a tweak so the home page displays the current weather as well as today’s summary.

The forecast page remains as-is but shows the new icon set.

By the way, I have not considered the extreme weather use-case.

For obvious reasons, I don’t want to be the one responsible for processing weather data into weather warnings, so instead of deciding whether or not I should show an alert, I need to trust the experts, and go with what their API gives me.

OpenWeatherMap does return alert data, but I haven’t looked into how well that syncs up to “official” weather alerts, such as Met Office weather warnings in the UK. This use-case will be shunted off for a future iteration though. There is much work ahead of me.

I’ve been working on a Smart Clock project for a while now. The working name is Timechief although I don’t believe that will stick around for too long.

I know that there are a lot of similar projects out there, but mine is different because I want to make it easy for users, and also excellent for makers.

So far I have:

• A really basic timechief hardware prototype
• A website for users to set up their Timechief
• An API to access all the data used by the Timechief and the web platform.

My vision is to create an API platform that makes it easy to link maker devices to APIs, because the platform will have most API integrations that you care about.

And of course, to make really cool clocks!

Please note: future versions will include but not be limited to green-on-black text themes.

I recently completed some work for Arb Research.

The details are private, however, I can share some basic facts:

• I created a data pipeline in Python for handling some Small Data
• It had a nice manifest file interface for defining the input batches
• Feedback from the boss: It worked like a charm

Absolutely love making a happy customer.

Thanks, Arb!