[Released] WlanThermo Binding

Dear all,

as you know, everything can be integrated into Openhab, sometimes you just need to write a binding :wink:

Same applies for my new BBQ thermometer, the WlanThermo. It started as a DIY project, but can now be bought online as a ready-to-use product. I was tired of always loosing the connection to my bluetooth device, so I bought this Wifi version.

Of course, the next step was to integrate it into Openhab. There were some approaches to use the general HTTP/MQTT binding, but all of them seemed to complex or did not provide the features I was looking for. Besides, I wanted to tackle the challenge of writing my own first binding…

Therefore, I proudly present the WlanThermo binding! :partying_face:

The binding is accessing the device locally via HTTP. Providing the login credentials is optional, if omitted, all channels are read-only.

It provides the data of all temperature channels (current temperature, min/max alarm threshold, …) as well as some general data of the device itself (state of charge, signal strength, …). Additionally, there are some alarm channels you can use in your rules.

Here are some screenshots of the bindings data in BasicUI:

For further details, please refer to the WlanThermo Binding Docs.
You will find examples for the .items and .sitemap file over there as well.

It has been tested with WlanThermo Nano V1+ and Mini. Pitmaster support is currently only available for WlanThermo Mini.

I’d be happy to receive your feedback!

Best regards


  • Since Openhab 2.5.9, the WlanThermo Binding can be installed directly via PaperUI!

Hi Chris,

that’s awesome - I’ll give it a try for sure, but I’ve got very little time at the moment.

Will post feedback here!

Many thanks & KR,

New Version V2 contains an additional channel indicating if the device is online or not.
Download link added to first post.

Hi there,

binding integration - works fine;

287 │ Active │  80 │      │ openHAB Add-ons :: Bundles :: WlanThermo Binding

adding thing / offline-online-status - works fine;

Mapping to items works also fine!

Great job, I’m loving it :)!


1 Like

Glad it’s wokring on your side and that it’s useful to somebody else as well :+1:

Short update - your binding runs stable, already hat 2 BBQ-sessions with it (also ribs with 6+ hours with not a single error/etc.).

Really love this, thanks again!



Hi Chris,

I built a Wlanthermo Mini years ago and wanted to give this a go. No dice so far. I’m new to this setup, so it could just be the way I am doing it. I am working with a fresh install of openhab 2.5.5 and was able to successfully create a thing from Paper UI. However, none of the values come through (even after linking to items). I get multiple parsing errors similar to:

Caused by: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was STRING at line 1 column 1 path $
at com.google.gson.stream.JsonReader.beginObject(JsonReader.java:385) ~[?:?]
at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:213) ~[?:?]

Any idea what could be causing this? It would be awesome if I could get this going!

Hi Frank,
unfortunately, I had no WlanThermo Mini for testing and the documentation of the API for the older versions is rather bad.
However, I’d be happy to integrate the support for Mini as well!

Apparently, the mini provides the API via …/app.php. Can you send me the output you get when accessing this page on your WlanThermo with your browser?
Feel free to contact me via PM for further details!

Best regards

Dear all,

thanks to @FrankK, the recent update added the support for the WlanThermo Mini (including Pitmaster).

Please let me know if everything’s working as expected!

Best regards,

1 Like

Hi thanks for development the binding!
I have a WlanThermo Nano V1+ everything seems to be working except for Signal Strength (wlanthermo:nano:5b3382aa:system#rssi)

its always value “2” in the WLANthermo Web-Page is the rssi value -63dBm
what das the value 2 mean/stand for?

Hi Andy,
you’re welcome! Glad to hear that it’s working on your side as well!

The signal strength is mapped to values working with the “qualityofservice” or “signal” dynamic icons, see e.g. How to use signal level icons?
Unfortunately, there is no real guideline on how to map dBm to the levels, so I implemented a linear scaling as Math.floor(system.getRssi() * -1 / 24).
If someone has a better formula to convert the signal strength, I’ll be happy to revise the implementation.

oha! You shouldn’t calculate it like that.
That would mean bad signal strength, more bars are displayed.

two suggestions:

  • you send the value natively e.g. -57 as shown in the WlanThermo-Webinterface. Then everyone can do what they want with it, e.g. Convert with a rule or map, …
  • You ask the WlanThermoNano developers so that you get the exact formula so that the bar value always exactly matches the number of bars on the WlanThermoNano-display.

by the way, i found a bug :frowning:
while I was playing with the binding (values changed via openhab to thermometer) suddenly a stable connection was no longer possible.
The things went online and offline every second (1000x communication errors in the openhab log).

[hingStatusInfoChangedEvent] - ‘wlanthermo:nano:bbq1’ changed from OFFLINE (COMMUNICATION_ERROR): Update failed, reconnecting… to ONLINE

openHBA restarted, all openHAB Temp-folders deleted without success. Already wanted to send the binding to hell and do everything myself via MQTT. Then I slept over it again one night and noticed that the color of a sensor in the WlanThermo-webinterface is empty. Could re-enact that now. If you change the color value of a sensor via openhab, which the WlanThermo-Webinterface does not know as its standard color and you save the sensor due to another change via the WlanThermo-Webinterface, the color value is empty, which the binding cannot tolerate.

You’re right, did some more research on that topic and the bars are indeed calculated wrong. I’ll update it with the next release and will try to find the according code snippet in the WlanThermo src-code.
The RSSI as a number-item is already implemented, but was not yet included in the last release. :+1:

I’ll also check the issue with the empty color and will try to reproduce it on my side.

Thanks for the feedback!

The issues should be fixed with the latest release.
I was able to reproduce it on my side and do not have any reconnects with the latest version.
RSSI as a separate channel and a fixed signal-strength calculation based on the original display have been added as well.

In this release, Pitmaster support for Nano is implemented as well!

Great News!

Starting with version 2.5.9, the WlanThermo Binding is included in the official releases and can be installed just like any other binding via PaperUI!

Compared to the last beta-version, there have been minor changes:

  • The online channel has been removed. Any channel can be used as an indicator, as it will be set to UNDEF if the device is not available.
  • Improved schedulers

Let me know if anything is not working as expected!

1 Like