Remote temperature sensors

For context: This thread is a much delayed response to the Wireless Temperature Sensor thread. The same general topic was also brought up in the Portable Remote Sensor thread and most recently in a comment on the thread about hardware availability.

The goal is to write documentation on how to customize the HestiaPi to be able to use one or more remote temperature and humidity sensors, either in place of or in addition to the sensor on the HestiaPi itself.

For this thread, I’d like to limit the discussion to sensors that speak MQTT. Other sensors can be handled separately.

HestiaPi remote sensing plan

The HestiaPi is configured to run an MQTT broker. If you’re not familiar with MQTT, InfluxDB has a pretty good page introducing it, but the main point is that MQTT clients publish (send) messages to a MQTT broker (server) and the broker notifies any clients that are subscribed.

In our case, we will create an OpenHAB “thing” and configure channels to listen to multiple MQTT topics (channels) for each attribute that we care about (temperature, humidity, barometric pressure, etc.). Each channel will be linked to an “Item”, which is where the data is stored.

After that is working, we should be able to update the “Rules” (javascript code) to implement whatever logic we want. The logic for when to turn on the heat/cooling could look at one temperature sensor during the day and another one at night. It could look at the last update time and decide to use the other sensor if it hasn’t gotten data recently enough. The sky is the limit, as long as you are willing and able to write some Javascript code.


This is a draft of the short version of the instructions that I wrote to get remote temperature data into OpenHAB on the Hestia Pi ONE. When they’re refined a little more and some gaps filled in, I’ll make sure they get put on the wiki and in the manual in the official git repo.

Make an item to store the data

OpenHAB → PaperUI → Configuration → Items → (+)

  • Name (can’t have spaces): livingroomtemp
  • Label (human readable, can have spaces): Living Room Temperature
  • Category (optional, leave blank)
  • Type: Number
  • Dimension: Temperature
  • Parent groups: Sensors, Proxy
  • Auto update: Enforce an auto update

Click the plus in the blue circle at the top to save.

Docs: Items | openHAB

Make a thing to represent the sensor

OpenHAB → PaperUI → Configuration → Things → (+) → MQTT Binding → Add manually → Generic MQTT Thing

  • Name (human readable, can have spaces): Living room sensor
  • Thing ID: livingroomsensor
  • Location: Sensors
  • Bridge selection: Mosquitto MQTT Broker
  • (leave the rest blank)

Click the checkmark in the blue circle at the top to save.

Docs: Things | openHAB

Add channels to the thing

This example matches the Thing that was created in the previous example. The text below is for adding temperature. Repeat the process for humidity, barometric pressure and anything else you want to get from the sensor.

OpenHAB → PaperUI → Configuration → Things → Living room sensor → Channels (+)

  • Channel type: Number Value
  • Channel ID (no spaces): temp
  • Label (human readable): Temperature
  • MQTT State Topic: homemade_sensor/living_room/temperature

Typically, temperature/humidity sensors that support MQTT will let you specify the MQTT State Topics. If they do not, then you will need to make the topic in OpenHAB match whatever the sensor is configured to use.

The “MQTT State Topic” can be pretty much anything you want as long as you’re consistent, but the pattern in the example is a typical pattern. You may have other home made sensors in other rooms, or entirely different types of sensors.

Make an Item to hold the local temperature

We are going to have the new sensor update the temperature field that is shown on the LCD display and in the web UI, but we will want to make sure that the HestiaPi’s built-in temperature sensor doesn’t try to continue also updating this item.

We will create a new item that can hold the value obtained from the local sensor allowing us to continue to use it later, if we decide we want to.

OpenHAB → PaperUI → Configuration → Items → (+)

  • Name (can’t have spaces): localtemp
  • Label (human readable, can have spaces): Local Temperature
  • Category (optional, leave blank)
  • Type: String
  • Parent groups: Sensors, Proxy
  • Auto update: Enforce an auto update

Click the plus in the blue circle at the top to save.

Re-linking local sensor to new item

The item that holds the temperature is labeled “Temperature” and it is named “MyTemp”. We want to have our remote sensor update this item, but first we want to tell the local temperature sensor to stop updating this. We will then link the local temperature sensor to the Local Temperature item that we made for it previously.

OpenHAB → PaperUI → Configuration → Things → Temperature Sensor

Under channels, click the blue concentric circles to the left of the “Output” channel, then click the trash can icon to the right of the linked item “Temperature (MyTemp)”.

While still in the Output channel of the Temperature Thing: Next to Linked Items → (+)

  • Profile: Default
  • Item to link: Local Temperature (localtemp)

Click the Link button to save.

Change MyTemp type

OpenHAB → PaperUI → Configuration → Items → Temperature (MyTemp) → Pencil icon

Type: Number

Click the check mark in the blue circle at the top to save.

It’s important to leave the Dimension blank here. Setting it to Temperature will result in an incorrect conversion from Celsius to Fahrenheit (so it’ll convert 0F to 32F, which is obviously undesirable).

Link the channel to the item

MyTemp is not available under the default profile, so we have to switch to Follow and then put the Profile back to Default.

OpenHAB → PaperUI → Configuration → Things → Living room sensor

Under channels, click the blue concentric circles to the left of the Temperature channel.

  • Profile: Follow
  • Item to link: Temperature (MyTemp)

Then click on the concentric circles and edit the linked item to put the Profile back to Default.

Repeat this process to also link it to the “Living Room Temperature (livingroomtemp)” item.

Docs: Configuration though Paper UI | openHAB

Verify our work

This is just to test to verify the item is updated when the MQTT message is sent.

OpenHAB → PaperUI → Control → SENSORS

You should see the Items you added here (local temperature and living room temperature). The values will be missing (e.g. a NaN or a -). To set the temperature, SSH into the HestiaPi and run the following:

sudo apt install -y mosquitto-clients
mosquitto_pub -h localhost -p 1883 -t "homemade_sensor/living_room/temperature" -m "25.6"

Note: This can also be run from another machine and changing localhost to the IP address of the HestiaPi.

As soon as that command is run, without refreshing the page, the living room temperature value should be updated. On the CONTROLS tab, you should also see the same temperature appear for the “Current Temperature” (Under "Sensors and Setpoints). If you look at the LCD on the HestiaPi, you should also see that same temperature there.

Open Questions

  • How can we make our sensor appear under OpenHAB → PaperUI → Control → SENSORS (instead of only being listed under OTHER)? (updated post to include this)
  • Is the local thermostat UI hardcoded, or will changes in OpenHAB affect that UI? OpenHAB changes won’t affect the LCD UI
  • How can the main OpenHAB -> Basic UI page be updated (e.g., to display the additional sensor)

I do realize that the UI is the hard part with this feature request and that it’s likely nobody has direct answers to these questions, but even pointers to resources (blog posts, documentation, etc.) would be helpful.

1 Like

It’s been many years since I’ve done anything with PaperUI, but IIRC the Control page is organized based on the Location property of the Thing.

It’s a completely separate application. It gets populated via the MQTT messages. Additions to OH should not impact that, but that also means that additions will not appear there either. I never did any direct work on that so am unfamiliar with what it takes to make changes.

It’s defined in /etc/openhab/sitemaps/<I don't remember the name>.sitemap. See Sitemaps | openHAB for the syntax but you should be able to see that file and copy/paste/edit the relevant lines.

Excellent. Thanks @rlkoshak, as always. I’ve updated the post to include setting the location, which does make it appear on the sensors tab.

I have some ideas on how to link things together and plan on experimenting in the next few days.

I’m not sure if I’ll want to modify the basic UI for this change or not, but I certainly will for another change (but I’ll save that for another thread).

What do you think about the temp/humid sensors from SwitchBot? We have about 8 of them scattered in the house, attic and vents. A 4 pack is about $40 on Amazon and this article seems to indicate MQTT support through sbm2mqtt. Also totally new here, and getting my thermostat on Monday, so early apologies if I spout out stuff that’s already been discussed.

Based on the documentation, those should work.

In the end, we’ll probably have multiple sections of the documentation along the lines of:

  • Adding remote temperature sensor (MQTT)
  • Adding MQTT support to SwitchBot Meter
  • Adding MQTT support to Ruuvi Tags

I believe the first one can be set up entirely from a web browser, so it should be accessible to anyone. The subsequent sections will be for people who are comfortable with setting up servers, debugging tech issues and so forth (developers, IT people, etc.)

I got this working on my local HestiaPi and updated the instructions in my original post with the steps that I think I did. Now I am flashing a fresh firmware image onto an SD card so I can blindly go through the guide and verify that it’s accurate (nothing left out, incorrect, etc.).

After I confirm I understand everything and the guide does what it says on the tin, I plan on making a diagram to make the whole process easier to understand. If nothing else, it’ll help me later when I go to set this up again or need to help someone do the same.

Before you proceed any further I would challenge the range of these remote sensors as to if BLE can reach you HestiaPi from anywhere you want to put them in or around the house… Check that first with a phone instead of HestiaPi and then try integrating just one into openHAB.

I also found that HomeAssistant (and possibly others) seem to prefer their MQTT data as JSON objects. The current configuration on the HestiaPi does not. They expect just the value.

While they could be changed, this would likely require a bit of work (OpenHAB rules, possibly the LCD UI, etc.). If we find that most temperature sensors can just send temperature value on the temperature topic, the humidity on the humidity topic, and so forth, then it should be easy to add them.

On the other hand, if they only support sending them in JSON format over MQTT, then I think it’d probably be worth the effort to update the HestiaPi configuration to do the same.

Edit: It looks like there is the same issue with the code that grabs data from the SwitchBot meter.

IMO that’s a violation of MQTT principles. MQTT should not impose work on its subscribers meaning it should publish stuff that has to be parsed if it can help it. Just because HA does that doesn’t mean it’s right, at least from an MQTT perspective. Tools like zigbee2mqtt and others offer both JSON or using the MQTT topic hierarchy to structure the data.

But just because they do it wrong doesn’t mean we can’t deal with that.

Off the soapbox…

It doesn’t have to be all or nothing. So long as the JSON gets pub/sub’ed to different topics there shouldn’t be a problem with internal HestiaPi MQTT stuff.

Receiving JSON from an external sensor should only require creating a Thing and configuring the Channels with the JSONPATH transform to extract the data required, assuming it’s valid JSON. If not a REGEX transformation could be used. There should not need to be any changes to existing MQTT stuff, just additions.

Publishing JSON to something else is going to require a rule and the publishMQTT action.

If you did want to convert everything to be JSON encoded, that’s going to require changes to openHAB configs including some new rules as well as to the UI. And I’d still maintain it would be foolish to have OH encode something as JSON and the UI to have to parse it.

Wow, I did not realize that there was a transform feature in the channel! I was planning on updating the rules to try to parse a JSON object and then fall through to a value, but this is way better. Thank you so much. You just saved me a bunch of work doing this in a way that would have ultimately been inferior anyways.

I’ve updated my system and now am successfully using a Ruuvi tag to provide the temperature that appears on the HestiaPi’s LCD screen and is used for making decisions on when to turn the heat on or off.

Sadly, it seems that I can’t edit my initial post anymore. I guess it locks after a while.

At any rate, based on @rlkoshak’s comments, here are the changes I would have made to my initial post if I could:

Install JSON Path Transformation Add-On

(This goes before the “Add channels to the thing” section)

OpenHAB → PaperUI → Add-ons → Transformations tab:

  • Install JSONPath Transformation

Add channels to the thing

The “MQTT State Topic” will be sensor specific. For Ruuvi tags, set this to ruuvi/YourBTMACAddress (e.g. ruuvi/AA:BB:CC:DD:EE:FF). Then click “Show More”, and set “Incoming Value Transformations” to “JSONPATH:$.temperature”.


I’m going to write up all of these instructions (specifically for a Ruuvi tag, since that’s what I have to test with) and put it onto the wiki and into the owner’s manual. That way people can have it whether they happen to be online or not (assuming they downloaded the owner’s manual at some point).

One other trick is there should be support for transformation chaining on the Channel in the MQTT binding. Where this becomes powerful is when you have multiple different JSON messages being published to the same MQTT topic. In that case you can put a REGEX transformation to test if the message has some marker indicating that the following JSONPATH will be able to process it. If it doesn’t match, the message is silently dropped instead of generating an error in the logs.

I don’t know if that will be needed here, but wanted to mention it just in case.