[SOLVED] HABPanel - What am I missing?

Hello everybody,

Here I am again facing a new problem that I can’t fix and I’m sure it’s just me learning openHAB. I really enjoy configuring this system, but sometimes it can be a real pain. Like this time.
I’m experimenting with HABpanel. It’s a real nice interface for many kind of systems and it is really nice to design in it. I specially enjoy the ‘Sjabloon’ template where you can insert items with a html design. I’m still finding out the possibilities, especially with angular, witch is new for me.
So I wanted to display weather information with the meteoblue binding. I must say they have the kindest support department. I asked a lot of questions and they all gotten answers. Understanding meteoblue parameters and finding out the weather icons and finding out that I can provide my own images made me glad. So I got a free api key and I can display weather data for the next 5 days in my sitemap and everything works very good. I can even control my home automation system with it. I had to create an interface between openHAB and the HA system. Found out Eclipse and created my own jar file.
Then came HABPanel and really openden my mind to find out witch possibilities there are :-). I started to create an interface to my weather interface:

<table class="table">
  <tr>
    <td class="text-left">Temperatuur:</td>
    <td><strong>{{itemValue('todayTempL')}} - {{itemValue('todayTempH')}}</strong></td>
  </tr>
  <tr>
    <td class="text-left">Regen waarschijnlijkheid:</td>
    <td><strong>{{itemValue('todayPrec')}}</strong></td>
  </tr>
  <tr>
    <td class="text-left">Regen:</td>
    <td><strong>{{itemValue('todayRain')}}</strong></td>
  </tr>
</table>

with this item as result

See that long number? I’m sure you can.
This is the item:

Number:Length todayPrec     "Total Prec. [%.2f in]"  <rain>  (weatherDay0)  {channel="meteoblue:weather:metBridge:A51:forecastToday#precipitation"}

And this is how I configured ‘temperature’ :

Number:Temperature  todayTempL  

"Low Temp [%.2f °C]"   <temperature>  (weatherDay0)  channel="meteoblue:weather:metBridge:A51:forecastToday#minTemperature"}

Both have the same definition for rounding the value:

[%.2f °C]

And yet temperature is rounded but todayPrec isn’t. And I have no idea why. It’s not that I messed up my system. I run on a raspberry pi and everything else runs just fine. Only that 1 value !?
This is something I can’t understand and hoping that somebody here can figure out what the solution is?

1 Like

Could you show the definition of the second item todayRain

1 Like

Sure, that probably a beter comparison :wink: Thanks

Number:Length todayRain     "Rainfall [%.2f in]"  <rain>  (weatherDay0)  {channel="meteoblue:weather:metBridge:A51:forecastToday#convectivePrecipitation"}

Looking at the definitions I would also expect both to show only two decimals.
However I never used anything with “units of measurement”, so I might proof wrong.
IMHO the value for the probability of precipitation, as I understand your label, is not expressed in inches. So the problem.MIGHT be there.

1 Like

Thanks but I guess then if I do this:

Number:Length todayRain     "Rainfall"  <rain>  (weatherDay0)  {channel="meteoblue:weather:metBridge:A51:forecastToday#convectivePrecipitation"}

Then we see ‘in’ in the :

I never encoded the in, so it must be coming from the variable?

For todayRain I would expect to see inches as the unit of measurement, so it could be coming with it, BUT for the other item, I would expect a percentage ( at least if your labeling is correct).

[EDIT]
I am wrong as your labeling is also wrong. The used channel is also giving precepitation and not a probability.
So I have no clue so far why this item is showing more then 2 decimals.

1 Like

Hmm guess I made a wrong translation, google calls it convectieve neerslag. Never heard of it. Maybe I don’t even need it for my template but it’s weird that it doesn’t shows up correctly. I want to understand this.

What happens which you switch the types and units around, how does that effect things. Is it just the in surfix that changes things or is it the :Temperature that actually changes things. This is a kind of debugging question where you start changing one item into the other and then you’ll find the feature or things that causes it to change.

I’ve never used the Number:Type syntax before so I would suggest trying

Number todayPrec     "Total Prec. [%.2f in]"  <rain>  (weatherDay0)  {channel="meteoblue:weather:metBridge:A51:forecastToday#precipitation"}

Also I would usually bind an item through paper UI rather than directly to the channel directly. See if that work, and look at the paper ui item to see what’s different.

1 Like

Thanks for your advice, but then I have NULL

Number todayPrec     "Total Prec. [%.2f in]"  <rain>  (weatherDay0)  {channel="meteoblue:weather:metBridge:A51:forecastToday#precipitation"}

What you think is the difference, “binding” an item through PaperUI is linking it to a channel.

Anyway, paperUI everything is fine and I have this Thing:


Also with the reference to Number:Lenght.

seems like @unparagoned was right. First I had a NULL as you can see in screenshot and after some time it came through. This was a direct copy from the tutorials, I guess everybody can make mistakes :wink: I’m glad you found it, @unparagoned, well done!

I moved the topic to the HABpanel category.

It would be nice if you updated the tutorials. There is a link at the bottom of the page that takes you straight to the file in github. See How to file an Issue for details, particularly the “I Can Fix It Myself” section.

What you think is the difference, “binding” an item through PaperUI is linking it to a channel.

When you use paperui it has some default unit options, etc. In this case there is no issues with connecting the item with the channel, but something around the options/unit types. That’s why I suggested it, not that I thought it was fundamentally different but because it would probably fix any mistake and then it should be easy to fix the problem or realise there is something weird going on.

thanks for your reply @unparagoned. It still plays around in my mind, I did some further testings and found out that I had the same issues with wind speed and could solve it the same way.

In my weather items I had to define them like this

Number  todayWindSpL   "Low Wind Speed [%.2f kmph]"   <wind>  (weatherDay0)  {channel="meteoblue:weather:metBridge:A51:forecastToday#minWindSpeed"}
Number  todayWindSpH   "High Wind Speed [%.2f kmph]"  <wind>  (weatherDay0)  {channel="meteoblue:weather:metBridge:A51:forecastToday#maxWindSpeed"}

Without the option ‘:Speed’ otherwise I had those long numbers.
Still can’t grasp why there is this difference.

@rlkoshak I’ll have a look on how to add this to the tutorial.

EDIT @rlkoshak made a Issue on
https://github.com/openhab/org.openhab.ui.habpanel/issues/356

I suspect it’s because of what Units of Measure do. They are a way to tell OH “this Number represents a measurement”. All measurements have units (degrees F, miles per hour, etc.) and many/most measurements have different units.

When you use the number, you need to tell OH what units you want to use. So even if you are receiving, for example degrees C from the binding, you can tell OH you want degrees F and OH will automatically convert it.

But, if the units you want to use differ from the units received that means OH has to perform a calculation. And that is where the long list of decimal points comes from. Computers are actually pretty bad at floating point math. Without going into the details, it is impossible to represent every decimal number the way that floating point numbers are usually represented in computer languages. Consequently, for example, the number 9.2 is impossible to represent. Instead you would get 9.1999999999999993 which is really really close, but not exactly 9.2.

What likely happened is when it converted the wind speed from mph (or whatever units the binding provides) to kmph one of the floating point number involved or the answer cannot be represented as a floating point number in Java. So you have an answer with a lot of decimal places that is really really close to the correct answer, but not exactly the correct answer.

:+1

1 Like

@rlkoshak: Thanks for the clarification.