You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix: serial entries on one adapter now share a connection (#384)
The shared connection hub exists to serialize transactions and 'prevent RS485
cross-talk', and was created only for TCP entries. That had it backwards: an
RS485 bus is precisely where two uncoordinated masters collide.
Each serial entry opened its own client on the same adapter and paced itself
with a per-instance min_read_interval, which says nothing about what the other
entry is doing. Two inverters on one USB-RS485 adapter - the normal way to wire
a parallel SPF stack - interleaved frames on one physical bus with nothing
serializing them, giving random single-sample read failures on both units.
The hub is now transport-agnostic, keyed on device path for serial and
host:port for TCP. Serial gets its own buffer drain via pyserial's
reset_input_buffer(), since the TCP path's socket recv() loop raises on a
Serial object and would silently skip the flush.
Parity/stopbits/bytesize default to N/1/8, matching what the non-shared path
has always hardcoded, so moving to a shared connection cannot change framing.
Note the runtime name for the serial class is ModbusClient - ModbusSerialClient
is imported only under TYPE_CHECKING. The first cut of this used the latter and
would have raised NameError on the first connection; the whole existing suite
passed because nothing ever asked a serial hub to connect. The new tests
exercise that path.
Verified red without the fix.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: docs/troubleshooting/rs485-gateways.md
+17Lines changed: 17 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -157,6 +157,23 @@ The integration holds one socket per host:port across polls. It was suspected of
157
157
158
158
---
159
159
160
+
## Two or more inverters on one adapter
161
+
162
+
If you run several inverters as separate integration entries over **one** USB-RS485 adapter or one gateway, they share a single physical bus. Only one master can be talking at a time.
163
+
164
+
The integration handles this for you: every entry pointing at the same device path (or the same host:port) shares one connection and one lock, so their reads are queued rather than interleaved. Nothing to configure.
165
+
166
+
**Serial setups need v1.7.0 or later for this.** Before that, only TCP entries were coordinated — each serial entry opened its own client on the same adapter and paced only itself, which produced random read failures on *all* the inverters sharing that bus. If you have two entries on one adapter and see unexplained dropouts, this is the first thing to rule out.
167
+
168
+
Two consequences worth knowing:
169
+
170
+
-**Polls queue, they do not overlap.** With several inverters the effective cycle is the sum of their polls. If a single poll takes 8 s, three inverters need an interval comfortably above 24 s.
171
+
-**A slow or failing inverter slows the others**, because they wait for the bus. If one entry is much worse than the rest, disable it and see whether the others recover — that isolates the problem device quickly.
172
+
173
+
Raising the scan interval is the main lever here, exactly as it is for a single unit.
174
+
175
+
---
176
+
160
177
## Gaps in the graph are the fix, not the fault
161
178
162
179
Since **v1.6.6** a register that could not be read is published as **unavailable** for that poll, not as `0`.
0 commit comments