V2 Question - OpenWeatherMap Using their New JSON Data Feed

[kblagron]

I had built a DarkSky weather driver for my own use due to licensing restrictions, and noticed that OpenWeatherMap now has a new One Call API that provides a very similar JSON data feed.  It gives forecast data for 7 days, and it was very easy to convert the DarkSky driver to use the OpenWeatherMap JSON data and seems to be working fine.

It is easy enough to make it V2, but my question is related to the number of days in the V2 documents.  It says "For the forecast fields, they are duplicated up to 5 times for the forecast days".  To make it V2 compliant, how should I handle the data for days 6 and 7 - Is it okay for them to start with "WEATH#"  to be consistent, or is that prefix only applicable for the V2 compliant fields.  I can do it either way, just wanted to make sure I did it correctly.

I noticed in the shipped OWM driver you didn't put the prefix on those fields that weren't V2 compliant.

[Dean Roddey]

It should be fine. The V2 spec just doesn't promise more than 5, so you would stick to five or fewer in your interfaces if you want to be likely to be able to swap to another driver at some point without having to change your interfaces.

Also be careful about the number of does. Is it really 7? Some times they don't do full days, they do three or four or some such hour chunks that you have to put together. The first and last ones won't cover the full day so they aren't really useful. That's been the case before. So I could only count on the inner ones actually representing a full day. At 10 at night, there might only be one small chunk of data for today, so you couldn't calculate anything useful from that.

[kblagron]

It should be fine. The V2 spec just doesn't promise more than 5, so you would stick to five or fewer in your interfaces if you want to be likely to be able to swap to another driver at some point without having to change your interfaces.

Also be careful about the number of does. Is it really 7? Some times they don't do full days, they do three or four or some such hour chunks that you have to put together. The first and last ones won't cover the full day so they aren't really useful. That's been the case before. So I could only count on the inner ones actually representing a full day. At 10 at night, there might only be one small chunk of data for today, so you couldn't calculate anything useful from that.

It actually gives 8 days of data, but doesn't start the day at midnight of the local time Unfortunately. the start time for the dates changes based on lat/longs, and really makes no sense.  

Eastern Daylight Time Zone:    Day 0 Forecast Starts at current day 17:00 UTC
Central Daylight Time Zone:     Day 0 Forecast  Starts at current day 18:00 UTC
Mountain Daylight Time Zone:  Day 0 Forecast  Starts at current day  19:00 UTC
Pacific Daylight Time Zone:      Day 0 Forecast  Starts at current day  19:00 UTC
London Daylight Time Zone:    Day 0 Forecast  starts at current day 11:00 UTC


I think rather than trying to sort all of this out like you did in your driver, just provide the dates and forecasts, with the correct start date/time for the lat/long, and let it provide the data - then place it in the quirks / limitations.

[kblagron]

Looking at this further, it looks like they place the timestamp at 12 noon standard time.  The times I listed above all show to be noon standard time if you look at the offset.  The MDT I listed was actually MST as I picked one of the states in Mountain time zone that doesn't switch but thought they did.

So the time may be noon to noon each day, or it could be how they decided to present the UTC time.  Not sure - maybe it will be more clear when we have a bigger weather change event here.  I can verify that the sunrise/sunset time is exactly where it should be for the reported date.

[kblagron]

I went ahead and posted the JSON Based OWM driver following the guidelines in "/Reference/DevClasses/Weather" to make it V2 compatible.  I ran the V2 Driver Validation Check in the IDE, and I am getting errors (attached)  that don't seem correct, but will let you comment on whether I did something wrong.

[Dean Roddey]

Be sure that you have the correct type, R/W access, and semantic type/limits where applicable. It checks all that stuff.

[kblagron]

Be sure that you have the correct type, R/W access, and semantic type/limits where applicable. It checks all that stuff.

I got them all cleaned up but one - WEATH#CurHumidity.  As a sanity check, I also checked the shipped OWM driver, and it has the same error message.  In the docs it says this field is an Int, but in the shipped driver it it is stored as a Card.  With either of them, I get the error:

Field 'WEATH#CurHumidity' did not match any available field configuration.

In the shipped driver it is initialized as shown below, which I have mimicked with the same error.  and also when changing the field to an Int:

Code:

        TmpDef.Set2
        (
            "WEATH#CurHumidity"
            , CQCFldTypes.Card
            , CQCFldAccess.Read
            , CQCFldSTypes.CurExtHumidity
        );

 
Any thoughts?  Or no big deal?

[Dean Roddey]

The XML that defines the device class is presumably wrong. It should be a Card. Negative humidity doesn't make any sense. So go with Card and ignore the error for now.