DEV Community: Tom Markiewicz

How to use Weather Company Data and Netatmo with Ruby

Tom Markiewicz — Fri, 15 Mar 2019 17:08:26 +0000

While weather insights are critical to many businesses, local weather data on a more personal and practical level can be important as well. Since I recently moved to an area with some pretty extreme weather, I find myself monitoring and measuring the local conditions much more than I used to. And with wind gusts that regularly exceed 50mph in the winter, this isn’t just an academic interest. Safety (both personal and property) is a significant concern.

In addition to the wind, I’m a skier, so I’m always interested in the amount of snow in the forecast. For some reason, this isn’t often displayed in most popular weather apps at a glance, so I was interested in building something simple to track my local weather as well as the forecast tailored to my interests.

To monitor the weather, a recent addition to my home was the Netatmo Smart Home Weather Station with a wind gauge module. While Netatmo provides an app and web dashboard to view all your data, it’s a bit much at times, especially when there are only a couple measurements I’m interested in monitoring. You can see a demo app of their dashboard here. Additionally, they offer excellent integration with Alexa and IFTTT so that you can incorporate your weather monitoring into a home automation system.

As my neighbor regularly texts me to find out what the station is measuring for the wind gusts on particularly bad evenings (hey, get your own!), I thought it would be interesting to explore my recorded data using the Netatmo API as well as examining at how it corresponds to an accurate weather API with a forecast.

There are numerous popular weather data APIs available for free or low cost, but since IBM owns the Weather Company, I figured this would be a logical place to start and be an interesting way to experiment with their weather data.

IBM bought the Weather Company in 2016 and offers its weather data as an API available through the IBM Cloud. From IBM:

The Weather Company, an IBM Business, delivers personalized, actionable insights to consumers and businesses across the globe by combining the world’s most accurate weather data with industry-leading AI, Internet of Things (IoT) and analytics technologies.

Our solutions provide newscasters, pilots, energy traders, insurance agents, state employees, retail managers and more with insight into weather’s impact on their businesses, helping them make smarter decisions to improve safety, reduce costs and drive revenue.

The Weather Company API provides a ton of data including an hourly forecast, daily forecast, intraday forecast, current conditions, historical data, weather alerts, location services, and almanac services.

Here, I’ll only be using the 3-day forecast, but the API offers a daily forecast for each of the next 3, 5, 7, or 10 days starting from the current day, including forecasts for the daytime and nighttime segments.

As far as pricing, on a free plan you get 10 API calls per minute and then 10,000 calls total per account. So the free plan isn’t free forever, and once you hit the 10,000 call limit, you’ll have to start paying. But this is more than enough for testing, prototypes, and hobby projects.

For this article, I’ll be illustrating how to use Ruby to make access and parse the data from both APIs. In a future article, I’ll examine building a basic dashboard to monitor the data you’re interested in on the web (and in my case stop my neighbor from asking me!).

To follow along with the entire demo though, you’ll need an actual Netatmo device and account as they don’t offer any demo keys, products, or a sandbox.

The full tutorial walkthrough and repo can be found on Github here: https://github.com/tmarkiewicz/weather-ruby and I’ll highlight some of the key steps below.

Initial setup

As you can see from the tutorial repo, I’m using Ruby on a Mac. OS X comes installed with Ruby, but you can check your version using this command:

ruby -v

If you want to upgrade (or install multiple versions of Ruby), I recommend using the Ruby Version Manager (RVM).

The next step is to clone the repo from Github and then run the bundler:

$ git clone https://github.com/tmarkiewicz/weather-ruby
$ cd weather-ruby

Then you’ll need to install the required Ruby gems using the Bundler Ruby gem:

$ gem install bundler
$ bundle install

The tutorial code samples in Ruby can be run from the command line via this syntax:

$ ruby filename.rb

The next two sections outline how to use the tutorial for both Weather Company Data and then Netatmo.

Weather Company

To access the Weather Company Data API, you’ll need an account on the IBM Cloud. My tutorial outlines the process in detail, but the necessary steps are:

sign up (or sign in) for the IBM Cloud
add the Weather Company Data as a new service
select the free plan
select add credentials, then view the credentials’ JSON
add these credentials to a .env file in the app directory

As a side note, there’s a great guide to using environment variables in Ruby here. In the tutorial, I also use this Ruby gem: https://github.com/bkeepers/dotenv

The next step is to make a test API call. I like to always start with curl or the Postman app to test any API credentials, the construction of the API endpoint, and of course the results:

From the Weather Company Data API docs, we can build the URL to make a request to retrieve the 3-day forecast for a specific latitude and longitude like this:

https://twcservice.mybluemix.net/api/weather/v1/geocode/40.014984/-105.270546/forecast/daily/3day.json

In the URL above, replace the latitude/longitude with those of the location you’d like to retrieve weather data. An excellent site to find your latitude and longitude can be found at LatLong.net.

Now that we have all the requirements, we can run the main file from the command line:

$ ruby weather-company.rb

And the output will look like this:

Forecast for Friday, February 22, 2019:
Periods of snow. Lows overnight in the upper teens.
1 to 3 inches of snow expected.
Snow this evening will give way to lingering snow showers late. Low 19F. Winds light and variable. Chance of snow 80%. Snow accumulating 1 to 3 inches.

Netatmo

As I mentioned above, this part of the tutorial is only available if you already have one or more Netatmo devices. If you’re looking at a full featured weather station with API access, I highly recommend their system as it’s pretty affordable for all the features provided.

Photo via Netatmo: Masaki Okumura, Marion Leflour, and Fred Raynaud

That said, you can still follow along with the remainder of this demo and if/when you get a Netatmo device you’ll know where to go for some step-by-step instructions.

One caveat on the data from Netatmo devices: they unfortunately only send measurements to the servers every ten minutes. From the Netatmo API docs:

Do not try to pull data every minute. Netatmo Weather Station sends its measures to the server every ten minutes. Get the last measures from all the devices of one user with the Getstationsdata method.

So while I’d much rather have some data much more frequently (wind speed and gusts come to mind), we have to work with what the company gives us in this case. Inconvenient for building a weather app, but not a dealbreaker.

As with the Weather Company section, the full steps for setting up the Netatmo API are in the Github repo, but the basic steps are as follows:

if you already haven’t, create a user account with Netatmo
sign up for a developer account
create a new application
copy the credentials for the new app

Once you’ve added the client id and client secret credentials to the .env file, you can then run the Netatmo file from the command line:

$ ruby netatmo.rb

The output will look like this:

Time: 2019-03-12 14:19:50 -0600
Temperature: 50 deg F
Humidity: 45%

And that’s it! A quick and easy to way get access to local weather data and forecasts.

Summary

While this is an introductory tutorial on to how to access weather data via the Weather Company and Netatmo, it’s not accessible outside running locally on your machine. In a future article, I’ll show how to quickly take this data and deploy it to an actual application. Once that’s done, my neighbor will be happy and possibly stop texting me for wind updates!

And if you're interested in using weather data with a mobile app, take a look at this tutorial on how to create a mobile app with weather forecasting. Additionally, take a look at using a serverless approach to Weather Underground data.

Build a cross-platform mobile app using React Native

Tom Markiewicz — Tue, 05 Mar 2019 00:00:00 +0000

As part of my developer advocacy efforts at IBM, I often build and share demos to showcase our products and how developers can integrate them into their own applications.

The IBM Developer site provides a wealth of resources for developers with a focus on code, content, and community. And code patterns are our way of providing full solutions to common problems that developers regularly face in their work. These code patterns “leverage multiple technologies to solve issues that our developer advocates have recognized as common use cases across multiple industries.”

I recently finished a new code pattern that shows how to create a cross-platform mobile application using React Native framework.

The pattern I built uses Watson Discovery News and React Native to build a cross-platform mobile app that fetches recent news for a specific company. React Native is a JavaScript framework that lets you write mobile apps for iOS and Android. The application uses Watson Discovery News to fetch recent and relevant news articles along with sentiment, keywords, and related concepts. Easily customizable, this demo app provides a convenient starting point to use Watson Discovery in your own React Native applications. Instead of learning Swift, Java, or Kotlin to build native mobile applications, you can quickly create apps using your JavaScript knowledge.

React Native uses the same design as React, letting you compose a rich mobile UI from declarative components. For an excellent overview on React Native and building mobile apps using only JavaScript, take a look at the article Dissecting React Native. If you’re interested in diving deeper into React Native, I highly recommend the Udemy course The Complete React Native and Redux Course by Stephen Grider.

If you’re unfamiliar with the service, IBM Watson Discovery is a cognitive search and content analytics engine for applications to identify patterns, trends, and actionable insights. Using Discovery, developers can extract meta-data from returned content such as concepts, keywords, and sentiment using natural language understanding. Watson Discovery News is an indexed dataset that is pre-enriched with natural language processing (NLP) features such as keywords, entities, semantic roles, sentiment, relations, and category classification. So instead of using two products (Watson Discovery and Natural Language Understanding), a developer can make a single API to get combined results.

It’s easy to get started and try the application, even if you have no JavaScript expertise. Just clone the repo, sign up for a free IBM Cloud account, and then update the Discovery credentials with your own. You can have your own cross-platform mobile news app running in minutes.

You can find the full repo on Github here. If you use this as a starting point for your application, please let me know!

Originally published at tmarkiewicz.com on March 5, 2019.

RubyMotion versus Swift for iOS Development

Tom Markiewicz — Mon, 26 Nov 2018 00:00:00 +0000

As I worked on the IBM Watson and Apple Core ML partnership, I was inspired to explore more ways to showcase machine learning for developers in different ways. One of my ideas was to look into using RubyMotion with IBM Watson.

If you’re not familiar, RubyMotion lets developers quickly write cross-platform native apps for iOS, Android, and OS X using the Ruby programming language. The applications are statically compiled and then call into the native platform APIs.

As a Rubyist, when RubyMotion was first released in 2012, I was pretty excited. I had wanted to explore developing apps for iOS, but Objective-C was not clicking for me, and it can be a challenging language to learn. So when Swift arrived, this fundamentally changed the equation as it was now much easier to get started developing for iOS. Swift for many developers was much easier to use while still as powerful.

The rapid advancement of Swift as the primary language for iOS development has significantly reduced the need as well as the appeal to write iOS applications in Ruby. At this point, it seems the main benefit would be a write-once approach to get iOS and Android support. However, at this point, there are much more popular and widely supported cross-platform mobile development options such as React Native (using JavaScript).

However, the biggest issue I saw from the beginning is that to use the various APIs for each operating system, the developer still had to read and understand the APIs (written in the respective languages of Objective-C, Swift, or Java). So while you could write most of your code in Ruby, you’re not insulated from learning and understanding the APIs in their native language. Thus I’ve never been convinced of the actual overall savings at that point for RubyMotion other than a technological curiosity.

Also, if you do a Google search for RubyMotion, you’re not going to find many recent results returned. So while this may look like it’s an opportunity to create tutorials and other content, I think the more significant reason is that RubyMotion was built when only Objective-C was an option for iOS development. Now that that Swift is becoming the primary iOS development language, the need for alternatives is significantly diminished.

Unless there are some significant changes to RubyMotion (it did come under new ownership relatively recently), I’m not optimistic about its gaining any popularity among Ruby developers.

I hope I’m wrong as I enjoy programming in Ruby, but I’ll be looking more to React Native for cross-platform mobile development.

Originally published at tmarkiewicz.com on November 26, 2018.