Weathersnoop 3.1.1 won't work with Indigo

[PottedPorkProduct]

I upgraded WeatherSnoop from 3.1.0 to 3.1.1 tonight, and now get the following error message (with Debug turned on in the Indigo Plugin):

Code: Select all

May 17, 2015, 9:55:48 PM
  WeatherSnoop Debug              Updating device: Davis Weather Station
  WeatherSnoop Error              Couldn't get site information from WeatherSnoop for device "Davis Weather Station" - check to see if WeatherSnoop is running correctly.
  WeatherSnoop Debug              Error specifics:
Traceback (most recent call last):
  File "plugin.py", line 522, in update
    uiVal = "° (%s)" % getWindDirectionCardinal(int(valueDict.get("value", 0)))[0]
ValueError: invalid literal for int() with base 10: '-9999.0'

Indigo 6.1.0, OSX 10.10.3

I tried restarting the plugin, and nothing changed. I can include more debug if you need it.

[jay (support)]

I'm checking with the WeatherSnoop guys on this one - I'll let you know what I find when I hear back.

[boisy]

Hi guys,

Jay alerted me to this thread. Nothing should have changed between 3.1.0 and 3.1.1 with regard to wind direction. If the value being returned is -9999.0, then that indicates that WeatherSnoop 3 is not getting a valid value from the wind direction instrument.

One thing I see wrong is that we're advertising the type as int, but the failure value is a float (-9999.0). We need to change that behavior on our end.

Getting back to the problem, I checked our Davis station (currently out of town at the moment on business) and at least in our case, we're getting valid values. See the XML below:

Code: Select all

<property id="windDirection">
<name>Wind Direction</name>
<type>Direction</type>
<time>2015-05-19 22:55:22 -0500</time>
<unit>deg</unit>
<values>
<value type="int" unit="deg" label="Degrees">106</value>
</values>
<minValueTodayTime>2015-05-19 00:16:44 -0500</minValueTodayTime>
<minValuesToday>
<value type="int" unit="deg" label="Degrees">4</value>
</minValuesToday>
<maxValueTodayTime>2015-05-19 00:16:27 -0500</maxValueTodayTime>
<maxValuesToday>
<value type="int" unit="deg" label="Degrees">359</value>
</maxValuesToday>
</property>

Jay I believe you guys setup the WeatherSnoop 3 plug-in to pull data from the XML V2 channel, correct? Can you confirm?

[jay (support)]

We're just using the URL that's returned via bonjour - not sure which one that is.

[PottedPorkProduct]

I'm using ye olde Davis Vantage Pro classico with an old firmware version.

I snooped some of the network traffic, and it looks like the plugin is using the top level sites.json, and then follows the value listed in the uri field of the response, not the uri_v2.

Here's sites.json:

Code: Select all

{
     "software": {"name": "WeatherSnoop 3","version": "3.1.1 (764)"},
     "sites": [
     {
           "siteDocument": "file://localhost/Users/housebot/Documents/My%20Davis%20Weather%20Station.wssite/",
           "agentName": "Davis Weather Station",
           "uri": "http://hausu.home.geoffdavis.com:8000/F81F5A9C-2481-4B3E-A3CA-8F60FEB660B3.json",
           "uri_v2": "http://hausu.home.geoffdavis.com:8000/F81F5A9C-2481-4B3E-A3CA-8F60FEB660B3_v2.json"
     }
     ]
}

And here's the content of the JSON shown in the "uri" (not uri_v2). Searching for "direction" yields two items. "tenMinuteWindGustDirection" has value -9999.0, "windDirection" has value 306.

Code: Select all

{
"software": {"name": "WeatherSnoop 3","version": "3.1.1 (764)"},    "site": {
   "time": "2015-05-20 21:15:34 -0700",        "name": "Normal Heights Central",
        "location": "Normal Heights, San Diego, CA, USA",
        "longitude": "-117.117904",
        "latitude": "32.767039",
        "elevation": "412 feet",
        "agent": "Davis Weather Station",
        "uri": "http://hausu.home.geoffdavis.com:8000/F81F5A9C-2481-4B3E-A3CA-8F60FEB660B3.json",
        "properties": {

[SNIP]

,"tenMinuteWindGustDirection": {
"name": "10 Minute Wind Gust Direction",
"type": "Direction",
"time": "2015-02-21 08:00:55 -0800",
"unit": "deg",
"values": [
{
"type": "float",
"unit": "deg",
"label": "Degrees",
"value": "-9999.0"
}
],
"minValueToday": {
"time": "2015-05-20 00:00:00 -0700",
"values": [
{
"type": "float",
"unit": "deg",
"label": "Degrees",
"value": "-9999.0"
}
]
},
"maxValueToday": {
"time": "2015-05-20 00:00:00 -0700",
"values": [
{
"type": "float",
"unit": "deg",
"label": "Degrees",
"value": "-9999.0"
}
]
}
}

[SNIP]

,"windDirection": {
"name": "Wind Direction",
"type": "Direction",
"time": "2015-05-20 17:12:32 -0700",
"unit": "deg",
"values": [
{
"type": "int",
"unit": "deg",
"label": "Degrees",
"value": "306"
}
],
"minValueToday": {
"time": "2015-05-20 15:58:57 -0700",
"values": [
{
"type": "int",
"unit": "deg",
"label": "Degrees",
"value": "174"
}
]
},
"maxValueToday": {
"time": "2015-05-20 16:40:15 -0700",
"values": [
{
"type": "int",
"unit": "deg",
"label": "Degrees",
"value": "335"
}
]
}
}

[SNIP]

[jay (support)]

[MODERATOR NOTE] I snipped out the unrelated parts - scrolling up and down the page was an exercise in frustration.

So, a couple of things:

• From the JSON, the plugin is failing on the tenMinuteWindGustDirection field. All other fields that use units of degrees ("unit": "deg",) have always been integers. However, it appears that for this one it's not the case. Boisy, can you confirm that's the case and not a bug?
• The plugin predates the v2 API, so as PottedPorkProduct notes we're using the 'uri', not the 'uri_2' field. We're also using JSON, not XML.

Regardless, I'll modify the plugin to deal better with degree units. PottedPorkProduct - send an email to me ([email protected]) and I'll get you an early release when I have it ready.

[boisy]

Jay,

Sorry for responding so late. I logged into the forums and saw this post.

The tenMinuteWindGustDirection appears as an "int" in the latest Pre-Flight 3.1.2:

Code: Select all

,"tenMinuteWindGustDirection": {
"name": "10 Minute Wind Gust Direction",
"type": "Direction",
"time": "2015-08-01 16:42:05 -0500",
"unit": "deg",
"values": [
{
"type": "int",
"unit": "deg",
"label": "Degrees",
"value": "359"
}

I don't remember, but I may have fixed this somehow due to this post.