IF next week's forecast is clear → THEN schedule an activity

Context
There was fantastic weather today despite it being February, a normally deep-winter month in my current location. I would have gone out cycling or jogging, but I had prior commitments to attend to. I am kicking myself because, well, I could have scheduled those commitments on other days had I known the weather was going to be great.

Challenge
I am hoping to pull some weather forecast value, such as average, low, or high temperature (willing to accept any of the three), and if said value exceeds a certain threshold, then create either an iOS Calendar or iOS Reminder event.

Complication
Weather Underground only provides UV index as a value that can be parameterized per se, and values such as temperature is an IFTTT Pro+ ($70/yr) feature. The price alone isn’t as much of the complication as the query itself - which has to be executed with actual code within the query/filter section.

Question
Could Apilio be used, perhaps in conjunction with Pipedream + OpenWeather API to accomplish this goal?

Hi @qdmt,

how much days in advance do you need to have the reminder?
The IFTTT weather applet gives you only tomorrows forecast.
https://ifttt.com/weather/triggers/tomorrows_weather_at_time
If that is enough, you can forward one or multiple forecast values to Apilio and trigger logic based on them.
There is also a service to create iOS calendar entries through IFTTT.

So given the restriction that it is only one day in advance, this is certainly doable.

Also, and I’m not saying this is relevant but might be an interesting condition for you, I use a service called Forecast.Solar which gives me what I find is a pretty reliable sunny weather forecast, down to 1hr resolution at your location. The output is in estimated solar power production so can easily be used for numeric comparisons.

Thanks Pebneter - I was hoping for greater flexibility on the days out, say, at least 3+ days out. In practice, I might like it checking every 7 days for the next 7 days, and plot in the candidate calendar days.

That said, I can try testing and working with 1 day out with the IFTTT weather applet in the meantime.

1 Like

Thanks Dan - that has the same impression I got from OpenWeather API. I will try digging into this further as well.

1 Like

Apologies, @DanT or @pebneter, hoping to grab a hint about what to do next. This is what I’ve done so far:

Core:

  • Activated pipedreams
  • Activated OpenWeatherAPI, tested API key successfully for 7 day forecast (in both browser & pipedreams)
  • Upgraded Apilio to enable API access

Code:
Node 1:
Setting aside for now the actual trigger (“Node 0”, which I presume I can trigger in IFTTT on a date/time basis to run weekly), in PipedIream, I have the following in my first node:

import { axios } from "@pipedream/platform"
export default defineComponent({
  props: {
    openweather_api: {
      type: "app",
      app: "openweather_api",
    }
  },
  async run({steps, $}) {
    return await axios($, {
      url: `https://api.openweathermap.org/data/3.0/onecall`,
      params: {
        lat: `mylat`,
        lon: 'mylon',
        cnt: '7',
        units: 'metric',
        appid: `${this.openweather_api.$auth.api_key}`,
      },
    })
  },
})

Node 2:
This is followed by the Apilio node, which evaluates successfully once the account was upgraded:

import { axios } from "@pipedream/platform"
export default defineComponent({
  props: {
    apilio: {
      type: "app",
      app: "apilio",
    }
  },
  async run({steps, $}) {
    return await axios($, {
      url: `https://api.apilio.com/api/v1/boolean_variables`,
      auth: {
        username: `${this.apilio.$auth.username}`,
        password: `${this.apilio.$auth.password}`,
      },
    })
  },
})

Back in Apilio, I created:
SunInForecast - a boolean variable, currently set in False state
ExpectingNiceWeather - condition linked to SunInForecast, must be true
NotExpectingNiceWeather - condition linked to SunInForecast, must be false

I presume then back in Pipedreams, I have to create a PUT request to store each of the 7 days temperature? Recall that I seek to ultimately schedule potential days to go cycling if the temperature is “good” (say, the feels_like parameter is > 5 degrees celsius.) Alternatively, the date/time trigger could run on a daily basis and evaluate the 7th day out on a rolling basis (e.g., each day, check the 7th day out - so each day is evaluated on its own as opposed to analyzing 7 days at a time.)

Here’s an example response from OpenWeather evaluated via Pipedreams:

steps.code{1}

$return_value{8}

lat:mylat

lon:-mylon

timezone:`mytimezone`

timezone_offset:-99999

current{15}

dt:16766734234529

sunrise:167234234024

sunset:234234

temp:5.38

feels_like:12.38

pressure:1212

humidity:12

dew_point:-5.00

uvi:0

clouds:30

-more-

minutely[61]

hourly[48]

daily[8]

0{20}

1{18}

2{18}

3{18}

4{18}

5{19}

dt:12312312

sunrise:123123123

sunset:123123

moonrise:12312312312

moonset:1671232320

moon_phase:0.06
temp{3}

feels_like{6}

pressure:1212

humidity:23
1 Like

Wow looks great but I think @pebneter is best qualified to help with this.

1 Like

Hah, thanks @DanT. The things I do on a Friday night :sunglasses:

1 Like

Just some update to my progress:

Back in Apilio, I created a numeric variable feelslikevar
In Pipedream, I have an Apilio HTTP request configuration as follows:

Now, when I try the following for params in Pipedream:
Query Name: numeric_variable
Query Value: {{steps.code.$return_value.daily[7].feels_like.morn}}

Result: error 500

If I change Query Name to feelslikevar, I get error 400:
param is missing or the value is empty: numeric_variable

1 Like

Hi @qdmt ,

in the logs I see an invalid request.
I think the problem is that pipe dream builds the request in a wrong way.
Remove the “Query Name”/“Query Value”, because it get’s appended to the URL.
But you need to specify a body content as JSON like this:
{"numeric_variable": {"value": 5}}

I guess you found the link to the API spec?

1 Like

Btw. you could also use the webhooks feature instead of the REST API - maybe it is a bit easier to implement in Pipedream: How to use webhooks to update variables and trigger logicblocks in Apilio

1 Like

Thanks very much, @pebneter. Yes, I do have the Apilio REST api spec open that I’m trying to get Pipedream to mimic as closely as possible.

With your advice, I am getting closer:
Putting the following test value of 5 in the body works:
{“numeric_variable”: {“value”: 5}}

But putting the path of the OpenWeatherAPI value per below evaluates to a param is missing or value is empty 400 error.
{“numeric_variable”: {“value”: {{steps.code.$return_value.daily[7].feels_like.morn}}}}

I found one request in the logs that looks like this:

[2023-02-18T23:12:57.339677 #2] INFO -- : method=PUT path=/api/v1/numeric_variables/cf591dd----------4849dd format=html controller=Api::V1::NumericVariablesController action=update status=400 duration=20.63 view=0.21 db=9.54 params={"_json"=>"JSON.stringify({\"numeric_variable\": {\"value\": -16.89})
I think there are extra curly brackets around the value that should not be there?

1 Like

Just figured it out. There were all sorts of issues and was just about to give up in favour of the webhook approach, but went through line by line and landed at this piece that successfully updates the numeric variable on Apilio side.

import {axios} from "@pipedream/platform";

export default defineComponent({
  async run({ steps, $ }) {
    const feelslikeresponse =
      steps.OpenWeatherAPI.$return_value.daily[7].feels_like.morn;

    let data = JSON.stringify({
      "numeric_variable":{
        "value":feelslikeresponse
      }
    })

    const { config } = await axios($,{
      method: "put",
      url: "(myUUID)",
      headers: {
        "Content-Type": "application/json",
        Authorization:
          "Basic (headercode)",
      },
      data : data
    });
       return feelslikeresponse;
  },
});

But not in the clear just yet…now on to the fun logic building on Apilio to actually act on the numeric variable update :slight_smile:

2 Likes

This is great!
Thanks for sharing your solution. :clap:

2 Likes

Appreciate the help! Tested it through IFTTT & logic evaluation worked great. Thanks again. I will post a full write up & guide on the Use Case forum.

1 Like

Awesome - looking forward to it!

1 Like

well done for persevering, it’s always worth the learning curve in the end (if it works) ; )