Silverline / Poolex Pool Heat Pump custom integration for Home Assistant

Share your Projects! Custom Integrations
1

If you own a Poolex Silverline FI pool heat pump — or one of its OEM siblings (Brustec, Steinbach Silent Mini, Phalén Calidi XP, and other Poolstar-platform units with a Tuya WBR3 module) — you've probably hit the wall that made me write this: the official Tuya integration shows the pump as off / heat only, and LocalTuya can't cleanly reach Boost or the cooling modes either. The hardware speaks seven modes; the existing tooling exposes maybe two of them.

So I built a small, local-only integration that models the device properly.

:backhand_index_pointing_right: Repo: GitHub - christianreiss/ha-silverline: Local Home Assistant custom integration for Poolex Silverline FI pool heat pumps (Tuya v3.3): climate control, diagnostics, presets, LAN auto-discovery, no cloud dependency, HACS-installable. · GitHub
License: MIT.

What it does

It talks the Tuya local protocol v3.3 directly over your LAN — no Smart Life cloud at runtime — and presents the pump as a single, clean climate entity:

  • HVAC modes: off / heat / cool / heat_cool (Auto)
  • Presets: inverter / boost / silent, which together cover all seven device modes — including Boost-Cool and Silent-Cool, the ones the official HA Tuya integration cannot reach (core#117566).
  • Per-mode setpoint handling: the slider's min/max adapts to the active mode (Heat 15–40 °C, Cool 8–28 °C, Auto 8–40 °C), because the device clamps differently per mode and keeps a separate stored setpoint for each.

On top of that:

  • Diagnostic sensors (firmware-dependent — see below): compressor exhaust/return temps, evaporator + ambient temps, water inlet/outlet, target/actual compressor frequency, EEV step count, fan rpm, and a decoded fault code.
  • Binary sensors for the water-pump relay and the common fault bits (water flow, antifreeze, high/low pressure, comms).
  • Fault codes as self-clearing Repair issues — a fault opens an issue under Settings → Repairs and closes itself the moment the device clears the bit.
  • Reauth flow when the local key rotates, Reconfigure flow for IP changes, plus LAN auto-discovery of the device.
  • Diagnostics download with secrets redacted, and German + English translations.

The protocol layer is a standalone async library (pysilverline) — a hand-rolled Tuya v3.3 client, usable outside Home Assistant if you want it.

Honest caveat: diagnostic sensors are firmware-dependent

This is the one thing I want to be upfront about. The rich diagnostic DPs (101–111) only exist on some firmware variants. The Poolex PC-SLP090N I verified live exposes exactly five datapoints — power, target temp, current temp, mode, fault — and none of the 101–111 diagnostics. The Brustec / Steinbach firmware ships the full set.

The integration handles this gracefully: it only registers entities for the DPs your firmware actually emits, so you never get a dashboard full of permanently-unavailable sensors. But it means: if you're on a minimal Poolex firmware, you get the climate entity + fault handling and not much telemetry. That's the device's limit, not the integration's.

Other known limits, all documented in the README: °F mode isn't supported (lock the remote to °C), Auto mode has no Boost/Silent variant (device limitation — selecting a preset in Auto raises a clear error), and switching HVAC mode restores that mode's last stored setpoint after ~½ second.

Install

Via HACS → Custom repositories → add https://github.com/christianreiss/ha-silverline as type Integration → install Poolex Silverline → restart → add it from Settings → Devices & Services.

You'll need the device's IP, Device ID, and local key (the usual tinytuya wizard / Tuya IoT Platform route — instructions in the README). The setup form validates the credentials against the live device before it creates the entry, so a wrong key surfaces as invalid_auth right there instead of silently failing later.

One gotcha worth repeating: the WBR3 module accepts one local TCP client at a time. If Smart Life is still talking to it on the same network, HA gets kicked. Cleanest fix is to firewall the pump off outbound 443/8886 so it stays genuinely LAN-only — which is the whole point anyway.

What I'd love help with :folded_hands:

I've only been able to verify against my own PC-SLP090N. The Tuya schema is shared across the whole Poolstar/WBR3 family, so the integration should work on the siblings — but "should" isn't "does."

If you have a Poolex JetLine Selection FI, a Steinbach Silent Mini, a Brustec BR, a Phalén Calidi XP, or any other Silverline FI size (120/180/200): please install it, and grab the diagnostics download from the device page (Settings → Devices → your pump → ⋮ → Download diagnostics — it's secret-redacted). Drop it here or open an issue. That tells me exactly which DPs your firmware exposes and lets me confirm the 101–111 diagnostic mapping on real hardware instead of inference.

Bug reports, mode-enum mismatches, and "this DP means something different on my unit" reports are all very welcome.

Repo, README, and full known-limitations list: GitHub - christianreiss/ha-silverline: Local Home Assistant custom integration for Poolex Silverline FI pool heat pumps (Tuya v3.3): climate control, diagnostics, presets, LAN auto-discovery, no cloud dependency, HACS-installable. · GitHub

Happy to answer anything below. :person_swimming:

2

Hello,
I own a Poolex Silverline Full Inverter 70 heat pump, which communicates using the local Tuya protocol v3.5.

After some effort, I was only able to establish communication using the Tuya Heat Pump (Local) integration, although not without difficulties.

I tested your modification/update, but unfortunately it did not resolve the issue and I was unable to achieve a successful connection.

Please let me know if you need any additional logs, diagnostics, or configuration details from my side.

3

Thanks a lot for testing this and for reporting back — really appreciated :folded_hands:

From what you described, your main issue seems to be the initial local connection itself (not just missing entities afterward), and the key detail is that your FI 70 appears to speak Tuya local protocol v3.5.

This integration is currently built for the v3.3 Poolstar/WBR3 family, so if your unit is truly v3.5, a failed handshake/auth is unfortunately expected right now.

If you’re willing, I’d love to collect a bit of data so I can verify this properly and see what’s needed for v3.5 support.

Please share: exact model + firmware version of the heat pump; Home Assistant version + integration version/commit you tested; debug logs from a failed setup attempt; diagnostics download from the config entry (redacted is fine); and whether tinytuya can connect locally with the same IP/device ID/local key (including what protocol version it reports).

For debug logs in HA, you can temporarily add:

logger:
  default: warning
  logs:
    custom_components.silverline: debug
    pysilverline: debug

Then restart HA, retry setup once, and share the relevant log excerpt.

:warning: Please do not post secrets publicly (local key, full device ID, tokens, etc.).

If you share those details, I can confirm whether this is a strict v3.5 protocol mismatch and map out the next step.

4

I released 0.8.3 with improved 3.5 Support; upgrade and give it a try!

5

Hi Christian,

after testing the new version, the device can now be added successfully, and there is no need for the heat pump to be without internet connection.

I selected the integration as “Other / Unknown” during setup (not a specific model).

Updated diagnostics from Poolex Silverline FI 70.

Key information:

  • Tuya protocol: 3.5 (detected + configured)
  • Connection: successful (local)
  • DP range: 1, 2, 3, 4, 13, 101–145

The behavior confirms a working v3.5 handshake, but DP-to-entity mapping needs adjustment (incorrect sensor/temperature values).

Diagnostics attached (redacted).

If needed, I can provide HA debug logs or a tinytuya comparison.

Thanks!
Michal

entites
entites163×811 37.4 KB

6

Glad 3.5 connects now! :tada:

The wrong readings are expected. Your Full Inverter 70 exposes DPs 101–145, but the integration's 101–111 map currently comes from a different model (the JetLine Selection FI). So those diagnostic sensors read the right DP numbers but the wrong meaning for your firmware — e.g. it labels whatever your DP 101 is as "exhaust temperature."

The core climate values (power/mode/set/current temp on DPs 1–4) should be correct. Could you confirm whether the set and current water temperature in HA match the OEM app? If they read ~10× too high (e.g. 280 instead of 28), there's also a scaling difference to handle.

To map your model properly I need to see what each DP actually is. Two things would let me do it:

(a) A raw tinytuya snapshot of the full dps dict (values, ideally with types):slight_smile:

python -m tinytuya scan to find it, then in Python:

import tinytuya
d = tinytuya.Device('DEVICE_ID', 'IP', 'LOCAL_KEY', version=3.5)
print(d.status())

(b) The OEM app readings at the same moment — water in/out, ambient/air temp, set temp, and any compressor frequency / fan values it shows — so each DP number can be matched to its meaning.

:warning: Please redact your device ID and local key before posting; the dps values themselves are fine to share.

With that I'll add a proper Full Inverter 70 profile (correct DP map + any scaling) in the next release.

7

Hi Christian,

I’m sending the DP values from the TinyTuya output:

{'dps': {'1': True, '2': 32, '3': 27, '4': 'Heat', '13': 0, '101': 28, '102': 22, '103': 27, '104': 67, '105': 8, '106': 6, '108': 35, '109': 85, '110': 85, '111': 267, '114': 781, '115': 0, '120': 230, '121': 4, '124': 45, '125': 12, '126': 12, '127': 0, '128': 2, '130': 0, '131': 2, '132': -1, '133': -8, '137': 10, '138': 0, '140': 80, '141': 0, '142': 40, '145': 8}}

Preliminary DP mapping:

  • DP 2 → 32 °C (set water temperature)
  • DP 103 → 27 °C (inlet water temperature)
  • DP 101 → 28 °C (outlet water temperature)
  • DP 102 → 22 °C (ambient air temperature)

I’m not able to reliably identify the meaning of the remaining DPs yet.

Thanks,
Michal

8

This is very helpful, thank you!

What's already clear from the dump:

DP Value Meaning
1 true power on
2 32 set temp (°C)
3 27 current water temp (°C)
4 Heat mode
13 0 fault bitmap (no faults)
101 28 outlet water temp (°C)
102 22 ambient air temp (°C)
103 27 inlet water temp (°C)

Note: DP 107 is absent from your firmware entirely — the JetLine FI has it as target frequency, your device doesn't use it.

My best guesses for the rest — please cross-check with the OEM app:

  • DP 108 = 35 → actual compressor frequency (Hz)?
    • DP 142 = 40 → target compressor frequency (Hz)?
    • DP 104 = 67 → outdoor humidity (%)?
    • DP 114 = 781 → power consumption (W)?
    • DP 120 = 230 → AC voltage (V) — looks very much like mains voltage
    • DP 121 = 4 → current draw (A)?
    • DP 124 = 45 → discharge gas temperature (°C)?
    • DP 110 = 85 → fan speed (% or RPM)?
    • DP 111 = 267 → water pump speed (RPM)?
      Could you check the OEM app while the pump is running and tell me what values it shows for frequency, humidity, power, and anything else — so I can pin down the unknowns?

Once confirmed I'll add a proper Full Inverter 70 profile so those diagnostic sensors all read correctly.

9

Hi,

That’s exactly the problem — in the Tuya app, the device appears only as a basic heater controller. I can adjust the temperature and switch modes (heating, cooling, etc.). I can also see the inlet temperature, outlet temperature, outdoor temperature, and the timer, but that’s about all it can do :frowning: