{"id":2974,"date":"2016-06-12T11:17:56","date_gmt":"2016-06-12T17:17:56","guid":{"rendered":"http:\/\/dev.iachieved.it\/iachievedit\/?p=2974"},"modified":"2020-04-18T13:31:35","modified_gmt":"2020-04-18T18:31:35","slug":"mqtt-with-swift-on-linux","status":"publish","type":"post","link":"https:\/\/dev.iachieved.it\/iachievedit\/mqtt-with-swift-on-linux\/","title":{"rendered":"MQTT Clients With Swift on Linux"},"content":{"rendered":"

\"Swift \"Swift<\/p>\n

Over the past few years I’ve made a living managing Internet of Things<\/a> (IoT) software development projects. In that time I’ve come to learn a number of protocols for communicating sensor and telemetry information back to “the cloud”. Among the most popular in the IoT space is MQTT<\/a>, a lightweight protocol that allows for publishing messages to topics<\/i>, as well as the ability to subscribe<\/i> to topics. This model is frequently refer to as “pub-sub<\/a>“.<\/p>\n

In addition to working with IoT and MQTT, I am passionate about Swift<\/b><\/a> and the inroads it is making into the server space since being open-sourced and ported to Linux. Naturally it made sense to combine the two areas and start working on an MQTT client implementation in Swift! We’ve taken the liberty to port an iOS implementation of an MQTT client<\/a> over to Swift 3.0 on a Linux platform. In general this is an example that, indeed, Swift will be making inroads into both the server and IoT domains.<\/p>\n

A disclaimer before we get started: the code below is based upon Swift 3.0 which is going through developer previews on Linux right now. To get started with Swift 3.0 on your Ubuntu 14.04 or 15.10 system go here<\/a>. Or, if you have an armv7 device such as BeagleBone Black, try the ARM port<\/a> of Swift 3.0!<\/p>\n

Sample Application<\/h2>\n

My first idea was to put together a cool BeagleBone MQTT client that was reading one of the ADC inputs and sending it up to the broker. The input was going<\/i> to be from a Microchip MCP9700<\/a> temperature sensor IC. The sensor IC maximum output voltage is 5.5V so I knew a voltage divider would be involved to keep the voltage input to the BeagleBone under 1.8V. I had the voltage divider all sketched out and everything!<\/p>\n

\"Don't<\/a>
Don’t Want to Blow Up the BeagleBone!<\/figcaption><\/figure>\n

Unfortunately while testing the sensor IC with a standard match I got the flame a little too close to the IC package and well, Project Icarus<\/a> came to an end. Our replacement example is a bit less ambitious, but serves the role of learning how to build an MQTT client with Swift. And it doesn’t involve matches.<\/p>\n

MQTT<\/h2>\n

Our application is built around a port of a client MQTT library (yay open source!). We’ve named it simply MQTT and posted it to GitHub<\/a>. The library is meant to be used in a Swift application that you can create as follows:<\/p>\n

\nmkdir PubSysTemp\ncd PubSysTemp\nswift package init --type executable\n<\/pre>\n
Running swift package init --type executable<\/code> is going to give you a Swift project shell (think npm init<\/code>) that you can begin customizing for your purposes.  We’re going to edit Package.swift<\/code> and add our MQTT library dependency:<\/p>\n
\nimport PackageDescription\nlet package = Package(\n  name: \"PubSysTemp\",\n  dependencies:[\n    .Package(url:\"https:\/\/github.com\/iachievedit\/MQTT\", majorVersion:0, minor:1)\n  ]\n)\n<\/pre>\n
MQTT Client Delegate<\/h3>\n
The design of the MQTT library is such that you will create a client class that inherits from MQTT<\/code> and MQTTDelegate<\/code>.  A very basic implementation looks like this:<\/p>\n
\nimport Foundation\nimport MQTT\n\nclass Client:MQTT, MQTTDelegate {\n  \n  init(clientId:String) {\n    super.init(clientId:clientId)\n    super.delegate = self\n  }\n  \n  func mqtt(mqtt: MQTT, didConnect host: String, port: Int) {\n  }\n  \n  func mqtt(mqtt: MQTT, didConnectAck ack: MQTTConnAck) {\n  }\n  \n  func mqtt(mqtt: MQTT, didPublishMessage message: MQTTMessage, id: UInt16) {\n  }\n  \n  func mqtt(mqtt: MQTT, didPublishAck id: UInt16) {\n  }\n  \n  func mqtt(mqtt: MQTT, didReceiveMessage message: MQTTMessage, id: UInt16 ) {\n  }\n  \n  func mqtt(mqtt: MQTT, didSubscribeTopic topic: String) {\n  }\n  \n  func mqtt(mqtt: MQTT, didUnsubscribeTopic topic: String) {\n  }\n  \n  func mqttDidPing(mqtt: MQTT) {\n  }\n  \n  func mqttDidReceivePong(mqtt: MQTT) {\n  }\n  \n  func mqttDidDisconnect(mqtt: MQTT, withError err: NSError?) {\n  }\n}\n<\/pre>\n
As you can probably guess the functions above are delegate methods that are called when the underlying MQTT client connects, publishes a message, subscribes to a topic, etc.  It is up to you, the client writer, to fill out the implementation to suit your needs.  In our case we’re going to implement the mqttDidDisconnect<\/code> method as follows:<\/p>\n
\nfunc mqttDidDisconnect(mqtt: MQTT, withError err: NSError?) {\n  NSNotificationCenter.defaultCenter().postNotificationName(\"DisconnectedNotification\",object:nil)\n}\n<\/pre>\n
I’ve mentioned in previous posts that I appreciate the flexibility of posting a notification and having it acted upon by whoever was listening for it.  DisconnectedNotification<\/code> will be handled in our main.swift<\/code> routine.<\/p>\n
main.swift<\/h3>\n
Let’s turn our attention to main.swift<\/code> which will instantiate an MQTT<\/code>-based client.  At a fundamental level here is all that’s required:<\/p>\n
\nlet client = Client(clientId:\"a-client-id\")\nclient.host = \"broker.hivemq.com\"\nclient.connect()\nclient.publish(topic:\"\/my\/topic\", withString:\"my string\")\n<\/pre>\n
We want our client to be a bit more robust, so we’ll add in the ability to automatically reconnect if our connection is dropped by doing something like this:<\/p>\n
\n_ = NSNotificationCenter.defaultCenter().addObserverForName(\"DisconnectedNotification\",\n                                                            object:nil, queue:nil){_ in\n  guard client.connect() else {\n    print(\"Unable to connect to broker\")\n    exit(-1)\n  }\n}\n<\/pre>\n
Now, one could argue that we don’t want to exit<\/code> if the connection to the broker fails.  What we could<\/i> do is set a timer and then rebroadcast our DisconnectedNotification<\/code>.  This will be our approach in the working code detailed further below.<\/p>\n
We should publish something useful to the broker, so let’s set up an NSTimer<\/code> to wake up every ten seconds and obtain the CPU temperature and then post that.<\/p>\n
\nlet reportInterval    = 10\nlet reportTemperature = NSTimer.scheduledTimer(NSTimeInterval(reportInterval), repeats:true){_ in\n  if let cpuTemperature = CPU().temperature {\n  _ = client.publish(topic:\"\/(client.clientId)\/cpu\/temperature\/value\", withString:String(cpuTemperature))\n  }\n}\nreportTemperature.fire()\nNSRunLoop.currentRunLoop().addTimer(reportTemperature, forMode:NSDefaultRunLoopMode)\nNSRunLoop.currentRunLoop().run()\n<\/pre>\n
It should be noted here that we set the timer up and then fire()<\/code> it immediately (so we’re not waiting ten seconds for that first post).  Also, you will notice that we’re posting to the topic \/<i>clientid<\/i>\/cpu\/temperature\/value<\/code>.  This is one example of an MQTT topic naming convention<\/a> and meant strictly as such.  As you delve further into designing IoT applications it will become apparent that your naming convention is of considerable importance.<\/p>\n
Getting the CPU Temperature<\/h3>\n
I love working with Linux and the wealth of information that is available in the \/sys<\/code> and \/proc<\/code> filesystems.  Unfortunately when you’re dealing with hardware you have to frequently tailor your code to the specific hardware it’s running on.  For example, on my x86 server the temperature of the CPU can be obtained by reading \/sys\/class\/hwmon\/hwmon0\/temp1_input<\/code>.  On the BeagleBoard X15 it is at \/sys\/class\/hwmon\/hwmon1\/temp1_input<\/code>.  That’s aggravating.<\/p>\n
We won’t bother with writing portable code for now, but you should be able to take this example and suit it to your own system’s needs:<\/p>\n
\nstruct CPU {\n  var temperature:Double? {\n    get {\n      let BUFSIZE = 16\n      let pp      = popen(\"cat \/sys\/class\/hwmon\/hwmon0\/temp1_input\", \"r\")\n      var buf     = [CChar](repeating:0, count:BUFSIZE)\n      guard fgets(&buf, Int32(BUFSIZE), pp) != nil else {\n        pclose(pp)\n        return nil\n      }\n      pclose(pp)\n\n      let s = String(String(cString:buf).characters.dropLast())\n      if let t = Double(s) {\n        return t\/1000\n      } else {\n        return nil\n      }\n    }\n  }\n}\n<\/pre>\n
Putting it All Together<\/h2>\n
Let’s put everything together to build a working MQTT client that posts our CPU temperature to broker.hivemq.com<\/code>.  As a bonus, we’ll provide a web page that shows the CPU temperature displayed as a gauge.<\/p>\n
We have three files that make up our client:<\/p>\n