I see this statement in the weather binding on github: All possible conversions can be found in the following Items section.
yet when I look at my weather binding Trace Log I see many properties like this: Property not mapped: ‘forecast.txt_forecast.forecastday.fcttext’ with value ‘Clear. Lows overnight in the mid 30s.’
is it possible to pull down more properties than I see on github? If so what is the pattern. I have tried to figure it out, but I do not see consistency. I guessed wrong when I tried String fcastTxt “Forecast [%s]” (Weather) {weather=“locationId=home, forecast=1, type=txt_forecast, property=fcttext”}
Not through the binding but if you use the HTTP binding and a Transform you can pull down any value that that weather provider publishes. I do this with Wunderground because the binding doesn’t support the amount of precipitation that has actually fallen today.
Remember the Weather binding provides a consolidated way to pull down weather from lots of different providers and not all providers have the same information or present it in the same way. So the binding ends up only providing a common subset of all possible values.
thank you for the example. I am also using wunderground. I studied some on the xslt. I’m still trying to get my head wrapped around it. I want do cache it and skip the weather binding. I will study your example and try to do one myself. A real example helps alot.
It took me a while to understand the xml transformations but it’s not too hard really. Have a look at the output from your api call to see what the format of all the available properties is. Also note the use either the conditions or forecast addresses to obtain slightly different data from Wunderground.
select="//simpleforecast/forecastdays/forecastday[1]/pop"/> Can be simply explained.
Taking the below example of the output from the froecast wunderground xml you can see the forecast section has two subsections. One for txt_forecast, and the other for simpleforecast. The above string defines information in the simpleforcast section, and down through the sub sections to forecastday.
The [1] at the end is how the transformation understands which of the following subsections it needs to look at. You can see this defined in the <period> section of the forecast day you want to look at. You could use [2] or [3] etc to grab data for the 2nd or 3rd forecast day respectively.
Lastly the /pop is just another subsection of the forecastday. You could similarly choose maxwind or avehumidity to have different outputs.
In this manner you can quickly grab completely different sections of the api xml file. See @rlkoshak’s examples above for reference of the different wunderground api addresses, although you will want to use your own api token, and he may want to mask his for future reference to this thread.
ok. I got it! Thanks all for the help. I cached the xml ane got my first read off it. Now I have to do the forcast. That will bring in the [2] selection.
I would like to use this for multiple forecasts.
Unfortunately im not to families with XSLT
Is there a way to use the same transform XSLT forearm forecast with some sort of variable or do I need to have 5 files for 5 days? Thanks
Unfortunately you need five files for five days. However you should be able to use XPATH and and not have any transformation files, unless you need to do something like strip the % off of the humidity field.