Shelly1 Gen3 + Addon + 2xShelly DS18B20

[embeathome]

Hello all,

Shelly1 Gen3 + Addon + 2xDS18B20 - tried already 2 pair of sensor, replaced addon too, but I cannot get it working. 1 probe is 3m long, second is 1m long, They work for some time but then they stop working, temperatures drop to Zero and finally to unavailable and Addon says there is no Peripheral connected. I am already desperate.
Both probes are outside, in the pool, but Shelly1+Addon are in a IP44 box, everything is perfectly tied.
I connected the last pair of probes yesterday, they were found immediately by shelly web, they worked for 14 hours and then they dropped to 0 and after Shelly restart they dissapeared.

Any idea what could be wrong? I have Claude installed in HA and it checked everything possible. I like Shelly products a lot, but this makes me crazy. I have another installation of shelly1PM Gen3 or4 in Boiler in dry condtions, it is just 1 probe and it works great. Here is what Claude says about the issue and its suggestion for email to Shelly:

I’m reporting a recurring hardware issue that has now happened twice, with two different Sensor Add-on units and two different pairs of genuine Shelly DS18B20 temperature sensors, on the same base Shelly 1 Gen3 device. Since the failure pattern is identical across different Add-on and sensor hardware, I suspect either a device/firmware-level issue or a specific bad batch, and would appreciate your help diagnosing it.

DEVICE INFO

• Model: Shelly 1 Gen3 (S3SW-001X16EU)
• MAC: 48F6EE935C54
• Device ID: shelly1g3-48f6ee935c54
• Firmware: currently 2.0.1-beta1 (build 20260819-101746/2.0.1-beta1-g8a88c73), previously stable 2.0.0 (20260710-101117/2.0.0-g87fbfa4) — issue occurs on both
• Add-on: Shelly Sensor Add-on, addon_type = “sensor”
• Sensors: 2x genuine Shelly DS18B20 (3.5mm jack), each wired to its own dedicated DATA and GND terminal on the Add-on (not sharing a terminal)

HISTORY

• A first Sensor Add-on + first pair of DS18B20 probes was in use on this same base unit from 2026-08-15. It had recurring “unknown” state read errors from mid-August onward, which we could temporarily clear with a manual RPC reset (Sys.SetConfig toggling device.addon_type off then back to “sensor”).
• That first pair of sensors is currently being returned as defective.
• On 2026-08-31 we installed a second, brand-new pair of genuine Shelly DS18B20 probes on the same base Shelly 1 Gen3 unit.
• This second setup worked correctly for about 14 hours, reporting plausible, smoothly-changing readings from both sensors (temperature:100 and temperature:101).
• On 2026-09-01 at approximately 07:26 UTC, both sensors permanently dropped to a stuck 0.0°C reading simultaneously, with no recovery.

TROUBLESHOOTING ALREADY PERFORMED (please don’t ask us to repeat these)

1. Soft reset: Sys.SetConfig with device.addon_type set to null, then back to “sensor” — no effect, sensors stayed at 0.0.
2. Full device reboot via Shelly.Reboot — after reboot, Shelly.GetComponents (dynamic_only=true) returns 0 components at all; the sensors are no longer detected on the OneWire bus even as a failed/0.0 reading.
3. Firmware update from stable 2.0.0 to beta 2.0.1-beta1 — same result, 0 components found after boot, addon_type config remains correctly set to “sensor” (confirmed via Shelly.GetConfig).
4. Ruled out physical causes: cables are fixed inside protective conduit and cannot move; all units (Shelly 1, Add-on, and the pool pump/salinator Shelly Plug M units nearby) are in IP44/IP67 rated enclosures, so moisture ingress into the enclosures is not a factor; sensors are wired to separate DATA/GND terminals on the Add-on (not sharing one terminal), so it is not a shared-terminal wiring fault.

QUESTIONS

• Is there a known issue with the Sensor Add-on’s OneWire driver or pull-up circuit that causes the bus to permanently stop enumerating any devices after some hours of correct operation, requiring hardware replacement?
• Is there a known bad batch/board revision of the Sensor Add-on or of the DS18B20 probes that matches this symptom?
• Given the same failure occurred with two independent Add-on units and two independent sensor pairs on the same base Shelly 1 Gen3, would you recommend RMA of the Add-on, the base Shelly 1 unit, or both?
• Is there any additional diagnostic (debug log level, RPC call) you’d like us to capture the next time this happens, before we power-cycle the device?

[Karosm]

@embeathome

probes are outside, in the pool,

You mean immersed in water? I don’t expect it to be waterproof beyond the steel tip.

[anon11644107]

I have similar probes purchased from Aliexpress at about half the price. They have been fully immersed in my pond for well over a year without issue.

I wonder if the chlorine in their pool water is attacking the probe sealing?

[embeathome]

Yes, one is fully immersed, like 70cm, the other probe is outside of the water, I plan to mount it in the T-fitting before the pump, so it will also be in the water..
I took it out of the water, the one, which was already in the water, let it dry, after about 30 minutes both connected again, then dropped out again, and so on in a loop… I should mention that the 1m one was not in the water at all…I am desperate.

[embeathome]

I don’t know…hard to say…but I’ve seen a video on YT, where the guy had similar setup.

Update: it is not. It should be 316L Stainless steel. But I doubt that 14hrs expose to the water could harm it so badly that it stops and starts operating, additionally both of them at once. And of course, I checked all connections to addon + addon to shelly1…
Again some 40minut both dropped to 0.0C, now they hold since they returned.

[ShadowFist]

@embeathome

TROUBLESHOOTING

Remove one of the probes & monitor the other for stability for a couple of days. Do the same with the other probe after the second day.

If both probes drop out, it’s a Shelly issue.

If one probe drops out, it’s a probe issue.

If neither probe drops out, it’s either a Shelly issue or interference.

[embeathome]

thanks. The truth is that Shelly 1 Gen4 with AddOn are in an IP44 box approximately 24×19×10cm. There is a power strip inside where the Shelly 1 Gen4 is connected, along with 2 Shelly Plug M sockets that control the pool pump and the salt chlorinator, in such a small enclosure, there is heat generated by the plugs/sockets themselves, but could there also be electrical interference? Omg…if so, how far would be OK to move Shelly1+addon from the box then?

[ShadowFist]

@embeathome

but could there also be electrical interference?

Probably, but I have no idea how sensitive those sensors are to electrical interference (I use a different type of sensor & have it running over twisted pair).

Looks like it would be pretty straightforward to rip out the Shelly & probes & hook them up inside the house (away from electrical cables) for a couple of days to check.

[Karosm]

@embeathome

but could there also be electrical interference?

Yes. Just switch off all pool electronics and see how it goes.
Your description sounds water problem though.

[embeathome]

Thank you guys, I will try and will report in a couple of days. It is not possible to move them inside, it is really far.

[anon11644107]

@embeathome

Update: it is not. It should be 316L Stainless steel.

I meant the heatshrink seal between the s/s probe and cable.

@embeathome

additionally both of them at once.

They are on a onewire bus. If one shorts they both stop working.

@embeathome

I took it out of the water, the one, which was already in the water, let it dry, after about 30 minutes both connected again, then dropped out again, and so on in a loop

Then the probe is definitely leaking water.

[Karosm]

@anon11644107

I have similar probes purchased from Aliexpress at about half the price. They have been fully immersed in my pond for well over a year without issue.

You were either lucky or read carefully reviews to source good probes. Many (or most) of these are not properly sealed. Good ones are carefully filled with potting compound, bad ones relay on heatshrink.
Latter ones die in no time when immersed.

[Karosm]

@embeathome

But I doubt that 14hrs expose to the water could harm it so badly that it stops and starts operating

You could open one failed probe to see how it’s sealed.
You can find some reference images here:

Improving the Accuracy of 1-Wire DS18b20 Temperature Sensor Groups

[embeathome]

well, I thought Shelly probes are among those good ones…

[Karosm]

I would expect that as well. But your experiments indicate opposite.

[embeathome]

Thanks for the above article, wow! So I was naive I think I will put the probe inside this and close it with epoxy completely. It will also act as weight and protection while kids are in the pool. It is 316Ti stainless steel- the factory confirmed today.

[IOT7712]

Look at your sensor readings.
The OneWire protocol used by the DS18B20 has extensive error correction for data transmission. Intermittent or corrupted data transmissions are usually rejected by the driver firmware receiving the data, whether it is the factory firmware or a custom flashed one. This will result in no data or a ‘fault’ status signal being passed on, depending on the algorithm the firmware designer chose to use for faulty data.

Either way, your HomeAssistant recorder statistics will have missing slots where the data didn’t arrive regularly, most temperature measurements done by regular polling loops, often far too often, but in this case, useful.

As your sensor degrades from water and chlorine ingress, the missing data will become more frequent over time but consistently degrades, the missing slots becoming more frequent. If the problem is interference, the missing slots will follow the interference if it is generated by the other equipment close-by being turned on, and disappearing when off again, or if it is constant, the missing slots will be consistently constant too.

Pull up a graph, and zoom in and out over an hour, day, week, and it should become clear.

No soldering or rewiring required!

Step back and look at the bigger picture. You are measuring water temperature. The DS18B20 does that to 12bits, one 4096th of a degree, far beyond what you need. Not a problem. How fast the temperature changes is probably going to be rounded down by a factor of quite a few bits by the time it is used in the automation decision logic, probably to a tenth or half a degree. You don’t need to monitor the water to the millionth degree, so consider what to monitor.

Your probes are touted to be water resistant. Cold water, pure water. Deploying them in salty chlorinated water in sunny conditions is going to give that waterproofing issue a hard time. The huge thermal mass of the pool water means the instantaneous temperature changes should be averaged out to prevent hysteresis about at set point - you don’t want your pump switching in and out every second. Not only will this waste electricity, shorten the life of the pump, but cause interference. Check your software includes hysteresis - most climate control software does. Having an ESP32 switch a pump on and off about a temperature trip point does not, unless you specifically tell it to. Show your YAML code please.

Consequently, having the probe in direct contact with the water is entirely unnecessary. Put it inside an enclosure that is in contact with the water (like a wall of a swimming pool) and measure the surface temperature of the other side of that instead. Like a second barrier that the probes that are heatshrink wrapped do already. A plate at the side of the pool with the sensor bolted or fastened to the dry side should follow the water temperature very accurately and completely remove waterproofing as an issue. If the plate is actually a steel box, the faraday cage aspect will remove induced radio interference as a factor. Using shielded connecting wire will further reduce possible electrical interference, as will shorter cable runs, putting the Shelley’s close to the probe.

Data analysis is free and you already have a lot recorded to closely examine. Try that first and let that be a guide as to which way you should proceed from there.

From generalisations to your specifics: I see your pool is above ground with probably steel sides. For purposes of problem isolation, using a piece of duct tape to fasten the sensor to the outside of the pool wall behind the electrical enclosure in your picture, and cover it with kitchen foil should reduce issues with interference and waterproofing enough to be seen in your data statistics graphs over a day or two. You will then know if a 316 grade stainless steel probe is going to make any difference. Having the pictured probe sticking out into your pool is probably undesired from a safety aspect if getting caught in swimmers or a gash in a passing body part. The length of 1 or 3 metres of your probes shouldn’t be enough to pickup a lot of interference unless you have faulty wiring connections going to your pump.

What app/integration are you using to digest the temperature data and use it to control the pump? This may be a contributing cause, not just probe degradation.

[embeathome]

So I performed this isolation test, here are my findings:

disconnected one probe, left the other connected in dry air for ~4 days, then swapped. Both probes outside of the water during the test.

• Probe 1 - this is the probe, which was in previously immersed in the water for 14 hours (test connected days 1-4): never went unavailable/unknown — but showed short episodes of implausible rapid oscillation (multi-°C swings within seconds). These episodes got progressively worse each day: ~19 min/day → 63 → 137 → 140 → 676 min/day (day 4), see the charts below. Disconnected after that.
• Probe 2 (connected since, days 4-6): rock stable. Only a fixed-interval single-sample unavailable blip every ~361 seconds (6 min), lasting <1s each time, with zero drift in timing or duration over 48h/479 occurrences. No oscillation at all.

I could maybe live with rapid oscilation, I don’t know. I can definitely live with second probe’s blips.
I didn’t move the Addon further from the socket and box yet.

[Karosm]

So your probe 2 is working. 6min “blip” is likely not related to the probe but something else in your setup.

[embeathome]

Yes, actually both work. But not sure why that oscillation happens. Probe 2 - Claude in HA couldn’t find the reason.