EEZ Studio Modbus Server Selection: Inspect the Cached Client Key Before Switching Addresses

Changing the Server address expression on an EEZ Studio Modbus action does not, in the inspected source, necessarily construct a new client. The client cache key omits that address. A later operation using the same cached connection key can therefore reuse the object constructed for an earlier address.

This is an EEZ Dashboard cache-identity question, not a change to the Modbus protocol's addressing rules. The Modbus action documentation describes Server address and Timeout. The concrete lookup behavior is in modbus.tsx at commit 3000161d09d40a5c1dc2477ddc30b38037b3a612, the pinned EEZ Studio v0.29.0 source.

No Modbus command was sent. Any confirmation fixture should use authorized local test endpoints and harmless read operations, never exploratory writes to production devices.

Compare requested properties with constructor inputs

The execute function evaluates connection, serverAddress and timeout. Its getModbusClient helper locates the connection object, then derives a cache key. Serial connections use the serial connection identifier together with timeout. TCP connections use the socket object's identifier.

Clients are stored inside a per-Wasm-module map. On a cache miss, the serial constructor receives the serial port, serverAddress and timeout. The TCP constructor receives the socket and serverAddress. The new client is then stored under the derived key.

On a cache hit, the existing object is returned. The shown path does not update its address from the newly evaluated Server address property. Since neither cache key includes serverAddress, changing that property alone does not distinguish the new request from the old cached client configuration.

A two-address fixture needs a fresh-client control

Use two authorized test server identities with clearly different read-only values. First perform a read through one connection and one address. Then change only the address expression and perform the same harmless read again.

Record the requested address, the effective connection key and whether a new client was constructed. An independent request trace or the mock server's receive record is stronger evidence of the actual destination than the label currently displayed in the Dashboard.

Compare that sequence with a fresh runtime or genuinely new connection identity configured for the second address. The control distinguishes an addressing or server-configuration problem from reuse of a client created earlier. Merely creating a second Modbus action box may not create a different connection key.

The source predicts client reuse; it does not by itself measure the installed library's final wire behavior. Keep those statements separate. If an installed build behaves differently, examine both its EEZ cache implementation and its Modbus client library rather than assuming the pinned code describes that build.

Timeout has a different cache relationship

For serial connections, timeout contributes to the key. Changing timeout can therefore cause a cache miss even when the underlying serial connection stays the same. That can make an address-change issue appear to disappear after an unrelated timeout edit.

Do not adopt “change timeout to switch servers” as an application interface. It relies on an incidental cache key and can leave more client instances associated with the same connection. The intended server-selection mechanism should be explicit and supported by the version being deployed.

For TCP, the inspected key does not contain timeout, and the shown TCP constructor call does not receive that timeout argument. This is another reason to record the actual connection type instead of assuming the documented property has identical construction semantics on both paths.

Review zero values separately from cache reuse

The initial validation rejects falsey serverAddress and timeout values. Thus a zero address or zero timeout reaches an earlier rejection branch; it is not a useful test of a cache hit. The documentation's broad address description should not be treated as proof that every listed value passes this specific implementation's gate.

The repair decision should follow the evidence. A pinned application may need a supported way to create appropriately configured clients, an upgrade with verified behavior or a narrowly reviewed integration correction. This article does not promise that reconnecting, changing a UI label or creating a second action automatically resets all cached state.

The central check is concrete: whenever a property is intended to select a different server, verify that it participates in the identity or configuration of the client actually used for the request.