Amazon AWS recently released the IOT service, a utility for lightweight devices to create and consume messages on the internet, and also in the case of AWS to leverage the rest of their feature set, such as Kinesis, Lambda, S3, DynamoDB, etc.
Of course, I didn’t fancy using the AWS SDK to do this. I just wanted to get mosquitto_pub and mosquitto_sub working on the command line, so see how easy it would be to get plain old MQTT working with it. It’s not that difficult.
First off, create a working directory, and download the root CA file for your client to use
wget https://www.symantec.com/content/en/us/enterprise/verisign/roots/VeriSign-Class%203-Public-Primary-Certification-Authority-G5.pem -O rootCA.pem
Now that you have the root certificate, head to the AWS IOT console, sign up or sign in, and click on the “Create a Resource”, and then the “Create a thing” button. Give it a name, and optional attributes, and hit “Create”. Once the page loads, you can now select your new “Thing” and aim for the “Connect a Device” button. You can then choose which SDK to use. That’s up to you, but after you select it and hit the “Generate Certificate and Policy” button you will be invited to download three files – public and private keys, and a cert. Do so, save them in your working directory, and also somewhere safe if you plan on deleting the directory later. You can’t download them again.
Now you have to ascertain what your broker endpoint is. The AWS IOT UI isn’t the clearest on this, but it’s helpfully hidden inside the parameter “REST API Endpoint”. You’ll need to select a thing from the console, and it appears at the top right. It’s just the domain part of the REST endpoint, so “https://A2HAT5HHRF2IFT.iot.eu-west-1.amazonaws.com/things/KyleG_Test/shadow” becomes A2HAT5HHRF2IFT.iot.eu-west-1.amazonaws.com
Once you have that information, and have the certificate files in place, it’s a simple case of passing some SSL options to the mosquitto client tools.
mosquitto_pub –cafile rootCA.pem –cert dec39df945-certificate.pem.crt –key dec39df945-private.pem.key -h A2HAT5HHRF2IFT.iot.eu-west-1.amazonaws.com -p 8883 -q 1 -d -t ‘$aws/things/KyleG_Desktop/shadow/update’ -m ‘testing’
At work we’re pretty heavily firewalled. This means that outbound requests on funny ports are often firewalled off, and systems that rely on such ports will time out.
One such system that is commonly used yet inaccessible is the GPG SKS port 11371. And many many Linux things use GPG!
What got me looking was the common command to import a key, in this case for Spotify.
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 94558F59
It will time out and fail to import the key, subsequently causing your apt-get operations to fail. A quick update to the command cures it. You *have* to specify hkp:// and :80
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 94558F59
Success! You can also apply the same changes to your default keyservers in ~/.gnupg/gpg.conf
I’ve had a Psion Wavefinder for a while now, and it’s never really worked that well due to the rather bad combination of poorly written amateur radio related software, out of date build environments (see the previous argument), and the fact that most amateur radio enthusiasts seem to use Windows (see the first argument again)
OpenDAB has been around for a while, and it certainly seems promising. However, although it’s not an absolute requirement, the use of DAB+ is preferable, and that subsequently requires Phil Karns FEC library.
Now Phil Karn might be a genius, but he doesn’t reply to emails, and nor does he keep his build environment or OS up to date. FEC 3.0.1 is now over 4 years, doesn’t compile with modern GCC versions, and requires some massaging to make work.
Firstly, GCC no longer allows labels at the end of compound statements. This screws up dotprod.c
Next, well, I dunno what’s going on. ld chucks its guts up at the end of the build on x64 (how long has x64 been around for now?), and suggests using -fPIC. So, makefile.in was tweaked to include -fPIC in CFLAGS
I believe -m32 will do the job too, so that it’s built for x86, but hey, this works. If anyone wishes to elaborate on the pros and cons of Position Independent Code vs x86 on x64 then comment away.
In addition to this, OpenDAB supplied a patch to be applied to fec.h, as described in their documentation.
Anyway, to make life easier I created a patch. This includes the OpenDAB patch, my own patch, and a patch found at http://mmbtools.crc.ca/component/option,com_fireboard/Itemid,55/func,view/catid,7/id,178/
Just untar the standard fec-3.0.1 package, cd into it, and patch it as below. A handy one liner is also evident on this example.
bagpuss@mine:~/src/WaveFinder/fec $ wget –quiet http://ka9q.net/code/fec/fec-3.0.1.tar.bz2 ; wget –quiet http://lodge.glasgownet.com/bitsnbobs/kg_fec-3.0.1.patch ; tar -xjf fec-3.0.1.tar.bz2 ; cd fec-3.0.1/ ; patch < ../kg_fec-3.0.1.patch patching file configure patching file cpu_mode_port.c patching file dotprod.c patching file fec.h patching file makefile.in bagpuss@mine:~/src/WaveFinder/fec/fec-3.0.1 $
Once patched, ./configure && make && make install should have FEC up and running, and ready for OpenDAB. I have it working here on my trusty x64 Ubuntu 11.04 (actually it’s Mint 11) desktop.
One day to go before Christmas, and the UK government have made an astounding contribution to the OpenStreetMap project. It will shortly be announced that through collaboration with the Department for Transport, Traveline, and OpenStreetMap, most of the NaPTAN and NPTG datasets will be offered to OpenStreetMap as a one off bulk import, with the possibility of updates in the future.
This means the import of up to 350,000 geocoded public transport access points, such as bus stops, ferry terminals, trains stations, etc, along with the import of up to 50,000 geocoded place names in a hierarchical format.
Once again, a big thank you to the DfT and Traveline for this massive contribution, and to the OSM Foundation for making it all possible.