Earlier this year Thingitude bid for some funding from Reading Council to develop an Internet of Things project with students throughout the summer holidays as part of Reading 2016 Year of Culture. A couple of months later I was told the bid was successful!
(gulp) – what did I promise?!!
“We will create a live heat-map of Reading’s arts events, that shows the size of the audience at each event, and allows audience members to rate the event and share it on social media. We will provide the data to the venue owners and artists so they can see how big an impact the event had, and how it compares to other events.
For publicly funded events it will provide a direct, objective measure of the impact of the event, and therefore an indication of the value delivered through the funding.
This is delivered through developing a device that is installed in each venue (whether indoors or outside), and counts the number of mobile phones in the area as an estimate of audience size. The devices will use The Things Network to send their data to an app that presents the data in a useful way to artists, venues and allows audiences to rate the event.”
Ok, so we need to design, develop, test and deliver:
- An app for the public that shows the venues on a map, and how many people are currently in the venue
- An app for the venue owners so they can see over time which days, times, events are busy and which are quiet
- A few devices that count mobile phones as a proxy for people, and then sends that data via wireless to the internet
- Some kind of database to hold all the information
- …oh, and the small matter of finding some students and a place to work
Now I respond well to a challenge, but in my day job the project budget is normally such that I can hand-pick a couple of top notch team members which sets the project up to succeed from the outset. And even if I can’t hand-pick the team, at least *I* know what I’m doing so can steer things along pretty well. Not so in this project – the joy of the Internet of Things is that it is all new and largely unexplored.
What could possibly go wrong..?
Getting started
Finding a place to work was supremely easy – our local collaboration, incubation and co-working hub offered me desk space before I could even ask. I am very grateful to GROW@GreenPark for their extraordinary hospitality and the residents for their friendship and generosity throughout our stay.
It was an amazing base for our project.
Finding students – not so easy. Reading University has closed most of its computer science and systems engineering research (because…?!), and disappointingly I didn’t get a single applicant from the University. So my plan for genius geeky undergrads knocking out a couple of apps in a few weeks needed rethinking. Luckily we have UTC Reading – the first university technical college to be rated as “Outstanding” by Ofsted – and their Physics teacher often comes to Reading Geek Night. He put me in touch with their head of IT and within a couple of days I had a handful of applicants. Hmm, how should I interview 17/18 year olds? – ooh, lets run a hackathon and see if they are any good!
Slight aside – I feel very fortunate that ICL (remember them? – the UK’s answer to IBM) took me on as an A-Level student and trained me up for two years. It was a fantastic opportunity and in hindsight an incredibly brave thing to do – putting this grinning idiot in front of customers, installing computers, swapping broken parts… I was so young and knew nothing, yet they paid me well – £7k including London weighting in 1987 was pretty good going, and in real terms much better than 18 year olds are getting on today’s “modern apprenticeships”. And the training was superb. More of this please modern companies!
The thingithon was fun. Four students turned up and after a quiet start gradually opened up over the course of the day. It was a pretty steep learning curve, but they just about got the hang of the challenge I’d set by the end of the day and I was happy I could work with them.
They all said YES – so I had a team: Kieron, Sam, Simon and Tom. Tom is a year older and off to university at the end of the summer, whereas the other 3 have another year of A Levels to go. What I didn’t have was any computers! Frustratingly the college didn’t want them installing software on their school laptops, and wouldn’t flex the rules, so I had to beg/borrow the necessary kit. Reading geeks and a brother in law came to the rescue! Many thanks to Ant, Ferg, Peter and Tom for lending us their spare old laptops – you saved the project 🙂
The first few days were spent describing the project aims, writing up the user stories, flows and sketching a data model. The next big challenge – find a common programming language. It turns out that C and PHP aren’t so popular with the cool kids these days, which was a bit of a problem because the starting point code I’d written for the device was all in C, and the code I’d written for the server and web apps was all PHP. And the students *really* wanted to create mobile apps not web apps, so PHP was not a good candidate. Kieron, Simon and me did a bit of research on possible languages/frameworks while Sam got to grips with my C code and Tom started designing circuit boards.
The apps and programming choices
We settled on Meteor.js as the platform of choice. You write your code in Javascript, and the server side stuff runs on Node.js so that’s Javascript too, which means we need to learn just the one language and the Meteor framework. Plus the bonus – one set of code will give you a web app, an Android app and an IOS app. We win! Kieron set to work on the public/audience app and Simon took on the venue owner app.
Programming has an odd relationship with time. You can spend days grinding through one seemingly simple feature, and then flash through the next 5 features in a couple of hours. It’s unpredictable, intensely frustrating, and you flip from feeling like a fool to a champion and back again. Over the weeks we all stumbled, got stuck, and then flew …sometimes straight into a wall! Kieron, Simon and me all struggled for a couple of weeks getting to grips with Meteor. Its biggest failing in my view is that it is so brittle – as in it breaks easily (and it ALL breaks); but it breaks silently with hardly any error messages, just a blank screen and a shrug.
Poor Sam struggled for a couple of weeks with C, and then rewrote everything on the device in Python. So now I had to learn Python. I may have complained about this. Sam didn’t mind, his stuff was beginning to work nicely. I remember spending several hours getting really annoyed at stupid Python because I couldn’t see how to convert my string into hex, which is straightforward in C (maybe half a dozen lines of code). So annoying, stupid langua… hey, what I just put “.encode(‘hex’)” on the end of the string? Oh, yeah that works. Hmmm…
I love Python.
I *quite* love Meteor too – it is frustrating when it breaks, but it breaks less often once you know what you’re doing. Funny that. Figuring out how to deploy it into production and for mobile phones is another battle with dodgy documentation, but worth the struggle!
The back-end
Obviously we used The Things Network to connect our devices to the internet. The Things Network publishes our sensor data using Mosquitto (aka MQTT) and my server subscribes to the feed with the right security credentials and receives the data. I am please to say it works like a dream!
I chose MongoDB as the database to hold all the sensor data – it loves the JSON data from The Things Network, and it works really well with Meteor.
My original collector program was written in PHP, but seeing as everything else is javascript I rewrote it in node.js for consistency, along with an aggregator program.
The hotspot device
The “thing” in our Internet of Things project needed a collection of sensors on a circuit board. Over the summer Tom took it from this:
…through a few iterations…
…to this:
We encountered a few problems along the way, which Tom overcame with each revision of the board. One of the local residents at GROW, Luke – gave Tom a masterclass in soldering and let him use his professional soldering kit which was incredibly helpful. We also uncovered some strange quirks of circuit board designers – they are very passionate about curved corners and dressed screw-holes. Who knew? Anyway, I think you’ll agree the circuit board is looking a lot better and a lot neater than when I started!
To finish it off we commissioned Alex from ADMG Consulting to design and 3d-print a case for us. Alex runs his 3d printer business out of GROW – he designs and builds 3d printers as well as designing items to print. This case has some very nice features including grooves for cables, angled holes for the sensors, built in mounts on the back, and a rainjacket for the mobile/outdoor version.
Here’s part of the case being printed:
…and here is the finished item. Ta-da!
The big questions
1. YES – it works. Not perfect, but perfectly good enough to start using. You can download it to your android phone or use the web app if you prefer – I’d love your feedback, but right now please use the Example quiet venue – I’ll keep that one running until I install the devices for the Council and we start using it for real.
2. YES – absolutely I would work with students again. I feel lucky with these 4 – all very bright, all happy to argue for their own ideas, all added a great deal to the project. It took a little while for them to realise that I was only searching Google and Stack Overflow to solve their problems, and it was easier all round if they did that themselves and only come to me with the bigger things to solve. It also took a little while for them to confidently try out new stuff without really knowing what they are doing. School does not teach these things, but that’s fine because they are all quick learners. Obviously they are not yet super high performing professionals, but their attitude was superb, they were 100% reliable, and I hope I get to work with them again.
3. YES – you can buy a hotspot for your venue! Get in touch 🙂