Netatmo in F not C

So this is driving me nuts. I have a Netatmo weather station which I used on OpenHab 1. I’ve since upgraded to OpenHab 2. I am certain that there was a mechanism in OpenHab 1 to convert the temperatures from C to F, Possibly a binding option but the OpenHab 2 version only has things entry. I can’t find an option anywhere to tell it that I want my temperatures in F. I know I could create a fake item and update with the converted number but before I do that I thought I would ask if anybody knows a simpler way to do this.


Hi Mark,

what about the Netatmo App? Did you switch the temperature units to imperial system over there? If so, which values does the OH2 Netatmo binding return? Celsius or Fahrenheit? I must admit I didn’t test that on my own.

I am still using the OH 1 Netatmo binding because it doesn’t support units other than metric. This plus some other functionality that is missing from the OH 1 binding.

The app is returning F. I checked the application set up on Netatmo’s website, the binding and looked to see if one could perform a mathematical transformation on a state. No luck. OH2 is setting the temperature items to values in Celsius.

So I’m not wrong then. The OH1 binding had the option to do this. I may follow your lead on this then. I really don’t want to set up a fake item for every temperature item in Netatmo. It just creates clutter.

I added the functionality to the OH 1 binding. Here’s the parameters I use:


Thanks for the pointer. I’ll try this later. Seems to be a step backwards in the OH2 binding :frowning:

1 Like

Ah, I see. I never tested that on my own. Changing the units in the Netatmo App doesn’t affect the API. Nice to know.

No, it isn’t. The idea is to have an overall unit conversion in the framework. Not in each binding. The development is currently in progress. See

Looks like the issue is still open and hasn’t been touched in a year and a half!

And worse, you see that open enhancement request used as the reason bindings aren’t getting updated to do it themselves all the time.

That’s true. Very sad. I am completely with you.

But that doesn’t mean that we are helpless right now. Even if the most bindings won’t have this feature on their own we as user are able to handle it by using some kind of transformation to get the units we are familiar with.

As far as I can tell from my research, you can use JavaScript to manipulate the number for display but the value in the actual item stays the same. It will display in F but all my rules such as “if the temperature drops below 32F” will need to be altered to test for 0 instead of 32.

Maybe you want to create two items. First one linked to the Netatmo channel. It stores the Celsius value. The second one meant to store the Fahrenheit value and matches your current item. You create a rule which triggeres everytime the first item has changed and calculates the value for the second item. In this setup you don’t have to adopt every existing rule in your environment. Wdyt?

Isn’t the whole point of OH2 to make it easier to use than OH1? wtf…

Really what I think is that the binding developer, in this case Netatmo, should not have relied upon vapourware. I will be able to resolve this but right now I am leaning towards a node js script that reads the Netatmo values, converts them and then sets them in OpenHab with a MQTT message. It would be fairly quick and easy script to implement. I’ll comment out the {} on my items and then when (if ever) the data conversion ever gets implemented I’ll trash the script and go back to the binding.

In the end I just modified my rules and changed the value with a JavaScript transformation. I scrapped node js idea even though there is a solid Netatmo library but I didn’t want to maintain another process. Also the snapshot version of the binding makes some reference to transformations that might be available but the docs were a little sparse. It looks as if you just need to drop files with specific names in the transformation directory. I’m not running snapshot yet though.

Actually this is more annoying than I originally thought. I came to find that not only do I have to modify my rules, that was a small number of changes, but also I had to modify the valueColor statements in my sitemap because it is displaying the result of the JavaScript conversion but testing the original value so <32 had to become <0 etc.

I am sorry for that.

I have some good news. There has been submitted a PR three days ago which addresses the unit conversion. Hopefully the next OH2 version will support this feature.