Smarthome: Weather binding

[lolodomo]

We don't have an equivalent of the OH 1.x weather binding in Eclipse smarthome or OH2. We only have the Yahoo weather binding but it provides apparently less data than the 1.x binding.
Any reason for that ?
Any work in progress ?
Any problem with the proposal of a general weather binding in Eclipse smarthome with several possible providers that will be a migration of the 1.x binding ?
I am a candidate to work on this new binding.

[lolodomo]

Here is my proposal:

• Bridges:
  
  
  
  • weather:geoLocation:locationId with config parameters: latitude, longitude
  
  
  • weather:yahooLocation:locationId with config parameter: woeid
  
  
• Things:
  
  
  
  • weather:yahooData:locationId:id with config parameter: updateInterval
  
  
  • weather:hamData:locationId:id with config parameters: clientId, clientSecret, updateInterval
  
  
  • weather:providerData:locationId:id with config parameters: provider, apikey, updateInterval, language
  
  
• Binding configuration parameters: speedUnit, temperatureUnit, rainUnit, snowUnit, pressureUnit, lenghtUnit
• Channels:
  
  
  
  • channel groups atmosphere_today, atmosphere_forecast1, atmosphere_forecast2, ... with channels humidity, visibility, pressure, pressureTrend, ozone, uvIndex
  
  
  • channel groups clouds_today, clouds_forecast1, clouds_forecast2, ... with channel percent
  
  
  • channel groups condition_today, condition_forecast1, condition_forecast2, ... with channels text, observationTime, id, lastUpdate, commonId
  
  
  • channel groups precipitation_today, precipitation_forecast1, precipitation_forecast2, ... with channels rain, snow, probability, total
  
  
  • channel groups temperature_today, temperature_forecast1, temperature_forecast2, ... with channels current, min, max, feel, dewpoint, minMax
  
  
  • channel groups wind_today, wind_forecast1, wind_forecast2, ... with channels speed, direction, degree, gust, chill
  
  
• General idea is to re-use what can be re-used from the 1.x binding, that is mainly all provider data retrieval and internal data storing (most of the binding code in fact)
• what would be lost (at least in a first time)
  
  
  
  • round/scale for numeric values
  
  
  • WEB view
  
  
• this binding will entirely cover the Yahoo Weather binding

Any comment ?

[watou]

I think each weather provider should have its own Bridge Thing handler implementation, hiding all provider specific details there, but feed data to a common set of Things like Conditions, Forecast, etc. The binding itself should have no configuration. The YahooWeather binding was meant mainly as a code example, iirc.

[kaikreuzer]

I think each weather provider should have its own Bridge Thing handler implementation, hiding all provider specific details there

👍 . This would imho be the correct approach, following the ESH design idea.

but feed data to a common set of Things like Conditions, Forecast, etc.

Not even that - only the channels should have the same tagging - imho the clean way is to define a weather-related tag library in the context of https://github.com/eclipse/smarthome/issues/1093.

[lolodomo]

Ok to have a bridge thing for each provider. The bridge thing will be in fact a mix of provider and location. We will provide no channels on the bridge things but the bridge thing will retrieve data from provider and dispatch the result to the things.

Then I think it is a good idea to have one weather thing for the current weather data, another one (same think type) for the 1 day forecast, another one for the 2 days forecast,, ... With this structure, it will be possible to have an automatic discovery of these things.

@watou: I am not sure to be ok with your idea to dispatch all the weather data on different thing types like one for wind, another one for precipitation, another one for temperatures, ... This will produce a lot of things. We can have only one thing type for weather data and we can group the channels in channel groups like one group for temperatures, one group for precipitation, one group for wind, .... Isn't it a better idea ?

@kaikreuzer : I have to read about your tag concept. I just hope I have not (again) to wait for a new concept implementation to make progress on this binding.

[lolodomo]

Regarding the tagging, that is not clear at all for me what is requested.
Do you want that I define new channel categories ? Define system channels rather than simple channels for all weather individual data ?
I understand more or less that the concept is to have some standard channels but it makes sense mainly for enum channels. All weather data are mainly numeric values except the weather condition and the wind direction.

[lolodomo]

Is Eclipse SmartHome the right place for this binding or should I consider an openHAB 2 binding ?
Can I take source files from OH 1.x binding and just rename the package/includes and the licence header to be compliant with Eclipse SmartHome ?

[kaikreuzer]

I do not know the details of the OH1 weather binding, but as discussed above, I doubt that it at all fits into the architecture (if my understanding is right that it internally uses yet another abstraction to be able to plug in different providers). There should be dedicated bindings for the different providers instead (and if there is code in common, we can discuss the creation of a shared bundle that all are using).

[maggu2810]

I agree that it would be "better" to create different bindings for different weather data providers and if there is code to share, we can create a bundle that contains all that shared code.

[lolodomo]

It will be a pity to not re-use the good work done with the 1.x weather binding.
There is not really an abstraction but the data parser for each provider is storing the retrieved data in a Java structure common to all providers. That is a good idea and looks like a good implementation. And thiese parsers are working well I suppose.

If we create a binding for each provider, we will have a lot of duplicated code because each binding will in fact do the same thing, that is start a scheduled job that will request data from the provider, then parse the data and finally update the channels of the binding. Each one will have to implement its unit converting for example. With several bindings, it will be more difficult to maintain something consistent betwwen the bindings.

That being said, we could try to create a shared bundle that will deal with provder request and result parsing. But then the weather bindings will be more or less duplicates of each other.

[maggu2810]

@lolodomo WRT commercial use of ESH bundles: If you use one binding for all weather providers and a customer owns only the agreement of one provider (e.g. he pays for) to use that weather data, how could the other ones removed from its product?
Perhaps the data parser itself could be implemented using OSGi services, so one bundle contains the generic implementation and the other bundles contains one service per provider.

[lolodomo]

We can also have very similar bindings, each one with its own code.
In this case, I will first implement the Wunderground Weather binding.

[lolodomo]

If we have one binding per provider, I propose to put the API key as a binding parameter. The binding will handle only one thing type: a weather location.

[lolodomo]

And we can copy a large part of the YahooWeather binding. What needs to be specific to each provider is the method updateWeatherData and of course all the getXXX methods to get individual information from the data returned by the provider.

[watou]

I propose to put the API key as a binding parameter.

Why not a property of the Thing? It makes more sense to me to address each weather providing API on its own terms, and supply as many channels as available from that provider, instead of abstracting above them all, and then making exceptions for each. Over time I've seen many problem reports with the OH1 weather binding where identifying the root cause was more difficult due to the abstractions internal to the binding.

[lolodomo]

We could put the API key on the thing but it is something that is attached to the provider (and so the binding if we decide to have one binding per provider). Putting it on the thing means that the user will have to enter the API key for each thing (location) he wants to define, with no real reason.

The thing type I imagine could even be shared by all weather bindings but I don't think the Eclipse SmartHome architecture allows this kind of things ? This thing type would have as parameters the location identifier and as channels all weather information that a weather provider can provide.

[lolodomo]

In fact, the ideal would be an abstract weather binding lol

[lolodomo]

What is the recommended JSON parser and mapper to Java object for Eclipse SmartHome and openHAB 2 ? Is it Google Gson ?

[watou]

Is it Google Gson ?

Yes.

[lolodomo]

Another reason to not re-use 1.x code ;)
So finally I will implement a new specific binding for Weather Underground that will look like the Yahoo Weather binding. This new binding could then be a good start point for any other weather bindings that requires JSON parsing.

[lolodomo]

The advantage of a specific binding for each provider is that we can provide specific provider data.
I will try to provide a first version of the Weather Underground binding before the end of the year (I have now already something very basic running).

[lolodomo]

Weather Underground provides icon sets for current weather conditions: https://www.wunderground.com/weather/api/d/docs?d=resources/icon-sets&MR=1
I am already afraid by your possible answer to the next question lol but what would be the correct way to provide this icon in Eclipse SmartHome ?
Shall I provide a channel with the URL ?
Shall I download the different icon sets and include them in Eclipse SmartHome ? I am not clear how to build and provide such a new incon set in Eclipse SmartHome.

[lolodomo]

In case I should consider iconset, should I simply add WU icon set in org.eclipse.smarthome.ui.iconset.classic as wu1-<state>.png for first WU icon set, wu2-<state>.png for second WU icon set, ... ? This would require that I convert original GIF images into PNG (and/org SVG images.

[hakan42]

There is a nice project over at https://github.com/ghys/org.openhab.ui.iconset.climacons that provides just icons. I was thinking of using that project as a template to create one of my own that provides the netatmo icons.

Perhaps something like that could be a basis for a seperate "binding" that provides just the icons, as I am not sure what the license situation with the WU icons are and whether they would be compatible with eclipse/smarthome ...

[lolodomo]

Do you know if such icon set bundle after deployment (put in addons directory or included in the distro) would be directly available in all UI ? I don't know if UIs consider only the "classic" icon set or all icon set bundles ? @kaikreuzer : you certainly have the answer ?
By the way, I am not sure at all that we have the right to download and provide these WU icon sets in any product ?
But I could imagine a new icon set provider that will provide the icon URL from WU, meaning we will not copy/provide the icons directly in our distro ?

[lolodomo]

No need to proxy, the icon set provider just needs to open an URL so a new icon set provider could provide the WU URL. The only problem would be the WU icon format (GIF) that is not supported by Eclipse SmartHome ! Would it be easy to add GIF format in Eclipse SmartHome ?

For Netatmo, I could imagine a similar icon set provider. (Note that a mapping could be required).

But still the same question: will such additional icon set provider be directly considered by all Eclipse SmartHome UIs ? How are defined the icon sets to be used ?

[hakan42]

I would expect the icons to be available to any and all consumers (bindings) in the same installation.

And about the gif format, the climacons project has a script inside it that converts some images automatically to svgs. A similiar build step could convert the WU icons to SVG or JPG, and maybe even provide both?

[lolodomo]

Maybe the mapping should be done in the binding itself rather than the icon set provider ?
I could even imagine to use the clamicons provider in the Weather Underground binding through an appropriate mapping.

[cdjackson]

Just for completeness, there's another nice weather icons here.

[lolodomo]

@cdjackson : interesting, there is even a proposed mapping for few weather providers including Weather Underground. But that is not clear for me how we could integrate that in Eclipse SmartHome.

[cdjackson]

Agreed - these are font icons - so they are used in CSS classes and not served up like images - many modern UIs are using them now as they are typically more theme-able… I just thought I’d throw the link into the mix ;)

[lolodomo]

Reading that page http://www.eclipse.org/smarthome/documentation/features/icons.html#icon-sets, unfortunately, I understand that an icon set cannot be specific to a category of channels but has to cover all standard channel categories. And there is the setting org.eclipse.smarthome.iconset:default to choose the used icon set.
My understanding is then that Eclipse SmartHome uses a unique icon set provider at a certain time.

The idea would then be to add weather icons in the "classic" icon set and to use in the weather bindings a mapping to be compliant with these icons ?

[lolodomo]

... and this would require to define a new system channel with a list of accepted values.
Where are defined the system channels ?

[watou]

By the way, I am not sure at all that we have the right to download and provide these WU icon sets in any product ?

Unless Wunderground explicitly licences their icons to be freely repackaged into something like openHAB, I would assume that doing so is forbidden, even when converted to another format.

[hakan42]

Agreed - these are font icons - so they are used in CSS classes and not served up like images - many modern UIs are using them now as they are typically more theme-able…

Well, the fonts are stored as one huge SVG file as well, so maybe some tool could be found / created that extracts each icon into its own SVG files. And then, we would be at the current setup, right?

Web-based: http://fa2png.io/
Command-Line tool: https://github.com/eugene1g/font-blast

[lolodomo]

@watou: in this case, using these WU icon sets in Eclipse SmartHome would require several prerequisites/enhancements in Eclipse SmartHome:

1. support of GIF icon format in Eclipse SmartHome
2. defining a new system channel for weather conditions with a pre-defined list of values
3. support the selection and the usage by UIs of several icon set providers at the same time, for example "classic,wu1" to use the classic icon set + the first Weather Underground icon set

The second point is by the way something we should define and use in all Weather bindings.

Then:

1. I will just have to create a particular icon set provider for Weather Underground that will map our system channel value to a valid WU URL. It could be used whatever the weather binding.
2. In the Weather Underground binding, I will set the system channel after applying the reverse mapping between the WU values and our values.

[watou]

support of GIF icon format in Eclipse SmartHome

If starting with GIF, it would make sense to convert to PNG, since both are lossless raster format, and optionally allow transparency. That's assuming one has the license to use the source images that way. One would not satisfyingly convert raster icons to vector (SVG) format in any case.

Would it not make sense to simply add more icons to the existing icon sets that represent "rain", "clouds," "lightning", etc., produced from the same license-safe origins as the existing icons? The existing icon sets cross many different "realms" already (lighting, HVAC, motion, etc.), and the icon sets aren't specific to a realm but instead specific to a "look". Would there be any role for MAP transformations so users could normalize condition states as they wanted? Do I have this all wrong? :slightly_smiling_face:

[lolodomo]

Checking a little more the existing code relative to icon sets, it looks like we use the CustomIconProvider which already provides additional icons (icons put by the user in conf/icons/classic).
So we could certainly update CustomIconProvider to additionally look for particular WEB icons.
But the icon format provided by WU would remain a blocking problem to use WU icons.

[lolodomo]

@watou: you're right, that would be an easy solution to create our own icons with the same looking as those already existing in the classic icon set, nothing to change except creating icons ... but then we need an icon designer because I have no skill for that !

[watou]

@watou: you're right, that would be an easy solution to create our own icons with the same looking as those already existing in the classic icon set, nothing to change except creating icons ... but then we need an icon designer because I have no skill for that !

I would almost expect that there is a license-friendly set of weather icons out there (in SVG or PNG) that can be incorporated into the codebase. Of course it's easy to say, less easy to track down and verify. :smile: Maybe ask the kind person(s) who contributed the icons so far if he/she has any suggestions?

[lolodomo]

Or we could just put inside the classic icon set the icons from the clamicons ? That is not really the same look but at least they are already available in an openHAB subproject.
But my understanding is that we cannot integrate this bundle directly in Eclipse Smarthome and use it in addition to the classic icon set.

[cdjackson]

The weather icons I linked above are licensed under MIT so should be compatible with EPL. As suggested by @hakan42, maybe it’s possible to convert the format...

[lolodomo]

Ckmacons are available here http://adamwhitcroft.com/climacons/ and I see no problem to re-use them in an open sourced project. So we could add them in the classic icon set with the appropriate script to convert them in PNG format

[cdjackson]

You can’t use them in any “open source” project as they are not for commercial use. My reading is that this means they aren’t compatible with some licenses such as EPL/MIT/Apache, and is probably more inline with GPL. It also states that you can’t redistribute them, so this might be a killer as I assume you would want to package them into openHAB and then distribute them as part of OH....

[lolodomo]

https://eclipse.org/smarthome/documentation/development/bindings/thing-definition.html

We already have the following channel categories:

• Humidity
• Pressure
• Rain
• Temperature
• Wind

That looks OK to me, I think we can use "Rain" even for snow.

Then I can propose to create the following system channel types:

• system.temperature-celsius => Number, read only, category Temperature, pattern "%.1f °C"
• system.temperature-fahrenheit => Number, read only, category Temperature, pattern "%.1f °F"
• system.humidity => Number, read only, category Humidity, pattern "%d %%"
• system.pressure => Number, read only, category Pressure, pattern "%.1f hPa"
• system.wind-mph => Number, read only, category Wind, pattern "%.1f mph"
• system.wind-kmh => Number, read only, category Wind, pattern "%.1f km/h"
• system.wind-direction => Number, read only, category Wind, pattern "%d °", min="0", max="360"
• system.rain-in => Number, read only, category Rain, pattern "%.1f in"
• system.rain-mm => Number, read only, category Rain, pattern "%.0f mm"
• system.snow-in => Number, read only, category Rain, pattern "%.1f in"
• system.snow-cm => Number, read only, category Rain, pattern "%.1f cm"

Are you ok ?

[watou]

system.temperature-celcius

celsius :slightly_smiling_face:

[lolodomo]

Fixed in my message ;)
I updated system.wind-direction too.

[lolodomo]

I took a look to the channel types defined by the netatmo binding and lot of them could be replaced by the system channel types I propose just above. The only difference I found is the pattern for the pressure channel type. I propose "%d hPa" while the netatmo binding is defining "%.1f hPa". Usually I see the pressure without a decimal value.

[lolodomo]

I just took a look to the YahooWeather binding and the 3 channel types defined by this binding could then be replaced by the system channel types I proposed.
One time again, the pattern for pressure is "%.1f hPa" in the YahooWeather binding. So maybe that is the pattern to be used for pressure.

[cdjackson]

I would suggest to use %.1f in general. I would also use these channel in the Meteostick binding.

[lolodomo]

Ok, I took a look to the Meteostick binding and they could be used. Just few differences:

• Pattern "%.1f hPa" for Pressure => so ok we definitevely define this pattern for the system channel type
• Pattern "%.0f °" rather than "%d °" for the wind direction
• Pattern "%.2f m/s" for the wind speed => Is it a common unit for wind speed ? Is it miles per second or meters per second ? I could add another system channel for this unit
• Pattern "%.1f mm" for rain => that is a terrific precision value ;)

[cdjackson]

Pattern "%.1f hPa" for Pressure => so ok we definitevely define this pattern for the system channel type
Agreed.
Pattern "%.0f °" rather than "%d °" for the wind direction
Fine with me.
Pattern "%.2f m/s" for the wind speed => Is it a common unit for wind speed ? Is it miles per second or meters per second ? I could add another system channel for this unit
It’s meters per second - I think it’s quite common.

Pattern "%.1f mm"for rain => that is a terrific precision value ;)
It’s quite common. Most rain sensors read with a precision of 0.3mm or better. Again, I think it’s better to keep precision than to loose it.

[cdjackson]

For wind speed - I don't mind converting to another unit, although meters/second is quite common.

[watou]

system.pressure => Number, read only, category Pressure, pattern "%.1f hPa"

The U.S. uses inches of Mercury (inHg) as the common unit for barometric pressure, so I suggest having two system channels, one for SI and one for Imperial. InHg should probably have three digits of precision.

[lolodomo]

Updated list:

• system.temperature-celsius => Number, read only, category Temperature, pattern "%.1f °C"
• system.temperature-fahrenheit => Number, read only, category Temperature, pattern "%.1f °F"
• system.humidity => Number, read only, category Humidity, pattern "%d %%"
• system.pressure => Number, read only, category Pressure, pattern "%.1f hPa"
• system.wind-mph => Number, read only, category Wind, pattern "%.1f mph"
• system.wind-kmh => Number, read only, category Wind, pattern "%.1f km/h"
• system.wind-ms => Number, read only, category Wind, pattern "%.1f m/s"
• system.wind-direction => Number, read only, category Wind, pattern "%d °", min="0", max="360"
• system.rain-in => Number, read only, category Rain, pattern "%.1f in"
• system.rain-mm => Number, read only, category Rain, pattern "%.1f mm"
• system.snow-in => Number, read only, category Rain, pattern "%.1f in"
• system.snow-cm => Number, read only, category Rain, pattern "%.1f cm"

For the windi direction, what difference between %d and %.0f and what would be the impact for existing bindings to switch from %d to %.0f ?

[watou]

For the windi direction, what difference between %d and %.0f and what would be the impact for existing bindings to switch from %d to %.0f ?

If there are decimals, %d will throw an exception, so it's a good idea to use %.0f anywhere there is a BigDecimal which could conceivably have decimals.

[lolodomo]

Updated list:

• system.temperature-celsius => Number, read only, category Temperature, pattern "%.1f °C"
• system.temperature-fahrenheit => Number, read only, category Temperature, pattern "%.1f °F"
• system.humidity => Number, read only, category Humidity, pattern "%d %%"
• system.pressure-hPa => Number, read only, category Pressure, pattern "%.1f hPa"
• system.pressure-inHg => Number, read only, category Pressure, pattern "%.3f inHg"
• system.wind-mph => Number, read only, category Wind, pattern "%.1f mph"
• system.wind-kmh => Number, read only, category Wind, pattern "%.1f km/h"
• system.wind-ms => Number, read only, category Wind, pattern "%.2f m/s"
• system.wind-direction => Number, read only, category Wind, pattern "%.0f °", min="0", max="360"
• system.rain-in => Number, read only, category Rain, pattern "%.1f in"
• system.rain-mm => Number, read only, category Rain, pattern "%.1f mm"
• system.snow-in => Number, read only, category Rain, pattern "%.1f in"
• system.snow-cm => Number, read only, category Rain, pattern "%.1f cm"

@watou: I am not sure that I have added what you requested for the pressure. You wanted one more or two more ?

[cdjackson]

For completeness, there was a discussion a while back about measurement systems (https://www.eclipse.org/forums/index.php/t/1068864/ https://www.eclipse.org/forums/index.php/t/1068864/). I’m just wondering if adding loads of channels for the same parameter, but different units, is the best approach?

[watou]

I am not sure that I have added what you requested for the pressure. You wanted one more or two more ?

Your updated list looks good now. Might want to add , min="0", max="100" to humidity. Also wonder whether system.relative-humidity would cut off future "complaints" of confusion between absolute and relative humidity. And just checking that snow is measure in centimetres usually (not arguing against, just checking).

I’m just wondering if adding loads of channels for the same parameter, but different units, is the best approach?

I think that either ESH gets a units system (see #1857), or the system channels duplicated by unit of measure, but not both!

[cdjackson]

1) Yes - relative humidity - we probably should also have absolute humidity, but then there’s probably at least 2 options for unit…
2) I’d personally prefer a proper system for handling units so that it’s handled centrally. I suspect in the longer run, having dozens of channels is going to be a mess. we really want 1 ‘temperature’ channel, and then a method to set/read it in different units and let the system handle what the user wants.

[lolodomo]

Updated list:

• system.temperature-celsius => Number, read only, category Temperature, pattern "%.1f °C"
• system.temperature-fahrenheit => Number, read only, category Temperature, pattern "%.1f °F"
• system.relative-humidity => Number, read only, category Humidity, pattern "%d %%", min="0", max="100"
• system.pressure-hPa => Number, read only, category Pressure, pattern "%.1f hPa"
• system.pressure-inHg => Number, read only, category Pressure, pattern "%.3f inHg"
• system.wind-speed-mph => Number, read only, category Wind, pattern "%.1f mph"
• system.wind-speed-kmh => Number, read only, category Wind, pattern "%.1f km/h"
• system.wind-speed-ms => Number, read only, category Wind, pattern "%.2f m/s"
• system.wind-direction => Number, read only, category Wind, pattern "%.0f °", min="0", max="360"
• system.rain-in => Number, read only, category Rain, pattern "%.1f in"
• system.rain-mm => Number, read only, category Rain, pattern "%.1f mm"
• system.snow-in => Number, read only, category Rain, pattern "%.1f in"
• system.snow-cm => Number, read only, category Rain, pattern "%.1f cm"

So I put that in standby until the new unit system is defined in ESH ?
And I will define my own channel types for the Weather Undergeround binding.

[lolodomo]

Of course the RFXCOM binding could have used these system channels too.

[watou]

2) I’d personally prefer a proper system for handling units so that it’s handled centrally. I suspect in the longer run, having dozens of channels is going to be a mess. we really want 1 ‘temperature’ channel, and then a method to set/read it in different units and let the system handle what the user wants.

Agree, as long as openHAB can 1) allow the use of SI and non-SI units per channel (not systemwide), and 2) a single binding can publish values in multiple units (for example, the Nest API publishes all temps in both C and F, and I would want the binding to be able to have channels for both values instead of having the system convert one to the other.) My "production" OH server manages items in both C and F since I'm a half-immigrant. :slightly_smiling_face: I suppose this comment belongs on #1857.

[lolodomo]

The Weather Underground Service provides values in the different units so my idea was to have one channel for each unit that just maps the provided value and no conversion inside the binding.

[lolodomo]

So I think we could already add these system channels (per unit) and later, when the Quantity item type is available, add other system channels that are not dependent on unit and attached to item type Quantity ?
Is it acceptable for all of you ?
Then each developer could choose what kind of system channel to use.

[watou]

Sounds good to me. Your weather bindings would be a very good sanity check for any future "units" enhancement, to make sure the enhancement at least meets the needs of binding developers.

[cdjackson]

I’m not sure it’s a good idea (sorry). I can understand why you suggest it, but in the longer term it would mean we have loads of system channels and most will not be used/required, and I suspect we have a backward compatibility issue.

In my mind, the big question is _IF_ the support for units and conversions will be added any time “soon” - if so, then we should wait. If not, then maybe we should go with the longer list ;). I’m not sure if anyone is working on this though, so I suspect the answer is it won’t happen any time soon...

[lolodomo]

As @watou and I mentioned, we have services that published the values in different units. In this case, we don't want to use a system channel that will convert between the units, we just want to provide the value as it is sent by the provider. If the system channels are not defined, these bindings will define specific channel types and will not use the system channels.
But I don't really see what is the problem to offer the choice to the developer and I don't see what could be the backward compatibility issue.

@kaikreuzer @maggu2810 : as you are the ones who validate the PR, before I spend too much time for something that will finally never be validated, let us know what you want regarding the system channels and what is the timing for the new unit conversion system in ESH.

[lolodomo]

@hakan42 : did you study the ability to extract individual icons from the big SVG file ?

[cdjackson]

My comment about backward compatibility was simply that if we add lots of channels now, then add more channels later, and remove the ones we add now, then we have a compatibility issue. I agree with @watou - we probably shouldn’t have both systems.

Providing the developer with options is fine - the problem is that it means the USER ends up not knowing what to do - there will end up being around 20 channels (the 13 you have defined now, plus the new ones later) - I just fear it’s a bit messy and will lead to a confused system.

[hakan42]

hakan42 : did you study the ability to extract individual icons from the big SVG file ?

@lolodomo sorry, not yet, as I am away from my computer. I can just follow github emails from my mobile for the next werk or so...

[hakan42]

Could we perhaps add UV Irradiance (or "Intensity") as a weather specific information item? Units would be "%.1f μW/cm²" or ""%.1f W/m²" if we go with the base SI units.

Any providers of this information could then convert this to the UV Index: https://en.wikipedia.org/wiki/Ultraviolet_index , https://en.wikipedia.org/wiki/Irradiance

I imagine my OH system playing the "Sunscreen Song" if I want to leave the house and the UV Index is too high 😄

[lolodomo]

@hakan42 : the Weather Underground service provides an UV value that is set to -1 when I checked it (the evening/night). Is it a normal value ? Any idea what is the range for the UV index ?
We could add a channel type for the UV index too.

[lolodomo]

Looking at the wikipedia page, it looks like the minimum value is 0.0. So I should probably consider a value "-1" as an unknown value.

[kaikreuzer]

The idea would then be to add weather icons in the "classic" icon set and to use in the weather bindings a mapping to be compliant with these icons ?

If we define new channel categories, existing icons sets should be extended to cover these, yes.

... and this would require to define a new system channel with a list of accepted values.

No, we only need to define new channel categories.

Would it not make sense to simply add more icons to the existing icon sets that represent "rain", "clouds," "lightning", etc., produced from the same license-safe origins as the existing icons?

👍 A lot of sense! Note that the idea of iconsets is that all their icons should follow a common look&feel. So ideally, we have icons designed by @reitermarkus (he is the wizard that created the classic icon set!) for any new category that we want to add.

_IF_ the support for units and conversions will be added any time “soon” - if so, then we should wait.

Yes, we SHOULD WAIT!
Please see https://github.com/eclipse/smarthome/pull/1857 - weather data is the ideal candidate for this feature and we should use the opportunity to actually test if this covers all requirements we might have. So I would strongly suggest to directly go for unit support in Number items instead of creating many alternative channels. As #1857 is a change pretty deep down in the core and it also requires the move to Java8 first, I would not want to merge it before the openHAB 2 release (on Jan 22) though, as this would be too risky. But I think we can already work on it, test it and merge it shortly after (i.e. some time around end of January, which isn't that far away anymore).

[lolodomo]

@kaikreuzer : as my Weather Underground binding should be ready in the following days, is it possible to push it in the openHAB 2 release ? I am sure lots of users will be happy.

Then later, when the #1857 will be merged, I will update the binding.
By the way, as already explained, Weather Undergeound is providing the different units. Using the internal unit conversion system could certainly lead to different values (less precision value). But of course I could add new channels with unit managed by openHAB and let the user decide between the "raw" channels from the provider and the channels with unit handling by openHAB..

[mhilbush]

Weather Underground binding should be ready in the following days

@lolodomo I'd be interested in testing this when it's ready -- either in the distro, or as a jar I can drop into addons.

[lolodomo]

@mhilbush : I will push my work in my Git fork and then submit a PR. I don't know if the PR will be merged or not but at least my binding will then be available to anybody. I will also put the jar file somewhere for downloading and communicate the link.

[lolodomo]

My current work is available here: https://github.com/lolodomo/smarthome/tree/wu/extensions/binding/org.eclipse.smarthome.binding.weatherunderground
I will probably push a request today.

For the about.html, where can I get the reference file ? I copied the file from the YahooWeather binding, updated the date and of course the part relative to third-party services. Is it the right way to provide this file ?

For the WU service, I played with "autoip" as location but it seems to be not reliable at all because I got data from a location at several hundreds kilometers from my location ! I have not documented this feature.

Then I tried to play with "country/city" as location and I discovered that for certain cities it does not provide weather data but just a list of available weather stations. That is the case for example for "France/Paris" or "Italia/Roma". In this case, the thing is OFFILENE. I will update the code to provide more information in the log about the available stations.

Using "latitude,longitude" as location, I discovered that I got weather data from a station that is several kilometers from my location, while the WU map is showing several stations just around me that are Netatmo personal stations. Does it mean that by default, WU is relying only on a few official stations (in particular airport stations) ?

[watou]

For Weather Underground, I use the OH1 HTTP binding and an XSLT transformation against a URL like this:

http://api.wunderground.com/api/b1bxxxx4981578f/conditions/q/pws:XCLOXXXI4.xml

So your binding ought to allow a thing to specify a pws parameter so the user can choose his or her preferred weather station.

[lolodomo]

Yes, you can enter a PWS too. Just enter "pws:XCLOXXXI4" in the location setting. Take a look at my README.md file.

[lolodomo]

Interesting, I started again (using lat,lon) and this time I got another station.
For the same lat/lon, WU does not always provide the data for the same station ?

[hakan42]

Nice, I logged in to wunderground to obtain an API key and search for a provider for my location, and it promptly offers me my own netatmo station 😄

I guess I have to search a bit more to find an "official" station

[lolodomo]

@hakan42 : I don't know if there is a way to identify and request professional stations ?

[hakan42]

I am looking over the web interface but did not find anything yet. The netatmo devices seem to have "netatmo" as their "software" tag, but I could not find this information in the response json.

All I could imagine right now would be to differientate between "airport" and "pws" nodes in the response.

[lolodomo]

The final question is how to identify a reliable and professional station.
I was surprised to see the "netatmo network" available in WU. I should compare the stations map from Netatmo and WU to check if all netatmo stations appear in WU.

[hakan42]

http://help.wunderground.com/knowledgebase/articles/838122-how-do-i-link-my-netatmo-station-with-weather-unde

"Due to a recent partnership between Weather Underground and Netatmo, weather data from all Netatmo stations that are registered through Netatmo appear on Weather Underground."

I read a few blog entries from people complaining about all the noise coming in from the badly calibrated netatmo devices, but wunderground seems to be adamant about keeping that data in their database.

[kaikreuzer]

I will also put the jar file somewhere for downloading and communicate the link.

I think this is the best for now. If you check the queue of bindings that has to be reviewed, it definitely won't be merged soon, especially as there are still questions open.
I agree with @cdjackson that we should not merge something now, only to completely change its use a short while later when having a solution for handling units.

For the about.html, where can I get the reference file ?

This is documented here: https://www.eclipse.org/legal/epl/about.php

[lolodomo]

PR #2748 pushed.

[pinkfish]

I think the way units should work, perhaps should pull that piece in a different issue? Is that the internals of the system should all use one unit. All the bindings use Celsius, use metric everywhere. In the ux you can set the unit you want as the display unit and the ux does the conversion on the edge to display it. We provide a nice helper class that does the conversions for you... Otherwise you end up with inconsistent values in a channel, one could be C and one could F so you cannot compare them properly. Or you end up with a whole whack of channels that have both C and F in them, which is also less than desirable. If the engine all uses SI units then all the automation and rules have a consistent way of interpreting the data. We could also put in some edge conversions in the rules code to handle F.

[kaikreuzer]

@pinkfish Please also note https://github.com/eclipse/smarthome/pull/1857, which will add the unit to the state. So in general I think it is ok if bindings provide the value in the unit that the device is actually providing - this way, we do not have any rounding issues and do not end up with "odd" numbers. Using the uom library would nonetheless allow us to do automatic conversion to any other unit that the user might want to use/see in UIs and rules.

[lolodomo]

We have now two weather bindings in ESH, the Yahoo weather binding and the WeatherUnderground binding.

As a reminder, here are the general opened discussions for all weather bindings:

• defining an iconset and mapping weather condition to this iconset in each weather binding
• using the unit management system still in development
• defining system channels that could be used by any weather binding

[9037568]

So, is it in the plan to implement the other weather bindings in ESH?

[lolodomo]

Once stuff relative to unit conversion is sorted, I will probably implement myself another weather binding.

[cweitkamp]

@lolodomo Any ideas which weather provider you prefer for your next implementation? I started work on my own version of an ESH binding for OpenWeatherMap. I could contribute if progress is sufficient.

The reason why I started this private project is to connect my Netatmo weather station to OWM using the recently introduced Station API.

[lolodomo]

Do you know that netatmo stations can already be available through WU ?

I will choose one free provider using JSON format as output to be able to mostly reuse the WU binding artefact.

[cweitkamp]

Yes, I read something about that the other day. Do you have experience with combining them? Is it possible to access my Netatmo station data with WU binding? I think we should resume this discussion in the OH2 community, shouldn't we? Is there a related topic?

[lolodomo]

To access your Netatmo station from WU, I think you simply have to setup your station to publish data and then select this station in the WU binding.

If you are working on a OpenWeatherMap binding, I could work myself on a World Weather Online binding. Normally, adding such a binding is just few days of work and probably even only few hours to get first data.

[cweitkamp]

Sounds easy. Maybe I try it later.

Your WU binding is a very good example for others to start. I follow your code base myself.

[lolodomo]

The 1.x version of the Weather binding provides a Common Id. Is it something we should consider through a channel for all 2.x weather bindings ? WDYT ?

[kaikreuzer]

I'd suggest to close this issue as we have dedicated bindings for different providers now.