Is this fixed?
It sounds like a lot of things will need to be changed / fixed starting with webcore, then likely most pistons using $weather.
Is this fixed?
It sounds like a lot of things will need to be changed / fixed starting with webcore, then likely most pistons using $weather.
I had not heard about this, it seems like we should expect webCoRE’s $weather
to stop working very soon. Not sure if @ady624 or another contributor can find a way to replicate some of that functionality with the new The Weather Channel data that SmartThings is providing but I doubt there will be nearly enough data to avoid requiring changes to pistons. @webCoRE_Minions be aware, this will probably cause trouble in the near future.
It appears getWeatherFeature(conditions) is now getTwcConditions()
It appears that getWeatherFeature(forecast) is now getTwcForecast()
It seems most any app using weather had to change unless you used a device handler that abstracted you from the change.
I think it would be bad move to switch $weather
over to the new APIs. It is still working with Wunderground data as of today but more importantly the data format is completely different. Instead I prefer to add a new system variable, I don’t care for the name but $twcweather
reinforces that it is using The Weather Channel data and API response format. I’m trying that out now before publishing anything for the beta testing team.
We have a bit of piston code inspection built in to the backup/restore feature. Currently it identifies pistons that have concerns that may be relevant to restoring, such as use of the Execute Piston action, but it could also look for use of $weather
. We do not have any other way to search piston code so this would probably be the easiest way to get something up to help people bulk-refactor pistons. Back up your pistons, then upload the file to see warnings about which pistons use $weather
(without actually restoring any pistons).
A similar warning should be displayed on the individual piston page for any piston that uses $weather, but for the folks with hundreds of pistons the bulk approach provides a better starting point.
I agree with your concerns.
Another choice is that users start using a weather driver vs. having built-in. This same issue makes pistons non portable across ST vs. HE
The new $twcweather
is in the dev branch on GitHub and being tested by the folks in our beta group.
Eric, do you wan’t an invite to the Beta group to test the new $twcweather
variable that @ipaterson has added?
Same goes for anyone else reading this thread.