Weather Binding "CommonId not found" since upgrad 1.8.0

snowy · January 14, 2016, 6:00pm

Hello,

since i have been update to 1.8.0 i receive this message:

2016-01-14 18:29:33.392 [WARN ] [o.b.w.i.parser.CommonIdHandler] - CommonId not found: CommonIdHandler[provider=YAHOO,id=,icon=]
2016-01-14 18:29:33.421 [WARN ] [o.o.b.w.i.bus.WeatherPublisher] - Weather forecast day 0 not available for locationId ‘home’, only 0 available
2016-01-14 18:29:33.433 [WARN ] [o.o.b.w.i.bus.WeatherPublisher] - Weather forecast day 0 not available for locationId ‘home’, only 0 available

How can i fix this error?

snowy · January 14, 2016, 9:51pm

I moved to OpenWeatherMap, and now it works fine!

Extrabannies · January 17, 2016, 9:29am

Hi Snowy,
just for good housekeeping maybe this would have helped:

Cheers
Björn

yancym · January 20, 2016, 2:32pm

This actually worked correctly for me on 1.8.0 for a week, then it stopped working yesterday and I started seeing this error. I’m also using Yahoo and would prefer to keep it that way instead of signing up on another site. No configuration changes were made for the binding set up. Any other ideas?

Mpower · January 20, 2016, 2:59pm

My weather binding isnt working since yesterday too and i am also using yahoo

Spaceman_Spiff · January 20, 2016, 3:28pm

same here, yahoo is not working any more:

[WARN ] [o.o.b.w.i.bus.WeatherPublisher] - Weather forecast day 0 not available for locationId 'wg', only 0 available

yancym · January 20, 2016, 3:53pm

Also an issue with 1.7.1. See this link for more detail. Looks like on the Yahoo side.

sipvoip · January 20, 2016, 4:16pm

Yep, had to switch back to underground yesterday.

sercasyr · January 22, 2016, 10:43am

I have exactly the same issue:

2016-01-22 10:52:17.163 [WARN ] [o.b.w.i.parser.CommonIdHandler] - CommonId not found: CommonIdHandler[provider=YAHOO,id=,icon=]

2016-01-22 10:52:17.165 [WARN ] [o.o.b.w.i.bus.WeatherPublisher] - Weather forecast day 2 not available for locationId ‘VLC-Yahoo’, only 0 available

It also happened recently, maybe when I switched to OpenHAB 1.8, but I cannot be sure.

Is there a solution?
Do we need to move to Wunderground or some other providers?

watou · January 22, 2016, 10:46am

One immediate workaround might be to use the HTTP binding and XSLT transforms, as was commonly done before the advent of the weather binding.

Mpower · January 22, 2016, 11:08am

I switched to Wunderground

sercasyr · January 22, 2016, 1:48pm

I also have wunderground.
What I like to know is wether there is a solution for this or not.
If the answer is no, I will remove the yahoo items.
If the answer is yes, I will wait.

I don’t want to go back to XSLT transforms.
IMO, if the yahoo service is dead or modified, then the binding should change.

wn2012 · January 24, 2016, 5:10pm

It seems Yahoo’s geo.placefinder used to search for latitude/longitude is currently unavailable.
In Weather Binding this URL is used Yahoo Weather with this query:
SELECT * FROM weather.forecast WHERE woeid in (SELECT woeid FROM geo.placefinder WHERE text='[LATITUDE],[LONGITUDE]' and gflags='R'
LATITUDE and LONGITUDE are replaced with openhab.cfg’s entries.

You can verify this on YQL Console.
Click geo.placefinder beyond DATA TABLES on the lower right side. Then the example string
select * from geo.placefinder where text="sfo"
brings the result:
http-status-code=“503” http-status-message=“Service Unavailable”

Yahoo schreibt dazu YQL geo.placefinder is now shutdown

watou · January 24, 2016, 5:59pm

It looks like Yahoo! has discontinued any free service that can receive a latitude,longitude and return a WOEID (Where On Earth ID). It also looks like Flickr, their photo subsidiary, offers a free service to do this, but it requires an individually assigned private app key that is rate limited, so I don’t think that’s an acceptable replacement.

I’ve also seen evidence that Yahoo! continues to allow passing in a place name, like “London, England” and returning a WOEID, if you submit a YQL query like: SELECT * FROM weather.forecast WHERE woeid in (SELECT woeid FROM geo.placefinder WHERE text='[PLACENAME]').

So, assuming all of the above is true…

Should I create a PR against the OH1 weather binding that allows you to provide either:

a place name to find your WOEID
an indication to use your public IP address to find your place name and then your WOEID, or
your preferred WOEID directly

This really ought to be fixed in some way for the 1.8.1 maintenance release, IMHO.

Separately, I’ve opened an issue against Eclipse SmartHome’s Yahooweather binding, which gets (from a different free service) a lat,lon from your public IP address, and then tries (and now fails) to get a WOEID from the lat,lon.

watou · January 24, 2016, 6:32pm

Funny, the place name query worked for me yesterday… OK, so a new config property for openhab.cfg where you have to supply the WOEID directly then if you are using Yahoo for weather?

…I’ve made code changes to the weather binding that explicitly require a new location property woeid to be specified in openhab.cfg along with all current config properties when the provider is Yahoo. This changes the YQL query to no longer try to read from geo.placefinder, but instead uses the WOEID you explicitly had to provide in openhab.cfg. I just tested the change and it works. I found my WOEID by seeing the number at the end of the URL when I went to weather.yahoo.com.

Do anyone want this change to be part of the weather binding in 1.8.1?

Or in the alternative, does anyone know of a reliable, free service that translates lat,lon into a WOEID that can be used with Yahoo! weather?

watou · January 24, 2016, 9:19pm

Submitted PR #3888 to address issue #3860.

If you are interested in testing this change, please download a test JAR here. If you are using the Yahoo provider, you will have to add

 weather:location.<your locationId>.woeid=<your WOEID>

to openhab.cfg.

The latitude and longitude are now optional for the Yahoo weather binding (since they are now unused), but woeid is now required, in the test JAR:

- * #weather:location.<locationId1>.latitude=
- * #weather:location.<locationId1>.longitude=
+ * #weather:location.<locationId1>.latitude=   (not required for Yahoo provider)
+ * #weather:location.<locationId1>.longitude=  (not required for Yahoo provider)
  * #weather:location.<locationId1>.provider=
+ * #weather:location.<locationId1>.woeid=      (required for Yahoo provider)
  * #weather:location.<locationId1>.language=
  * #weather:location.<locationId1>.updateInterval=

pauljanssens · January 25, 2016, 9:28am

seems to work fine form me now (I’m only fetching Temp and Humidity)
Thanks for the quick change.

watou · January 25, 2016, 9:40am

Thank you, Paul! Could you verify one last thing for me? If you comment out the longitude and latitude lines for your Yahoo weather provider in openhab.cfg (by putting a # mark at the beginning of each line) and making sure it’s taken effect, and using a JAR file from the provided link of no more than an hour ago, is your log still error-free?

Or, if you had already commented out or removed the longitude and latitude lines, please just let me know. Just trying to be thorough with field tests before I merge this change (and make an equivalent one for 1.8.1, since the source code has been reformatted meanwhile…).

Thanks very much!

pauljanssens · January 25, 2016, 12:24pm

Hi Watou,
I grabbed again the jar from the link in the above email, but I notice that the MD5 (8d49c7bbffc010fe1d90589d8dd25d0e) and SHA1 checksums of the new download are the same as the one I grabbed at 9.47 this morning. So either your change was already done, or the link does not get me a newer fileversion.
I commented out the Lat and Long entries and enabled debug log trace and can see that still all is coming in fine (also the 5 day forcast)
–Paul–

watou · January 25, 2016, 12:48pm

Paul, thanks very much for your diligence! I will make sure this change makes it into 1.8.1, and I will leave my hotfix JAR in place at the above link in the meantime. And once it’s merged, I will update the wiki page.