Another IntelliFlo3/Pro3 data point — TX works, zero RX, ever
@El_Duderino (post 25) and @PatHush (post 28) — I’m in exactly your position, so here’s a fully documented third case in the hope it helps narrow this down.
Short version: IntelliPro3 VSF, Waveshare ESP32-S3-Relay-6CH, pentair_if_ic. Frames transmit perfectly. The pump has never returned a single byte.
Hardware / firmware
- Pump: Pentair IntelliFlo/Pro3 VSF 1.5hp, provisioned March 2025
- Controller SW 1.07.003 · Drive SW 1.06 · IoT SW 1.16 · Flow Table 0.06 · Comm Board HW D
- Board: Waveshare ESP32-S3-Relay-6CH (onboard isolated RS485, auto direction — no
flow_control_pin)
- ESPHome 2026.7.4, UART GPIO17/GPIO18, 9600 8N1
Pump only — no chlorinator. I have no IntelliChlor on this bus. Takeover mode is enabled in the attached log since FreezerEagle calls it out as essential, but the result is identical with it off — I ran it both ways. (I realize that this mode may not be needed, but its a switch I could toggle, so I did.) The 10:02:50:... frames are the component’s IntelliChlor polling and are expected to go unanswered; the ones that matter are the two A5 pump requests per cycle.
Wiring
Two-conductor to DATA+ / DATA− only, per the RS-485 table in the pump manual (yellow=DATA+, green=DATA−; my cable is red/black in those positions). No ground, no +12V — same as rwlove’s confirmed-working 6CH install in post 29. I also tried A/B reversed. No change.
DMM readings across A+/B−, for whatever they’re worth
| Condition |
At Waveshare |
At pump |
| Connected, pump running |
1.88 V |
1.88 V |
| Connected, pump unpowered |
1.76 V |
1.76 V |
| Pump disconnected |
3.82 V |
0.0 V |
Waveshare open-circuit at 3.82V is its fail-safe bias with no load. Connecting the pump halves it to 1.88V, so the pump’s transceiver is presenting real input impedance — it’s electrically there. Identical readings at both ends prove continuity on both conductors. Positive differential (A high at idle) confirms correct polarity.
So the physical layer checks out as far as a multimeter can take it. What it can’t tell me is whether the pump ever actually transmits, or whether the board’s receiver works — for that I’d need a scope or a second RS-485 device.
What the bus actually shows
With uart: debug set to direction: BOTH, every polling cycle looks like this, and has across many sessions:
IF Sent: FF.00.FF.A5.00.60.10.07.00.01.1C (11)
>>> FF:00:FF:A5:00:60:10:07:00:01:1C
IF Sent: FF.00.FF.A5.00.60.10.04.01.00.01.1A (12)
>>> FF:00:FF:A5:00:60:10:04:01:00:01:1A
Counting the attached capture — 2m24s, five complete polling cycles: 45 frames out (>>>), 0 bytes in (<<<). Not malformed frames, not checksum errors — literally nothing inbound. The status request decodes correctly (dst 0x60 = automation address 1, src 0x10, cmd 0x07, checksum valid), so the transmit side is provably doing its job.
Everything ruled out on the pump side, in order
- Automation Address set to 1 in Pentair Home, saved — matches the
0x60 in the frames
- All programs deleted (one non-removable timed task disabled)
- Priming and Dry Start disabled under Advanced Settings → Priming Parameters
- Device removed from the Pentair Home app entirely
- Breaker cycled 60s
After removal the Connect LED flashes green and On/Stop shows amber/pink. Per the pump’s own labeling, magenta on Connect = automation control — it has never reached that state.
One thing I can’t close
No inbound byte has ever appeared, which means the RX path itself has never been proven alive. On this board’s auto-direction transceiver you don’t see an echo of your own TX, so “pump won’t answer” and “board can’t listen” look identical from the log. I don’t have a second RS-485 device to inject traffic and settle it. If anyone has a cheap way to prove RX on this board short of a USB-RS485 dongle, I’d take it.
Compile note for anyone on recent ESPHome
Unrelated to the above, but it cost me a while. pentair_if_ic.h unconditionally includes text_sensor.h and number.h. ESPHome only makes a core domain’s headers available if that domain appears somewhere in your config, so a pump-only YAML fails to build with:
fatal error: esphome/components/text_sensor/text_sensor.h: No such file or directory
Don’t patch the header — just declare the domains. A text_sensor: block (the pump’s program: is a real one worth having) and any number: block, even a template, resolves it. FreezerEagle’s own config declares number:, text_sensor:, and even an empty text:, which is why it builds cleanly on his end.
(New user, so I couldn’t add FreezerEagle or rwlove)
