Connexin Live

 I can’t help thinking that  HullOS  has a much better ring to it…

I can’t help thinking that HullOS has a much better ring to it…

A couple of weeks ago I was at the Hull Arena marvelling at how Hull could put on such a fantastic digital awards ceremony. Today I’m at the same place marvelling at how Hull can host a splendid technical event. One of of the first thing the delegates were told about Connexin was that they are a Hull company. Born and bred. And proud to be here.

Connexin are a local company with global plans and big hitting partners in the form of Cisco. A Cisco person had even flown all the way from San Francisco to speak at the event. The theme was something very dear to my heart; Smart Cities. We heard from Hull City Council and Hull University about their ideas for the future and from folks from Newcastle about what they had been up to.

These are challenging and exciting times for local government. Challenging because budgets are being squeezed as never before, and exciting because technology is showing real potential for improving the lives of the people that the councils serve.

It was great to hear all these inspiring plans being laid in Hull. I couldn’t stay to the end unfortunately, I had to go and see how the Hardware Group at c4di was getting on. The answer, by the way, is very well. We’ve got three new members who’ve turned up and want to have a go with the Arduino. I’m putting together some kits for them for the next meeting. You can come along and have a go too if you like. The next meeting is on the 11th of October at c4di, starting at 6:00 pm.

MQTT topic management conundrums

31119526288_2b9d11758e_z.jpg

Well, this sounds like a gripping title for a post eh?

But actually for me it’s a thing. I’m getting my head around MQTT as a way of sending data from our air quality sensors to the systems that want to work on the data. MQTT is a “publish and subscribe” transport. An MQTT node can send messages to a particular address managed by sn MQTT broker process running on a machine somewhere. Other processes can subscribe to that address on the broker and, when the mode sends a packet of data (string of bytes) to the that address the broker will then send that message to everyone who has subscribed to that address.

Make sense? OK, think of it as a mailing list for a pop star, perhaps David Essex. Anyone interested in what David is up to can subscribe to the mailing list, which has a particular name. David’s publicist, who produces the content describing the amazing life that I’m sure David has, (other pop stars are available for this exercise) connects to the mailing list as a publisher, and sends messages which are then sent out to all the subscribers. So MQTT Is basically a fan mail management system.

The address expressing the a particular endpoint is called a topic. Topics are hierarchical. So, an air quality sensor could send a messages to the following topics with the respective data items from that sensor:

Sensor01/temp
Sensor01/pressure
Sensor01/humidity

Alternatively, an air quality sensor could send a single message containing all three values, encoded as a lump of JSON (JavaScript Object Notation) to a single endpoint:

Sensor01/data

Which is better? I’m not sure. Object Oriented Rob says that having all the related items in a single cohesive object which can also contain things like timestamp and location information will make it much easier to process. Free Wheeling Rob says that having individual data on separate topics makes it possible to handle data produced at different rates by different sensors, and also makes it easier for something only interested in temperature (a fan perhaps) to just subscribe to that data item. And both Robs need to remember that the broker is just that, a broker. It doesn’t have any bearing on what will happen to the values that are passed through it from a device to a process that is doing something with it.

As usual, when faced with a problem like this, I’ve gone a bit meta. To me the important thing is probably not which particular way the values are configured for a given application, but that it should be easy to change this configuration during the lifetime of a node. To this end I’m working on a little protocol which will let a node advertise the readings that it has available and then be told which readings to be sent where. Once a node has been told where to send its data it will do that until told otherwise. This means that we can change how we use the sensors so that we could use either of the above approaches.

The good news is that this will be wonderful. The bad news is that I’ve got to do it. Oh well. Today I got a Python program talking to MQTT. The next step is to get JSON working on the Arduino so our systems can start exchanging configuration information.

Talking MQTT

mqttmessages.PNG

Ha! Today has been a good day. I’ve got my Air Quality sensor talking MQTT to the Connected Humber server and sending messages. This has been a bit of an adventure, mainly because I had to mess around with the libraries for the Heltec device that I’m using.

Anyhoo, I’m now sending messages over both LoRa and MQTT at the same time. Go me. Now I just need to add some configuration options and I think we might actually have a product here.

Incidentally, I’m using a Windows app called MQTTBox to view the messages on the server and post test messages to my sensor. Works rather nicely. And free.

Rob at Ron Dearing UTC

30041497068_3f43db175b_z (1).jpg

Despite arriving a tiny bit late, I had a great time at the evening event at Ron Dearing UTC today. A whole bunch of folks came to see me to talk about technology and I showed off some Hull Pixelbots, my silly goggles and the prototype air quality sensor that we’re working on over at Connected Humber.

Of course, I totally forgot to take any pictures at the event. Silly me. That’s why there’s a rather splendid picture of Whitby pier at the top of this post instead of anything relevant to the night.

Anyhoo, I talked to a bunch of folks and gave out a bunch of advice. Summarised thusly (posh prose)

  • If you’re into computing, start playing with the Arduino device. It’s cheap to get started (much less than a video game) and extremely creative. Buy a Sintron Arduino kit (search ebay or Amazon for “Sintron Arduino” to see a selection of kits. The one that is around thirty pounds is good value. If you want to start cheaper, come along to a Connected Humber event (we have them on the first and third Thursday of the month at c4di starting at 6:00pm in the evening). We’ll sell you an Arduino and some hardware for five pounds and give you some things to do with it. You can find out more here.

  • Start learning about 3D design. Lots of people that I spoke to were already doing this. The ability to think in 3D will stand you in good stead whether you go into fields ranging from video games to product design. There are lots of free packages you can use, I quite like FreeCad, although it can be a brute to get to grips with. If you’re a programming type, take a look at OpenScad. If you want to use a free, professional level, tool take a look at Blender. It will really make your head hurt, but you can do awesome things with it. Take a look online for howto videos for these tools. If you don’t like the ones that you find, make some better ones of your own.

  • Which brings me to my third point. Lean to write and talk. When you start doing something, start writing about it too. Put your writings into a blog, a personal diary or a log. I don’t mind. The important thing is that you do this. I made the point lots of times that you can learn a good living, and have fun, as a programmer. But if you also have the ability to write well and are good at communicating your ideas this makes you much more useful and interesting to employers, getting you even more interesting and rewarding things to do. So you should work at getting those skills. Deliberately do things that take you out of your comfort zone. Practice talking to people (networking is a big part of success) and try to force yourself to speak in public. Trust me. It really pays off.

By the end of the evening my voice had just about worn out, as had the batteries in the robots. But it was great fun. And then I went home and had bananas and custard for supper. Such fun.

Air Quality Sensor Version 1.0

If you think that all I've done over the last week is work on my Air Quality sensor you'd be wrong. But I have been quite busy with it. I've now got a proper menu system with messages and numeric input. Plus a box. The box has been particularly fun to design, especially as the Heltec micro controller, in common with lots of similar devices, doesn't seem to provide any way that it can be fitted into a case. I've ended up making a little clamp that holds it in position. I'm not happy with this, but then again I'm not crazy about my looks either - but what are you going to do? 

To say that the case is printed version 1.0 it has gone together quite well. I'm using the "dead cockroach" assembly technique, where you regard the chip as a dead cockroach lying on its back and connect the wires to the upturned legs. There are no components other than the devices that I'm wiring together. The only tricky bit is that the clock and the temperature sensor share the same SDA and SCL lines and so I've had to make up some custom cables. But it's all working, and now I have a box with all my sensors and whatnot that I can start to to build software for. 

42346248680_6e74e01191_z.jpg

This is the ugly truth about what's in the box. We'll gloss over the way that the wires for the RTC are too short to allow it to be fitted onto its mounting post, and the wire for the sensor is far too long......

The next step is to add a "WiFi Setup" mode that can be used to get the device onto the internet and then we can start pushing readings into the cloud. You can track the project on GitHub here. Bear in mind that this is a work in progress, and so nothing is fixed. This is all part of the Connected Humber Monitaire project, you can find out more here

Building an Air Quality Sensor

I've been having proper fun today. I started with one of my tiny Heltec embedded controllers and an urge to connect it to an air quality sensor and a temperature/air pressure/humidity sensor. 

It wasn't easy, but it was possible. Biggest problem was that the temperature sensor uses an i2c connection to the Heltec device, and so does the lovely little OLED panel that you can see above showing numbers.

Turns out the way to make it work is to create another Wire instance and then use that for the temperature sensor. Anyhoo, it works. If you want to see the code you can find it here.

I've written everything using message pumps and state machines so that it should be possible to have all this working together without something getting stuck. 

Hull Meetups is becoming Connected Humber

Things are changing, but not changing. The c4di Hardware Group is turning into Connected Humber. We'll be meeting up at exactly the same time, in exactly the same place, doing pretty much the same things. Only more so.

We're going to turn the group into a Community Interest Company CIC, which will make it possible for us to do even more interesting things, and give us a recognisable presence when dealing with companies and local bodies. 

For existing members the biggest change is that you can now find out about meetups and what we are doing by using the Connected Humber website. We'll be bidding fond farewell to the Meetup site that we've used in the past and we have a Slack channel for members of the group. Ping me a message if you want an invite, or turn up to the meetup this Thursday (16th August). 

We've lots of community activities planned, starting with a project to build a network of Air Quality sensors that we plan to deploy around the area. Exciting times.