There’s a new version here if you want to try it out.
Finally got around to testing the new .jar on my end, and it works like a champ — first time out it pulled a value of 60.7% for humidity and it mapped into OpenHAB without any issues. Thanks for the fix!
1 Like
That’s great. Thanks for the feedback. 
The change was merged yesterday, so it’ll be in 2.5.4 when that comes out in about a month.
1 Like
Many thanks for this great binding! Contributing weather data from a PWS, this comes in very handy 
One thing I noticed when doing the configuration: the language code must be set in format e.g. de-DE or en-US to work. (In the documentation an underscore is mentioned.)
And since I’m particularly lazy I used an Excel-based “code generator” to create the item definitions (mostly in German though).
Maybe it’s useful for someone else too…
The Weather Company Config.pdf (66.5 KB)
Please rename to .xlsx (but the file format is now allowed for uploads).
Thanks for the feedback. I assume you’re referring to the things file example where it’s showing the language code with an underscore instead of a hyphen. I’ll fix that.
Yes, exactly - that’s what I meant. Thanks!
Fix is in and will be in the 2.5.4 release.
Thanks for pointing it out!
I have been using the autodiscovered local thing but tried to create another one from the example as:
Thing weathercompany:weather-observations:patagonia “Torres del Paine Weather” @ “Patagonia” [pwsStationId=“IPUNTAAR4”,refreshInterval=30]
But this generates the following error/warning in the log:
> 2020-04-28 00:05:05.356 [INFO ] [.smarthome.model.core.internal.ModelRepositoryImpl] - Loading model 'weathercompany.things'
> 2020-04-28 00:12:13.600 [INFO ] [.smarthome.model.core.internal.ModelRepositoryImpl] - Validation issues found in configuration model 'weathercompany.things', using it anyway:
> Provide a thing type ID and a thing ID in this format:
> <thingTypeId> <thingId>
> 2020-04-28 00:12:13.609 [INFO ] [.smarthome.model.core.internal.ModelRepositoryImpl] -
Refreshing model ‘weathercompany.things’
Is it supposed to be using a different format? I am using 2.5.4 stock.
Thanks.
Sorry, the documentation is wrong and needs to be updated.
You can do it like this.
Bridge weathercompany:account:bridge [ apiKey="your-key-goes-here" ]
Thing weathercompany:weather-observations:patagonia "Torres del Paine Weather" (weathercompany:account:bridge) @ "Patagonia" [pwsStationId="IPUNTAAR4",refreshInterval=30]```Ok so just remove the brackets… Thanks!
Remove the brackets from the Bridge definition and add the bridge UID to the Thing definition.
I took the (weathercompany:account:bridge) to mean a group designation (which I didn’t need). It seems to work without it.
That’s really odd. With the Thing definition outside the Bridge definition (because the brackets are gone), you should need to specify the bridge in the thing definition; otherwise, I don’t know how it will know to put the bridge in the thing config. Unless it’s smart enough to know there’s only one bridge defined for that binding…
I think the correct way to get it to work with the {} and without ref the bridge, this form seem to be ok::
Bridge weathercompany:account:bridge [ apiKey=“xxx” ] {
weather-forecast hpn “Westchester County Airport” @ “White Plains” [locationType=“iataCode”,iataCode=“HPN”,refreshInterval=600]
}
Yes, that’s correct. That way is fine, and is the more common way to do it.
However, the Thing UID won’t match the example item definitions in the documentation. The way I did it above, which is what I’m submitting for the documentation, will ensure that if someone copy/pastes the things and items definitions from the documentation, it will work without any changes.
Hi all,
I have been using this binding for several months and find it very useful.
I wonder if it will return also the historical data of the PWS, and what would be the syntax in the .items file.
API call is:
https://api.weather.com/v2/pws/dailysummary/7day?stationId=KMAHANOV10&format=json&units=m&apiKey=yourApiKey
thanks
Yes, just add a weather-observations thing type and configure it with the station you want.
The documentation here shows an example of items for a weather-observations thing. Note that if your station doesn’t upload some of the data elements, IIRC the items will show UNDEF.
Oh, nevermind, I see you want historical data… No it currently doesn’t do that.
If the binding were to do this, it might be done as a thing action that would return the full json string in the units defined in the openHAB system config. In addition, there could be a thing action for each type of historical query.
PWS Daily Summary - 7 Day History
PWS Recent History - 1 Day - Rapid History
PWS Recent History - 7 Day - Hourly History
PWS Historical
It’s a shame it’s not supported.
I will try to do the same thing with a CRON rule that retrieves the JSON and parses it to an item.
If you want to work with a thing action that returns the JSON string, do you want to try out a version that supports these three actions? 
String getDailySummary() - Get the daily summary of observations for the last seven days of Personal Weather Observations
String getOneDayRapidHistory() - Get the daily observations records in rapid frequency (as frequent as every 5 minutes)
String getSevenDayHourlyHistory() - Get the hourly records for each day's observations report for the last seven days.