Six Colors
Six Colors

by Jason Snell & Dan Moren

Support this Site

Become a Six Colors member to read exclusive posts, get our weekly podcast, join our community, and more!

By Dan Moren

Putting Netatmo weather on the menu

If there’s two things that we here at Six Colors love, it’s putting data in our Macs’ menu bars and the weather—also, of course, combining those two things.

Netatmo Weather menu

Following Jason’s previous excursions into adding weather info to his menu bar, I decided to embark upon a similar task with my recently acquired Netatmo weather station and our perennial favorite menu bar utility, SwiftBar.

Netatmo provides an API to let you retrieve data from its weather stations, and its documentation page even allows you to test it out with your own device (you’ll need to log in to your Netatmo account first).

The standard Netatmo system is composed of two modules: one that sits inside your house and one that goes outside. I was more interested in the outside temperature, though I may adapt it in the future to provide information from both. However, the outside module collects relatively little information: just temperature and humidity.1 (The inside module, by comparison, also measures noise and CO2 levels.)

Writing the script itself proved to be fairly straightforward; it was largely built on a similar script that I’d made to display the current UV level. Like many APIs, Netatmo’s can be accessed using a variety of programming or scripting languages. Data is returned in JSON format, allowing you to pick out the specific information you want.

But the real challenge came in dealing with authentication. The example code shown on the API page includes an authorization token…but that token is only temporary. Netatmo uses a framework called OAuth, which not only requires a more complex process to obtain an authorization token, but also provides tokens that expire after a certain amount of time. So I couldn’t simply hardcode in the tokens used in the example page—instead, I had to add code to request a token.2

Once I had the script working, I added a few additional refinements. In addition to the current temperature, the Netatmo API provides information about the temperature trend, in terms of whether it’s going up, down, or is stable; this is reflected in my script by an up arrow or down arrow next to the temperature (I opted to show nothing if the trend is stable, for simplicity).

I also added a battery level gauge, including a handy icon to show you if it’s good (above 50 percent), moderate (between 10 percent and 50 percent), or low (10 percent or lower). And since the data from the module refreshes every 10 minutes, I added a timestamp to say when it was last updated.3

Finally, I used SwiftBar’s link feature so that if you select any of the information from the dropdown portion of the menu, it will take you to your Netatmo web dashboard, which includes historical data and other metrics (mostly gathered from sources other than your weather station).

I may continue to refine this over time, but for the moment, I’m making it available for download, with the following configuration information.

Configuration

Note that this script is written in PHP, which I believe is no longer included in the operating system as of macOS Monterey, so you’ll need to install it via Homebrew. Also note that Homebrew installs on different locations whether you’re using an Apple or Intel processor; this version of the script expects PHP in /opt/homebrew/bin/php, which is the default installation location on Apple silicon.4

You’ll need a handful of details to configure the script, including the username and password for your Netatmo account, and your module’s MAC address (probably easiest to obtain via your Wi-Fi router).

In addition, you’ll also need to create an application via Netatmo’s developer page. Once you do, it will provide you with two key pieces of information: a client ID (a string of static characters identifying your app), and a client secret (essentially a password). These two pieces of information are used to retrieve the authorization token, as described above.

Once you’ve entered your information in the script, drop it in your SwiftBar plugin folder, and it ought to retrieve the necessary info.

Note that the script is being provided as is for your entertainment; I welcome feedback, but I can’t necessarily accommodate troubleshooting requests for particular setups. Best of luck, and enjoy!


  1. Somewhat confusingly, the API page claims that the outdoor module also monitors pressure, however, in practice that information only seems to be returned by the indoor module? I’m not sure how significant the difference would be, but I haven’t yet bothered to add support for it in the script. 
  2. As a result, my system requests a token every time the script refreshes—which works, but actual web developers will know isn’t really how the system was designed. In theory, it should use a different refresh token to request a new authorization token when the earlier one expires, but that would require caching persistent information on disk, and, as far as I can tell, SwiftBar’s plugin architecture isn’t really designed for that. 
  3. This ended up being weirdly complex, thanks to the fun that is timezones. 
  4. If you’re running on Intel, this should probably be /usr/local/bin/php instead, but you can clarify by running the command which php in Terminal and using the resulting path. 

[Dan Moren is the East Coast Bureau Chief of Six Colors. You can find him on Twitter at @dmoren or reach him by email at dan@sixcolors.com. His latest novel, The Aleph Extraction, is out now and available in fine book stores everywhere, so be sure to pick up a copy.]

If you appreciate articles like this one, support us by becoming a Six Colors subscriber. Subscribers get access to an exclusive podcast, members-only stories, and a special community.


Search Six Colors