AccuWeather API

First up in my series on weather APIs is the one from AccuWeather.

There are a few really great things about this API–or rather this set of APIs–but first let me tell you about the downsides. Accuweather doesn’t use a standardized system for locations so, as far as I can tell, there isn’t a way to simply input Lat/Lon coordinates. Instead your first stop on any journey has to be with their location finding API. Not only is this counter-intuitive, but since they only provide 40 free hits to their API a day, having to make regular checks for different locations could quickly eat up your allotment. Furthermore since forecast, current conditions, and indexes are all separate APIs, you are likely to be making a lot more calls than you would with a service like Darksky. I don’t mean to complain–after all they do offer access for free and 40 API calls is more than enough for the average hobbyist–but it seems stingy in comparison to most other services.

On the other hand, the API provides a superb data set that is easy to navigate and is clearly described in their documentation. Just take a look at their current conditions API which is well documented and includes all sorts of numbers that I didn’t even know were things–honestly did you know what “wet bulb temperature” was before reading that page? Similarly the forecast API offers things like pollen and air pollution information which must APIs lack.

Importantly AccuWeather does not suffer from the “disappearing metric” problem which plagues many APIs–more on this later.

The AccuWeather API may be right for you if your needs are limited to a single location and only a few updates a day. But if your location needs are more complex or want minute-by-minute updates. Also I think that AccuWeather only outputs to JSON, so if you are an XML head you are out of luck. For my particular use–graphing weather data for general interest and to compare to internal sensor data–AccuWeather works well and may come the closest to being an all-in-one solution. I just really wish that they supported more options for location input.

In my next post, I will share some example Python code which will show you how easy it is to get up and running with this API.

 

Advertisements

Evaluating Weather APIs

Many Internet-of-Things applications require knowledge of various environmental factors such as temperature, humidity, and light levels. While various sensors exist that fill this need locally–such as the ubiquitous DHT11/22 temperature and humidity sensor–sometimes an application requires broader weather data or just a sense of whether or not it is raining outside. Other applications might benefit from weather forecasts.

Thankfully the Internet provides us hobbyists and makers with a ton of APIs that provide weather data. Honestly the sheer volume of the APIs can be overwhelming. For a project that I’ve been playing around with–an indoor environmental monitoring system–I wanted some external data for comparison and worked with quite a few different APIs before I found the mix that worked for me. In the next few posts I’ll share my experiences and some sample code for working with each one.

But first here is a look at the contenders I will be evaluating

As a preview I’ve found that each has their pluses and minuses. Some provide lots of information, but have quirks in their API that make them annoying to use. Others lack data that seems essential. Ultimately–as I have cycles and bandwidth to spare–I combined all four in my final solution.

What people don’t get about MQTT

I’ve been spending a lot of time reading and responding to MQTT questions on Stackoverflow and I’m struck that the same basic misunderstandings keep coming up. I’m no expert on MQTT certainly (there’s a guy who posts under the handle hardlib who knows far more than me) but I do have experience in education–namely in breaking subjects down in a way that people without a broad knowledge base can understand–so I’m hoping that I can correct a few misconceptions with this post.

MQTT is a protocol, not a program

This seems to be the most fundamental misunderstanding. Many questions ask things like “how do I reply to MQTT messages” or “how can I edit MQTT messages on a server?” There are potentially meaningful answers to these questions but they all miss the fact that MQTT is simply a well defined and useful protocol. Upper-level considerations such as how an application responds to a message, how messages are retained on servers, and so on and so forth are all handled by the broker, publisher, and client–not by the MQTT specification itself. Therefore if you want to meaningfully ask a question about MQTT you must (generally) at least specify the broker you are using if not explain the entire ecosystem that you are building or using.

Indeed, if you have anything beyond a passing interest in MQTT you really should read the standard  which is superbly written and quite clear.

MQTT is not an instant messaging platform

Unfortunately Facebook’s use of MQTT seems to have suggested to every developer that MQTT is a person-to-person messaging standard. But it isn’t! MQTT is a machine-to-machine standard. This is an important distinction because MQTT was never designed to supply the kinds of things a messaging platform requires (message history, the ability to retract messages etc.). Now, as Facebook proves, you can use MQTT as the underlying communications protocol for a messaging platform or application but you will have to program all of the additional facilities that you require that go beyond the standard and a few niceties added by specific brokers. So asking about how to build an instant messaging application with MQTT is a bit like asking how to build a website that uses HTTP: it is a meaningful, but absurdly broad question.

MQTT topics do not exist without content

Probably the most common misunderstanding I see in questions revolves around the idea that MQTT topics exist without content. It is an easy mistake to make given that MQTT hierarchies look a lot like file paths or other familiar things. But MQTT just doesn’t work like that. Topics in MQTT are not indicators of a place or anything like that, they are simply routing instructions that the broker uses to move payloads from publishers to subscribers.

Here is an example that might clarify this a bit. Say you have a directory called /spam/eggs/ in which there is a file called payload. The full path of that file would be /spam/eggs/payload. In this case the directory /spam and /spam/eggs literally exist on your hard drive. However in the case of MQTT the equivalent statement /spam/eggs/payload simply tells the broker to send the message to all subscribers subscribed to #, / #, /spam/#, /spam/eggs/#, or /spam/eggs/payload. There are a few others that I left out for brevity, but you get the point. This distinction may not seem important, but I’ve seen it at the root of many false understandings of how MQTT works.

MQTT topics should not start with a /

To make the point above, I intentionally made a subtle mistake. Did you catch it? Adding the / to the front of the topic created an entirely unnecessary topical level. This is more of a pet peeve than a real problem, but I see people doing this constantly. The addition of this first topic level is not only unnecessary but, if you aren’t aware of it, it can lead to real confusion.

I hope this has been of use, and I’m more than willing to answer any questions or make any corrections necessary to these points. But while I’m writing, do you have anything that drives you crazy about how people understand MQTT?

 

 

 

MQTT Cookbook: Round-trip Time

Most MQTT brokers provide statistics on what they are doing (number of messages sent etc.) but do not provide meaningful information about how well the broker and client are performing. To gather that sort of information you need to consider the entire chain between the client and the broker. Although there may be several different ways to approach this, the simplest is to measure the round-trip time or RTT. In the case of MQTT that means measuring how long it takes from the publication of a message to its distribution to subscribers.

Thankfully the loose coupling between publishers and subscribers in MQTT allows the same client to be both. This allows us to measure the entire chain in a few lines of code.

import paho.mqtt.client as mqtt
from time import time, sleep
import uuid

INTERVAL = 1
QOS = 0


def on_connect(client, userdata, flags, rc):
    client.subscribe(topic)
    client.publish(topic, time(), qos=QOS)


def on_message(client, userdata, message):
    msg = message.payload.decode('utf-8')
    rtt = time() - float(msg)
    rtt_array.append(rtt)
    rtt_max = max(rtt_array)
    rtt_average = sum(rtt_array) / len(rtt_array)
    rtt_min = min(rtt_array)
    print('Current: %s' % rtt)
    print('Maximum: %s' % rtt_max)
    print('Average: %s' % rtt_average)
    print('Minimum: %s' % rtt_min)
    sleep(INTERVAL)
    client.publish(topic, time(), qos=QOS)


def on_log(client, userdata, level, buf):
    print(level, buf)


rtt_array = []
topic = str(uuid.uuid4())
client = mqtt.Client()
client.on_connect = on_connect
client.on_message = on_message
client.on_log = on_log
client.connect("test.mosquitto.org")
client.loop_forever()

 

The script might seem a bit odd unless you understand how the call backs are structured in MQTT. The program flow goes something like this:

  1. The client connects to the broker triggering on_connect
  2. The client subscribes to the randomly determined topic
  3. The client publishes to the randomly determined topic
  4. The reception of the message that the client published triggers the on_message callback.
  5. The payload of the message is the time the message was sent which is then compared to the current time to get the RTT
  6. The RTT is added to the list rtt_array and used to calculate average, maximum, and minimum.
  7. After sleeping for INTERVAL seconds, a new message is published to the the topic returning the script to step 3.

As this script runs indefinitely you will have to break it manually by hitting CTRL+C. Also, the preset interval is pretty short (1 second), you will likely want to extend that to 10 or 60 if you are running this for more than a short burst.

Right now the script is configured to connect to the test.mosquitto.org server but it can easily be adapted to connect to your local broker.

Another interesting use of this script is that it makes it simple to test the performance consequences of using higher QoS settings. I notice around a 50% performance hit at QoS 2.

That’s pretty much it. If anyone has suggestions about how to improve it, tell me about them in the comments.

MQTT Cookbook: Thingspeak to MQTT

One of the most common problems in IoT is the need to bridge between two different infrastructures. It is a long story, but I ran into a situation where I needed to bridge a pre-existing ESP8266 connected to Thingspeak with my broader MQTT network. Thankfully, hacking together a quick bridge between the two services proved fairly easy.

import requests
import paho.mqtt.client as mqtt

CHANNEL =
API = ""

def get_thingspeak_field(channel, api, field):
    _url = 'https://api.thingspeak.com/channels/%s/fields/%s.json?api_key=%s&results=1' % (channel, field, api)
    _r = requests.get(_url).json()
    return _r['feeds'][0]['field%s' % field]


def on_connect(client, userdata, flags, rc):
    client.publish('thingspeak/field1', field1)
    client.publish('thingspeak/field2', field2)
    client.disconnect()


def on_log(client, userdata, level, buf):
    print(level, buf)


field1 = get_thingspeak_field(CHANNEL, API, 1)
field2 = get_thingspeak_field(CHANNEL, API, 2)
client = mqtt.Client()
client.on_connect = on_connect
client.on_log = on_log
client.connect("test.mosquitto.org", 1883, 60)
client.loop_forever()

 

The code is fairly self-explanatory but lets walk through it. There is a Thingspeak library for Python but it is actually easier to just import requests and make a standard API request. To facilitate this I wrote a simple function which takes the channel, api key, and the field that you want to read. After reading the fields it connects to an MQTT broker–currently the Mosquitto test broker–and publishes the fields.

Simple as that! Now you can hook your Thingspeak and MQTT infrastructures together in any way you want.

MQTT Cookbook: Logging Activity

It’s been a while since I actually posted here. Between finishing my Ph.D., the frustrations of the academic job market, and working on my book, I haven’t had nearly as much time for hobbies. But I have recently been learning about MQTT and have decided to post some simple “recipe” style Python scripts that would have helped me when I was just starting out.

The first script was inspired by the sudden upsurge of questions on Stack Exchange (such as this one and this one) which deal with logging activity on an MQTT topic. Since Mosquitto (and most other brokers) do not include a database to store messages, you have to implement logging on top of MQTT.

The simplest way to do this is simply to print the output of a topic to a text file. For testing purposes I am using the Mosquitto test broker and a few of the server’s internal metrics.

Continue reading “MQTT Cookbook: Logging Activity”

Cool ESP8266 Display Project

Saw this over on Hackaday. Pretty nifty way to cheaply create an Internet-connected screen anywhere. I want dozens of them! Wish that they would put it out in kit form though, SMD and me are not always on friendly terms…

Anyone have an even cheaper, easier way of rigging up a wifi display (maybe just an LCD) with an ESP8266?