In summer 2020, I picked up a WeatherFlow Tempest station...a purchase I'd been considering for the better part of a year. It's an awesome and compact little thing, and on the whole I've been super happy with it. In my location it tends to over-report rainfall as the haptic rain sensor is also sensitive to vibrations on the mounting point (a pole in my yard). I've done about as much as I can to stabilize the mount point, but as I am a long-standing CoCoRaHS participant I don't actually find the rain sensor to be a big deal since I'm taking daily measurements with a trusted device.
I could go on about features of Tempest, but my favorites include (in no particular order):
- It has an API;
- The lightning detection;
- Sonic wind detection/anemometer;
- Totally solar powered for ease of siting; and
- The Android (and web) app is pretty cool.
What's This Series About?
Over the course of this and the next 3 posts I will walk through various aspects of the project over the next several weeks. If you're interested in "skipping ahead" to the final/current product, though, the Slack Tempest WeatherBot landing site (or the Github repo for the project) are both publicly available to peruse or clone.
Extending the Tempest
For the first several months, I quite happily rolled with the default features, some of which are shown above. As I reached my normal "Christmas break" time away from work, I was thinking about fun and random projects to develop for grins. Since Tempest has an API...I thought about building a Slack "bot" to interact with the station...basically as a way I (or others in the Slack workspace) could interact with the station or ask it questions.
So it came to be...playing with the API.
Getting Started
I chose Slack as the "host" of the Bot...mostly because I had previous experience playing around with Slack's webhooks which also granted me basic access to other "bot account" functionality like Slack Blocks and the Slack API. I don't intend to go too deep into the Slack-side details in this series because, with the exception of the messaging blocks, the rest of the WeatherBot source could be used from other systems (including a web app).
The Tempest API is pretty well-documented, and it was easy to get started as a device owner. There are considerations about fair use and remote data access (namely that basic access is intended for personal use by the device owner). This wasn't a problem for me since the system and integration is for a private Slack workspace and totally for my own nerdy/hobbyist purposes.
Once I had an API token, it was time to get building! As I have a couple of personal LAMP hosts out on the Internet, I would use one of them for my production instance, but used WSL and VSCode as my dev environment. Everything is written in PHP because it's easily portable between all of these places and doesn't require any additional libraries.
Implementing the Basic Calls
The Tempest API (specifically REST) really doesn't have many endpoints so everything starts with basic station metadata. You need the device and/or station ID to do anything with the observation or forecast endpoints. I made the preliminary and exploratory calls both with the Swagger content and later in Postman. These steps ensured I was making proper calls with the correct syntax/data, and Postman gave me an easy way to generate the proper cURL request code. These details live in the TempestAPIFunctions.php
source file, along with the functions to get observations and forecast data provided by the API.
Building a Real Thing
Once I had those basic functions in place, the question was then how to translate from Slack, grab data from Tempest, and respond in Slack. The original design was to simply use a slash command (e.g. /weather
) in Slack to ask a curated question such as /weather now
or /weather yesterday
or /weather next 8 hours
.
With Slack, a slash command is just a POST action to some receiver on the Internet. In my case, there's a specific web-accessible request handler to receive the POST, do basic validation to ensure an "authorized" user made the request, and then generate the proper Tempest API call (along with other details), forming the response parameters to send back to Slack.
Those response details are then formatted accordingly, and pushed back with a SlackPost
call. This is all intended to wrap up in a few seconds from the originating request.
There are obviously several significant details I've omitted here, but the gist is that over the course of a few hours I had a mechanism to handle a couple of arguments from Slack, grab the proper data from Tempest, and ping that data back to Slack!
Expanding to Support more Options
Over the following days I focused on adding options/arguments to the slash command. The vast majority of the commands available in the help documentation were developed and fine-tuned. This also involved handling all of the weird stuff contributing to how Date Math is Gross...though less about timezones and more about translating the human-friendly "next" and "last" values into numeric and logical values. By the time of the first real release about three weeks later, the WeatherBot was a functional thing that I would use often.
Coming Up: Adding Slack Features for Interactivity
The next post outlines features I added to make Slack interactivity more user-friendly, along with a major code cleanup of the Tempest observation process.
Headline image via WeatherFlow Tempest product page