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

Integrations
,
12

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

1 Like
13

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.

14

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
15

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
16

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.

17

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

18

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.

21

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).

22

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
23

HA has vastly improved the BLE support in the last few releases. It has not adopted all of the ble_monitor stuff yet, so I’m still using that.

24

I’m still looking for a non Home Assistant room temp solution for a mate of mine that would hook best into emoncms.

He’s got a emonbase (emonTX and heatpump HAT). But no HA at the moment.

There’s no real way of running a DS18B20 into a room unfortunately.

Shelly Plus H&T still the best bet do you think?

25

Quite probably. Other way would be an ESP32 and ESPHome to read the BLE data…

26

Depends on how much of a finished solution they want/need. A Raspberry pi zero W (or Pico W) plus a DS18B20 or a Si7021 would likely be cheaper.

27

While that’s likely, Mick also said:

28

Yes, I know, but that’s not what I’m proposing. No long wires required. I’m proposing putting the Pi and the sensor both in the room, much as you would with the Shelly device. The W on the end of the Pi’s name means it supports wi-fi, which is how it would communicate with the emonbase.

29

If he’s got no wi-fi issues, that would definitely work.

30

Thanks guys.

I doubt my friend would be up for a Pi/pico/boards etc. Think he’d prefer a more ready made / aesthetically pleasing device on the counter side, ideally battery driven.

So in lieu of the emonTH being available, perhaps the Shelley is the way to go.

31

If anyone is considered using ESPHome, then this is a handy resources of devices that can be flashed https://www.esphome-devices.com

32

HI I am a new user just getting set up and have a couple basic questions on this topic. Any guidance would be apricated, thanks!

NOTE: I am currently getting going on the hosted emaonscms.org vs a local rpi/base (but could add that if better)

  1. Is it still the case that the current Shelly H&Ts and their energy reporting smart plugs require a MQTT translation in order to send to emoncms?

  2. Assuming yes to #1, for a limited-skills rpi lunix guy, do you imaging going the nodeRed route or the HA route makes more sense? I have basic experience with both.
    – For nodeRed, since using hosted emoncms I assume I’d run nodeRed and if needed a mqtt receiver on an Ubuntu VM?
    – If HA route, is that easy and reliable?

Note: Its too bad emoncms doesnt have an option to receive variants of mqtt per source.

Thanks

33

Different, not better. You can access more data sources on a local setup via MQTT. the online version is limited to HTTP API.

To an extent, but that would be a lot of work considering the number of different data structures possible. Use a different tool to do the translations.

Use both! HA to receive the data and the Node-RED addon to poll the sensors and send the data to emoncms.

Steep learning curve, but pretty reliable IME and you can do other things with it.

[edit]
Of course HA can then communicate with the online emoncms easily via HTTP.