The case: a Shelly 2PM Gen4 with an Add-on and a DHT21 temperature and humidity sensor. It works for about three hours and then shows nothing; cut the 2PM’s power and it reads again for a few more hours. The pattern has a recognisable cause and a direct fix: the DHT22, which is the one the Add-on supports.
What the API shows
The sensor configured on the Add-on appears as two components, temperature:100 and humidity:100. While it reads, Temperature.GetStatus returns the reading in tC; when the sensor hangs, the value disappears and the component starts reporting a read error.
http://<ip>/rpc/Temperature.GetStatus?id=100Which peripheral the Add-on has configured — and as which type — is what SensorAddon.GetPeripherals tells you. It is the first thing to look at: if it says dht22 and what is connected is a DHT21, that is your explanation.
http://<ip>/rpc/SensorAddon.GetPeripheralsWhy it hangs
- The DHT21 is not supported. The Add-on takes the DHT22, the DS18B20 (up to five), digital and analogue inputs, but not the DHT21 or the DHT11. They share the one-wire protocol, with different timing tolerances: the DHT21 works on and off and ends up locked.
- A locked DHT only recovers when its power is removed. That is why it comes back when the 2PM’s power is cut: it is the only moment the sensor loses its supply.
- The supply is tight. The Add-on gives the sensor 3.3 V and at most 10 mA. An unsupported sensor, at that margin and on a cable, grows unstable over the hours.
The fix: DHT22 (AM2302)
Same wiring — VCC, DATA, GND —, same job, temperature and humidity, and supported. Swap the sensor and, while you are at it, bring the 2PM Gen4’s firmware up to date. If the peripheral was registered as another type, remove it and add it again as dht22:
http://<ip>/rpc/SensorAddon.AddPeripheral?type="dht22"Bear in mind the Add-on takes either one DHT22 or up to five DS18B20s, not both at once: they share the data line. If you later want DS18B20 probes, the DHT22 has to go.
If the cable is long
At around 10 m, the cable becomes part of the problem: the DHT one-wire protocol is not meant for long runs. If you need that distance:
- Twisted pair, DATA with GND, ideally shielded, with the shield to GND at the Shelly end only.
- A stronger pull-up on DATA to 3.3 V, around 1–2.2 kΩ against the usual 4.7–10 kΩ: it charges the cable’s capacitance sooner and the edges rise faster. At 3.3 V, 1 kΩ is 3.3 mA with the line low, within the Add-on’s margin.
- 100 nF at the sensor between VCC and GND, and enough cross-section on the supply.
Even so, at 10 m a DHT is at its limit. For that distance the reliable answer is another sensor: a DS18B20, whose 1-Wire is designed for long runs (temperature only), or a BLU H&T over Bluetooth at the measuring point, which the 2PM Gen4 itself reads as a gateway (temperature and humidity).
What about rebooting the sensor every 20 minutes?
It can be scheduled, but it does not reboot the sensor: the Add-on cannot cut the DHT’s supply in software. All you can automate is Shelly.Reboot of the whole 2PM, which also interrupts its relays — shutters, lights —, drops the connection for a few seconds and is a patch to maintain forever. Cutting only the sensor’s VCC would need a separate relay. Not worth it: the supported DHT22 solves it.
| Sensor | Supported | Measures | Distance |
|---|---|---|---|
| DHT11 / DHT21 | No | T + RH | — |
| DHT22 (AM2302) | Yes, one | T + RH | Short |
| DS18B20 | Yes, up to five | T | Long |
| BLU H&T | Over Bluetooth | T + RH | No cable |
In short: a hung DHT only recovers without power; the Add-on supports only the DHT22, at 3.3 V and 10 mA; check the type with SensorAddon.GetPeripherals; and for long runs, DS18B20 or BLU H&T.