The Light Clock

Estimated reading time:

My Light Clock arrived on Friday, and the weekend was a great opportunity to set it up and learn more about how it worked.

I’d backed this project for two key reasons;

  • The project was run by an Australian hardware and software engineer – Chris Carter – who was recommended by colleagues in the opensource community. I’m passionate about opensource development, and I wanted to help back an Australian project, particularly given the success of LIFX.
  • The project was based on open hardware and open software. The base board for The Light Clock appears to be the arduino-compatible ESP8266 which is fast becoming the go-to board for open hardware developers. The lighting is based on AdaFruit’s neopixel range.

The box was very plain and simple, and the device itself was packed with polystyrene peanuts and bubble wrap – very secure nonetheless. The Australian adaptor was included in the box, however the lead on the device was only about 1.5m long. The Light Clock sticker on the back of the device was a nice touch, however I would have liked a Light Clock sticker separate in the box for say laptop stickering. Being one of the first 200 people to receive a Light Clock device, a ‘Kickstarter Edition’ engraving or similar would have been a welcomed addition, but understandably not part of minimum viable shippable product.

First steps with #thelightclock, a @kickstarter project I backed.

A photo posted by @kathyreid_id_au on

The short lead presented the first design and installation challenge; ostensibly this device is aimed at replacing existing analogue clocks that are wall-mounted. However, it’s rare that someone would have a general power outlet (GPO) high up on their wall, necessitating a fairly long lead run to a ground-level GPO. This may not be the case in say corporate offices, which may already have networked clocks in place, or existing infrastructure for digital signage.

Connecting to the network

The next challenge was connecting to the Light Clock, and getting it on to my home wi-fi network, so that it could use NTP to keep in sync. The Light Clock correctly appeared as an advertised SSID in my Network Manager, however every attempted connection to this SSID failed. Rather than spend the time diagnosing it, I used my Nexus 5X mobile phone, running stock Android, to connect to The Light Clock SSID. This was successful on the first attempt, and I was able to join The Light Clock to my home wifi network. As expected, The Light Clock could not see my 5GHz SSID, and could only see my 2.4GHz SSID. This appears to be pretty normal for most IoT devices at the moment, but I suspect we’ll see more support for the 5GHz frequency over time. The service that joined The Light Clock wasn’t responsively designed, so it was a bit tricky on a mobile device.

Once I got the device on the network, I then went back to try and diagnose why I couldn’t connect to The Light Clock SSID via Ubuntu, and found something very interesting. The MAC address picked up by the router, shown in the image below, was;

18:fe:34:e2:14:43

however, the MAC address picked up in dmesg (the Ubuntu Network Manager log) was

1a:fe:34:e2:14:43

So, I think there may be an issue with the MAC address it’s broadcasting, or how my machine was picking up the MAC address. Here’s a link to the dmesg logs in case anyone is curious. For the record, I’m using an Atheros network card in my ASUS N76. It’s otherwise generally pretty reliable.

How The Light Clock appears as a device on the router
How The Light Clock appears as a device on the router

Configuring The Light Clock

Configuring The Light Clock proved much easier than getting the device on the network. You simply connect to a web interface to the device over your WiFi network and adjust the settings.

Another observation was that clear setup instructions were at thelightclock.com/setup.

/setup is becoming the default setup URL for devices such as this

The Light Clock settings screen
The Light Clock settings screen

Experimenting with colours yielded some interesting conclusions. The colour settings tended to work best when both colours – the hours colour and the minutes colour – were heavily saturated and bright. Neon type colours – bright pinks, yellows, blues and greens – tended to work best in terms of contrast between hours and minutes. For someone whose house is pretty much all neutral shades – stones, earthy colours – finding a colour palette that was both clearly readable but resonant with the rest of the interior design was very challenging, and I couldn’t settle on a palette that met both requirements.

The blending option when set high tended to make the time much more difficult to read, and I settled on the lowest blending setting. The other feature that would be useful here would be the ability to adjust the brightness of the hours colour setting and minutes colour setting independently, so for instance you could have a very bright hours setting and a very dull minutes setting. I’m not sure if this is possible with the Neopixel hardware though. I did have a look at the source code to see if it was an easy pull request to do, but I couldn’t figure out how the brightness value is added to the pixel colours.

The settings also had three slots to save different colour schemes, which is a useful UX addition, however I would have liked to have seen more slots. In experimenting with the hour markers, I found that no hour markers at all actually made the time more readable, which was counter-intuitive.

With a little tweaking, I think this device could be integrated into other design projects, such as on canvas or with something like LilyTwinkle.

Integration with other IoT devices

One of the key drawbacks of The Light Clock is that it doesn’t appear to have any integration with other IoT devices, such as LIFX, Hue, Nest and so on. There are a number of use cases I can see for The Light Clock to have a lot of additional value if integrated such as;

  • Using The Light Clock as a visual indicator of notifications, phone ringing and alerts
  • Synchronising The Light clock as a wake-up device. Currently I use LIFX to slowly turn on my bedroom light in the morning, and I’d like The Light Clock to be synchronised with this, particularly given that it tends to work best with neon colours.
  • Integrating Light Clock control in to other apps – such as LIFX. I’m really glad that I don’t have to install yet another mobile application to control The Light Clock – because the IoT app market is already so fragmented.

I was also half expecting some sort of documented API for The Light Clock so that I could experiment with some integration myself, and although the source code is available, the device itself doesn’t appear to have a documented API or web service. From what I can tell, the settings page basically takes a bunch of GET variables and writes them to the board, so even knowing the range of GET vars would help to be able to integrate The Light Clock with other devices.

The verdict

This is a great product for people passionate about open hardware, and who like to tinker, but it’s not yet mature enough for a mainstream product. With some small design tweaks and attention to detail in the codebase, it would be a strong standalone product, however it’s key value lies in integrating with other IoT devices to provide meaningful and valuable interactions.

I’m not sure what I’ll do with my Light Clock – I don’t have a wall mounted GPO or GPO in range where I could mount one, unless I find a longer-lead adaptor.

List of feedback for next iteration of this product

  • Include an adaptor that has a long lead to cater for the use case where someone doesn’t have a wall-mounted GPO available, or allow this to be selected during the purchase process.
  • Alternatively, the product could be redesigned to run on batteries (wasteful) or better, power over ethernet – but again the same design limitation remains – just as people are unlikely to have a wall mounted GPO available, they’re even less likely to have a wall mounted RJ45 ethernet port available. I suspect this will change as more and more people have networked devices on their wall though, so I don’t see it as a major limitation.
    Note to self: I need to include wall-mounted GPOs and RJ45 sockets in my home renovation master plan
  • Chris Carter’s The Light Clock source code is available on GitHub, but isn’t in its own project. There also aren’t any license files for the different repositories, so I’m not sure if I’m allowed to fork it or issue pull requests.
  • In the settings, you manually have to set whether it’s daylight savings time or not. Given that it uses NTP for keeping network time, I would have thought it would be possible to get it to automatically accommodate daylight savings time. Could be wrong here, NTP may not store that data, or it may be difficult to pick up the geolocation from the home wifi network.
  • Have separate brightness settings for minutes and hours
  • The web interface for adjusting The Light Clock settings would benefit from being responsively designed
  • Can haz API plzkthx 😀

 

Update: trying to mount it to the wall

So, I gave mounting it to the wall a go. This was a nightmare. The two circular openings to hang The Light Clock with are flush to the back of the clock, meaning that I couldn’t mount it with cuphooks  as the hooks were too curved to snag into the openings. I also tried with the Command re-usable big hooks, and tried to assemble them so I stuck them in the openings first, then tried to stick the entire lot to the wall, with no success. Definitely frustrating. Even if I had got it to mount on the wall, I would have still had a cord trailing down the wall, and the 1.5m power cord is still insufficient to reach the GPO.

Was anyone else able to mount this successfully? How did you do it?

Learning Bitcoin and the blockchain with the 21.co bitcoin computer

Estimated reading time:

Digital currencies have been gaining traction for some time now, and although I had a broad sense of what they did and how they could be used, I hadn’t had an opportunity to utilise them in a real world setting. So, I set some personal learning goals and set about achieving them:

  • To learn the terminology associated with digital currencies, in particular Bitcoin, and the blockchain, which would serve as a foundation for building my knowledge
  • To undertake some practical exercises involving the actors, methods and marketplaces for digital currency, allowing me to explore limitations, current and future applications, and understand the enterprise use cases for the blockchain.

Buying the 21.co bitcoin computer

The initial research indicated that the 21.co bitcoin computer would be a good place to start. What drew me to it was that it was backed by some big names in the industry, and its approach to a digital currency marketplace was unique; leveraging micro payments for micro transactions such as sending an SMS or an email. Based on Raspbian and running Linux also gave it bonus points 🙂

The first problem encountered was that it didn’t ship to Australia. Challenge accepted.

Having already set up an Australia Post Digital Mailbox, it was super easy to establish a ShopMate account. The experience here was seamless, and for an additional $AUD 43 my 21.c0 bitcoin computer was shipped from Portlandia to Australia. Win!

The cost of the computer was a bit steep at $USD 399, which worked out to just under $AUD 600 with the woeful exchange rate. Still, I figured this was cheaper than say a formal course on bitcoin or blockchain.

Initial steps

Unboxing, as many fellow geeks will resonate with, is a ritual, and an integral part of any large tech purchase. The 21.co didn’t disappoint. The packaging was sleek, black, minimal and beautifully put together. The Raspberry Pi-based computer was nestled comfortably in black firm styrofoam, with the power cords and accessories stashed underneath.

Inside the box was the 21.co bitcoin computer itself, power cord, and USB cable to connect the board to your computer for initial setup. The USB cable actually had four connectors, but the 21.co board has three pins. The unneeded connector (red) had been cut off, to make setup easier. This was a small detail, but indicative of the thought that had been put into the product. A USB wireless adaptor was included in the box, without which the product would have been almost unusable, so this was a great inclusion. Perhaps the only improvement suggestion here would be to use a WiFi adaptor that supports both the 2.4GHz and 5GHz ranges – my router runs two SSIDs, one on each range, and the included WiFi adaptor was only able to connect to the 2.4GHz SSID.

The only component that wasn’t initially included that I had to hunt up was a US -> ANZ power adaptor, which is forgivable considering 21.co don’t technically ship to Australia.

Behold! The first three @21 Bitcoin Computers in The Netherlands. Want to join the hackathon? Let me know!

The next step was to connect my Ubuntu 14.10 LTS-based laptop to the 21.co and run some setup software. This was excellently documented, with instructions inside the box itself, and also prominently displayed on the 21.co website. What I really liked about the setup was that there was an automatic version, and a manual version if you had more experience on a Linux CLI. There were also options for other operating systems.

I got a little bit stuck on the initial setup, and couldn’t get the setup.py script to run. Initially, I wondered whether I’d triggered an unsafe shutdown of the device, and it was trying to re-index the database, so I let it run setup overnight. This didn’t fix the issue, so I jumped on to the 21.co support Slack (about 0700hrs Australian Eastern Standard Time – so GMT +1000hrs), thinking that no one would be online. Not only was support readily available, it was helpful, polite, friendly, and assumed that technically I knew what I was doing – an excellent support experience. In the end, it was a total n00b issue – the microSD card in the 21.co computer wasn’t seated correctly!

#21co first steps with #bitcoin and #blockchain

A photo posted by @kathyreid_id_au on

 

Learning a bit more

Once I had run setup successfully, I was able to mine my first Satoshis (sub-units of Bitcoin currency). Because it’s now difficult to mine Bitcoin directly, due to the computational complexity, a single machine has a very low probability of successfully mining a Bitcoin block. To work around this limitation, 21.co facilitates a collective approach called buffered pooled mining. In this scenario, many 21.co computers work co-operatively to mine Bitcoin, and collectively distribute the rewards. This means that you may only receive a few thousand Satoshis per day, but it’s sufficient to learn the concepts involved and start to prototype applications and ecosystems that leverage Bitcoin and the blockchain.

The next challenge was to see if I could set up a simple application that utilised the 21.co infrastructure to provide services for micro payments of Bitcoin. Using the tutorial, it was reasonably quick and easy to do. I found all the tutorials were written in really clear, simple terms, and stepped you through the different concepts being demonstrated in a very logical way. There were a few glitches along the way, mostly to do with package management and dependencies, so having at least a basic grasp of apt and pip was very useful.

I’m not sure where I’ll go next with this hardware – perhaps a micropayment webservice or too, but even with the initial steps here I’ve got a much better understanding of how Bitcoin and blockchain concepts can be applied more broadly. I could choose to run the 21 Bitcoin computer as a full Bitcoin node, but my internet connection is so slow that it probably isn’t worth it.

Use cases for the blockchain

The foundation of digital currency – the blockchain – has implications far beyond monetary transactions. The blockchain itself models provenance – the ownership of an asset (in the case of digital currencies, monetary assets) over time. Could it be applied to the physical as well as digital world, for instance to record the change of ownership of physical assets? I’m not so sure.

Physical and digital assets have different properties that may limit the blockchain’s applicability to the physical world – for instance physical assets such as cars, houses and jewellery can both be destroyed, or reconfigured. For instance, I could take piece of clothing and burn it, thus destroying it. The blockchain – or at least the Bitcoin blockchain, cannot easily handle such a use case, and the protocol would need to be extended to do so. It also cannot handle the reconfiguration of assets. Let’s say that I have a string of pearls, with 100 pearls on the string, that was given to be my by mother. The blockchain could record the change of ownership from my mother to I, but let’s say that I cut the string of pearls in half, creating two shorter strings with 50 pearls each, and then I gift one of the 50-pearl strings to my sister. The blockchain could handle this monetarily – splitting one value into two values, each distributed to separate owners, but it could not handle this physically – but recognising that two separate assets had been created where one previously stood. Of course, it’s possible that in time extensions or additions to the blockchain would address these shortcomings – it will certainly be an interesting thread to track.

Privacy and identification in the blockchain are also of interest. The blockchain itself doesn’t identify participants in transactions, which is great for privacy, but not so great for transparency. I suspect we’ll see the rise of services such as OneName which help to identify participants. For instance, imagine if government transactions were on the blockchain – you’d want them to be transparent.

Of course the blockchain itself also represents a unique big data source. As the use of Bitcoin evolves over time, it would be an interesting exercise to observe trends or changes in the patterns of transactions – such as average value, the frequency that BTC was transferred to or from particular addresses and so on.

Another interesting application of blockchain could be in content management and for handling versioning – as essentially a content management system is a series of assets that are mutative via known transaction types. Using blockchain for content management would also help to solve some of the problems around “what did a particular asset or collection of assets look like at a point in time” – as the blockchain contains an entire historical record.

A fascinating area.

 

linux.conf.au 2016 Geelong – LCA By the Bay

Estimated reading time:

So, it’s been about six weeks now since linux.conf.au 2016 Geelong – LCA By the Bay concluded, and after a lot of sleep and catching up, it’s about time to pen some thoughts about the process, the experience and learnings.

Getting linux.conf.au to Geelong

When you think ‘epicentre of opensource’, Geelong is not what comes to mind. Well, it’s not what used to come to mind! So, how did we bring linux.conf.au to Geelong?

Late 2013

Firstly, we needed some core people to put a bid together. David Bell and I had worked on BarCampGeelong before, and had semi-seriously considered bidding previously. We felt that we had a complementary set of skills, and the drive, leadership and passion to make it happen.

We worked with Business Events Geelong, and the wonderful Terry Hickey, to put together a bid document, covering key aspects of what linux.conf.au in Geelong would look like. Business Events Geelong were able to assist with a professional bid document template, and with sourcing pricing to include in the bid document. A couple of hours later, and we had formally submitted our bid to host linux.conf.au!

linux-conf-au-geelong-bid (PDF, 1.5 Mb)

linux.conf.au is chosen by a committee of trusted senior members of Linux Australia, the organisation that umbrellas linux.conf.au and a stable of other events, such as PyconAU, Open Source Developers Conference and a number of WordCamp and Drupal events in Australia. Linux Australia calls for expressions of interest from teams interested in running linux.conf.au every year – bids – and forms a small committee to evaluate the submissions. This normally involves travelling to the bid city, and assessing elements such as;

  • accommodation
  • conference venue
  • transport to and from the conference
  • conference event locations

April 2014

Terry and the Business Events team were amazing at hosting the bid team, and showcased a number of Geelong’s leisure and recreation offerings, cementing the quality of our bid. It was a great opportunity to learn from the bid team, as they assessed our risk management, our planning and our ability to pull together such a large event.

Venue visit for #lca2015 #geelong. Beautiful.

A photo posted by @kathyreid_id_au on


Although Auckland were awarded linux.conf.au for the year ahead (2015), the decision was made to award Geelong linux.conf.au 2 years out. This was an excellent decision, and provided long term stability not only to the event, but also provided the conference team with a longer term planning horizon.

Woo! We won a bid for linux.conf.au! Now what?!

Once we had a strong idea of how the main conference venue (Deakin University’s Waterfront Campus) would work, we focussed our efforts on preparing to showcase Geelong as an outstanding venue at linux.conf.au 2015 in Auckland. Often, the next year’s conference prepares promotional material or flyers to help encourage conference attendees. We had decided on our conference theme of

life is better with linux

and in keeping with the theme, worked with Martin Print to have NFC keyrings printed.

Now the hard work began. Firstly, we needed to ensure that our conference management system was functional. linux.conf.au traditionally runs on a piece of software called ZooKeepr, and it needs a bit of maintenance each year. Luckily, we had Josh Stewart and James Iseppi to give us a bit of a hand, and with David Bell being generally awesome with anything technical, in no time we were able to get ZooKeepr ready for the Call for Papers.

Call for Papers (#CfP)

The Call for Papers (#CfP) happens about 6 months before the conference, and the challenging part for conference organisers is ensuring not only that there are a large volume of submissions, but that the quality of submissions is of a quality fit for an internationally renowned conference. One of the ways in which the conference spreads the word about #CfP far and wide is to reach out to all past Speakers of linux.conf.au and encourage them to make submissions. We also lean heavily on the Papers Committee, the group of senior and respected Linux Australia members who review the #CfP submissions and make recommendations to the conference team on which submissions should be accepted into the conference.

This year, the conference team decided to add another type of submission to the mix – Prototypes – alongside the standard 45-minute Presentation and 110-minute Tutorial. This worked out wonderfully and some of the most popular talks of the whole conference were submitted as Prototypes – including the crowd-favourite Linux-powered microwave by David Tulloh.

Thanks to the efforts of Papers Committee and past Speakers, we received almost 300 submissions, and the overall quality was excellent. The Papers Committee spent a day in Sydney in in August making some very tough decisions, and after around 10 hours we had our Schedule! I was incredibly impressed by the talent in the room, and the generosity of the Papers Committee to give up their time – and in many cases their own coin – to travel and attend.

Schwag

While I was busy liaising with Speakers and getting travel organised, and David was busy with event venues for our conference events, Sae Ra Germaine was being a superstar with our schwag. She found an excellent supplier for our conference bags, Ecosilk, and designed a contemporary yet simple t-shirt for our delegates (navy) and volunteers (orange). She also worked to ensure that we had sunscreen  and hand sanitiser as part of the Schwag bag.

#lca2016 all tired out.

A photo posted by ms_mary_mac (@ms_mary_mac) on

Sponsors

David took a strong leadership role in Sponsorship, and developed a Sponsorship Prospectus, and negotiated sponsorship agreements with all of our fabulous sponsors. Many of our Sponsors support linux.conf.au year after year – without them, the conference wouldn’t happen. One of the challenges the conference has is having to re-establish sponsor relationships year after year, and our Ghosts debrief session and good documentation helps to ensure continuity.

Venue and catering

Deakin University’s Waterfront Campus and Costa Hall are beautiful architecturally, and provide a wonderful environment for collaboration and learning. However, the campus cannot hold 600 conference delegates in a 5 stream conference easily. So, we worked with the National Wool Museum, located a block away from Deakin, who had a conference room available. Another benefit of this arrangement was that delegates were able to see the jacquard loom – programmed via punch cards that the Museum had in their collection.

Patching a bug on a two story high computer. #lca2016

A photo posted by John Dalton (@varrqnuht) on

We worked with Waterfront Kitchen to arrange lunch options for delegates, and arranged to have menus placed in the Schwag bag. WFK also handled all catering for the conference, including morning and afternoon teas. We also made the decision to have core team and volunteer lunches fully catered, so that we could free up time during the busy conference period, and this proved to be a wise choice. We received nothing but positive feedback from our delegates regarding WFK’s catering – the variety, the attention to detail and handling of special dietary requirements.

By November, organisation of event venues was in full swing. linux.conf.au has three traditional conference events – Speakers Dinner, Professional Delegates’ Network Session (PDNS) and the main conference dinner, the Penguin Dinner. Speakers Dinner was held at the fabulous Balmoral at Fyansford, with the Limoncello String Quartet for music.

PDNS was held at the fabulous Little Creatures Brewery, and it was perfect. Great beer, great food and great company. It was amazing to see over 300 people of linux and opensource having a great night out.

 

Our Penguin Dinner was at the fabulous The Pier restaurant, and was an amazing night out for all concerned.

AV and Networking

A great conference needs great AV and networking, and we were fortunate to have some wonderful people, including Andrew and Steven working with us. The networking crew laid over 200m of fibre optic to the Wool Museum so that they could have solid internet, and we utilised the services of AARnet for our on-campus networking. Deakin University also provided phenomenal support, working with AARNet to provide strong wireless across the conference venues.

A great team

There were so many different parts of linux.conf.au that had to come together to make it an excellent conference, and the entire team needs to take credit for that. Aaron, who co-ordinated our childcare arrangements, which was greatly appreciated by attendees, Brittany whose excellent accountancy skills kept us very well budgeted, Michael whose social media prowess ensured we trended nationally, George who provided a helping hand where it was needed, Erin who was our Rego super-hero, Josh who helped us keep ZooKeepr and our payment gateway under control, Daniel our stellar volunteer co-ordinator and Brett whose photographic talents and video production blew us away – every single person was part of an amazing, productive, motivated and awesome team that I was so incredibly proud to be a part of.

LCA2016 - Wednesday