Watlow Standard Bus — empirical findings¶

Companion to protocol-stdbus.md (literature survey). This document records what was reverse-engineered against a live EZ-ZONE PM3 (part number PM3R1CA-AAAAAAA) on 2026-04-25 over a B&B Electronics 485USBTB-2W USB↔EIA-485 adapter at 38400 8N1.

The library implementation — frame builder/parser, payload codec, and type-tag table — is in src/watlowlib/protocol/stdbus/ and every claim below is pinned by a unit test against captured wire bytes (see tests/test_crc.py and tests/test_codec.py).

Wire format summary¶

+---------+-----+-----+-----+--------+------+----------+----------+
| 55 FF   | FT  | DST | SRC | LEN_BE | HCRC | PAYLOAD  | DCRC_LE  |
+---------+-----+-----+-----+--------+------+----------+----------+
                BACnet MS/TP outer frame                Watlow inner

Header CRC: BACnet MS/TP CRC-8 over [FT,DST,SRC,LEN_HI,LEN_LO]
Data CRC:   BACnet MS/TP CRC-16  over PAYLOAD, transmitted little-endian

Outer (BACnet MS/TP) — fully confirmed¶

Inner (Watlow attribute service) — confirmed¶

The payload is a small tagged-attribute protocol that resembles CIP common services in spirit, with Watlow-specific service codes.

request   ::= 01 SERVICE [MODE] CLASS MEMBER INSTANCE [VALUE]
response  ::= 02 SERVICE_OR_ERROR ...

SERVICE = 0x03 (read) | 0x04 (write)
ERROR   = SERVICE_OR_ERROR with high bit set; payload = 02 ERROR  (no echo)

VALUE   = TYPE_TAG [LENGTH] DATA

MODE only appears in read requests as the byte after 0x03. In every in-the-wild capture it is 0x01. We confirmed it selects a service mode (see "Block / multi-parameter reads" below). For all normal use, MODE = 0x01 (single-attribute read).

Type tags — confirmed¶

The "Wide Enumeration" data type from the EZ-ZONE register list shares tag 0x0F. In every live capture so far the count byte is 1 (single 16-bit word). We have not yet observed a Wide Enum that exceeds 16 bits, so the multi-word case is implemented in the codec but unverified on the wire.

The "2 - unsigned 16 bit" data type from the spreadsheet (used on parameters in the 20000 range — CIP pointers) is not a distinct wire type. When read, it returns whatever type the pointed-to parameter uses.

Error responses — confirmed¶

Error response payload is exactly two bytes: 02 <code>. No echo of the failing selector.

Address mapping — confirmed¶

Confirmed by reading the live PM3 at 0x10 and observing source MAC 0x10 in every reply.

"Parameter ID" encoding — corrected from research doc¶

The literature-survey hypothesis (decimal-split: 4001 → digits 04, 01) was wrong. The wire bytes are (Standard_Class, Standard_Member, Standard_Instance) read directly from the EZ-ZONE register list columns. The Parameter ID shown in user manuals is just Class * 1000 + Member. Examples confirmed on the wire:

The encoding is therefore one byte for class and one byte for member. No edge cases yet found that break this (parameters above 25500 would overflow member; the highest member observed in the PM register list is in the 80s).

Reverse-engineering results¶

CRCs (offline)¶

BACnet MS/TP CRC-8 (header) and CRC-16/CCITT (data) verified against all six canonical frames from the literature survey. 12/12 CRC unit tests pass; the frame round-trips byte-for-byte.

Baseline replay¶

Three known-good reads against the live PM3:

Instance edges¶

The PM3 exposes only instance 1 of every parameter probed. read(4001, instance=2..3) and read(7001, instance=2..3) all return NO_SUCH_INSTANCE (0x84). The "PM3" model designation does not refer to loop count; the unit has a single control loop.

Type-tag catalog¶

Seven distinct wire data-type tags discovered (table above). Live captures for each are stored as fixtures in tests/test_codec.py. The catalog accounts for every type seen in the EZ-ZONE register list except:

• unsigned 32-bit was confirmed via param 16006 (tag 0x05).
• Member Based is a software construct (parameter is a pointer; type comes from the target).
• 2 - unsigned 16 bit resolves to whatever target the CIP pointer points to.
• Wide Enumeration shares tag 0x0F with Enumeration; only the count byte differs in principle. Multi-word (count ≥ 2) packed-int responses remain unobserved.

Error responses¶

All three error classes seen exactly. No timeouts, no malformed responses. The error envelope is the simplest possible: 02 <code>.

Frame-type space¶

Sent four non-0x05 frames at the live PM3. All four returned silence.

Conclusion: the PM3 is not a participating MS/TP node. It only handles frame type 0x05. Bad header CRC is silently dropped. EZ-ZONE Configurator's "autodiscovery" therefore must be brute-force address polling with 0x05 read frames.

Block / multi-parameter reads (partial)¶

The byte after function 0x03 in read requests is not a count of parameters, contrary to the natural intuition. Empirically:

For library v1 we expose only mode 0x01. Mode 0x02 is documented as a future feature pending more capture work.

Open items¶

• Service mode 0x02 (Get_Attributes_All) payload decoding: identify the sub-header, the per-attribute envelope, and the attribute-ID encoding. Likely requires capturing EZ-ZONE Configurator doing a full settings dump (it almost certainly uses this service).
• Wide-enum count ≥ 2 behavior: have not yet found a Wide Enum value that exceeds 16 bits.
• Save-to-EEPROM / non-volatile commit semantics: empirically confirmed on a lab PM3 (wire captures under captures/2026-04-26/). Writes to RWE parameters (we tested 17009 Protocol) persist across power cycles automatically when 17051 (Non-Volatile Save) is set to 106 (Yes), which is the factory default. 17051 itself is a sticky mode, not a one-shot trigger — it stayed at 106 across multiple unrelated writes. The "two-phase commit" hypothesis was wrong: RWE writes are single-step persistent on this firmware.
• Profile / recipe upload-download: the F4T family supports profile upload via Standard Bus; the PM has its own profile-step parameters (class 19+). Not yet exercised.
• Other function codes: only 0x03 (read) and 0x04 (write) confirmed. We deliberately did not probe arbitrary function codes against the live load. This should be done on a sacrificial controller before opening up exotic services.
• F4T Ethernet Watbus (port 44819): out of scope for this library iteration.