Workshops by the sea

Student vigorously shaking a motion sensor

Our love affair with Wales continues!

For quite a while now Thingitude has been helping colleagues in the Welsh Assembly understand and promote the benefits of LoRaWAN as an IoT network for rural areas. Over the last few months our combined efforts are beginning to bear fruit.

Recently Thingitude was commissioned to run two 2-day workshops at MITEC in Milford Haven, one the western tip of the Pembrokeshre coast Continue reading “Workshops by the sea”

Things Connected innovation programme

Since last summer I’ve been helping Digital Catapult with their Things Connected programme – an intervention to encourage UK business to learn about LPWAN technology and how it can work for their organisation.

In the last quarter of 2017 I organised and ran an innovation programme for small businesses working on LPWAN solutions for social housing and independent living use cases. These are two areas that councils believe have potential to benefit from the Internet of Things, and LPWAN in particular. Continue reading “Things Connected innovation programme”

Thingitude has graduated!

Digital Catapult is a government funded non-profit company that aims to grow the UK economy by encouraging digital innovation in specific areas it has targeted. One such area is the LPWAN technologies that are of growing importance in the Internet of Things.

This year the Catapult ran its first Things Connected innovation programme for startups and SMEs – giving access to their London LoRaWAN network and support in developing products, providing a showcase and introductions to potential clients, partners etc.

Thingitude applied and was accepted onto the programme, and over the first half of the year we developed a method for enabling LoRaWAN solutions to work across multiple networks (write-ups here and here) and got several devices working on The Things Network and Things Connected. Continue reading “Thingitude has graduated!”

Is the Smart City hype over? Is it finally HAPPENING?

I first got interested in Smart Cities and the Internet of Things in the summer of 2015. In November that year I dived in and got very excited by The Things Network.

I have just spotted that this coincided with two peaks on Google Trends for the topic “Smart City”. So much for me being a unique, visionary thought leader (or whatever we are meant to strive for these days)– I was just one more snowflake in a veritable blizzard!

In the last 12 months the Google Trends chart for “Smart City” web searches has been very flat. But since January there has been a noticeable month on month increase in the number of “Smart City” news searches (I’m disregarding the drop-off during the election period).

Does this mean anything I wonder? Are city leaders (or their giant IT partners) beginning to announce Smart City projects – is the hype over …is it finally HAPPENING?

On Twitter recently shared an article by Boyd Cohen in FastCompany that describes the 3 generations of Smart Cities. It’s well worth a read, but the gist of it is that:

  • Generation 1 was technology-led
  • Generation 2 is city-led, and
  • Generation 3 is/will-be citizen co-creation.

One of the aspects of The Things Network that I really like is its bottom-up, grass roots approach to innovating and building IoT solutions. I love that a whole town (hello Reading!) or city can be covered by LoRaWAN for a few thousand pounds. I think it is truly game-changing. We don’t need Vodafone or BT or anyone, we can run it ourselves for free. How liberating is that?!
It has taken me a while to get to the bottom of what upsets me so much about Local Authorities partnering up with the corporate IT giants to design their Smart City. After all, who expects a city to rely on a crowd-sourced, casually managed wireless network for its critical services? Of course cities need to work with the likes of Cisco and Microsoft to provide infrastructure that guarantees the availability of critical services.

But here’s the problem:
The smartest cities – the ones that will grow, the ones that people are eager to live and work in – will be those smart cities that have personality and identity. And you simply cannot get that through top down design by some IT giant.
Not convinced? Let’s do a test:

  1. Hands up if you honestly think Brighton or Bristol would be more vibrant, more exciting places to live and work if they were designed by Dell. Incidentally Dell’s UK base is Bracknell – ’nuff said?
  2. When you are planning your Friday night out– who thinks to themselves “hey, let’s go wild and hang out where the Oracle guys go”?
  3. When you are picking a city break, what do you look for? Is it a tough call between one that has the most predictable shopping mall, and another that has the finest automated taxi queues? Or do you go for something a bit more …you know, human?

I have written previously about my fear of cookie-cutter smart cities. It is why when I talk to people about starting a Things Network community I emphasize the need to build a community not a club.

City leaders – if you want your city to prosper, then you NEED the communities you serve to be engaged in the Smart City agenda. Look closer to home, there might be a Things Network or similar Internet of Things community already happening. If not you can easily start one or find another way to involve local people in your Smart City plans. There are almost certainly a few startups and small businesses in your city who would be very excited to work with you and your communities, and they’d be happy to work with your big IT partners too.

You need to be this Generation 3 kind of Smart City that FastCompany talks about. And you need to meet the needs of ALL your residents and workers. This means not just listening to the well paid white male consultants your IT partners put in front of you (but please listen to this one, obvs!)

I love all the IoT technology that will help remove friction in city living, but it is the unique mix of communities and businesses – the people – who will breathe life and personality into any city or town. They, and the people looking to relocate to a better city are the ultimate judges on how successful, how smart your city really is.

Roaming across LoRaWAN networks, part 2

The application end

Quick recap – In the absence of a UK-wide LoRaWAN network I am looking into the feasibility of developing a LoRaWAN based IoT solution that can work across a patchwork of LoRaWAN networks.

The previous article focused on making the Long Range VAN device – a burglar alarm for white van drivers everywhere – able to roam between different LoRaWAN networks. I am testing with The Things Network in Reading and Things Connected in London.
This article looks at the application end. My application, which receives alerts and GPS position from the van alarm will need to collect messages from different networks and relay then to the van owner.

The Things Network publishes data using MQTT. Things Connected used a different technique – it sends json data to your web server. Either way you need to have a message collector running on your server to listen out for new messages, and then process them appropriately.

On my device I control the structure of the payload (GPS co-ords), but I have little control over the structure of the LoRaWAN message I receive at the app end. There are differences between the two networks in message structure, although they are both essentially JSON format. It would be interesting to try this with Stream Technologies’ implementation of LoRaWAN, or LorIoT to see how much variety exists in message structure between networks.

At the device end I configured the device to use the same device EUI, but I don’t know if this would be permissible on all LoRaWAN networks. It feels prudent to allow for the possibility that different networks may have different device EUIs for the same physical device. An alternative approach would be to include an ID in the payload that we use instead of the device EUI. The significant downside to this alternative is that it increases the message size, which will increase the airtime usage per message, and therefore gobble up the 1% duty cycle more quickly. In my judgement it is better to keep the payload small and do the extra work within the collector.

For the purposes of proving the roaming capability I have written 2 collectors in Node.js, one listening to each network. Each collector converts the received data into a common format JSON document which is inserted into my Mongo database. My app is thereby oblivious to the fact that the data arrived over more than one network. It works with multiple devices on these 2 specific networks for one application. I could write a third collector for say Stream Technologies, and a fourth…

It strikes me that I (or you) could design and write a more general collector that could work for multiple devices and multiple networks for multiple applications and multiple databases. This feels to me like it could be a useful service to offer. I wonder whether there would be sufficient benefit and interest in such a middleware service for IoT application providers who don’t really want to worry about whose LoRaWAN network their clients have installed?

But wouldn’t it be better if the LoRaWAN specification supported roaming so we didn’t need to worry about this stuff? Hmm, maybe it’s in the post…