Shelly Plus H&T Wireless Temperature Sensor to Emoncms via MQTT

The Shelly Plus H&T is a WiFi connected temperature and humidity sensor with a nice e-ink display and local MQTT connectivity which can be used without the involvement of any cloud service.

Unfortunately Shelly use a JSON MQTT structure, therefore it can’t be connected directly to emonPi / emonBase MQTT, I used a simple nodeRED flow to decode the MQTT and post to the emonPi / emonBase:

  1. Connect Shelly Plus H&T to local WiFi network, following Shelly user guide
  • Put Shelly into WiFi AP mode by pressing the button on the back
  • Connect to Shelly WiFi AP
  • browse to
  • Enter in local WiFi details
  1. Configure Shelly MQTT to connect to emonPi / emonBase MQTT broker
  • Wake up Shelly using button on the rear
  • Connect to Shelly on local WiFi network using local IP
  • Configure MQTT as follows:
    – MQTT prefix: shelly
    – hostname: emonpi
    – username: emonpi
    – password: emonpi2016
    – Enable all status updates

At this point we can use MQTT explorer to connect to emonPi MQTT using the same credentials and see the data coming from the Shelly:

We’re interested in the temperature reading on topic shelly/status/temperature:0, as you can see this temperature reading of 23.1C is in JSON encoding, let’s use nodeRED to decode this and re-publish it to the correct MQTT structure of emonPi:

  1. Install NodeRED on emonPi / emonBase: Running on Raspberry Pi : Node-RED

Import this nodered flow which subscribes to MQTT topic shelly/status/temperature:0, extracts the temperature value from the JSON and then publishes the numerical value to emon/shelly/indoorT.

[{"id":"f3520e0179695c89","type":"mqtt out","z":"41627eb6fef015f6","name":"","topic":"emon/shelly/indoorT","qos":"","retain":"","respTopic":"","contentType":"","userProps":"","correl":"","expiry":"","broker":"440a5329ca832801","x":580,"y":200,"wires":[]},{"id":"440a5329ca832801","type":"mqtt-broker","name":"","broker":"localhost","port":"1883","clientid":"","autoConnect":true,"usetls":false,"protocolVersion":"4","keepalive":"60","cleansession":true,"birthTopic":"","birthQos":"0","birthPayload":"","birthMsg":{},"closeTopic":"","closeQos":"0","closePayload":"","closeMsg":{},"willTopic":"","willQos":"0","willPayload":"","willMsg":{},"userProps":"","sessionExpiry":""}]

The data will then appear in local Emoncms Inputs and can be logged to a Feed, I would recommend using ‘variable interval’ Emoncms feed type since the Shelly only posts data when there is a change in temperature rather than periodically ever x seconds.

The update rate seems good enough for indoorT monitoring, I’m currently powering the unit via USB-C, I’m not sure if the update rate will be slower if running on batteries:


Funnily enough, I was talking to a pal who I’m putting a heat meter in for and we were talking through the options for getting indoor temp into the heat meter app.

I take it there’s no timescale on the emonTH stock?

A battery powered option would certainly be the preferred route.

Personally i’ve got a Xiaomi Aqara zigbee sensor hooked up to my Home Assistant setup, with a HA trigger to post to emoncms every 5 mins via a POST API call.

So un-pretty!!! :rofl:

The emonTH situation is very frustrating, the main issue is global unavailability of the SI7021-A20-GM1R temperature and humidity sensor we use on the emonTH, we’re looking at alternative sensors, but this was a very nice sensor with very low power consumption. Hopefully we’ll be able to source stock of these sensors soon, or we may need to compromise and go with another sensor. Another option is to drop the humidity sensing and just us a DS18B20 for temperature only sensing…

I’ve used Govee recently (though the price has gone up) and ble_monitor in HA to get the data. Cheap and easy to setup.

I have a generic Node-RED flow that sends data for all the temperature (and humidity) devices in HA to emon via MQTT JSON message regularly. The generic nature, means if I add a device to HA, it just appears in emoncms!

1 Like

BTW @glyn.hudson, do you notice any difference in readings between the TH and the Shelly devices?

I notice wide variations between devices of the recorded Temp/Hum and the rates of change (or reaction to change).

I’ve not yet done a proper comparison, the data I have is with the two sensors at opposite ends of a room, however the rates of change looks pretty similar.

I’d be interested to see when next to each other. I consistently see different max/min in particular.

That’s pretty cool, BLE will be much lower power than wifi so more suitable for battery powered sensor nodes. Can you use the BT built into a RasPi to receive the data? Or do you need a BT dongle?

Yes and it is one of those things that ‘just works’. My smart scales just work, no need to even go near any Chinese app.

Yes I think can (not certain - I have 2 external dongles as not on a Pi). The ble_monitor (ble_monitor/ at master · custom-components/ble_monitor · GitHub) started life as an add-in to HomeAssistant, but has largely been adoped by the core team with the original author heavily involved. The adoption is not complete so I am still on the add-in. There were discussions about having a stand-alone version of ble_monitor a while back, but I suspect that option has passed.

1 Like

That does look nice for £15, could be just the ticket.

Just need someone to write an emonhub interface entry for it and we’ll be golden!! :wink:

I don’t think the ble part is that simple, unfortunately. However, you use HA so it is simple :slight_smile:

I use to monitor prices on Amazon. Often they do lower the price regularly. I got the last one recently for £12 IIRC.

1 Like

Yeah, i’m cool with HA, but was thinking about an easy to use solution for the non HA people.

1 Like

A DS18B20-only version would be great! Anything for some stock. I planned to add a few to outdoors anyway, so I’d only be using the DS18B20 to get that weatherproof enclosure seal.

Question though: would the battery life be the same with DS18B20 as it is with the Si7021? I know the emonTH v2 got its longer battery life mostly from the switch to the latter, but didn’t see any info on battery life when using a DS18B20 probe.

The emonTH V2 got longer battery life because of the switch from DHT22 to Si7021

The DS18B20 is low power, battery life with a single DS18B20 should be very good if not better.

We’re considering using the AVR128DB32 MCU for the emonTH V3, this may result in even better battery life since it looks like the AVR128DB32 should be more efficient then ATmega328p that was used on the emonTH V2

1 Like

That’s great news. Looks like I’ll have to do with a cheapo 433MHz weather station sensor with an NTC thermistor that’ll go bad outdoors before long until the emonTH v3 comes out, which would ideally just have a DS18B20 (but I’m being selfish) and last years.

1 Like

I use quite a lot of Shelly devices with node red. Good to see the new Shelly H&T works well. The older ‘golf ball’ one i found to be quite unreliable. It would work well on an internal battery, but didnt last long. Unfortunately i found using an external battery pack (to give longer life), it would fail to wake up. I’ve seen other people report this on the Shelly Forum. Shame because its a nice cheap sensor.

3 posts were split to a new topic: MQTT Proxy to modify topics

I just noticed this device (i.e. Shelly Plus H&T) because of this thread, but when I read the reviews on Amazon the first few very uniformly are bad because of unreliable readings. Can anybody who has one confirm or deny these reviews?

BTW this device also has BT, apparently.

Just continuing the original thread, ESPHome has a pretty simple method of collecting data from Xiaomi devices. I’ve used the LYWSDCGQ devices extensively in my house (but with the BLE_Monitor method of pulling the data). With ESPHome you can easily set the base topic or a full topic the data should be sent on (in addition to going to HA via their API).

I got a few of those Govee sensors (based on Borpin’s recommendation) and they were stupidly quick to setup in Home Assistant through Govee BLE integration.
That’s just using built-in Bluetooth on Raspberry Pi (running Home Assistant) and nothing else.

1 Like