Announcing OpenWeatherMap binding for Eclipse SmartHome / openHAB

Thanks Scott! So would you put all those conditions in a transform file like for the wind direction?

John

No need… the binding does it for you in the Condition Item. The ConditionID does not have much use. It looks like your Condition Item is setup for the ConditionID.

Where would I change that at? In the Items file?

Yes, if you have one. If not, and you have Simple Mode turned on, turn it off. Then modify the Item in Paper UI.

I’m using this binding, but I’m having an issue using the temperature in a rule. Can someone please point me in the correct direction?

item file:

Number:Temperature localCurrentTemperature "Current temperature [%.1f %unit%]" 						  <temperature> 	(Weather)	{ channel="openweathermap:weather-and-forecast:c5e7a131:local:current#temperature" }
Number:Temperature localDailyForecastTodayMinTemperature "Minimum temperature for today [%.1f %unit%]" <temperature> 	(Weather)	{ channel="openweathermap:weather-and-forecast:c5e7a131:local:forecastToday#min-temperature" }
Number:Temperature localDailyForecastTodayMaxTemperature "Maximum temperature for today [%.1f %unit%]" <temperature> 	(Weather)	{ channel="openweathermap:weather-and-forecast:c5e7a131:local:forecastToday#max-temperature" }

Rules:

rule "Summertime"
 when
 	Item localCurrentTemperature changed
 	
 then
	val localTemp = localCurrentTemperature.state as DecimalType

 	if(localTemp as Number > 79)  {
 		sendCommand(Summer, ON)
 		logInfo("Summer", "It is hot outside!")
 		}
 	else sendCommand(Summer, OFF)
end

Error log:

2019-02-19 15:53:31.209 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Summertime': Could not cast 85.424 °F to org.eclipse.smarthome.core.library.types.DecimalType; line 736, column 18, length 44

I would really like to use the max daily temp to drive my virtual switch, but my understanding is that those only return on paid accounts.

Thanks in advance!

1 Like

Thank you 5iver! That is just what I needed!

If you are using an Items file, then forget about about Simple Mode. Your Item is linked to the proper Channel for the currrent condition, so you must have some other Item with the same label that is linked to conditionId.

Oh… you withdrew your post.

I’m not sure what was wrong, when I came back to the screen tonight it was working like it was supposed to and I didn’t change anything.

1 Like

I’ll have to go back and look in the Paper UI. I just updated the screen and it changed back to 800 again!! Thanks for point me in the right direction!!

John

5iver
Sorry about removing the reply. I thought I found the problem. In digging into this deeper, I started looking into these two lines in the Items file.

String localCurrentCondition "Current condition [%s]" <sun_clouds> { channel="openweathermap:weather-and-forecast:api:local:current#condition" }
Image localCurrentConditionIcon "Icon" { channel="openweathermap:weather-and-forecast:api:local:current#icon" }

The first line that includes the <sun_clouds> always displays the sun_clouds icon no matter what the weather is. It is the second line that displays the current weather icon and is displayed like this with the current weather icon one line below. As I have been checking the Paper UI settings and the Items file, I have seen the current number number change between the current number and the text it represents and back again.

I have checked the variables as you suggested before and double checked the Paper UI settings and didn’t see any duplicate settings there. Any other ideas or suggestions to fix this?

Thanks

John Frankforther

This is normal. It will be static, but the Icon Item will change. The Icon will take up two rows, but that is a limitation of the Basic and Classic UIs. Look into Habpanel if you want something prettier.

Take a look at the ConditionID Channel in Paper UI> Configuration> Things> your OWM weather and forecast Thing. Check if your localCurrentCondition Item might be linked to that Channel. If not, maybe @cweitkamp would have an explanation how this could be occurring. You’re using OH 2.4 stable?

5iver
Yes, I’m running the current version if OH2.x as I just updated everything yesterday.

I was looking in the things file and tried commenting out the line for the

Thing uvindex local "Local UV Index" [location=long,latit",forecastHours=0, forecastDays=7]

and that seemed to fix the problem with the text not showing up for the current condition.

The Thing files in the doc are just examples, for those who want to use files. Much easier, IMO, to create/manage Things in Paper UI. It’s good that you have learned how to make unmanaged Things though! I still do my Items this way.

Glad to hear it’s all working now!

I have The OpenWeatherMap running well. Tonight I noticed there was no wind direction displayed. I am using this for the windscale:

[0..22] = North
[23..45] = NorthNorthEast
[46..67] = NorthEast
[68..90] = EastNorthEast
[91..112] = East
[113..135] = EastSouthEast
[136..157] = SouthEast
[158..180] = SouthSouthEast
[181..202] = South
[203..225] = SouthSouthWest
[226..247] = SouthWest
[248..270] = WestSouthWest
[271..292] = West
[293..315] = WestNorthWest
[316..338] = NorthWest
[339..360] = NorthNorthWest

and the Item file that goes with it:

Number:Angle localCurrentWindDirection "Current wind direction [SCALE(wind.scale):%s]" <wind> { channel="openweathermap:weather-and-forecast:api:local:current#wind-direction" }

In checking the log file, I noticed the wind direction angle was reading 67.5xx. I was reading about this in the Scale help file. It looked like they were showing whole numbers only. What do you do with readings that fall in between the whole numbers? Would I have to change the %s to something like %.0f?

John Frankforther

Yes, like in the example, which uses %d… OpenWeatherMap - Bindings | openHAB

That is because 67.5 is not included in your scale file.
On my phone but it should look like this:

....
[46..67[
[67..90[
....

See the scale transformation docs for more details

2 Likes

Thanks, Guys!!
I did go through and read the Scale docs before I tried putting the open bracket on the leading number like this ]46…67] and got a screen full of errors in the log file. I did not try putting it on the trailing number as suggested or changing the data type.

Thank you for the link to the OpenWeatherMap docs I didn’t know that was available yet.

*added note… I tried putting the opening bracket on the trailing number …67[ and it gave me no displayed wind direction. Vince, I read your reply closer the second time and I did not put the numbers together as you displayed, the 67 on both lines. That is why it didn’t work.

[46..67[
[67..90[

I’m still learning!!

Thanks again!!

John Frankforther

I implemented the daily forecast min/max ranges (temperature, pressure, humidity, wind speed) and daily sum values (rain, snow) with plain rules and by relying on a strict Item naming convention so I can use lambdas to perform the computations (saves writing lines of code). I use group-based persistence for the OWM Items.

To properly forecast the weather parameters for the current day:

  • use the current values as starting values for min/max
  • include all forecast parameters for which the forecast timestamp fits in the current day

The boundary case where the first forecast is for tomorrow instead of today, is also the only in which the free 12hour (5 day) forecast values can fully be used for generating full-day min/max/sum daily forecasts. Otherwise the 5th day will miss values (those corresponding to the forecast values that fit in the current day).

It would be great if we could use UoM for displaying the min and max values in one range Item, but I don’t think OH supports this.

You can find my experimentation and musings here: OpenWeatherMap daily forecasts with free API using plain OpenHAB rules - #13 by shutterfreak

I still need to correct the forecast calculation for the current day (less trivial due to odd OWM current rain/snow data that always returns 0) and for the boundary case in which the first forecast timeframe (03h) is for the day after the current day (trivial fix).

I expect that computing the total rain and snow of the current day won’t work with OWM as we don’t have access to historic data with a free account, and the current snow/rain values are always zero.

Hello Christoph,

thanks for your binding supply.
There is one issue, that makes some troubles to me.

As far as I know, openweather API tags the rain value with “3h” if this value came out of the weather model. If there is a nearby weather station, the rain value is tagged with “1h” to be more precise.
And here is the problem, because the binding will not proceed with this 1h value, right? I had a short look to your code, and it seems to me, that the rain channel doesn´t support this value.
Maybe, this can be changed very easily…and this would also improve the binding.
Thanks very much in advance.

Sebastian