APOGEE P2 (Protocol II) — Technical Reference

Table of Contents

• Summary
• 1. Introduction, Scope, Lineage & Conventions
• 1.1 What P2 is
• 1.2 The protocol family — P1, P2, BACnet coexistence
• 1.3 Audience and goal
• 1.4 Document conventions
• 1.5 Lineage (informative)
• 1.6 Conformance levels
• 2. Architecture & Layering
• 2.1 The layered stack
• 2.2 Node roles and the object hierarchy
• 2.3 Service model (informative)
• 3. Topology & Addressing
• 3.1 Network tiers
• 3.2 BLN forms
• 3.3 The point-address 3-tuple: LAN / Drop / Address
• 3.4 Named scopes and their constraints
• 3.5 Inter-BLN routing
• 3.6 Liveness and replication cadence (topology layer)
• 3.7 No multicast discovery beacon
• 3.8 FLN / P1 fieldbus hanging off a panel
• 3.9 Documented topology limits
• 4. Physical & Datalink Layer
• 4.1 Ethernet/IP transport (the canonical P2 transport)
• 4.2 AEM serial-to-TCP tunnel (a second observable P2-bearing TCP port)
• 4.3 Serial BLN datalink (dedicated RS-485 trunk)
• 4.4 FLN / P1 field bus (RS-485 two-wire)
• 4.5 Open items — serial and field-bus framing
• 4.6 The serial trunk is token-passing, and its parameters are named
• 5.0 Documented timer defaults, and how they scale
• 5. Discovery, Liveness & Replication
• 5.1 EPing — Ethernet-BLN availability probe (liveness, not a beacon)
• 5.2 Multicast availability channel (optional, off by default) — and the beacon myth
• 5.3 Node-name-table replication (the self-organizing BLN)
• 5.3.6 The EBLN diagnostic reads, and what each one returns
• 5.3.1 Replication opcodes
• 5.3.2 EBLN configuration & node-management opcodes (struct-derived)
• 5.3.3 Peer identity lives in three separate stores
• 5.3.4 Deletion is tombstone-based
• 5.3.5 Removing an entry, and why not to reach for a power cycle
• 5.4 What a fresh client learns, and what it cannot
• 5.5 FLN discovery (P1WhoAreYou)
• 5.6 Open items — discovery & FLN timing
• 6. Frame Format (Wire)
• 6.1 Frame byte layout
• 6.2 The msg_type discriminator (message class / dialect)
• 6.3 The direction byte
• 6.4 Routing slots
• 6.5 Sequence number and request/response pairing
• 6.6 Legacy and modern dialect differences
• 6.7 Segmentation
• 6.8 The byte-oriented P2 encoding (non-TCP links)
• 7. Service Model & Message Types
• 7.1 The ASDU service model
• 7.2 Success vs error responses
• 7.3a The stack's service primitives
• 7.3 Connection and session model
  • 7.3.1 Session establishment, in order
  • 7.3.2 Response timing, measured
• 8.1 The string TLV
• 8. Body Encoding Primitives
• 8.2 Scope tag and command priority
• 8.3 Numeric value fields
• 8.4 String character encoding — RAD-50 vs ASCII
• 8.5 ASDU field convention
• 9. Function-Code (Opcode) Catalog
• 9.1 The AP2 function code
• 9.1.1 The wire opcode is the bottom of a three-tier model
• 9.2 Naming, families, and value layout
• 9.3 Destructive and sensitive operations
• 9.4 Family overview
• 9.4.1 Which of these does a panel actually implement?
• 9.5 The catalog
• 9.5.2 Opcodes the panel implements that the enum does not name
• 9.6 The session/keepalive opcode 0x4640 (EBLN_PING)
• 9.7 Wire behavior: message classes, directions, error tails
• 10. Message Body Structures
• 10.1 Encoding convention
• 10.2 Shared sub-types
• 10.2.1 Two body idioms not covered above
• 10.2.2 0x099F UPL_ALL_PORT — reading a panel's communication ports
• 10.2.3 Range-and-resume: how every enumeration is paged
• 10.3 Read / command / COV core
• 10.4 The point model (Point_base)
• 10.5 CABINET_DISPLAY — firmware / identity block (0x010C)
• 10.6 Session / EBLN node block (0x4640)
• 10.7 Node / BLN management bodies
• 10.8 Upload / PPCL / TEC / trend / alarm representatives
• 10.9 Buildability register — what a reader can and cannot decode
• 10.10 The full structure set is enumerable
• 11. Point Model
• 11.1 The three point layers
• 11.2 Logical point types
• 11.3 Physical-subpoint composition
• 11.3.1 Hand/Off/Auto — a point can be taken away from the panel at the terminal
• 11.4 Point teams (.ptd) and the FLN subpoint model
• 11.5 Analog scaling, sensor types, and enumerations
• 12. Change-of-Value (COV)
• 12.1 The subscription opcode set
• 12.1.1 When subscriptions are registered — concentrated at session establishment
• 12.2 The COV class mask and subscription type
• 12.3 The annunciate / value payload
• 12.4 Command priority (carried in the COV payload)
• 12.5 COV behavior and tuning
• 13. Alarming
• 13.1 Standard vs Enhanced alarms
• 13.2 Alarm priority is distinct from command priority
• 13.3 Analog limits, transitions, and deadband
• 13.4 Alarm destinations and routing
• 13.5 Controller alarms as digital points
• 13.6 Alarm report and acknowledgment opcodes
• 14. PPCL over the Wire
• 14.1 Program model
• 14.2 Point references, names, and macros
• 14.3 Statement / keyword vocabulary
• 14.4 Expressions, operator precedence, and the command parameter array
• 14.5 PPCL program-management opcodes
• 15. Scheduling (TOD / EQS)
• 15.1 Time-of-day mode bitmask
• 15.2 TOD opcodes (per-point time-of-day scheduling)
• 15.3 EQS — equipment scheduling
• 15.3.1 SSTO — start-stop time optimization
• 15.3.2 An EQS zone being created, on the wire
• 16. Database, Bulk Transfer, On-Disk (.P2) Format, Application Catalog & Firmware
• 16.1 Bulk database transfer
• 16.2 On-disk (.P2) panel-database format
• 16.2.1 The supervisor-side device-backup container
• 16.3 Application catalog (controller applications)
• 16.4 Reading a controller application from a live panel
• 16.4.1 AP2_SERVICES_RENDERED — the capability document
• 16.5 Firmware and revision identity
• 16.6 Cabinet lifecycle and destructive opcodes
• 17. Security Considerations
• 17.1 P2 has no cryptographic security
• 17.2 The only gate is the BLN name
• 17.3 Pre-authentication information disclosure
• 17.4 Ungated destructive operations
• 17.5 Registration versus impersonation
• 17.6 Guidance for implementers and owner-operators

• 17.7 Detecting BLN-name enumeration

• 18. Appendices

• Appendix A — Value-enum reference
• Appendix B — Opcode-family index
• Appendix C — Glossary
• Appendix D — Open-questions register
• Appendix E — Evidence-tag legend and lineage pointer

Summary

P2 ("Protocol II") is the application-layer network protocol of the Siemens APOGEE building-automation system — the language supervisory workstations and field panels use to exchange point values, change-of-value (COV) reports, alarms, schedules, control-program (PPCL) source, trend data, and node-routing information. This reference describes P2 as it runs over TCP/IP, the transport used by all Ethernet-attached APOGEE installations.

At a glance:

• Transport. TCP, default port 5033 — every field panel and the supervisor listens here; some installations add a second supervisor-side listener on 5034. Frame semantics derive from a frame's contents and direction, never from the TCP port that carried it.
• Peer model. On the backbone (the BLN, also called the ALN) every member — supervisor and panel alike — is an equal node, and any node may originate traffic. "Request" and "response" describe the role of a frame, not of a node.
• Frame. Big-endian throughout: u32 total_len | u32 message_type (low byte = message class) | u32 sequence | u8 direction | four NUL-terminated ASCII routing slots [BLN, dst-node, BLN, src-node] | (request/push frames only) u16 opcode | body. The opcode is present only on direction == 0x00 frames; a response is matched to its request by the echoed sequence number.
• Dialect. The message class is a legacy/modern pair fixed by a panel's firmware generation — data 0x33/0x34, second channel 0x2E/0x2F, peer carriers 0x29/0x2A — not by direction. A client reads a panel's firmware once (via CABINET_DISPLAY, opcode 0x010C) and selects the dialect and the string encoding (ASCII vs RAD-50) from it; there is no on-wire negotiation.
• Operations. A 2-byte function code (the "AP2 function code") selects the operation; about 630 are defined and 135 are observed on the wire in the reference corpus (§9.5). The high-volume operations are the COV value push (0x0274), the liveness/identity heartbeat (0x4640), point command and read (0x0240 / 0x0220), COV subscribe/unsubscribe (0x0271 / 0x0273), and the database upload/replication family.
• Encoding. Strings are length-prefixed TLVs (01 00 <len> <ascii>); analog values are IEEE-754 single-precision big-endian floats; command priority rides a scope tag. Bodies are ordered, positionally-typed field structures (ASDUs).
• Control logic. Panels run a resident, line-numbered control language — Powers Process Control Language (PPCL); the supervisor reads, edits, and uploads it over P2 but never executes it (§14).
• Security. P2 carries no authentication and no encryption; the only admission gate is a matching BLN name. Any party with network reachability and the BLN name can read points, command points, and reconfigure panels. §17 covers the implications and an owner-operator hardening posture.

The sections that follow specify each layer: transport and ports (§2, §4), framing (§6) and encoding primitives (§8), addressing and identity (§3), discovery / liveness / replication (§5), the operation catalog (§9) and body structures (§10), the point model (§11), COV (§12) and alarms (§13), PPCL (§14), scheduling (§15), database and firmware (§16), and security considerations (§17).

1. Introduction, Scope, Lineage & Conventions

1.1 What P2 is

P2 ("Protocol II") is the application-layer trunk protocol of the Siemens APOGEE building-automation system. It is the language that supervisory workstations and field panels use to exchange point values, change-of-value (COV) reports, alarms, schedules, control-program (PPCL) source, trend data, and node-routing information across a building's automation network. [D/I]

P2 is a peer protocol: on the network tier where it runs, every member — supervisor and field panel alike — is an equal node, any node may originate traffic, and there is no single bus master. [W][D] At the wire level the protocol is symmetric: the same frame format carries traffic in both directions, and the terms "request" and "response" describe the role of a frame, not the role of the node that emitted it (see §6 for framing, §7 for the session model). [W]

This document specifies P2 as it operates over TCP/IP, which is the transport used by all current (Ethernet-attached) APOGEE installations. A reader who works through this reference can implement a conformant P2 peer — a client that establishes sessions, reads and writes points, receives COV reports, enumerates panel contents, and participates in node-routing exchange — interoperating on a live P2 network exactly as a supervisor or panel does. The two normative conformance levels (minimal client, full peer) are defined in §1.6. [I]

Within the APOGEE product family the protocol is also written "PII" — the same "Protocol II" — so "P2", "PII", and "Protocol II" all denote this one protocol. [D/I]

1.2 The protocol family — P1, P2, BACnet coexistence

An APOGEE installation layers several distinct protocols. An implementer must keep them separate; this document specifies only P2.

The vendor's own topology metadata tags a network backbone as BLN Type="BLN_PII" (a Protocol-II backbone) and a fieldbus as FLN Type="FLN_P1" (a Protocol-I fieldbus), and distinguishes an Ethernet BLN (EBLN) from a BACnet BLN (BBLN). [S][D] On a mixed site, the same physical panel may carry both a P2 (EBLN) presence and a BACnet (BBLN) presence; the two are independent stacks selected at the panel. [D] BACnet coexistence is noted here only so an implementer can recognize and ignore BACnet traffic; the BACnet stack, its segmentation, and its object model are explicitly out of scope of this reference. [I]

1.3 Audience and goal

The intended reader is an engineer implementing a compatible P2 device or client — for example, an owner-operator building a monitoring tool, a gateway, or a replacement supervisor for legacy hardware they own and operate. The goal of the document is implementation completeness: every layer needed to put a conformant P2 node on the wire — transport, framing, encoding primitives, addressing, the session handshake, the operation/opcode catalog, the point model, replication and discovery, COV/alarms, error codes, and the on-wire form of PPCL programs — is specified here. [I]

Where a claim derives from observable wire behavior, from the protocol's type-system definitions, or from vendor documentation, that provenance is recorded with an evidence tag (§1.4), so each statement is traceable to how it was established. [I]

1.4 Document conventions

1.4.1 Evidence tags

Every non-trivial claim carries an inline tag, at the end of the sentence or in the final column of a table, recording how it was established:

A field-layout table is tagged [S] when its field order and types come from the ASDU structure definitions, and [W] when the layout has additionally been confirmed on the wire. A behavioral claim tagged [D] must never be presented as a byte-level wire fact; where the byte offsets behind a documented behavior are not pinned, the gap is tagged [OPEN].

1.4.2 Byte, integer, and field conventions

• Hexadecimal byte values are written 0xNN. A run of literal bytes is written space-separated, e.g. 01 00 04.
• All multi-byte integers in the P2 header and in body integer fields are big-endian. The header length, message-type, and sequence fields are unsigned 32-bit big-endian (u32 BE); the opcode and the error code are unsigned 16-bit big-endian (u16 BE). [W]
• Analog values are IEEE-754 single-precision (32-bit) floats in big-endian byte order (f32, big-endian). [W]
• Byte/field layouts are presented as tables of the form:

Offsets are relative to the start of the structure under discussion (frame, body, or sub-structure); each table states its origin.

1.4.3 Terminology

The following terms are used consistently throughout (cross-referenced in detail in §2 and §3):

• BLN — Building Level Network: the P2 peer backbone. Later product generations also call this the ALN (Automation Level Network); the two names denote the same trunk and the same wire field. [D]
• FLN — Floor/Field Level Network: the P1 fieldbus sub-bus beneath one panel. [D]
• CEC — the controller/panel exec (a field panel as an addressable executive). [S][D]
• P2 = Protocol II — the BLN/backbone protocol (this document). P1 = Protocol I — the FLN/fieldbus protocol. [S][D]
• PXC / MEC / PXM — field-panel hardware families (modern modular/compact controllers, the modular equipment controller, and the panel-mount operator/controller variant). Legacy panel families include SCU, RCU, MBC, and MEC. [S][D]
• TEC — terminal equipment controller (a P1/FLN field device); UC — unitary controller. [S][D]
• AEM — APOGEE Ethernet Microserver (a serial-to-TCP terminal server that tunnels a serial P2 byte stream over TCP; §2.1.4). [D]
• EPing — the Ethernet-BLN liveness/discovery ping (the 0x4640-class heartbeat at the protocol layer; §5 and §10). [S][D]
• PPCL — Powers Process Control Language, the line-numbered control language a field panel executes (§14). [S][D]
• AP2 function code — the name for the 2-byte wire opcode (also abbreviated fc, "function code"; §9.1). [S]

1.4.4 Scope summary

In scope: the P2 wire protocol over TCP/IP and the adjacent layers an implementer must understand to use it — transport and ports, framing and encoding, addressing and identity, the session handshake, the full operation/opcode catalog, the point model, replication/discovery, COV/alarms, error codes, and PPCL-over-the-wire.

Out of scope: the BACnet protocol stack (BACnet/IP and BACnet MSTP) that coexists on later panels; the serial-era physical layer except as lineage context (§1.5); and any management-station-internal supervisor-to-station RPC that does not appear on the panel wire. [I]

1.5 Lineage (informative)

This subsection is informative; nothing in it is required for interoperation. It orients an implementer to why the protocol is shaped as it is.

Powers → Landis & Gyr → Siemens. P2's data model and much of its vocabulary descend from the Powers System 600 of the 1980s and its Protocol II — the peer ("token-passing") network discipline of that era — as distinct from Protocol I, the master/slave polling discipline that survives conceptually as the FLN sub-bus beneath a panel. [D/I] The product line passed through Landis & Gyr (and a parallel Staefa Control System branch) before consolidating under Siemens' APOGEE, which is why conventions from several BAS lineages coexist in the modern system. [D/I]

PPCL. The control language a panel executes is Powers Process Control Language, carrying the Powers name forward into the modern product. PPCL is specified, to the extent needed to read and write programs over the wire, in §14. [D]

The model is stable; the encoding and transport evolved. The point taxonomy, the linear analog calibration (engineering value = digitized value × slope + intercept), the command-priority ladder, the point-condition/COV mask, and the peer network model are all carried forward essentially unchanged from the Powers/Protocol-II era. [S][D] What changed is the wire. The original serial-era constructs — the RS-485 multidrop trunk, the circulating media-access token, packed numeric point addressing, RAD-50 name packing, and a serial-link CRC — are not part of P2 over TCP: the modern transport is TCP, integrity and ordering are provided by TCP itself, there is no token because there is no shared bus to arbitrate, and routing is by NUL-terminated ASCII name rather than by packed numeric address. [W][I] The peer-equality concept of Protocol II survives (panels originate their own connections, pushes, and routing advertisements) while the serial mechanism that once implemented it does not. An implementer building for TCP MUST NOT implement RS-485 token arbitration, the serial CRC, or numeric wire addressing; these survive only inside a panel's internal database and CLI reports (§5.5). [I]

A note on string encoding across the lineage. Name/string encoding is a per-firmware-revision, per-platform property, not a per-frame one. Early (pre-IP) field-controller and supervisor revisions pack names in RAD-50 — three characters per 16-bit word, over the 40-symbol alphabet " ABCDEFGHIJKLMNOPQRSTUVWXYZ$.?0123456789" (index 0 = space, 1–26 = A–Z, 27 = $, 28 = ., 29 = ?, 30–39 = 0–9), packed as ((c0×40)+c1)×40+c2. [S] All P2/IP revisions use plain ASCII in the length-prefixed TLVs and NUL-terminated routing slots of §6 and §8. Whether a given platform uses RAD-50 or ASCII is keyed by firmware/platform class (a per-platform STRING_TYPE of RAD50 vs ASCII). [S][D] A peer presenting RAD-50-packed names is a pre-IP revision and is out of scope for a TCP/5033 implementation, which is ASCII throughout. [I]

1.6 Conformance levels

Two conformance levels are defined.

• Minimal client (read-mostly). MUST implement: the Ethernet/IP transport (TCP/5033, §4.1); the frame format (§6) including the four NUL-terminated routing slots and the rule that the opcode is present only when the direction byte is 0x00, parsed by scanning the slots rather than at a fixed offset (§6.4); the service model and error handling (§7); the encoding primitives (§8); a session via EBLN_PING 0x4640 (§5.1, §10.6); and the read/COV opcodes POINT_LOG_VALUE 0x0220, COV_ENABLE/COV_DISABLE/COV_ANNUNCIATE 0x0271/0x0273/0x0274, and CABINET_DISPLAY 0x010C. This is sufficient to discover a panel's identity and read live point values.
• Full peer. Additionally MUST implement: commanded writes with priority (POINT_CMD_VALUE 0x0240 / POINT_CMD_PRIORITY 0x0241, §8.2, §12.4) honoring the command-priority >= gate and release semantics; the upload family (UPL_ALL_*, §9); node-table participation and global-data replication (EBLN_REPL_* 0x4633–0x4636, §5.3); and PPCL transfer (§14). A full peer that emits node-management or cabinet-lifecycle opcodes (§16.6, §17.4) MUST treat them as destructive.

Both levels MUST NOT depend on a multicast discovery beacon — none exists (§5.2) — and MUST treat the BLN-name slot as the only admission gate (§3.4, §6.4).

2. Architecture & Layering

2.1 The layered stack

A P2/IP node is best understood as a small stack of layers. From bottom to top:

  +-------------------------------------------------------------+
  | Application / ASDU layer                                    |
  |   AP2 function code (2-byte opcode) + typed ASDU body       |  §9, §10, §8
  +-------------------------------------------------------------+
  | Transport layer                                            |
  |   unicast TCP, canonical port 5033 (full mesh among peers)  |  §2.1
  +-------------------------------------------------------------+
  | Physical / datalink (one of)                               |
  |   - Ethernet (TCP/IP) ............ the modern, in-scope path |
  |   - RS-485 serial BLN ............ legacy multidrop trunk    |  §2.1.3
  |   - P1 / FLN fieldbus ............ sub-bus beneath a panel   |  §2.2
  |   - AEM serial-over-TCP tunnel ... serial P2 wrapped in TCP  |  §2.1.4
  +-------------------------------------------------------------+

The same application/ASDU layer rides over whichever datalink a node uses; this document specifies the application layer and the TCP/IP transport. The serial, FLN, and AEM paths are described only enough to delimit them from the TCP wire. [I]

2.1.1 TCP/5033 — the canonical transport

P2 runs over TCP, and TCP port 5033 is the canonical and default P2 port. [W][D] Every node that participates in the BLN — the supervisor and every field panel — listens on TCP/5033 for inbound P2 connections, so the BLN is a full mesh at the transport layer: any node may open a connection to any other node's 5033 listener, and a communicating pair commonly holds two connections, one initiated in each direction (§7.3). [W]

The port is configurable but must be set identically across all panels and the supervisor on a given BLN; the vendor exposes a small fixed set of selectable "Transport Server Port" slots, defaulting to 5033, applied uniformly BLN-wide. [D] An implementer should default to 5033 and treat any other value as site configuration. A P2/IP deployment additionally requires, at the network layer, that every node reach every other node by its actual IP address — network address translation between panels and the supervisor is not supported; each node must present a stable, directly reachable address. [D]

2.1.2 TCP/5034 — an optional second supervisor-side listener (NOT a protocol-standard port)

Some installations run a supervisor that also listens on TCP/5034 as a second listener distinct from the canonical 5033. A client MUST NOT assume it exists and MUST default to 5033. [W]

Why a second port exists at all. The supervisor's listening port is a configurable setting, documented as defaulting to 5033, which an integrator is directed to change only when a second P2 application shares the same management station — the two must not collide on one host. A non-5033 supervisor port is therefore a deployment artifact of co-hosted P2 applications, not a protocol feature and not a Siemens-standard second channel. The vendor's own configuration procedure states it directly — accept the default 5033 when the supervisor runs alone, and change it only so it does not conflict when a second P2 engineering application shares the management station. [D] This is the operational reason behind the <host>|<port> identity form of §3.3.1: one host can present more than one P2 endpoint, so the port disambiguates the identity. Expect the common case to be a supervisor on 5033 with no suffixed identity at all. [D] Where it appears, only the supervisor host listens on 5034; field panels never do — the listener set on 5033 is the full mesh, while 5034 is a star into one supervisor box. On the wire, 5034 carries the panel→supervisor push/announce (reverse) channel: panels open a connection to the supervisor's 5034 listener and push COV/value frames there, while the supervisor reaches panels on their 5033 listeners (§7.3). What that endpoint is was previously recorded here as undeterminable from traffic. It is largely determinable, and the answer matters to an implementer: the second port is a P2 node with its own points, not a listener. See §2.1.8. [W] The protocol carried on 5034 is identical to that on 5033 — the same frames, opcodes, and semantics — and unsolicited pushes (COV, alarms) are port-agnostic: a push rides whichever connection/port the receiving supervisor is listening on, and the port number does not change the meaning of any frame. [W]

The decisive evidence that 5034 is not a protocol feature: a supervisor's identity string commonly carries a |5034 suffix (e.g. DCC-SVR|5034), and that exact suffixed identity appears in thousands of frames captured on a 5033-only connection, while the literal text 5033 appears in zero frames anywhere. The supervisor stamps its HOST|PORT identity into the routing slot regardless of which TCP port carries the frame — so the |PORT suffix is part of the identity string, not a live port indicator (§2.1.5, §6.4). [W] A conformant implementation derives all frame semantics from the frame's direction and contents, never from the TCP port that carried it, and defaults to 5033 only (exposing any other port as explicit configuration). [I]

And the two listeners on one host need not be the same service. At an observed supervisor, panel-initiated sessions succeed on 5034 — a panel connects, pushes COV reports and point commands, and every one is answered — while 5033 on that same host accepts the connection, reads the request and closes with no application reply: 984 such connections in 25 minutes, nine panels retrying every 14 seconds, zero payload bytes returned (§5.1). The reason is a deployment one and it generalises: the canonical port was already taken by another product on that machine, so the supervisor's P2 peer service was configured onto a second port. Whoever binds 5033 there answers the TCP handshake and then drops the session. A client MUST NOT infer from an open port that the peer speaks P2, and MUST treat a silently closed session as a configuration outcome rather than a fault. [W]

2.1.3 The serial BLN (legacy datalink, context only)

Before Ethernet, the BLN was a terminated RS-485 multidrop trunk (8 data bits, no parity, 1 stop bit), with up to a few trunks (trunk numbers 0–3) and a firmware-tiered baud rate (e.g. 38400 baud where all firmware on the trunk is recent enough, otherwise 19200; modem links lower). [D] The serial BLN implements the same peer model and the same data model as the Ethernet BLN, but with the serial-era mechanics (token, CRC, packed addressing) noted in §1.5. It is not the subject of this document; an implementer targeting TCP/5033 does not implement it. [I]

2.1.4 The AEM tunnel (serial-over-TCP, context only)

The APOGEE Ethernet Microserver (AEM) is a Lantronix-class serial-to-TCP terminal server that tunnels an existing serial P2 byte stream verbatim over TCP (commonly channel 1 ≈ TCP 3001 for P2, channel 2 ≈ TCP 3002 for the HMI console; 8/N/1). [D] The AEM does not define a new framing layer — it is a transport wrapper around the serial stream, so the bytes inside an AEM tunnel are the serial-P2 bytes, not the native TCP/5033 P2 frames of §3. An implementer targeting native P2/IP does not interact with the AEM path; it is documented only to explain the AEM socket construct present in the vendor datalink layer and to warn that an AEM-bearing port (≈3001) is a different byte stream from a 5033 listener. [I]

2.1.5 The |port identity-suffix convention

A node's source-identity string — carried in the source-node routing slot and exchanged at session establishment — commonly appears as NAME|PORT, e.g. P2SCAN|5033 or DCC-SVR|5034. The |PORT portion is part of the identity string (a HOST|PORT disambiguator that lets one host present distinct identities); it is not a network-layer port indicator and not a field delimiter. [W][D] Handling rules: when building a frame, emit the full literal identity including the suffix and do not split on |; when parsing, accept both the suffixed and bare forms (responses and routing-table entries frequently return the bare NAME) and match identities with the suffix tolerated on either side. [W] See §6.4 for the identity model.

2.1.6 No multicast discovery beacon

P2 has no multicast presence or discovery beacon that a client can listen for to find nodes. [W][D] There is no periodic UDP multicast that a node emits to announce itself for discovery. A multicast group exists in the protocol, but only as an optional, default-disabled peer failure-detection (liveness) feature: when an operator explicitly enables it, panels join a configured Ethernet-BLN availability multicast group (the vendor-documented default group is 234.5.6.7, UDP port 8, up to four group/port pairs per panel) solely to detect peer failure — not to advertise presence for discovery. [D] It is off by default and must not be relied upon for node discovery; an implementation MUST NOT implement a "beacon listener" as a discovery mechanism, because there is no P2 discovery beacon to receive. Node discovery is performed by connecting to known addresses on TCP/5033 and exchanging frames, and on mixed sites by the BACnet-side and Ethernet-BLN discovery exchanges of §10. [I]

Correction of a common misattribution. Traffic to the multicast group 233.89.188.1 (UDP/10001), sometimes mistaken for an "APOGEE multicast beacon," is not Siemens-sourced. It is the Ubiquiti device-discovery protocol, and the captures identify it positively rather than merely excluding Siemens: the source is the gateway (x.x.x.1), the payload is the constant four bytes 01 00 00 00, and each datagram is dual-emitted to 233.89.188.1:10001 and the directed broadcast 255.255.255.255:10001. 233.89.188.1:10001 is Ubiquiti's discovery group and port. Siemens devices on the same segment emit only BACnet/IP and ARP, never to that group or port. The 233.89.188.1 "beacon" does not exist as a P2 feature. Do not implement or rely on it. [W]

2.1.7 Surrounding network services

A P2/IP node typically depends on several platform services around the P2 port itself: name resolution (DNS) to resolve node names to addresses — and where a site has no DNS the vendor's procedure is to populate the management station's hosts file with each panel's and each AEM's name and address, which is worth knowing because it makes name resolution a per-station configuration rather than a network service [D] — address assignment (BootP/DHCP) where dynamic addressing is used, file transfer (FTP) and a console (Telnet and/or a serial CLI) for firmware administration, and management (SNMP) for monitoring. [D] These are platform services around the P2 node and are outside the P2 wire protocol; only TCP/5033 (and, where present, the site-specific 5034) carries P2 itself. [I]

2.1.8 What is on the second port: a node, not a listener

An earlier edition recorded the second supervisor-side port as a "reverse channel" whose nature could not be settled from traffic. It can be, once requests are resolved by who is treated as what rather than by which port carried them.

Every operation the supervisor drives goes outward to a panel on 5033 — reads, COV subscriptions, uploads, priority commands. The point-write opcode runs the other way: 96.7% of 0x0240 POINT_CMD_VALUE in the corpus is a panel sending into the second port. [W]

The full request mix addressed to that port, across the corpus: [W]

Peers write its points, subscribe to COV on it, replicate node tables with it, and send it alarms. That is the behaviour of a field panel. A node that other nodes subscribe to and command is a peer in the BLN, whatever else runs on the same machine.

The point names confirm it. Every write addressed to that port names one of only nine distinct points, and 97% of those writes carry the .BN / .BAC name-twin suffixes — the BACnet-twin convention of §11. The endpoint is publishing BACnet-side values into the P2 name space. [W]

Two identifications fit, and the wire does not separate them:

• A software field panel. Vendor documentation describes field-panel firmware run as a service on a workstation — a virtual panel that behaves on the network like a physical one — and identifies it by exactly the observed form: host name, a pipe, and a TCP port that must differ from the transport server port. A second host in the corpus presents the same HOST|PORT form, so it is a naming rule rather than a local accident. [D][W]
• A BACnet-side trunk. The vendor's BACnet integration presents a BACnet network to the supervisor as though it were a P2 trunk; an endpoint on the supervisor host whose points are overwhelmingly BACnet twins is what that looks like from the wire. [D][I]

They are not exclusive — a BACnet trunk realised as a software panel satisfies both readings.

What an implementer should take from this. Do not model a non-canonical P2 port as "the supervisor's other socket". Model it as another node, resolve it by the node identity in the routing slots rather than by its port, and expect it to behave as a full peer: it holds points, it answers COV subscriptions, and it participates in replication. The port number remains site configuration and must never be used to infer a frame's meaning (§2.1.2). [I]

2.2 Node roles and the object hierarchy

2.2.1 Node roles

Every P2 node — supervisor or panel — is a peer: there is no single master that owns the network. A panel originates traffic without a prior request, using the request encoding (direction byte 0x00), and a supervisor likewise originates reads, writes, and commands; both directions use the identical frame format (§6). [W]

2.2.2 The object hierarchy

P2 addresses entities by name through a five-level hierarchy, broadest to narrowest:

  BLN  (Building Level Network — the peer backbone; one BLN System Name)
   └─ Site  (a grouping container inside a BLN; affects liveness/replication cadence, not admission)
       └─ Node / CEC  (a supervisor or field panel — the addressable executive)
           └─ Point  (a logical point name on that node; may group 1–4 subpoints)
               └─ FLN device / drop  (a P1 sub-device on the panel's fieldbus — a separate namespace)

This hierarchy is corroborated by the vendor's own object model, which nests BLN → CEC → Point at the database and codec layers (a building network contains controllers, which contain points), with a point team abstraction whose default member is the logical point. [S] Addressing detail for each level is specified in §3; the FLN device level is reached through the panel and is not carried in the four routing slots (§6.4). A panel and the supervisor are each a Node (equivalently a CEC, the controller/panel exec). [S]

2.2.3 Point teams

A "point team" groups the physical/virtual subpoints that make up one logical point. A logical point name may bind 1 to 4 subpoints under a single name — but that is a product constraint, not a wire one, and a decoder must not encode it: member_count is an UNSIGNED16 and the member array is nrOfreport_members : UNSIGNED_16 followed by Team_Members[], so the encoding admits 65,535. Read the count; do not size a fixed array of four. [S]

The team's default member is the logical point a client normally reads or commands, and a panel's point-team metadata maps the team's members to their subpoint indices, link types, and engineering-unit scaling. [S][D] FLN sub-device subpoints derive their names from the parent point name plus a suffix describing the subpoint. The point team is the unit a panel uploads when a supervisor enumerates a device's points (§9), and the FLN/TEC point-team templates (the vendor's .ptd device-family library) define, per device family, which subpoint indices exist and what each means. [S][D] Full point-model detail is in §11.

2.3 Service model (informative)

This subsection is informative orientation, not part of the normative wire specification. It describes the request/response service model that the wire framing of §6–§10 realizes; nothing here is required to build a conformant node.

2.3.1 Confirmed and event services

P2 follows the classic ISO/OSI confirmed-service idiom: a Request at the originator becomes an Indication at the receiver, and a Response at the receiver becomes a Confirm back at the originator, with the operation's payload carried as an ASDU (Application Service Data Unit). Operations fall into two service classes, which the implementer sees on the wire as the direction byte (§6.3):

• Confirmed service — a request that expects a matching response, correlated by the sequence number.
• Event service — an asynchronous, unsolicited indication with no prior request: a panel-originated push (COV report, alarm, routing advertisement, heartbeat).

On the wire, both a confirmed request and an event push are emitted with direction == 0x00 and carry an opcode (§6.3); the difference is only whether the peer was expecting them. This confirmed-vs-event distinction is the origin of the wire's request/push-vs-response structure — for example, COV is a register/cancel subscription with an asynchronous annunciate indication (§11, §12). [I]

2.3.2 Dispatch

A practical consequence for an implementer: the wire opcode is the primary dispatch key on a request/push frame, but a robust receiver dispatches on the opcode together with the body shape and direction, because the same opcode can select different operations by body and direction (§3.7). A management station may use a different internal index for an operation, but only the wire opcode appears on the wire; a conformant peer keys solely on the wire opcode (plus body and direction). [I]

3. Topology & Addressing

P2 (Protocol II) is the backbone protocol of an APOGEE automation network. This section defines the network tiers a P2 deployment is built from, the forms a BLN (Building Level Network) can take, the way nodes and points are named and numbered, how those identifiers are carried on the wire versus how they live in a node's database, how traffic crosses from one BLN to another, and the documented size limits of the architecture. Frame-level encoding of the routing identifiers is specified in §6 (frame encoding); the session admission rules that gate membership are in the handshake section; this section is about structure and naming, not bytes on the wire except where the structure dictates them.

3.1 Network tiers

A P2 installation is organized into three stacked network tiers. P2 is the protocol of the middle tier.

The two upper names matter to an implementer because the supervisor's RPC layer is a different protocol from the wire P2 stack. Supervisor-internal command classes (the __Rpc*/CPI vocabulary used between a workstation and its station services) operate above P2; they are not what travels between panels. The wire-level command vocabulary is the AP2 function-code set (see §8). When this document says "P2 wire" it means the BLN tier exclusively. [I]

The vendor's own name for the BLN-tier protocol is "APOGEE PII protocol" — Protocol II — confirming P2 = Protocol II, the Powers/Landis-&-Gyr System 600 lineage carried into the IP era. [S][D]

3.2 BLN forms

A single logical BLN can be realized over three different physical media. P2 framing and the AP2 function-code semantics are identical across all three; only the datalink underneath differs.

3.2.1 Ethernet BLN (EBLN)

The modern form. All panels and the supervisor sit on a switched IP network and speak P2 over TCP/5033 (see §4 for transport). Every node listens on TCP/5033, so an EBLN is a full mesh at the transport layer: any node may open a connection to any other node. [W][D]

EBLN discovery is performed by the vendor's "EPing" (Ethernet Ping) mechanism, an application-layer liveness/discovery exchange (AP2 function code 0x4640 EBLN_PING), not by any multicast beacon (see §3.7). The discovery engine reports each BLN's own name during the exchange, so the BLN name is obtainable from the EPing dialog rather than from a passive broadcast. [S][D]

The vendor's discovery layer distinguishes EBLN (Ethernet BLN) from BBLN (BACnet BLN). They are separate stacks (see §3.2.4). [S]

3.2.2 Serial RS-485 BLN

The legacy form. Panels are wired on a terminated, 2-wire RS-485 multidrop trunk; the supervisor reaches them through a serial port (or, historically, a dial-up modem with the ESC fallback protocol). [D]

Each link class on a panel carries its own configurable baud — the vendor exposes separate BLN_BAUD_RATE, FLN_BAUD_RATE, HMI_BAUD_RATE, and MSTP_BAUD_RATE settings. The BLN baud is uniform across a serial trunk; FLN and HMI bauds are per-link. [S][D]

3.2.3 Remote P2 RS-485 via AEM (transport-tunneled serial)

A serial RS-485 BLN segment can be carried over IP by an AEM (APOGEE Ethernet Microserver) — a Lantronix-class serial-to-TCP terminal server. The AEM tunnels the existing serial P2 byte stream verbatim over TCP (channel 1 ≈ TCP/3001 = P2, channel 2 ≈ TCP/3002 = HMI; 8/N/1). The AEM defines no new RS-485 framing — it is a transport wrapper only, so a P2 implementation that speaks the serial byte stream sees an AEM-tunneled link as an ordinary serial BLN reached over a TCP socket. An alternate P2-bearing TCP port (3001) therefore exists at AEM sites; it is not the canonical 5033. [D][I]

3.2.4 BACnet BLN (BBLN) — separate stack, noted only

Later product generations support a BACnet BLN (BBLN): panels that are BACnet-native (or dual P2+BACnet, e.g. DXR-class controllers) and present themselves over BACnet/IP (UDP/47808, I-Am/Who-Is) rather than over P2. The discovery engine has distinct HandleAddEBlnRequest (P2) vs HandleAddBBlnRequest (BACnet, via IAm) paths. [S][D]

A BBLN is out of scope for this document: it is a different protocol stack with a different addressing model, different framing, and a different security surface. The only cross-tier fact a P2 implementer needs is the negative one in §3.5: there is no BACnet→P2 routing path. A point on a BBLN is not reachable through a P2 frame and vice versa. [D][I]

3.2.5 The logical BLN is self-organizing

Regardless of medium, a BLN is a logical peer group, not just a wire. Membership is gated by the BLN System Name (see §3.4.1): two nodes exchange traffic only if their BLN names match exactly. Within a matched-name group the BLN self-organizes — each node maintains a node-name table (the roster of known peers) that auto-replicates BLN-wide, so every node converges on the same membership view. Peers gate communication to nodes the table marks dead. This is why the membership unit is the name, not the cable: an Ethernet panel and a serial-trunk panel that share a BLN name and a route are members of the same logical BLN. [D][S]

3.3 The point-address 3-tuple: LAN / Drop / Address

Every point on a P2 network has a canonical numeric coordinate, the LAN / Drop / Address 3-tuple. This is the addressing model the vendor's own database export uses for every point record (PointLan / PointDrop / PointAddress). [D]

The 3-tuple is the identity a point database stores, and it does appear on the wire — as the physical-address field of any point that has a physical location (§10.4.2). What it is not is the wire routing key — P2/IP routes frames by NUL-terminated node name strings in the four routing slots (§6), and reads/writes a point by its logical point name carried in the request body, not by the numeric tuple (see §11 for the point model). An implementer uses LAN/Drop/Address to reason about and index topology, and uses names on the wire. [W][S][I]

The vendor's database tags the tuple's network types explicitly: a BLN is BLN_PII (Protocol II backbone) and an FLN is FLN_P1 (Protocol 1 fieldbus), confirming the two-protocol stack the tuple spans. [D]

3.3.1 Node numbering: serial integer vs. Ethernet name

A node has two parallel identities depending on the BLN medium.

• Serial node integer. On an RS-485 BLN a node is a numbered drop, 0–100: panels occupy 0–99 and the supervisor/management station takes 100 (one number is consumed by the supervisor). The protocol carries a set of resident liveness points named NODE0..NODE99 — one per possible drop — whose value reflects that drop's online/failed/ready state. These resident points are how a node's liveness becomes a readable point value to the rest of the BLN. [D][S][I]

• Ethernet pingable DNS node name. On an EBLN a node is identified by a DNS-resolvable node name of ≤ 30 characters (see §3.4.2). The Ethernet node is reached by resolving its name to an IP and connecting on TCP/5033; the numeric drop survives as a conceptual coordinate (and in the database tuple) but is not the wire address. [D][W]

• <host>|<port> — the identity form for an IP participant that is not a physical panel. Node-table dumps contain entries carrying a pipe, such as the supervisor's SUP|5034 alongside its bare SUP (§5.3). §2.1.1 establishes from the wire that this suffix is part of the identity string rather than a live port indicator; the naming rule behind it is documented too. It is a defined identifier form: the machine's host name, a literal |, and a TCP port number. It exists because more than one P2 endpoint can live on one host, and the host name alone would not distinguish them; the port disambiguates. Virtual panels are named this way as a rule and, unlike a physical panel, take no site or system name component in the identifier at all. A parser must therefore treat a node name as an opaque string that may legally contain |, and must not assume one endpoint per host. [D][W]

A deployment constraint follows, and it is worth recording because it is otherwise inexplicable: two P2 endpoints on the same host may not be given port numbers differing by exactly 100. If one uses 5407, then 5307 and 5507 are both unavailable to the others. A ±100 exclusion is the signature of an endpoint quietly occupying a second port at a fixed offset of 100 from its configured one, so that two endpoints spaced 100 apart would collide on it. What that second port carries is [OPEN]; the exclusion rule itself is documented. Note this does not explain the 5033/5034 pair seen in captures — those differ by 1, and §2.1.1 covers them separately. [D][I]

A practical consequence for an implementer: the same logical panel can be referenced as a serial drop integer (in legacy databases and in NODEnn liveness points) and as a DNS node name (on the Ethernet wire). They denote the same node. [I]

3.3.2 Node name length: ≤ 30 wire, ≤ 15 where RAD-50 packed

Node-name length has two regimes, keyed to the firmware's string encoding (cross-ref §8 for the RAD-50 codec and the platform encoding table):

• ASCII regime (all P2/IP revisions): node names are plain ASCII, ≤ 30 characters, NUL-terminated in the routing slots. [W][S]
• RAD-50-packed regime (pre-IP / legacy field-controller and supervisor revisions): names are packed three characters per 16-bit word from the 40-symbol RAD-50 alphabet, which budgets a node-name field to ≤ 15 characters. A system name is modeled as Base + Suffix, with the base length-bounded, corroborating the ≤15-character node-name basis. The documented 15-character node-name limit is also why the session handshake's ≥15-character self-identity acceptance threshold lands where it does (cross-ref the handshake admission rules). [S][D]

Correction — the ≤15 limit is not only a legacy artifact. An earlier revision of this document concluded that "the ≤15 limit applies only to legacy RAD-50 platforms". That is wrong. On a current Ethernet BLN the limit is keyed to the role of the named party, not to the string codec, and both limits are documented rules for present-day configuration: [D]

Two consequences. First, the hyphen is legal in a panel node name and illegal in a supervisor node name, and the underscore is illegal in both — so a validator cannot use one rule for the routing slots. Second, the ≤15 supervisor limit is the documented origin of the 15-character self-identity threshold in the session handshake: the handshake is checking a supervisor identity against the longest one that can legitimately exist. The earlier text reached that conclusion by inference; it is a documented rule.

The panel node name "replaces the node number on a dedicated (P2) BLN" — which states the architectural split of §3.3.1 from the vendor's own side: a serial BLN addresses by number, an Ethernet BLN by name, and the name is a DNS name rather than a protocol-internal identifier. [D]

A peer presenting RAD-50-packed names is a pre-IP revision and is out of scope for an ASCII TCP/5033 client. [I]

3.4 Named scopes and their constraints

P2 addresses entities by name. Five named scopes nest from broadest to narrowest:

BLN (Building Level Network)
 └─ Site
     └─ Node (panel / supervisor)
         └─ Point (logical point name)
             └─ FLN device / drop (sub-bus, separate namespace)

The point-name separator is configurable, and a parser must not hard-code it. Point names are compound — the observed corpus is full of dotted forms — but the character joining the parts is a site setting chosen from six: period, apostrophe, comma, dash, underscore or space. Period is the default and the vendor recommends it, which is why almost everything one sees uses it, and exactly why a tokenizer written against observed traffic will hard-code the wrong thing. [D]

Note that this is the opposite constraint from the scopes below it: BLN, node and site names forbid periods and spaces (§3.4.1–§3.4.3), while a point name may be joined by either. A client splitting a compound name must take the separator from configuration, and one that cannot should treat the name as opaque rather than guess — the wire carries the name as a single TEXT_ TLV in any case (§8.1), so nothing in the protocol requires it to be split at all.

The wire-level enforcement asymmetry of these names (BLN strict, destination node case-insensitive, source identity format-shaped) is specified with the handshake; this section gives the naming constraints themselves.

3.4.1 BLN name

The BLN name is fixed for the life of a network and appears twice in every frame's routing slots (slots 0 and 2; see §6). Later product generations call the same trunk the ALN (Automation Level Network); the wire name field is unchanged. [W][D]

3.4.2 Node name

A supervisor / management-station identity is shaped differently from a panel node name: it is a composite HOST|PORT token (e.g. DCC-SVR|5034, or the placeholder P2SCAN|5033). The |PORT suffix is part of the identity string — a HOST|PORT disambiguator that lets one host present distinct identities — and is not a connect-address. The supervisor stamps the same suffixed identity into its source slot regardless of which TCP port the frame actually rides (a frame seen on TCP/5033 routinely carries a source identity suffixed |5034). The suffix number may coincide with a real listener on the host, but a client MUST treat the whole token as one opaque identity, MUST NOT parse the suffix to choose a TCP port, and derives the connect port from configuration (defaulting to 5033). [W][I]

3.4.3 Site name

The Site name is a grouping container inside a BLN. It scopes the cadence of background liveness/replication traffic between physical locations (intrasite vs. intersite EPing periods, §3.6) but does not gate data exchange and is not validated during the handshake. [D][W]

A node accepts a peer whose Site name differs from or is unknown to it, provided the BLN name matches and the destination node is known. Site grouping additionally appears in a node's database as a container — observed test injections created orphan site groupings (e.g. <DIAGSITE>) in a panel's field-panel log, so the Site is a real on-node structure, not merely a cadence selector. [W][D]

3.4.4 Node numbering and the management station

A node has a conceptual numeric identity 0–99 for field panels; number 100 is reserved for the management station (supervisor/host), which sits above the panel range. This is the conceptual node-id model from the protocol's lineage. On the P2/IP wire, routing is by node NAME, not number — a client places the node's name string in a routing slot, never a numeric id. The 0–99/100 model remains useful for reasoning about topology (and is the Drop of §3.3) but is not a wire field on EBLN. [D][S][I]

3.5 Inter-BLN routing

P2 panels do not talk panel-to-panel across BLN boundaries. A panel on BLN-A cannot directly address a panel on BLN-B; the BLN name is a hard membership gate (§3.4.1), and a frame whose BLN name does not match the receiving panel's own is rejected at the transport layer (TCP RST on a field panel). [W][D]

Cross-BLN data flow is brokered by the supervisor, via its CrossTrunkService. The supervisor is a member of (or a proxy onto) multiple BLNs and relays data between them — BLN-A ⇄ supervisor ⇄ BLN-B. The four routing slots in every frame ([BLN, destination-node, BLN, source-node], see §6) carry exactly the information this brokering needs: the BLN name in slots 0/2 scopes which trunk the frame belongs to, and the source/destination node names in slots 1/3 identify the endpoints. When the supervisor relays a frame across BLNs it is operating on these slots. The repeated-BLN structure of the four slots is the wire expression of the per-trunk scoping that makes brokered cross-trunk routing possible. [W][I]

Two hard constraints bound cross-BLN traffic:

• No BACnet→P2 path. A point on a BACnet BLN (§3.2.4) is not reachable through a P2 frame; the supervisor brokers within and between P2 BLNs, but BACnet and P2 are separate stacks with no protocol-level bridge in the P2 direction. [D][I]
• ~300-point cross-BLN COV-share cap. The number of points that can be shared across BLNs by change-of-value subscription is bounded at approximately 300 points per the cross-BLN sharing limit. Beyond this cap, cross-BLN COV sharing is not available; an implementer must not assume unbounded cross-trunk COV propagation. (COV mechanics are in §12.) [D]

Cross-trunk behaviour an implementer has to plan around. Vendor documentation for the feature adds three constraints that are not visible in the frame format and will surprise anyone treating a cross-BLN reference as equivalent to a local one: [D]

• Commands and COV reports cross the boundary at one per second, and excess is coalesced rather than queued — if several commands are issued within a second, only the last is sent. A cross-BLN write is therefore not a reliable sequence of writes, and a client must not use one to drive a state machine.
• It is explicitly not intended for real-time control, and the vendor directs that cross-trunk references be kept out of control-loop statements.
• The direction is one-way. The brokering lets a P2 panel reference points on another P2 BLN or on a BACnet BLN; it does not let a BACnet panel reference P2 points. That is the same asymmetry the first bullet above states from the wire side, now confirmed from the vendor's own description of the service.

The feature is also enabled per BLN rather than globally, and is not supported on every panel generation — so its availability is a site property, and a client must not assume a cross-BLN reference will resolve. [D]

A node-eviction operation exists at the node-management layer, by which a node can be force-evicted from the BLN roster; it is a node-table mutation, documented here for topology completeness and flagged as destructive (it removes a node from the operating membership view). It is not a routing facility and is not part of normal traffic. [S][D]

3.6 Liveness and replication cadence (topology layer)

BLN membership is maintained by two background mechanisms whose cadence is topology-relevant (the per-frame timing is in the session/COV sections, not here):

• EPing (Ethernet liveness/discovery), two-tier: intrasite period 10 s, timeout 5 s; intersite period 60 s, timeout 5 s (intersite period configurable up to ~900 s). The Site name (§3.4.3) selects which tier a peer relationship uses. [D]
• Node-table replication: notify ~10 s, poll ~30 s, full cycle ~75 s, holdback ~10 s, tombstone 86400 s (24 h) before a removed entry is reaped. The node-name table auto-replicates BLN-wide so all members converge on one roster. [D]

The 24-hour tombstone and the auto-replication are why stale roster entries persist and propagate across a BLN — relevant to the accumulation behavior discussed in the findings, and the reason an implementer should expect a roster to contain entries for nodes not currently reachable. [D][I]

3.6.1 Node states

A node-table entry carries a state. The node-state vocabulary (the values an entry can hold, and the events that transition it) is the liveness taxonomy: [S]

Node-table transition events include node_added, node_removed, node_failed, node_ostracized, node_coldstarted, node_made_online/node_made_offline, node_made_ext_timeout, and node_make_ready. The ostracized and coldstarted events correspond to the destructive node-management operations (§9.3, and the cabinet-coldstart opcodes in §9). [S]

3.7 No multicast discovery beacon

P2 has no multicast presence/discovery beacon. There is no periodic broadcast a node emits to announce itself and nothing to passively listen for to enumerate P2 nodes. Discovery is active: connect to known addresses on TCP/5033 and exchange EPing/IdentifyBlock frames (§3.2.1). [W][D]

Two clarifications an implementer must not get wrong:

1. An optional, default-DISABLED multicast failure-detection feature exists. When an operator explicitly enables it, panels join a configured multicast group/port (the real Ethernet-BLN availability group is 234.5.6.7, UDP port 8; up to four group/port pairs per panel) solely to detect peer failure faster. It is a liveness heartbeat among already-known peers, off by default, and is not a discovery beacon — a fresh node is not discoverable by listening for it. [D][S]

2. The 233.89.188.1 "APOGEE multicast beacon" does not exist. Traffic to 233.89.188.1:10001 observed on test networks is UniFi-gateway-sourced (source IP = the gateway's own, Ubiquiti OUI, 4-byte 01 00 00 00 payload, ~10.5 s cadence), not Siemens. Siemens devices on the same segment emit only BACnet/IP and ARP. Any tooling that labels 233.89.188.1:10001 as a Siemens P2 beacon is misattributing gateway traffic. A P2 implementation MUST NOT implement a beacon listener as a discovery mechanism, because there is no P2 beacon to receive. [W]

3.8 FLN / P1 fieldbus hanging off a panel

Beneath an individual panel hangs a Field Level Network — a sub-bus of field controllers the panel polls master/slave. FLN device points are a separate namespace from BLN points: they are not addressed through the four P2 routing slots; the parent panel mediates all access to them. [D][W]

FLN device classes are enumerated by the vendor FLN_Device_Type set: TEC (terminal equipment controller), TCU, UC (unitary controller), PXM, DPU/MPU, P1BIM (P1 Bus Interface Module), GATEWAY/FLOAT_GATEWAY, GLOBAL_IO, and FSCS. [S]

An implementer reaches FLN data by establishing a session to the parent panel (§7.3.1) and issuing the FLN browse/enumerate opcodes of the 0x09xx upload family (UPL_ALL_TEC, etc.; see §9 and §10). FLN-scoped operations ride a session-carrier message class on the wire (§6). The panel returns the FLN device's point data on behalf of the field controller; there is no direct P2 transport to an FLN device. An FLN point is selected by its drop number on the addressed FLN plus its subpoint index — this is the lowest level of the LAN/Drop/Address tuple (§3.3) and the FLN-device tail of the named-scope hierarchy (§3.4). [W][S][I]

3.9 Documented topology limits

The architectural maxima below are deployment limits, not wire-protocol constants; they bound what a conformant deployment may contain and are useful sanity checks for an implementer sizing tables or validating configuration. [D]

The two per-BLN limits have different origins, and the difference matters. On an RS-485 BLN the ~99 ceiling is an addressing artifact: it is the 0–99 drop range and nothing more. An Ethernet BLN does not use drop numbers at all — its members are identified by DNS-resolvable names (§3.4.2) — and yet it is still capped, at 100 panels per logical BLN. A limit that survives the removal of the addressing scheme that supposedly caused it is not an addressing limit. It is a node-table capacity, which is the right way for an implementer to think about it when sizing the replicated table of §5.3. [D][I]

Concurrent sessions, measured. The last row is the only one of these that the corpus can speak to, and vendor documentation gives it no number. Sweeping connection lifetimes across 11,529 connections that have a P2 listener at one end, on 515 distinct listeners: a single field panel's 5033 listener serves a peak of 9 concurrent sessions from 9 distinct peer hosts, and in each capture where that peak occurs exactly 10 P2 hosts are present — so the peak is every other node on the BLN at once. A supervisor listener peaks at the same 9. Counted as sockets rather than hosts the peak is 18, because a peer commonly holds two connections to the same node (the 5033/5034 pattern of §2.1.2). [W]

Read this as a floor, not a ceiling: nothing in the corpus was refused a connection, so no firmware limit was reached, and the site is a 10-node BLN — 9 is what full mesh costs here, not what the panel can bear. The useful conclusion for an implementer is the shape rather than the number: a panel must expect every other node on its BLN to hold an open session simultaneously, so a listener that accepts only one or two peers is not conformant.

These figures derive from vendor topology documentation; treat them as the documented ceiling, not a guarantee that a given firmware enforces each one identically. Where a finding or operation depends on a limit (e.g. the cross-BLN COV cap), the dependency is called out at the relevant section. [D][I]

4. Physical & Datalink Layer

P2 (Protocol II) is a logical application protocol that has been carried over several physical media across its lineage. The dominant modern transport is Ethernet/IP (the Ethernet BLN, or EBLN); the original and still-supported transport is a serial RS-485 multidrop trunk (the dedicated serial BLN). Below P2's BLN tier sits the field bus, P1 (Protocol I) over RS-485, addressed by route-through from the BLN. This section defines what is known about each medium at the physical and datalink layers. The byte-level frame grammar (length prefix, routing slots, opcode, ASDU body) is medium-independent and is specified in the framing section (see §6); on the serial media that same logical frame is carried inside a medium-specific link framing whose exact bytes are not established here.

4.1 Ethernet/IP transport (the canonical P2 transport)

Native P2 over IP runs on TCP. Every BLN member — the supervisor and every field panel — listens for inbound P2 connections on a single configurable unicast Transport Server Port, default TCP/5033 [W][D]. The BLN is therefore a full mesh at the transport layer: any node may open a TCP connection to any other node's listener (see §7). The port is observed carrying P2 in the capture corpus on 5033 and (at sites with a second supervisor listener) 5034 [W].

The 8-slot model means a panel can be told to listen on an alternate port (e.g. to deconflict with a co-resident supervisor product on the same host, which is the origin of the site-specific TCP/5034 second listener); slot 1 always defaults to 5033 and is the canonical port. A client should default to 5033 and treat any other value as site configuration. See §2.1.5 for why the |PORT suffix that appears inside identity strings (e.g. NODE1|5034) is part of the identity string and is not a live port indicator — the same suffixed identity rides whichever TCP port actually carried the frame [W].

The 5034 listener and the two-connection pattern. In the observed Desigo deployment, 5034 is not merely a "site-specific second port" — it is the supervisor-side inbound listener for the reverse (panel→supervisor) channel: field panels listen on 5033 for the supervisor's poll/command channel, while the supervisor listens on 5034 for node-originated push/value traffic and node announcements. Each node-pair therefore maintains (at least) two TCP connections — supervisor→panel:5033 and panel→supervisor:5034 — one opened in each direction (§7.3). The exact supervisor port assignment is deployment-specific (it can equally be 5033, and the 8-slot model permits other values), but the two-listener / two-connection model is the structural pattern, independent of the specific port numbers. [W]

4.1.1 Surrounding observable service footprint

A P2/IP panel is a small embedded host that exposes platform services around the P2 port. These are not P2 and carry no P2 frames; they are listed only as the observable footprint of a real panel, useful for fingerprinting and for understanding what else is on the wire. Only TCP/5033 (and optionally a second supervisor listener) carries P2 itself.

The Telnet CLI is a significant secondary observation surface: panel-side node-name-table reports, field-panel reports, and point-look output are read over Telnet, and these have been used to corroborate wire findings (e.g. confirming a registered identity appears as a Permanent node-table entry) [W]. The CLI is not part of the P2 wire protocol.

4.2 AEM serial-to-TCP tunnel (a second observable P2-bearing TCP port)

The AEM (APOGEE Ethernet Microserver) is a Lantronix-class serial-to-TCP terminal server that bridges a legacy serial BLN onto IP by tunneling the panel's serial RS-232 byte stream verbatim over TCP [D]. To the supervisor the tunneled BLN appears as an always-connected remote BLN.

Critically, the AEM does not define new P2 framing [D]. It encapsulates the existing serial P2 byte stream inside a TCP connection — the same bytes that would have crossed the RS-485 trunk, wrapped in TCP. Channel 1 (TCP/3001) is therefore a second observable P2-bearing TCP port distinct from native 5033, but the application bytes inside it are serial-BLN P2, not the IP-native framing of §6 (the IP-native handshake/heartbeat opcode behavior is specific to the EBLN stack). An implementer treating an AEM Channel-1 stream must speak the serial-BLN dialect, not assume the TCP/5033 IP-native conventions.

4.3 Serial BLN datalink (dedicated RS-485 trunk)

The original P2 BLN is a terminated, multidrop RS-485-style two-wire trunk — the Powers "dedicated BLN" — tapped via a Trunk Interface (TI / TI2, e.g. part 538-670) at the workstation COM port.

Observed operator-terminal (MMI/HyperTerminal) capture of a legacy panel shows the LAN bus speed reported as 4800 baud for LAN #1–#3 on that panel, confirming the serial-BLN baud is a per-panel configurable parameter at the operator layer [W][D]. The firmware-tiered default (19200 legacy / 38400 modern) is the documented network-wide rule; individual panels may be configured otherwise.

4.4 FLN / P1 field bus (RS-485 two-wire)

Beneath each panel sits the Field Level Network (FLN), running P1 (Powers Protocol I) over a two-wire differential RS-485 trunk. FLN device points live in a separate namespace from BLN points and are reached by route-through from the hosting panel (§5.5); the panel is the gateway/master polling its FLN devices.

On a modular panel the RS-485 FLN trunks are provided either by built-in ports or by an add-on RS-485 FLN expansion module — Siemens' PXX-485.3 carries "three RS-485 P1 FLN connections OR one MS/TP FLN connection" per the public PXC Modular Series datasheet. This module sits on the panel's downstream (field) bus and is wholly separate from the upstream ALN/supervisor link that carries P2 — it has no bearing on the P2 wire dialect (§6.6). [D]

A panel may alternatively host a BACnet MS/TP field bus in place of P1 (Fln_type_enum: P1 = 0, MSTP = 1) [S]. Which one is available tracks the panel's firmware track, not the hardware: proprietary-P2/APOGEE firmware (the subject of this spec) drives a P1 FLN only, while the separate BACnet firmware build of the same hardware adds the MS/TP option. MS/TP is a different protocol stack and is out of scope for this P2 specification; only the P1/FLN bus is treated here. [D]

4.5 Open items — serial and field-bus framing

[OPEN, PARTLY ANSWERED] Serial-BLN P2 link framing bytes. Only the line parameters (8/N/1, baud tiers, trunk numbering) were established for the dedicated serial BLN. The message layer above the framing is now recovered from controller firmware — see §6.8 — giving the address byte and its position, a compact operation encoding, a 253-byte cap, and the forwarding rule for a message addressed elsewhere. The message layer is now attested from the supervisor end as well — a supervisor-side codec builds the same encoding, agreeing with the panel on the group/ordinal pair and adding the ordinal's byte order (§6.8). [C] What is still unobserved is the link layer beneath it: start/sync delimiting, CRC/checksum, and the medium's segmentation, all of which a lower layer has already stripped before the code in §6.8 sees the message. The supervisor's link-layer component was examined for them and does not carry them: it is a transport — ports, partners, sequence numbers, a socket path and a modem path — and it hands the codec's output down without prefixing a P2 header, so the three bytes preceding the group byte are added below it or supplied by the medium. [C] An AEM Channel-1 capture (TCP/3001) remains the way to see them, since the AEM tunnels the serial stream verbatim.

[OPEN] FLN/P1 frame bytes. The P1 fieldbus discovery transaction (P1WhoAreYou), addressing (drop + application number), physical layer (RS-485 2-wire), and baud are documented, but the P1 frame byte layout itself is unobserved. The on-wire P1 frame structure, the WhoAreYou request/response bytes, and the per-poll cadence/retry behavior require a P1-bus capture or a route-through capture from the BLN. The route-through opcode is now named: 0x0313 AP2_P1_ROUTE, with 0x0314 alongside it (§9.1.1). Sixteen distinct field-device operations tunnel through 0x0313, so a capture containing it carries P1 payloads inside a P2 frame — which is the cheapest route to these bytes, and needs no access to the RS-485 segment itself. Neither opcode occurs in any capture in the present corpus.

[OPEN, LARGELY ANSWERED] P2 segmentation thresholds and reassembly rules. The ~256-byte figure from vendor connection-test material is a connection-test ping size, not a maximum P2 data-packet cap — single P2 frames are observed with total_len up to ≈1,587 bytes (a ~1,530-byte body of packed records plus header+slots) in one response [W]. The ceiling and the reassembly rule are now recovered from the supervisor's AP2 codec. A segment buffer is 16,384 bytes, of which the encoder is handed buf+2 with a capacity of 16,382 bytes; the two reserved bytes at buf[0] are the u16 function code, which is why the wire carries the opcode immediately before the body and why total_length includes it. Reassembly is a cursor against a declared total: each mapped segment copies n bytes and advances the cursor, except the last, whose length is total - cursor; the sender therefore knows the total before it begins. The command object carries an explicit more-follows field, set on the segmenting path and cleared on the direct one. [S] What is still open is the wire behaviour at the threshold. No body in the corpus exceeds 16,382 B — the largest complete body is 1,570 B and the largest declared is 12,073 B — so the corpus is consistent with the ceiling without exercising it. Whether a result larger than one segment appears as two P2 frames, and what marks the continuation on the wire, needs a capture of an upload large enough to segment. [W][OPEN]

4.6 The serial trunk is token-passing, and its parameters are named

The frame bytes remain open (§4.5), but the medium-access discipline is settled: the serial trunk driver is configured with a token hold time and a local node address, which is a token-passing MAC, not a master/slave poll. [S] The driver's parameter set, with the values it ships with:

Two of these are structurally informative. InterCharTime implies the serial framing delimits by an inter-character silence gap rather than a start delimiter, which is consistent with §4.5 finding no start/sync byte — there may not be one to find. And the two distinct transaction timeouts, client 30 and server 40, mean the responder is given a longer budget than the requester waits, so a server that answers between those two values produces a response the client has already abandoned.

The driver exposes eight channels and up to four installed adapters, each with a legacy ISA I/O base and a shared upper-memory segment. That is the architecture the trunk was designed around, and it is why trunk numbering (§4.3) is per-channel rather than per-host. [S]

5. Discovery, Liveness & Replication

A P2 BLN is a self-organizing peer network. There is no central registry: nodes find and monitor one another using a liveness probe (EPing), an optional multicast availability channel, and a node-name/IP table that auto-replicates across the whole BLN. Below the BLN, the panel discovers its FLN devices with the P1WhoAreYou transaction. This section defines each mechanism, its wire opcode where one exists, and its documented timing.

5.0 Documented timer defaults, and how they scale

The discovery and replication timers of §5.1–§5.3 have documented defaults, and four of them are not constants — they scale with the number of panels on the BLN. All values in seconds. [D]

Measured against the wire. Five opcodes run on a fixed period, measured per peer connection across 621,268 frames — every one with a median absolute deviation of 0.00 s: [W]

EBLN_PING at 10.00 s is the EPing row of the table above, confirmed on the wire. EBLN_REPL_PULL at 60 s per peer does not match the 30 s "replication polling period", and the discrepancy is left open rather than reconciled: the mapping from that documented timer name to this opcode is an assumption — §5.3 describes 0x4634 as the digest advertisement, not necessarily as what the polling timer governs. Either the timer is not this opcode's, or this site is configured off-default. [OPEN]

One candidate explanation is now ruled out. Both timers above have an intrasite and an intersite default, so 60 s could simply have been the intersite figure showing up in a mixed site. It is not, and two measurements close it off:

There is no second population in either. EPing runs at its intrasite default of 10 s on every connection and never at the 60 s intersite value, which establishes that every peer here is intrasite — and an all-intrasite site should then show replication at 30 s, not 60 s. So the disagreement is real and is not a site-topology artifact: this is one timer at twice its documented intrasite default, uniformly, on 153 connections. What remains open is only whether 0x4634 is the opcode that timer governs. [W]

Measure per peer connection, not per node. A node with several peers emits one of these per peer, so a per-node aggregate reads far faster than the protocol cadence — for EBLN_PING on a node with three or more peers the aggregate median is 0.01 s, which is the emission burst, not the timer. Every period above is per connection.

The intra-site column is what a single-site capture shows, and it is the column this document's observed timings match. The scaling rule applies only to the inter-site timers, and the guidance is to leave the defaults alone below 50 panels — so a small deployment runs entirely on the constants above.

Two things follow for an implementer. A client that infers "the EPing period is 10 seconds" from a capture has measured the intra-site default and should not generalise it. And the 900-second cap means the inter-site timers stop scaling at 720–840 panels depending on the setting, which is far above the liveness-addressable node ceiling of §14.2 — the cap is not the binding limit on BLN size.

5.1 EPing — Ethernet-BLN availability probe (liveness, not a beacon)

The Ethernet BLN's availability/liveness primitive is EPing (Ethernet Ping). On the wire EPing is the AP2 function code 0x4640 (AP2_EBLN_PING) [S], and 0x4640 is the single most frequent opcode in the capture corpus (78,623 requests against 53,101 for the COV value-push 0x0274). That ranking inverted when panel-side captures were added: measured from the supervisor alone 0x0274 leads, because a supervisor sees COV pushes and point reads while a panel mostly sees the mesh keeping itself alive — the steady ~10-second per-peer heartbeat, present in the tens of thousands of frames in any multi-hour supervisor capture [W]. That cadence is configuration, not protocol. The EPing interval is a per-device supervisor setting whose documented minimum is 10 seconds, so an observed ~10 s means the site is sitting at the floor; other installations may ping far less often. A client MUST NOT hard-code the interval, MUST NOT infer a peer is dead from a single missed interval, and MUST NOT use the observed cadence to fingerprint a firmware or product generation. [D]

Measured, and it is remarkably tight. Over 16.7 continuous hours on a panel's own switch port, each of its eight panel↔panel pairs exchanged 6,008–6,010 pings at a median interval of 10.0 s and a maximum of 10.5 s — essentially no jitter, sitting exactly on the configured floor. Across the whole window no peer was silent for longer than a single interval, so a peer that misses two consecutive pings is genuinely unusual and is a reasonable liveness threshold at a site configured this way. The supervisor is on its own schedule, however: the panel↔supervisor pair carried 8,403 pings at a median of 8.8 s over the same window — about 40% more traffic and a shorter interval than any peer pair. Liveness cadence is therefore per-endpoint, and a client must derive it by observation per peer rather than assuming one value network-wide. [W] The same 0x4640 opcode also serves as the session establish / IdentifyBlock exchange and the in-session keepalive (see §6, §7): establishing presence and proving continued liveness are the same operation, which is why this one opcode is so prominent in the traffic. 0x4640 is observed under every message class seen anywhere — 0x29, 0x2A, 0x2E, 0x2F, 0x33, 0x34 — and on both observed ports 5033/5034. (0x2A carries it only in panel↔panel sessions, so it appears in panel-side captures and not in the supervisor-side census; see §9.7.) Its body is the eBLN_Node block (§10.6) and its length is variable. Do not compute it arithmetically. An earlier edition of this document gave 35 + node-name length, which reproduces every observation in the corpus and is still wrong to publish: the corpus is a single site, and that 35 is 3 (name TLV header) + 6 (site_name TLV) + 10 (bln_name TLV) + 16 (fixed tail) — the site's own site-name and BLN-name lengths baked into a constant. At a site whose site or BLN name differs in length the figure differs, and an implementation using it would mis-frame every ping.

The correct rule. Parse the three leading TLVs, then take a 16-byte tail. Where a length must be computed rather than parsed — sizing a buffer, or validating a frame before decoding it — the general form is:

body_length = 25 + len(node_name) + len(site_name) + len(bln_name)

  25 = 3 TLV headers (3 bytes each) + the 16-byte fixed tail

All three name lengths are site and node configuration; only the 25 is a protocol constant. Checked against every distinct body size observed: 25+5+3+7 = 40, 25+6+3+7 = 41, 25+15+3+7 = 50 — the last being a supervisor identity of 15 characters. Substituting this site's site_name (3) and bln_name (7) collapses it to the old 35 + node-name length, which is how the site-specific terms went unnoticed across 621,268 single-site frames. [W] Whether a ping is answered depends on which side opened the session. Every supervisor-initiated 0x4640 in the corpus drew a reply. Panel-initiated pings into a supervisor's 5033 may not: in a 25-minute capture at one supervisor, nine panels each opened a fresh TCP connection to its 5033 every 14.0 seconds, sent a well-formed EBLN_PING, and were answered with zero payload bytes and a FIN — 984 connections, no application reply on any of them, while that same supervisor answered its own outbound pings to those panels on a 10.0-second cadence, 100%. A client must therefore treat an unanswered EPing as a possible policy outcome and not only as a liveness failure, and must not assume the absence of a reply means the peer is down. [W]

On the wire the EBLN_PING (0x4640) request and response bodies each carry, in order: TLV(node-name) + TLV(site) + TLV(BLN-name), then the eBLN_Node trailer — five 1-byte boolean flags (failed, ready, replication_online, reresolve_all, reresolve_unresolved; observed 00 01 01 00 00), a u32 spare (0), a u32 baseTime — an absolute Unix-epoch wall-clock timestamp (e.g. 0x6A3D… ≈ a 2026 date/time; it advances frame-to-frame because it tracks wall-clock, not an uptime/tick counter), a u16 timezone offset, and a u8 DST flag. [W] This is the eBLN_Node identity element of §10.6 realized on the wire — the node/site/BLN triple is the same identity the access gate checks (§6).

EPing is two-tier, distinguishing peers in the same physical site from peers across a slower inter-site link:

A node that stops seeing a peer's EPing within the timeout treats that peer as unavailable and gates communication to it (§5.3). These are discovery/liveness-layer periods, not P2 frame-level retry counts or per-frame ACK timeouts — the latter are not established (see §5.6 open items).

Note: EPing/0x4640 is a unicast TCP exchange between known peers; it is not a broadcast or a discovery beacon. Discovery of a peer's existence comes from the replicated node-name/IP table (§5.3), not from passively listening for EPing.

5.2 Multicast availability channel (optional, off by default) — and the beacon myth

P2 supports an optional IP-multicast availability/failure-detection channel layered over the unicast TCP transport. It is disabled by default and activates only when an operator configures a multicast port.

This is a peer-liveness heartbeat group, not a discovery beacon: a node does not announce itself to the world for newcomers to find, and a P2 implementation must not implement a multicast beacon-listener as a discovery mechanism — there is no such beacon to receive. Discovery is via the replicated node table (§5.3).

Beacon-myth correction. A previously asserted "APOGEE multicast beacon at 233.89.188.1" does not exist as a P2 mechanism [I]. That assertion was a misattribution: the traffic in question was unrelated gateway/network-appliance traffic (UniFi-class), mislabeled by an early dissector. The only multicast P2 uses is the off-by-default availability group at 234.5.6.7 / UDP 8 above. Independent confirmations: the vendor field-panel/LocalNet configuration documents 234.5.6.7:8 as the group [D]; and on a live network with multicast disabled, no 233.89.188.1 P2 traffic is present in capture [W]. Any tool keyed to 233.89.188.1 for P2 discovery is wrong.

5.3 Node-name-table replication (the self-organizing BLN)

BLN membership is carried in a node-name table (name ↔ IP, with state) that is entered once on any one panel and auto-replicates to every panel on the BLN [D]. Each panel continuously monitors every other peer and temporarily disables communication to any peer that becomes unavailable, resuming when the peer returns [D]. This is the application-layer membership model built on top of the EPing/multicast liveness layer — there is no central master; the table is the shared, replicated source of truth for "who is on this BLN and at what IP."

The replication of shared/global data (the node-name table, plus alarm destinations, user accounts, state-text tables, etc.) runs on a notify + poll + cycle schedule with dead-node tombstoning:

(N scales with node count.) A dead node's entry persists for 24 hours (tombstone lifetime) before it expires. This replicated background traffic — distinct from per-point change-of-value (see §12) — accounts for the steady low-rate 0x46xx replication frames seen alongside the EPing heartbeat.

5.3.1 Replication opcodes

The replication exchange is a small family of AP2 function codes. In the current capture corpus only 0x4634 (EBLN_REPL_PULL) is routinely wire-observed (thousands of frames); the other four appear only rarely (empty bodies) in the broader capture set and did not fire during captures that contained live database changes — so they are documented from the type system, not confirmed as the delta-carrier here (see step 3 below):

0x4634 (EBLN_REPL_PULL) is the mechanism by which a node advertises/obtains the current node roster — the same roster that constitutes BLN membership; its request carries the full version digest and the matched response is an empty (0 B) success ack (§5.3 step 3). The actual changed-record delta propagation observed on the wire rides the DBCHANGE_*/UPL_ADDED_*/UPL_DEL_* family on the second channel, not these 0x463x opcodes.

Note on naming: an earlier behavioral label for 0x4634 was "PushRoutingTable" (from its observed effect of conveying the node/routing roster). The function-code enumeration names it AP2_EBLN_REPL_PULL [S]; the roster-bearing behavior is consistent (a pull of replicated routing/membership data). This reference uses the enum name; the behavioral description (roster transfer) is unchanged.

EBLN_REPL_PULL (0x4634) body — the replicated node table as a versioned digest. The body is the full node-name table carried as a version-vector digest, wire-confirmed [W]: an 8-byte header (00 00 00 00, then a 2-byte table-level version, then a 2-byte entry count) followed by one entry per node, each a TLV(01 00 <len> <node-name>) immediately followed by a u32 per-node version. A $paneldefault entry leads, then every BLN node and the supervisor (the supervisor participates as ordinary node entries — e.g. both its SUP and SUP|5034 identities appear; the pipe form is the defined <host>|<port> identifier described in §3.3.1, not an artifact).

offset 0:  00 00 00 00  <u16 table-version>  <u16 entry-count>     -- 8-byte header
then, per node entry:
   01 00 <len> "<node-name>"      -- name TLV
   <u32 per-node version>         -- this node's current change generation
first entry:  ... "$paneldefault"
then:         every BLN node + the supervisor identity(ies)
finally:   00 00 00 00                -- 4-byte trailer/terminator after the last entry

The u32 after each name is that node's change generation — it increments whenever that node alters its replicated state. Crucially, the version is a per-node convergence counter, not a timestamp, and it does not grow during a quiet capture. Across a 3-hour supervisor capture (1,653 pull digests) each node's advertised version was constant in time within any one observer's view, but differed by vantage: the supervisor advertised a lower per-node version than the panels did for the same node (observed panel−supervisor offsets ranged ≈ +1,781 to +3,564). That gap is a snapshot of how far the supervisor's replicated copy lags the panels' current state, i.e. the mesh's convergence state at capture time — it is not a per-second increment. (An earlier reading that took a node's min-to-max version across digests as growth-over-time was conflating two vantages' digests, not two points in time.) A burst of growth would appear only when a node's database actually changes (add/rename/command), bumping its own counter and the header table-version; these captures were largely quiescent. The 2-byte table-level version tracks the table as a whole, and the entry set reflects the advertising node's own view of membership, so roster length can differ between nodes.

How a name added on one panel reaches all of them. This is masterless anti-entropy gossip over the full mesh (§7.3), reconciled by version comparison — no central coordinator:

1. You add (or rename) a node entry on panel A. A inserts the row, bumps its own per-node version (and the header table-version).
2. On its next replication round A sends its full digest to its peers via EBLN_REPL_PULL (0x4634) — observed flowing mutually in every direction (panel→panel, panel→supervisor, supervisor→panel), so every node periodically advertises its whole table to every other node. [W]
3. Each receiver compares the advertised per-node versions against its own. If they already match, it answers with an empty (0-byte) success ACK — the steady-state case, and it is overwhelmingly the case: 10,003 of 10,016 matched 0x4634 responses are empty. The digest request carries the full version vector; the response is just an ack. An earlier edition said every matched response was empty. Thirteen are not — each carries a 4-byte body holding the u32 value 3 (nine of them) or 2 (four). What that count is, is [OPEN]; that it exists means a client must read the response length rather than assume zero. [W] If a peer is behind on some node (A's version is newer, or A carries an entry the peer lacks), it fetches the delta. Two delta paths are seen. The commonly observed one, during live database activity, is the ordinary database-change opcode family flowing on the 0x2E/0x2F second channel: DBCHANGE_* (e.g. 0x0956 DBCHANGE_CONTROLLER), UPL_ADDED_* (0x0971 POINT, 0x0974 TREND, 0x0976 TEC, …), and UPL_DEL_* (0x0961/0x0964/0x0966/…) — i.e. the changed records propagate as the same add/delete operations the supervisor uses, addressed peer→peer. [W] The dedicated replication-delta opcodes — EBLN_REPL_NOTIFY (0x4633, "I have changes"), EBLN_REPL_CHANGES (0x4636, changed records), EBLN_REPL_PULL_MORE (0x4635, paging) — are also a live carrier, not merely a formal one. A single passive supervisor capture holds 340 0x4636 frames with bodies of 331–1551 bytes and none empty — the supervisor continuously distributing host-table state across the BLN. An earlier reading of this document called them rare and empty-bodied; that was a corpus-wide frame-count artifact and is withdrawn. Both paths are real: the DBCHANGE_*/UPL_ADDED_*/UPL_DEL_* family carries record propagation on the second channel, and the EBLN_REPL_* family carries the anti-entropy digest and delta. [W][S]
4. Each peer that merges the new entry then re-advertises it on its own next round, so the addition ripples across the entire mesh until every panel and the supervisor converge — typically within a poll cycle or two given the ~10 s notify / ~30 s poll cadence above. A removed entry lingers as a tombstone for ~24 h before it is reaped, which is also how a deletion propagates without a node that missed the change silently re-adding it.

Because the key is the exact node-name string, adding a name that differs only in case or spelling creates a separate replicated entry rather than updating the existing one — the capture shows two co-existing supervisor rows differing only in case, each independently versioned and mesh-replicated. Obtaining this roster via 0x4634 is also the pre-auth membership-disclosure path of §17.3.

5.3.2 EBLN configuration & node-management opcodes (struct-derived)

Adjacent to the replication family is the full EBLN configuration/management opcode block. These set or display the very identity, IP, port, BLN/site name, multicast, and host-table values that the replication layer then propagates. They are definitional from the vendor function-code enum [S]; most are not seen in the read-only capture corpus (they are write/config operations). Several are destructive or identity-mutating and must be treated accordingly by any tooling (document, do not exercise blindly):

The host-table add/remove pair (0x462D/0x462E) is the explicit write path for the node-name table whose contents §5.3 says auto-replicate BLN-wide. Companion node-state operations in the 0x003x range govern membership at the routing layer: 0x0032 AP2_REMOTE_NODE_CHECK, 0x0033 AP2_GET_COMPLETE_NODE_STATE, 0x0034 AP2_SET_NODE_STATE, 0x0035 AP2_SET_COMPLETE_NODE_STATE, and 0x0030/0x0031 AP2_SET_GLOBAL_DATA / AP2_GET_GLOBAL_DATA [S]. The node lifecycle these drive is enumerated in Node_table_event_enum — including node_added, node_failed, and node_ostracized (a force-evict of a node from the BLN, a node-availability denial mechanism) [S].

Security note (struct-derived, not a wire claim). The EBLN config block and the node-state setters are full, unauthenticated-protocol write paths to a panel's network identity, BLN membership, port configuration, multicast, host table, and Telnet enablement, gated only by the BLN-name admission check (see §6). 0x4620/0x4621/0x462B/0x4638 (name/IP/BLN/MAC mutation), the host-table writers (0x462D/0x462E), the node-state setters (0x0034/0x0035), and node-ostracize are destructive to availability and identity. They are documented here for completeness; legitimate tooling for owner-operators should treat them as read-only-by-default and must not exercise the mutating members against production panels.

5.3.3 Peer identity lives in three separate stores

A peer name is not held in one place. Three distinct stores exist, and which of them contain an entry for a given name determines whether — and from which panels — outbound sessions are initiated. Conflating them is the usual reason a removal appears to work and then does not. [W]

Scope correction. The node-name table was previously described here as BLN-shared and replicated. Console evidence contradicts that: after a name-guessing campaign against one panel, that panel's NODE NAME TABLE REPORT listed ~150 probe identities while a peer panel on the same BLN, checked minutes later, listed only the 13 legitimate entries. The names are carried in 0x4636 replication traffic addressed to eight peers, but peers do not materialise every replicated change record as a node-name-table row; what governs that is [OPEN]. The persistent active-peer state below does propagate — three phantom entries reached a panel that was never probed. [W]

The node-name table is a flat name → IP (Permanent) mapping. The persistent active-peer state is a BLN → site → peer hierarchy that the firmware treats as the set of peers this BLN should actively maintain sessions with — so an entry there causes every panel to initiate outbound sessions to that name and to re-establish them after a restart. [W]

The practical consequence: clearing the node-name table alone does not stop outbound sessions, because the persistent active-peer state still lists the peer. Both BLN-shared stores must be cleared, and in the order given in §5.3.5.

5.3.4 Deletion is tombstone-based

Removal via Remove (node-name-table shell) or dElete (Fieldpanels shell) does not simply drop a local row. It generates a tombstone — a deletion marker that propagates BLN-wide over the same replication mechanism as an addition, and which every receiving panel honours by removing its local copy. [W]

This is why removal is a single-panel operation, not a per-panel sweep. Deleting on one panel is sufficient; the tombstone does the rest, within Intrasite_poll_repl_period (60 s) or Intersite_poll_repl_period (100 s).

The tombstone itself persists for Tombstone_lifetime (86 400 s = 24 h), so that a panel offline during the deletion window still receives the removal when it returns. The corollary is a real operational constraint: every panel on the BLN must come online and apply the tombstone within 24 hours. A panel absent longer than that can re-propagate an entry that every other panel has already forgotten.

5.3.5 Removing an entry, and why not to reach for a power cycle

There is no protocol-level removal. No opcode deregisters a peer; the write paths in §5.3.2 add, and nothing on the wire subtracts. Removal is a console operation. [W]

Order matters:

1. Console into any one panel on the BLN.
2. In the Fieldpanels sub-shell, dElete the entry from the BLN → site → peer hierarchy (the persistent active-peer state).
3. In the nodeNametable sub-shell, Remove the same name.
4. Wait for tombstone propagation (§5.3.4), then verify on a different panel — nodeNametable Display, and the field-panel listing.

Reversing steps 2 and 3 strands the field-panel entry. Recovering a stranded entry requires a privilege level above the normal engineering account. Do the field-panel delete first. [W]

Do not use a power cycle as a cleanup. It does not work and it carries real risk. It does not work because the BLN-shared stores are non-volatile: a restarted panel is repopulated by peers that were not restarted, so entries return. And older PXC hardware is known to sometimes fail to reload after a power interruption, entering a Not ready state that requires a vendor-supervised reflash from a backup configuration to recover — observed once on a production panel during the investigation that produced this section. The console procedure above is non-disruptive and is the correct mechanism. [W]

5.3.6 The EBLN diagnostic reads, and what each one returns

The 0x464A–0x4650 block is the EBLN replication diagnostic set. None of these values appears in the supervisor-side AP2_Function_Code enum except 0x464C, and none occurs in ordinary traffic — this supervisor never issues them, across the whole corpus. Whether another supervisor product or a maintenance tool does is untested. They are nonetheless implemented: every one below answered dir=0x01 success with a distinct structured body opening with the standard SYST scope preamble.

0x4642 and 0x4643 answered not_supported: a handler was reached and refused. 0x4647 returned nothing at all and remains [OPEN].

0x464C is the NodeList report, established from three independent directions rather than inferred: the vendor function enum names it AP2_EBLN_REPL_DIAG_NODELIST; the panel firmware's own resource names an EBLN Replication NodeList Report with columns Node Name | Connection | Replication; and the captured body is exactly a list of node names. [W][S]

0x464D is the replication data store. The 4,380 bytes that arrived before the client reset contain 57 replication grain keys in the &<origin>&MMDDYYHHMMSS&<counter> form of §5.3, from eight distinct origin nodes. At that density the full declared 12,073 bytes carries on the order of 150 grains. [W]

0x4650 puts the host table on the wire. This matters for anyone reasoning about who can see that table: it is not surfaced in supervisor operator tooling, but it is retrievable over P2 by any peer that satisfies the BLN check of §4. "Not visible" is true of the operator UI and false of the protocol. [W]

The report catalogue

The panel's own firmware resource names the reports this family produces. Six concern replication:

EBLN Replication Partners Report
EBLN Replication NodeList Report        Node Name | Connection | Replication
EBLN Replication Poll Schedule Report   Node_Name | Last_Polled_Time |
                                        Is_Partner | Reconcile_Pending
EBLN Replication Add Data Store Report
EBLN Replication Delete Data Store Report
EBLN Replication Diagnostic view

alongside TRUNK_SETTINGS_REPORT, Ethernet TCP/IP Port Configuration Report, Ethernet Setup Report, MII (Media Independent Interface) Report, MAC Address Report, MultiCast Address Report and MTU (MAXIMUM TRANSFER UNIT) REPORT. [S]

Which opcode emits which named report is deliberately left unstated for all but 0x464C. Six report names and seven responding opcodes invite a positional mapping, and a positional mapping across a range whose gaps are unknown is exactly the reasoning that produced a wrong Telnet binding earlier in this document's history. Where a body's content identifies it, that is recorded above; where it does not, the gap stands.

Intra-site and inter-site are configured separately

The trunk settings the panel exposes are, in resource order:

Intrasite_eping_period          Intersite_eping_period
Intrasite_eping_timeout         Intersite_eping_timeout
Intrasite_notif_repl_period     Intersite_notif_repl_period
Intrasite_poll_repl_period      Intersite_poll_repl_period
Intrasite_repl_cycle_timeout    Intersite_repl_cycle_timeout
Tombstone_lifetime              Holdback_delay

Every replication timer exists twice — once for peers on the same site and once for peers on another — and Tombstone_lifetime / Holdback_delay are shared. The distinction does not appear in captured traffic because every observed peer was intra-site; a deployment spanning sites will show the second column's timers governing its cross-site exchanges. [S]

5.4 What a fresh client learns, and what it cannot

Because membership lives in the replicated node table rather than a beacon, a client's discovery path is:

• Liveness of a known peer: send/observe EPing (0x4640) and watch the ~10 s cadence (§5.1) [W].
• Membership / roster: obtain the node roster via the replication pull (0x4634) once admitted, or read it from a panel's host-table display (0x462F) / Telnet node-name-table report [W][S].
• Cold discovery of an unknown site: there is no P2 broadcast that enumerates nodes for an unauthenticated newcomer. With multicast off (the default) and no replicated table access (admission requires the correct BLN name, §6), a fresh client cannot passively discover P2 nodes; it must know addresses to connect to. This read-only posture is by design and is consistent across the evidence [W][I].

5.5 FLN discovery (P1WhoAreYou)

Below the BLN, a panel discovers and identifies the devices on each of its P1 FLN trunks using the P1WhoAreYou transaction [D]. An FLN device's identity is its drop number + application number: the drop number (0–31, §4.4) locates it on the bus, and the application number identifies which point-team/application it runs (the supervisor reads the device's application self-ID — conventionally subpoint 2, "APPLICATION" — to learn which point map the device implements; see the point-model section). A definition must match both the FLN device's system name and its address; a mismatch produces a Failed P1WhoAreYou error [D].

Access from the BLN to an FLN device is route-through: a client connects to the hosting BLN panel (over P2/TCP) and then addresses the device behind it; the panel polls its FLN device over P1 and returns the data (see §3 / the addressing section). The FLN-scoped browse/enumerate operations on the BLN side are the 0x09xx upload/enumerate family and the FLN-topology query 0x5301 AP2_GET_FLN_TOPOLOGY [S]; FLN scan enable/disable is 0x4630/0x4631 (AP2_FLN_SCAN_ENABLE / _DISABLE) [S]. The route-through model is why BLN-to-FLN access never appears as a separate transport — it is always layered on an established P2 node session.

5.6 Open items — discovery & FLN timing

[OPEN] FLN/P1 wire bytes. P1WhoAreYou, FLN addressing (drop + application number), and the route-through model are documented at the behavioral level, but the P1 frame bytes — the WhoAreYou request/response layout and the per-device poll cadence — are unobserved. Needs a P1-bus or route-through capture.

[OPEN] Per-frame retry/ACK timing. All established timing is at the discovery/replication layer (EPing periods/timeouts; replication notify/poll/cycle; the binary Extended-Timeout pre-Rev-2.1 compatibility flag). P2 frame-level retry counts and per-frame ACK/sequence timeouts are not established and should not be inferred from the discovery-layer periods.

0x4636 body layout. Mapped from the read-only corpus; 1,412 of 1,412 grains decode under the constraint that each record must tile the buffer exactly. [W]

u16   reconciliation
u32   boc_usn_changed
u8    more_data
u16   srce_cycle_number
u16   srce_cycle_pdu_number
u16   n_utdv                     "up-to-dateness vector" entry count
      utdv[] :  TLV node name | u32 USN          <- the version vector
u16   n_grain
      grain[] :
        TLV   record key         "&<origin>&MMDDYYHHMMSS&<counter>"
        u32   local USN
        u8    replication command type
        u8    grain type
        TLV   target             host-table name; MAY be zero-length (BLN scope)
        u16   embedded length
              u16 opcode | TLV scope ("SYST") | 23 3f ff ff ff | TLV name | tail
        u32   counter
        u32   origin time        unix epoch seconds
        TLV   origin node
        u32   origin USN

Field names follow the vendor's ATOMGrainMetaData / ATOMReplicationUpToDatenessVector structures, which also define tombstone time and holdback time members corresponding to the Tombstone_lifetime and Holdback_delay trunk settings of §5.3. [S] A zero-length target TLV is legal and marks a BLN-scope rather than host-scope record; a decoder that rejects empty TLV values silently drops those records. [W]

[OPEN] The COV/condition block carried inside change records for point-value updates is still not mapped; the grains observed carry host-table and configuration operations. Confirming it needs a capture taken during live point-value replication.

6. Frame Format (Wire)

This section defines the P2 on-wire frame: the exact byte layout, the message-type discriminator, the direction byte, the four routing slots, the opcode field, and segmentation. P2 ("Protocol II", the APOGEE BLN/backbone protocol) runs over TCP/5033 (see §4/§3 for transport and addressing). The frame format is uniform across all message classes and both protocol dialects; only body conventions and session role differ. Every multi-byte integer in the header is big-endian (lengths and the sequence number are big-endian u32; the opcode and the error code are big-endian u16; analog values in bodies are IEEE-754 big-endian f32).

6.1 Frame byte layout

A frame is a fixed 13-byte header, followed by four NUL-terminated ASCII routing slots, followed — only on request/push frames — by a 2-byte AP2 function code (the opcode), followed by an opcode-specific body. [W]

total_len is self-inclusive: it equals the exact on-wire byte count of the frame counting the four length bytes. For a body-less success response the value is 13 + (sum of the four NUL-terminated slot lengths including their NUL terminators). [W]

S is the variable post-slot offset at which the opcode (request) or body (response) begins. It is variable because the four routing slots are variable-length strings. A parser MUST locate S by scanning forward from offset 13 and counting four NUL terminators; it MUST NOT assume a fixed offset. The four slots are the only variable-length region of the header, so once four NULs have been consumed the parser is positioned at the opcode (if dir == 0x00) or at the response body. [W] A fixed-offset opcode parser is wrong and fabricates phantom values. [W]

6.1.1 Framing over TCP

Framing is a pure length prefix over the reassembled TCP byte stream — no record delimiter, no escape mechanism. A receiver reads four bytes, decodes total_len, then reads total_len − 4 further bytes to complete the frame. A single TCP segment may carry several P2 frames, and one P2 frame may span multiple segments; a receiver MUST buffer across segment boundaries until a whole frame has arrived. [W] An implementation should reject any frame whose declared total_len exceeds a sane ceiling (for example 65536 bytes) before buffering, to bound memory against a malformed or hostile length prefix. [I] It should equally reject one that is too small: 13 header bytes plus four NUL terminators is 17, and a request adds two opcode bytes for 19, so any total_len below that cannot describe a valid frame and a reader that subtracts without checking will underflow. No frame in the corpus comes close — the observed range is 31 to 1,622 bytes, median 85 — but the floor is a property of the format, not of the traffic. [W]

6.1.2 Annotated hex example

A legacy-dialect (msg_type low byte 0x33) ReadShort-class request, addressed from supervisor identity P2SCAN|5033 on BLN BLNNAME to destination node NODE1, carrying opcode 0x0220 (POINT_LOG_VALUE, the modern compact read) with a SYST read-scope prefix. All values are sanitized placeholders; the body grammar of a given opcode is defined in §8.

00 00 00 5E   total_len  = 0x5E = 94 bytes (self-inclusive)            [W]
00 00 00 33   msg_type   = low byte 0x33 (legacy DATA dialect)         [W]
00 00 1A 2F   sequence   = 0x00001A2F (per-connection, big-endian)     [W]
00            dir        = 0x00 (request — opcode IS present)          [W]
42 4C 4E 4E 41 4D 45 00              slot[0] "BLNNAME"\0   (BLN)        [W]
4E 4F 44 45 31 00                    slot[1] "NODE1"\0     (dst node)  [W]
42 4C 4E 4E 41 4D 45 00              slot[2] "BLNNAME"\0   (BLN again) [W]
50 32 53 43 41 4E 7C 35 30 33 33 00  slot[3] "P2SCAN|5033"\0 (src id)  [W]
02 20            opcode = 0x0220 (POINT_LOG_VALUE / ReadShort)         [W]
01 00 04 53 59 53 54                 SYST scope-name TLV               [W]
00 3F FF FF FF                       scope selector: scope_byte 0x00 (read) + mask [W]
00 00                                name_space = system (§8.5)        [W]
01 00 0A 43 54 4C 52 30 31 2E 30 30 31   name TLV part 1 "CTLR01.001" (10) [W]
01 00 07 52 4F 4F 4D 54 4D 50            name TLV part 2 "ROOMTMP"     (7)  [W]
00 00 01 00 00 01 00 00              read trailer (8 bytes)            [W]

The two BLN-name slots are byte-identical; both MUST be populated. The opcode sits immediately after the NUL terminator of slot[3]. On the matching response (§6.3) dir becomes 0x01, slots [1] and [3] swap, and the two opcode bytes are absent — the response body begins immediately after slot[3]'s NUL. See §6.4 for the consequences of reading post-slot bytes off a response frame.

6.2 The msg_type discriminator (message class / dialect)

msg_type is a 32-bit field whose top three bytes are always 0x00 0x00 0x00; only the low byte varies. The low byte is a per-transaction message-class / dialect selector. The header layout and the four-slot routing structure are identical for every value — only body conventions and session role differ. Six low-byte values are observed; 0x40 is never observed in any capture and is not a P2 message class. [W]

Class-frequency profile (shape, reproducible per-capture; absolute totals are deployment-dependent): 0x33 (legacy data) dominates, then the legacy second-channel 0x2E, then the modern data dialect 0x34, then the modern second-channel 0x2F; the session carrier 0x29 is small and the peer carrier 0x2A appears only in panel-to-panel (mirror) captures. 0x2E consistently outnumbers 0x34 — the second channel runs on every legacy panel, while 0x34 runs only on the (typically few) modern-firmware panels. Representative single 3-hour supervisor capture (≈163,700 P2 frames): 0x33 ≈ 130,000; 0x2E ≈ 18,900; 0x34 ≈ 11,500; 0x2F ≈ 3,300. (A panel-side mirror capture additionally shows the peer carriers — in this corpus 0x29 only, 10 frames, §9.7.) [W]

The session / second-channel band. The low-byte values 0x29–0x2F form a session / second-channel band (0x29 session carrier, 0x2A peer-session carrier, 0x2E legacy second channel, 0x2F modern second channel) — all of which carry the EBLN_PING (0x4640) identity exchange — as distinct from the data band 0x33 (legacy dialect) / 0x34 (modern dialect) that carries the operational opcode set. The pairing within the band is by panel firmware generation, not by session role or direction (§6.6): a legacy panel uses 0x2E in both directions, a modern panel uses 0x2F in both. [W]

• 0x2E = the legacy panel's second channel — the 0x4640 identity exchange plus the panel→supervisor announce and DB-change/replication records and alarm prints (§5.3, §13). [W]
• 0x2F = the modern panel's second channel — the same role as 0x2E, selected by firmware generation. The identity body is TLV(node-name) + TLV(site) + TLV(BLN-name) (the same triple as the 0x4640 eBLN_Node body, §5.1, §10.6). [W]
• 0x29 / 0x2A = the peer (panel↔panel) carriers of the same exchange (session / peer-session), visible only from a panel-side mirror. [W]

The residual nuance — which peer is treated as primary vs secondary within a panel↔panel 0x29/0x2A session (and on what criterion the primary is chosen) — is not pinned. The role/initiator meaning of the band itself is established. [W][OPEN]

Parsing vs emitting. 0x33 and 0x34 are interchangeable for parsing — a receiver treats them identically. Only the emit-side dialect choice must match the peer. When a client must discover a peer's dialect, the candidate set is exactly {0x33, 0x34}, probed in that order; the carriers 0x2E/0x2F/0x29/0x2A are session/second-channel carriers, not data dialects, and MUST NOT be iterated during dialect detection. Dialect is not negotiated by a handshake message; it is a fixed per-peer property of the panel's model + firmware generation (§6.6) — legacy panels speak 0x33+0x2E, the newer platform speaks 0x34+0x2F — and is best discovered by fingerprinting the peer via CABINET_DISPLAY (0x010C, §10.5) rather than blind-probing. [W]

The second channel (0x2E/0x2F) carries more than identity. Between a supervisor and a panel, the 0x2E (legacy) / 0x2F (modern) class is the announce / reverse / DB-sync channel: besides the 0x4640 identity exchange it carries database-change and replication records (DBCHANGE_*, UPL_ADDED_*, UPL_DEL_*) and alarm prints (ALARM_PRINT 0x0508) flowing panel→supervisor. The peer (panel↔panel) carriers 0x29 and 0x2A are visible only from a panel-side mirror, never from the supervisor's own vantage. Measured there, both are dominated by the 0x4640 identity/keepalive exchange, not by COV: across five panel-side captures on two panels 0x29 carries 0x4640 (43,610), then 0x4634 (6,223), then 0x0271 (245), with 0x4633/0x4636 in single figures, and 0x2A carries 0x4640 in roughly ninety-nine frames out of a hundred (6,228) with 0x0271 (46) and 0x4634 (4) making up the rest. An earlier edition described 0x2A as the panel↔panel COV-subscription carrier; COV management rides it, but calling it that mistakes a minority of its traffic for its purpose. [W]

Second-channel session establishment. Session establishment is not a distinct opcode or message class — it rides the second channel as the 0x4640 (EBLN_PING / IdentifyBlock, §7) identity exchange. When the source identity in slot[3] matches a node already in the receiver's peer list, the receiver replies with a distinct, short (~48-byte) second-channel response that is effectively an outbound peer offer back to the peer — different from the passive ~91-byte 0x33 DATA-dialect response returned to a freshly-accepted (wildcard) identity. [W] Critically, this second-channel identity path accepts an arbitrary slot[3] identity (it is not bound by the data-service identity-length gate of §7); empirically it has accepted identities at lengths 10 and 15. [W]

0x2F is the modern counterpart to 0x2E — a per-panel-platform pair, not a direction. 0x2F is to 0x2E exactly what 0x34 is to 0x33: the modern-platform form of the second channel. The choice between the pair is fixed by the panel's firmware generation (§6.6), not by traffic direction — a legacy panel uses 0x2E in both directions (supervisor→panel and panel→supervisor) and a modern panel uses 0x2F in both. An earlier reading that mapped 0x2E to the supervisor→panel direction and 0x2F to the panel→supervisor direction was an artifact of a small capture in which the one modern panel happened to be the main reverse-pushing node; a three-hour fleet capture shows the split tracks the panel, not the direction. [W] A client that does not originate peer-to-peer connect offers need not emit 0x2F, but MUST accept and correlate inbound 0x2F frames by sequence, and MUST emit the pair member that matches the peer's generation. [W]

Connection modes. The second-channel class chosen for a connection follows the panel generation; within that, two usage patterns appear, by whether the carrier hands off to the data class:

In the first two rows the carrier class establishes/keepalives the session (via 0x4640) and carries the panel→supervisor announce + DB-change records, while operational reads/writes ride the matching data class; in the single-type-carrier pattern a whole transaction (e.g. a schedule edit or an alarm burst) stays on the carrier class start to finish. A parser distinguishes a session-establishment frame from an operational frame by inspecting the two bytes after the routing slots on a dir == 0x00 frame: if they equal 0x4640, the frame is a session establish/keepalive; otherwise they are an ordinary opcode. [W]

6.3 The direction byte

The single byte dir at offset 12 selects the meaning of everything after the routing slots. Exactly three values are defined. [W]

Observed corpus distribution: 0x00 314,273; 0x01 300,989; 0x05 6,006 (summing to 621,268). [W]

The governing rule is: the opcode field is present if and only if dir == 0x00. A response of either kind carries no opcode. An unsolicited push — for example a change-of-value report (opcode 0x0274, COV_ANNUNCIATE) or an 0x4640 heartbeat — uses dir == 0x00 exactly like a request, carries an opcode and body, and is acknowledged by the peer with a dir == 0x01 empty success. [W] The dir == 0x05 error response is the panel's application-layer error path; it is distinct from a TCP-level reset (which signals a wrong-BLN rejection or a fault, §7) and from the comm-status flag inside a value block (which signals device health). [W][I]

6.4 Routing slots

The four slots carry the routing identity of the frame as NUL-terminated ASCII strings. They carry no length prefix — distinct from the length-prefixed TLV form (<textType> <len:u16>) used inside bodies; the two MUST NOT be conflated. [W]

There are always exactly four, and the count is not conditional on anything — direction, message class, opcode or body: 621,268 frames of 621,268 carry four, with no exceptions. A parser may therefore read four NUL-terminated strings unconditionally after the header and does not need to probe for a terminator count. [W]

Slot lengths, measured. Across those frames — about 2.5 million slot strings — the two node-name slots stay well inside the documented 30-character limit of §3.4.2, and the source-identity slot runs longest because of its |PORT suffix: [W]

The documented 30-character limit cannot be tested from outside, and it is worth saying why. Exactly six distinct slot strings in the corpus exceed 30 characters, at lengths 32, 63, 64, 127, 128 and 255 — powers of two and their off-by-ones, each appearing exactly twice because the BLN name is doubled into slots 0 and 2. All six are 0x4640 frames from a single capture whose name marks it a probe, and no P2 frame returned on the reverse tuple for any of them.

That is not evidence the panel enforces a length limit. A 255-character BLN name is, by construction, not this site's BLN name — so the BLN-correctness gate of §17.2 rejects it on identity long before any length check could matter, and the two variables are confounded. The rejection is what §6.4's wrong-BLN result already predicts, and it would look the same at 31 characters as at 255.

A length limit on the BLN-name slot can therefore only be tested from the inside, by configuring an over-length BLN name on a panel and observing whether the firmware accepts it. Treat 30 as a documented bound (§3.4.1) that vendor traffic never approaches — the longest real name here is well under it — rather than as an enforced wire constraint. [W]

On a request (dir == 0x00, including an unsolicited push) the slot order is:

slot[0] = BLN name           (the building-level-network name)
slot[1] = destination node   (the node being addressed)
slot[2] = BLN name           (identical content to slot[0])
slot[3] = source node / self identity (the sender)

On a response (dir == 0x01 or 0x05) the destination and source contents swap, so each frame's slot[1] always names that frame's destination. A request addressed [BLNNAME, NODE1, BLNNAME, P2SCAN] produces a reply addressed [BLNNAME, P2SCAN, BLNNAME, NODE1]. Slots 0 and 2 are stable (both the BLN name); slots 1 and 3 reverse. The BLN name appears twice in every frame; both copies carry the same value, and a conformant node MUST populate both. [W] The vendor framing logs the routing as name/channel/trunk/cabinet, with the trunk corresponding to the BLN. [S]

Why the BLN name appears twice — a better answer, and a way to test it. The routing object in the supervisor's own stack does not model four independent slots. It models four roles: a trunk id, a panel id, a supervisor id, and an object name. [S] Read against that, the wire's four slots are not [BLN, dst, BLN, src] but two (trunk, node) pairs — each identity carried together with the trunk it lives on. The duplication is then not redundancy at all; it is one field per pair, and both pairs happen to name the same trunk on a single-BLN network.

That is a falsifiable prediction: on a frame that crosses between two BLNs, slots 0 and 2 should carry different trunk names. The present corpus cannot test it — across 621,268 trusted four-slot frames, slots 0 and 2 are identical in 206,045, and every one of the five exceptions is a deliberately malformed research probe rather than production traffic. Every capture to hand is single-BLN, so the pair reading is untested, not confirmed. A capture taken where two BLNs exchange traffic would settle it in one frame. [W] [OPEN]

Two further details from the same object model. Names decompose into a base plus a suffix with an explicit truncate operation — which is the mechanism behind the length limits of §3.3.2 rather than a separate rule — and there are two distinct name types, a system name and a user name, each with its own base/suffix pair. §3.4's system-name-versus-user-name distinction is therefore structural in the implementation, not merely a UI convention. [S]

Implementation note: node names may differ in letter case between a request and its reply (e.g. node1 vs NODE1). Case variation is cosmetic and does not affect routing. [W]

Slot meaning and validation. The three identity fields are enforced unequally. The BLN name is the membership gate — two nodes exchange P2 traffic only if their BLN names are identical. [W]

A wrong-BLN handshake is footprint-free: in a controlled 24-handshake test (8 wrong-BLN variants × 3 reps) the panel returned TCP RST for every attempt, with zero data responses, zero silent drops, and zero new NODE NAME TABLE entries. [W] Registration is gated by BLN-correctness, not by data-service acceptance: a right-BLN handshake with a novel slot[3] identity writes a Permanent NODE NAME TABLE entry at the sender's IP even when the panel refuses to serve data at the 5033 data layer (the data-service identity check is a separate, later gate — see §7). [W]

The |port identity suffix. A source identity in slot[3] commonly appears as NAME|PORT, for example P2SCAN|5033 or DCC-SVR|5034. The |PORT portion is part of the identity string — a HOST|PORT disambiguator that lets one host present distinct identities — and is not a network-layer port indicator and not a field delimiter. [W] Decisive evidence: a supervisor stamps DCC-SVR|5034 into slot[3] in thousands of frames captured on a 5033-only link, and the literal 5033 appears in no slot of any frame in the corpus. The same suffixed identity rides whatever TCP port carried the frame. [W] Handling: when building a frame, emit the full literal identity including the suffix and do not split on |; when parsing, accept both the suffixed and bare forms — responses and routing-table entries frequently return the bare NAME without the suffix. [W]

Opcode presence warning. The opcode is present only when dir == 0x00. Reading the two post-slot bytes off a 0x01 success or a 0x05 error frame fabricates phantom opcodes — the values 0x0100, 0x0200, 0x0300, 0x0400 seen by such a parser are response-payload artifacts, not function codes. Any census, dissector, or scanner that tallies opcodes off response frames is inventing them. A robust dispatcher keys on (opcode, body shape) together, because several opcodes are polymorphic — the same value selects different operations by body shape, scope tag, and direction (e.g. 00 FF read trailer vs 00 00 command trailer on the same addressing grammar). [W] Some opcodes carry a 2-byte sub-field immediately after the opcode (e.g. 00 00 or 00 01) before the body; its presence is opcode-specific. The session opcode 0x4640 carries no such sub-field — its TLVs begin immediately after the opcode. [W]

6.5 Sequence number and request/response pairing

sequence is a per-connection 32-bit (big-endian) value. A response — success (0x01) or error (0x05) — echoes the sequence of the request it answers. This echo is the only correlation between a request and its reply: because a response carries no opcode, the requester recovers the meaning of a response body by looking up the opcode of the outstanding request bearing the same sequence. A sender increments sequence per request; each TCP connection has an independent sequence-number space. [W]

The vendor datalink maintains three change counters — Master / Primary / Secondary (ChangeMseq / ChangePseq / ChangeSseq) — underneath this single wire field. [S] These map to multiple independent sequence spaces by role/channel: a node's outbound-request counter, its COV/value push counter, and each peer-channel counter are distinct number lines, not one shared counter. [W] A sender should initialize sequence to a random value rather than 0/1. The normative correlation rule is exact echo: a response carries the verbatim sequence of the request it answers, and a robust requester matches on that exact value against its set of outstanding requests. [W]

Pipelining is real and confirmed. Two overlapping live captures show the request sequence and the reverse-direction response sequence carrying the identical value range — the response echoes the request's sequence verbatim, which is exactly how a client matches a reply to its outstanding request — and up to 14 requests outstanding observed before their responses arrive. Measured across the whole corpus (306,990 paired exchanges), the peak depth per connection is 1 for the large majority — 2,073 connections never exceed one outstanding request — with a tail through 2, 3, 5, 9, 10 and a single connection reaching 14. 14 remains a capture-bound maximum, not a protocol limit; treat it as "at least 14" and use a sliding-window matcher with no fixed depth. A reply may therefore lag a request by a small number of steps (never arrive ahead of it); a sliding-window matcher keyed on exact sequence is the correct implementation, not merely defensive accommodation. [W]

Implementation note — each TCP connection has its own narrow counter at a distinct base. Every TCP connection carries its own sequence space, and that space is narrow — no single connection's 0x33/0x34 sequence was observed spanning more than ≈0.04M over a 3-hour capture. The wide ranges you see when you (wrongly) merge a host-pair's two connections are an artifact: a supervisor↔panel pair runs two concurrent connections (the panel's :5033 data-listen channel and the supervisor's :5034 push/command channel), each at a very different base. On one multi-panel supervisor capture: legacy panel node6's :5033 data channel ran ≈3.300M–3.338M while its own :5034 channel ran ≈7.087M–7.123M; a second legacy panel's :5034 channel sat near ≈0.311M; the modern panel's :5033 (0x34) ran ≈3.300M–3.338M and its :5034 ran ≈4.372M–4.373M. Distinct, widely-separated bases per connection refute a single global counter shared across connections — if one counter fed every link they would share one contiguous range, which they plainly do not. [W] Within a single connection the value increments by ≥1 with small gaps (the node's other concurrent channels/operations consume intervening values), so a receiver MUST treat sequence as opaque per-connection match data and MUST NOT assume a strict +1 increment. A reconnecting node resumes its counter (the first frame on a freshly-opened TCP connection continues the prior high value, it does not reset to 0/1). [W] The normative rule remains exact echo: a response carries the request's sequence verbatim; match on that against the set of outstanding requests on that connection. [W]

6.6 Legacy and modern dialect differences

The legacy dialect (0x33) and modern dialect (0x34) are byte-compatible. For the same operation the only required byte difference is the msg_type low byte:

legacy:  <total_len> 00 00 00 33 <sequence> 00  <slots> <opcode> <body...>
modern:  <total_len> 00 00 00 34 <sequence> 00  <slots> <opcode> <body...>

The header layout, four-slot routing, opcode position, direction semantics, TLV grammar, scope tag, f32 encoding, and error tail are all identical across the two dialects. The two carry the same operational opcode set and the same value encoding — a side-by-side check of COV_ANNUNCIATE payloads on both dialects returns identical big-endian f32 values; only the msg_type low byte differs. [W]

Dialect is a stable per-peer property fixed by the panel's firmware generation — not a per-transaction choice, and not by hardware type. In a single supervisor capture spanning a nine-panel fleet, each panel used exactly one dialect pair for its entire lifetime in the capture, and the split tracked firmware generation on identical hardware: all nine were the same hardware platform (a modular-cabinet controller — PXME in the firmware identity string), but the eight on an older firmware build (a 2013-era revision) spoke legacy 0x33 DATA + 0x2E on their second channel, while the one on a newer firmware build (a 2019-era revision) spoke modern 0x34 DATA + 0x2F exclusively. [W] The panel's firmware revision string, version, and build date are all readable in one round-trip via CABINET_DISPLAY (0x010C, §10.5), so a client SHOULD fingerprint the peer and select the dialect from its firmware generation rather than blind-probing. As a fallback when the firmware is unknown, the candidate set is exactly {0x33, 0x34} (§6.2), legacy first; for parsing, the two are interchangeable (a receiver treats them identically). Note this legacy↔modern split is a revision within the proprietary-P2 firmware line (a later 2.x build emits the modern classes) — it is not a protocol-family change, and is distinct from the separate "P2 vs BACnet firmware" choice the same hardware platform can be ordered with (§10.5); a BACnet-firmware unit is not a P2 node at all and does not appear on the P2 BLN. Opcode coverage overlaps but is not identical: most high-volume operations occur in both, while certain single-shot and legacy-supervisor operations occur only in the legacy dialect. [W]

Implementation note: name/string encoding is a per-firmware-revision property, not a per-frame one. Early (pre-IP) revisions pack names in RAD-50 — three characters per 16-bit word over the 40-symbol alphabet " ABCDEFGHIJKLMNOPQRSTUVWXYZ$.?0123456789" (index 0 = space, 1–26 = A–Z, 27 = $, 28 = ., 29 = ?, 30–39 = 0–9), packed as ((c0 × 40) + c1) × 40 + c2. [S] All P2/IP revisions use plain ASCII in the length-prefixed TLVs and NUL-terminated slots. A node uses one string encoding for its whole revision; the firmware/platform identity selects the encoding (the vendor's per-platform STRING_TYPE = RAD50 or ASCII). A peer presenting RAD-50-packed names is a pre-IP revision, out of scope for a TCP/5033 ASCII implementation. [S][D]

The per-peer capability model — how one client speaks to every panel generation. Dialect and encoding are not negotiated on the wire; there is no capability handshake, no version byte exchanged per transaction, no feature bits. Instead the encoding and dialect are learned once per peer, at connect, from the peer's firmware revision, and then applied statically for the life of the session. A conformant multi-generation client (this is exactly how a supervisor talks to a mixed fleet) keeps a small per-peer record — { device generation, string encoding, message-class dialect } — and fills it in the first time it reaches a peer:

1. Learn. Read the peer's firmware revision once at connect — CABINET_DISPLAY (0x010C, §10.5) returns the revision string, version, build date, and platform in a single empty-request round-trip (a pre-IP serial peer is identified by its revision-table entry instead). The revision string is the the single defining input. [W]
2. Classify. Map the revision to a device generation, which is purely a function of the revision value: a field-bus (FLN/P1) device, a modern APOGEE Ethernet panel (revision at or above the APOGEE threshold), a legacy / pre-APOGEE panel (revision below it), a LON-integrated panel, or a BACnet-firmware unit (which is not a P2 node at all and never appears on the P2 BLN, §10.5). This classification is the same one the field's own supervisor makes, and it is derivable entirely from the observable revision — no probing required. [S][I]
3. Select encoding. The generation selects the string encoding — pre-IP revisions = RAD-50, all IP/APOGEE revisions = ASCII (above) — via the vendor's per-revision STRING_TYPE. [S][D]
4. Select dialect. The generation selects the message-class dialect — modern 0x34/0x2F for the newer-firmware generation, legacy 0x33/0x2E otherwise (§6.2). The selector reduces to a single bit driven by the stored per-peer generation, not by anything on the wire. Measured across the corpus, and it holds: [W]

The 34 are not counter-examples. Twenty-nine mix by exactly one frame, the rest by two to five, and the largest — eighteen — is in a capture named for a supervisor enumeration test: they are our own scanner probing both dialects, not a peer alternating. 728 of 762 pairs never mix at all.

The generations also agree between the two channels: of the nodes emitting exactly one data dialect and exactly one second-channel class, 263 of 263 pair 0x33 with 0x2E and 0x34 with 0x2F, with zero disagreements.

Note the unit. A node may well emit both 0x33 and 0x34 — 34 of 461 sources do — because a supervisor speaking to a mixed fleet uses each peer's dialect. Group by the pair, never by the sender, or the mixed-fleet supervisor looks like a protocol violation. [W] 5. Cache and reuse. A client may store the record against the peer and reuse it for every subsequent frame: the dialect itself is stable per peer for as long as any connection to it lasts (item 4). What a client must not assume is that the identity block behind it is read once. The observed supervisor re-reads CABINET_DISPLAY on a fixed timer — measured per peer across the corpus, successive reads to the same peer fall in two tight populations, 30.006 s (σ 0.0043 s, n=82 intervals over 7 peers) and ≈3600.4 s (n=33 over 10 peers), with one peer showing both. All 115 of those intervals are within a single live connection, so neither is a reconnect artifact, and only 13 of the 115 connections carrying an 0x010C open with one — it is a poll, not a session handshake. Whether the supervisor is refreshing its dialect record or merely using the same opcode for periodic health is not observable from the wire; what is observable is that a peer must expect the identity block to be re-read on a schedule regardless of whether anything about it has changed. [W]

(§5.0's cadence table measures the same opcode per connection and reports 30.01 s over 102 intervals; this measurement is per peer, which is a different denominator, and it is what exposes the hourly population — an hourly peer contributes few intra-connection intervals. The two figures agree where they overlap; neither corrects the other.)

The practical consequence for an implementer: you do not blind-probe {0x33, 0x34} or guess the encoding. You issue one CABINET_DISPLAY, classify the generation from the returned revision, and from that one read you know both how to encode names (RAD-50 vs ASCII) and which dialect to frame in — for that peer, permanently. This learned-once-per-peer record is the entire mechanism behind "it just works with every controller on the BLN." [W][S][I]

6.7 Segmentation

P2 carries large payloads across multiple frames via a more-follows / segment mechanism in the application layer. The application layer exposes a more-follows segmentation flag and MapSegment / GetSegBufferCopy segment-buffer machinery; a partial reply sets more-follows and the requester pulls the next segment (the replication family EBLN_REPL_PULL / EBLN_REPL_PULL_MORE / EBLN_REPL_CHANGES carries explicit srce_cycle_number + srce_cycle_pdu_number segment cursors and a more_data : BOOLEAN_ field for exactly this). [S]

The ~256-byte figure is NOT a frame-size cap. A previously cited "roughly 256 bytes as the maximum P2 data packet" is a vendor connection-test ping figure, not a limit on how large a single P2 frame may be. [D] On the wire a single P2 frame's total_len is bounded only by the header's u32 length field (implementations cap at a sane ceiling); the largest single legitimate frame observed in the corpus has total_len = 1,622 bytes — a 1,570-byte body of packed TLV(name)+value records plus the 13-byte header and the NUL-terminated routing slots. (A raw census maximum of 65,536 B is a stream-desynchronization artifact, not a real frame.) Large multi-record read/trend responses arrive as one large frame, not as a 256-byte-segmented exchange. [W]

The sender's ceiling, and the two reserved bytes. The supervisor's AP2 codec allocates a 16,384-byte segment buffer and hands its encoder buf+2 with a capacity of 16,382 bytes. The two bytes it holds back at buf[0] are the u16 function code, written after the body is encoded — which is exactly why the wire carries the opcode immediately before the body, and why total_length counts it. An implementer reading a body is reading the encoder's buf+2. [S]

Reassembly is a cursor against a declared total, not a negotiation. Each mapped segment copies n bytes into the buffer and advances the cursor; the final segment's length is total - cursor. The sender knows total before it begins, and the command object carries an explicit more-follows field, set on the segmenting path and cleared on the direct one. [S]

The ceiling is not exercised by anything we have captured. No body in the corpus exceeds 16,382 B: the largest complete body is 1,570 B and the largest declared body is the 12,073-byte replication data store of §9.5. So a client may size a receive buffer at 16 KB with confidence for this implementation, but the on-wire form of a multi-segment exchange — whether it appears as two P2 frames and what marks the continuation — remains unobserved (§4.5). [W][S]

The observed continuation mechanism for UPL_ALL_* is application-layer cursoring, not a frame-level more-follows flag. Bulk enumerations (UPL_ALL_POINT 0x0981, UPL_ALL_TEC 0x0986, UPL_ALL_EQS_CMD_TABLE 0x0988, …) are paginated by request: each request carries the last-returned object's name as a cursor (a TLV(name) after the application-number TLV), and the response returns the next object's record. To walk a list the client re-issues the opcode with the previous response's object name until the panel returns end-of-list. A controller with a long point list (e.g. an AHU returning consecutive ~1514-byte records) is walked the same way — each response is one near-MTU frame and the next record is fetched by cursor, not by a continuation bit. Across every UPL_ALL_* capture the panel kept each response to a single frame (frame ≤ 1,622 B) and the client advanced by cursor; the data-channel more-follows flag was not observed firing. [W] The codec has a more-follows mechanism [S] and the EBLN_REPL_* replication bodies use explicit segment cursors (above), but for ordinary 0x33/0x34 reads the on-wire pattern is cursored request/response pagination capped near one MTU.

[OPEN] Whether a single object whose record exceeds the largest observed frame triggers the codec's frame-level more-follows flag (and at what byte) is still unpinned — no single record that large was captured; every large result was continued by cursor instead. [S][OPEN]

Do not read the Ethernet MTU as the boundary. A P2 frame is not capped near 1,514 bytes: 128 frames in the corpus exceed it, running to 1,622, in both dialects and across five captures, each one arithmetically exact (13 + slots + body = total_len). 122 of the 128 are responses and 6 are 0x4636 replication requests. So a P2 frame routinely spans more than one Ethernet segment and a receiver must reassemble across TCP segment boundaries (§6.1.1) — the MTU is a property of the link, not a protocol limit, and the pagination described above is a cursor convention rather than a size ceiling the codec enforces. [W]

P2 segmentation is distinct from the BACnet-side Transport Segment Management (TSML) layer (High/Low halves, per-TSM invokeID/userID, ReqACK, out-of-order expected/received reassembly) that rides over the BACnet IPC connection. TSML is a different stack and is out of scope for the P2 wire. [S]

6.8 The byte-oriented P2 encoding (non-TCP links)

Everything in §6 so far describes P2 as it rides TCP. A controller also speaks P2 over a byte-oriented link, and it is not the same encoding — same protocol, same operations, a far more compact frame. This is recovered from controller firmware, not from a capture: the corpus is entirely TCP/5033. [F]

  offset  size  field
  ------  ----  ---------------------------------------------------------
     0     1    node address  -- checked against the receiver's own id
     1     1    [OPEN]
     2     1    [OPEN]
     3     1    group         -- selects a translation table (§9.4.1)
     4     2    ordinal (u16) -- the operation within that group
     6   ...    arguments

  total <= 253 bytes; payload after the 4-byte header <= 249 (0xF9),
  enforced -- an over-length route is rejected with error 2.

Two things identify this as P2 rather than P1 or an internal bus. First, the receiver's rule for a message whose address byte is not its own id: it does not interpret the message, it wraps the raw four header bytes and the payload verbatim and raises it as operation 0x0136, whose name in the function-code enumeration is AP2_P2_ROUTE. Second, the encode path is byte-for-byte symmetric — given 0x0136 it restores the same four header bytes and payload and puts them back on the link. A multi-drop link forwarding P2 between nodes. [F][S]

The operation is encoded as (group, ordinal) rather than as the 16-bit AP2 function code, and §9.4.1 gives the tables that translate between the two, in both directions. The ordinal's width is fixed by the firmware's 2-byte read primitive and independently by group 0xE0, whose ordinals run 256–259 and could not fit in a byte. The ordinal is big-endian, and the group byte precedes it directly. [C]

The pairing is attested from both ends. Everything above is the panel's side. A supervisor-side codec builds the same encoding, and for group 0xE0 it emits ordinals 256, 257, 258 and 259 — the same four the panel's 0xE0 table holds, plus a fifth, 260, that this panel generation does not implement. Two independent implementations for two different processors agreeing on four exact values in a 16-bit space is what makes the group/ordinal reading safe to build on. [C][F] The same codec shows that not every leading byte is a group selector: some classes are followed by an ordinal, others by a fixed addressing prefix of their own, so a decoder must switch on the class byte before assuming an ordinal follows it. [C]

Set against the TCP framing of §6.1 — u32 total_len | u32 msg_type | u32 seq | u8 dir | four NUL-terminated slots | u16 opcode — the difference is stark: one address byte where TCP carries four variable-length name slots, and a group+ordinal pair where TCP carries the function code. An implementer should not assume one P2 parser handles both.

Which serial link is [OPEN]. Two carry P2 outside the TCP framing — the dedicated RS-485 BLN and the dial-up path. A one-byte node address with multi-drop forwarding fits the RS-485 BLN, but nothing observed excludes the modem path, and both may use this same encoding.

And the framing beneath it is [OPEN]. The firmware receives the four header bytes already parsed into fields, so start/sync delimiting and any CRC are stripped by a lower layer this code does not contain.

Two layers above the wire have been checked and neither adds the three bytes that precede the group selector. The supervisor's protocol adapter builds the request object, points it at a 600-byte buffer, calls the encoder — which writes the group byte at offset 0 — and hands that same buffer and the encoder's own length to the transmit call, with nothing prepended. The link component beneath it is a transport: ports, partners, sequence numbers, a socket path and a modem path, and no P2 header assembly. [C] So on the supervisor's send path a message begins at the group byte, and the node | ? | ? prefix is either added below both of them or is not present on that path at all.

That second possibility is worth stating because it is testable and would explain the shape: the panel-side header is described by code that forwards a message whose address byte is not its own (0x0136), which is a routing concern. A directly-addressed message may simply not carry it. This document does not choose between the two — it records that the two layers where the prefix would most naturally be added do not add it. [C][OPEN]

A note on the ~256-byte figure. §6.7 records, correctly, that the ~256-byte number in vendor connection-test material is a ping size and not a maximum P2 data-packet cap — TCP frames run to 1,622 bytes. That stands. But a 253-byte cap, enforced in code, now exists on this link, and the proximity is suggestive: the vendor figure may describe this encoding's frame limit rather than anything about TCP. Offered as a plausible origin, not a demonstrated one. [I]

7. Service Model & Message Types

7.1 The ASDU service model

P2 is an ISO/OSI-style application protocol. The vendor codec frames every transaction as a service primitive carrying an ASDU (Application Service Data Unit) as its payload, with the classic four-primitive shape: Request → Indication on the originator/receiver pair, and Response → Confirm on the reply path. [S] The 2-byte wire opcode is the AP2 function code (a 16-bit word); a management station may use a different internal command index for the same operation, but the wire carries the AP2 function code only. [S]

The model has two transaction shapes, which map directly onto the direction byte (§6.3):

The stack-selector layer's read primitives confirm the split: ReadConfirmedInd (confirmed request/response) versus ReadEventInd (asynchronous event indication). [S] The dominant Event-class transaction is the change-of-value push 0x0274 (COV_ANNUNCIATE): 120,764 request frames in the corpus under the criteria of §9.5 — almost all acknowledged with a 0-byte success, a small minority unanswered. [W] COV itself is a register/cancel subscription — a peer arms COV with COV_ENABLE (0x0271) / disarms with COV_DISABLE (0x0273), after which the panel emits COV_ANNUNCIATE events. [W][S] The session/heartbeat opcode 0x4640 (EBLN_PING) is a Confirmed transaction reused as the ~10-second in-session keepalive (its ASDU body is a single eBLN_Node element). [W][S]

A second corroboration of the Confirmed model: bulk database transfer (the upload / UPL_ALL_* and DBCHANGE families) proceeds record-by-record, each record drawing its own success-or-fault reply. This per-record success/fault pattern is the Confirmed request/response loop applied iteratively, and it is what the per-record dir == 0x01 / dir == 0x05 outcomes in upload captures show. [W][S]

7.2 Success vs error responses

A response correlates to its request solely by the echoed sequence (§6.5) and never carries an opcode (§6.4).

• Success (dir == 0x01). Carries a result body that may be empty. Many command/acknowledge operations reply with a 0-byte success (the corpus shows ok:0B for 0x0240 POINT_CMD_VALUE, 0x0273 COV_DISABLE, 0x4634 replication, and others). Read/enumerate operations reply with a sized body whose length varies with the embedded name/value TLVs and firmware. [W]
• Error (dir == 0x05). Carries exactly two bytes: a big-endian u16 error code, and nothing else. The error frame is the panel's application-layer rejection path; it is distinct from a TCP RST/FIN (transport-layer wrong-BLN rejection) and from a "no response at all" (the V2-class DoS signature, where the trigger draws neither an error nor a success before the panel's TCP stack goes silent). [W]

Worked error example. A TREND_DATA_DISPLAY (0x0295) request naming a point that has no trend log returns dir == 0x05 with the 2-byte tail 0x0003 ("not found", §7.2.2) — the same not-found code returned for any named object that does not exist. [W]

The whole error vocabulary the corpus exercises. Pairing all 6,006 error responses back to their request by sequence gives seven codes and no unknowns — every one is already named in the error table of §7.2.2, which is the first time that table has been checked against traffic rather than against the type system: [W]

These sum to 6,006, the whole dir == 0x05 population. 97% of all errors are not_found, and exactly one error response in the corpus cannot be paired back to its request. Three operations in the corpus never succeed — 0x0272 COV_DELETE_STUB (0 ok / 46 err), 0x400F TEAM_DESC_UPLOAD (0/12) and 0x5354 HOA_MAP_LOOK (0/6) — and 0x0220 POINT_LOG_VALUE fails more often than it succeeds (1,910 ok / 2,415 err), which reflects how a supervisor walks point space rather than anything about the opcode. An implementer sizing retry logic should not read a high error rate on 0x0220 as a fault. [W]

Reliability and acknowledgment. P2 runs over TCP and relies on TCP for in-order delivery and retransmission; there is no application-layer retransmit and no separate app-layer ACK frame. On a busy link ~1.2% of frames are TCP retransmissions — handled entirely by the transport, invisible to the P2 codec. [W] The application-level acknowledgment of a request is its dir == 0x01 success (or dir == 0x05 error) response, matched to the request by the echoed sequence (§6.5). A peer that needs to know a request was received and acted on waits for that sequence-matched response; nothing else on the wire confirms receipt. [W]

Measured round-trip latency. Median application round-trip (request dir == 0x00 → matched response dir == 0x01/0x05, by echoed sequence) on a busy live link, with p95 < ~2× the median and up to 14 requests pipelined outstanding (§6.5):

These figures are deployment- and link-dependent; they are illustrative of relative cost, not absolute guarantees. The ordering is the durable observation: pings and COV are cheap, point read/write are mid-cost, and trend retrieval is the slowest by an order of magnitude over pings. [W]

7.2.1 Error classes (vendor AP2 error taxonomy)

The vendor codec defines a fixed set of AP2 error classes (C++ RTTI types in the codec, mirrored as named members in the managed type system). These are the definitional error categories; the wire carries a numeric code (§7.2.2) that maps onto them. [S]

7.2.1a Nothing retries a failed request

There is no retry behaviour in the observed clients. A first look suggested the opposite — of 6,005 error responses paired to their requests, 5,522 are followed by the same opcode on the same connection, at a median of 0.02 s — but that test cannot tell a retry from the next request in a poll cycle, and POINT_LOG_VALUE is issued constantly.

The control settles it. Measuring how long until the identical request recurs — same opcode and same body length — split by whether the answer was an error or a success: [W]

A retried request would recur faster after a failure. It recurs slower — 42× slower for POINT_LOG_VALUE. So a client that receives an error moves on, and the request reappears only when its normal cycle comes round again.

Two consequences for an implementer. A panel must not rely on a client re-asking; an error is final for that exchange. And a client gains nothing by implementing retry against these panels' behaviour — if a name is not_found it will still be not_found, which is what 97% of these errors are (§7.2.2).

Scope. Every client in this corpus is the same supervisor product, so this characterises that implementation, not a protocol requirement. Nothing in the wire format forbids a retry; nothing here performs one. [W]

7.2.2 Observed wire error codes

These 2-byte codes appear as the dir == 0x05 error tail in the corpus. Distribution across the 621,268 trusted P2 frames, of which 6,006 are error responses: 0x0003 5,805; 0x00AC 127; 0x0E15 38; 0x0002 28; 0x0E11 4; 0x0E12 3; 0x0009 1 - summing exactly to 6,006. not_found is 97% of all errors. [W]

Where 0x00AC comes from, read off the panel. A controller does not hold one opcode table. It holds at least eight, each a list of {u16 internal_code, u16 ap2_opcode} records with its own count, and it picks between them at dispatch time on a per-peer selector value. An incoming opcode is matched against the second field of each record; when the selected table has no matching entry, the panel writes 0x00AC into the response and stops. So "not supported" is not a single global judgement about the function code — it is the answer from one particular translation table, which is exactly why the same opcode can be refused by one panel and answered by another. The revision reading of this error was documentary until now; it is the structure the firmware actually implements. [F]

The same function special-cases 0x0136 AP2_P2_ROUTE ahead of any table lookup and enforces its length bound inline — payload ≤ 249 bytes, total ≤ 253 (§6.8) — writing 0x0002 if the frame exceeds it. [F]

0x0E10–0x0E17 is the FLN error band. Every code in it reports a fault in the field-level network, the device, or the physical point — invalid FLN number, invalid drop number, device failed, invalid point number, physical point failed, not commandable, value out of range, application invalid for device. A client should read any 0x0Exx tail as field-level, not as a record-state rejection. [D]

A correction, recorded because the wrong reading shipped. The error table in earlier editions of this document and in the released tools was wrong in 26 of its 42 entries, and almost all of it was a single defect: the list was shifted by one entry against the vendor's catalog, from 0x0007 through 0x0210 and again across the FLN band, so each code carried the name belonging to the next code up. The _v2 suffixes the old table used (already_exists_v2, value_out_of_range_v2) are the tell -- the duplicate names the shift produced were suffixed rather than investigated. Among the consequences: 0x0009 was unnamed when it is already exists, 0x0E11 was named already exists when it is an invalid FLN drop number, 0x0E12 was invalid point number when that is 0x0E13, and 0x000B/0x000C had value out of range one code early. One consequence was behavioural rather than cosmetic: the released scanner treated 0x0E11 as a success, so a failed FLN point-add was reported as having worked. The whole table is regenerated and fixed in the tools and here. [D]

The full catalog.

Seven codes is what this corpus produced; it is not what a panel can return. The complete set is 42 codes, and a decoder needs all of them — a code this site never elicited is not a rare code, it is a code for a condition this site never hit. The E-number column is the vendor's own label for each error and is simply the decimal of the code, which is worth knowing because vendor material and panel displays cite errors that way (E172, not 0x00AC). [D]

Three properties an implementer should read off it. The catalog is sparse and irregular — 42 codes over a range of 3,600 — so a decoder must use a lookup and not an array index. The bands are meaningful: 0x0001–0x0210 are panel and record errors, 0x0080–0x0082 are the user-account band, and 0x0E10–0x0E17 is the FLN band described below. And the observed distribution is nothing like the catalog — one code is 97% of every error this corpus contains, while 35 of the 42 never appeared at all. A decoder tested only against a capture is a decoder tested against one row. [W][D]

On the code↔AP2 error class pairing, which an earlier edition left open. The question was whether the type system's per-operation *_Error_enum types define a second, per-operation error namespace that would have to be mapped onto the wire codes. They do not, and there are far fewer of them than the question assumed — 16 in the whole type system, fifteen of those RACS partner and port operations. Where they carry a value it is the same value the global catalog uses:

So a per-operation error enum is a named subset — it says which of the global codes that operation can return, and gives each a name in that operation's terms. There is no translation to perform. [S]

Two members do not fit, and are reported rather than smoothed over: no_ram_available / no_ram = 0 in the two RACS partner add/modify enums, and port_not_found = 0 in the three RACS port enums. The global catalog defines no code 0 — its memory error is 0x0001 and its not-found is 0x0003. Both are the first-declared member of their enum, which would suggest a generator default, except that AP2_Racs_Partner_Delete_Error_enum has exactly one member and it is partner_not_found = 3, so the first member is not auto-zeroed. Either 0 is a real code the catalog omits, or those five enums number from a different base. That is a narrow open item: it affects five RACS operations and no code this corpus has seen. [S][OPEN]

7.2.3 Implementation guidance

A parser MUST inspect dir before interpreting any post-slot bytes. An error tail and a value block can both begin 00 03: read as a value block, 0x0003 ("not found") would fabricate a phantom value where the peer actually reported an error. [W] A robust client treats dir == 0x05 as an application-layer "operation failed with code N," distinct from transport-level RST/FIN (connection rejected/closed) and from silence (no reply). A 0-byte dir == 0x01 is a positive acknowledgement, not an empty/failed result — and it is the majority shape, not an edge case: of 300,985 success responses paired to their requests, 169,462 (56.3%) carry a zero-length body. [W]

But emptiness is a property of the exchange, not of the opcode, and a client must not key on it. Some opcodes always ack empty — 0x0274 COV_ANNUNCIATE (120,749 of 120,749), 0x0273 COV_DISABLE, 0x4636, 0x4635, 0x0508, 0x4633. Others always return a body — 0x4640 EBLN_PING, 0x0981 UPL_ALL_POINT, 0x0271 COV_ENABLE, 0x0220 POINT_LOG_VALUE. And at least two do both: 0x0240 POINT_CMD_VALUE answers empty 32,451 times and with a body 30 times (a Name_response — the point's name and suffix echoed back), and 0x4634 answers empty 10,003 times and with a u32 13 times (§5.3). Read the length; do not infer it. [W]

7.3a The stack's service primitives

Beneath the opcode catalog the P2 stack presents a small, named set of service primitives. They are worth stating because they explain why the opcode families are shaped as they are: [S]

The GetFirst / GetNext / CancelGetNext triple is the same cursor idiom §7.2's continuation discussion describes at the application layer: enumeration is a stack-level concept, not a per-opcode convention, which is why the UPL_ALL_* family and the browse families all cursor the same way. The third member matters to an implementer and is easy to miss — a cursor can be abandoned explicitly. A client that walks half an enumeration and disconnects leaves the server holding cursor state that a CancelGetNext would have released.

The stack selector also enumerates the transports the same service layer can sit on — Protocol II, Ethernet, Profibus, a remote link, and an "other" catch-all — which is the layering §2 describes, from the implementation's own side. [S]

7.3 Connection and session model

P2 runs over TCP with a role-asymmetric, multi-connection topology. A field panel listens for P2 on TCP/5033 (§4.1); a supervisor listens on its own P2 port(s) for node-originated traffic — in the observed Desigo deployment the supervisor listens on TCP/5034 for panel push/value traffic and also accepts node announcements there (§4.1, §2.1.2). Exact supervisor port assignment is deployment-specific, but the two-listener / two-connection pattern below is the model. [W]

Two connections per node-pair. Each side opens a TCP connection to the other side's listener, so a communicating pair maintains at least two long-lived TCP connections, one per direction:

• supervisor → panel:5033 — the supervisor's poll/command channel.
• panel → supervisor:listener — the panel's announcement + COV/value-push channel.

The message classes a given pair uses are fixed by the panel's firmware generation, not by which of these two connections a frame rides: a legacy panel uses 0x33 data + 0x2E second-channel in both directions, a modern panel uses 0x34 + 0x2F (§6.2/§6.6). The second channel (0x2E/0x2F) is where the panel's announce/identity and DB-change/replication records flow toward the supervisor.

These connections are long-lived; reconnects (panel reboot, link flap, supervisor restart) add further connections over the life of a capture. [W]

How long-lived, measured. In the 16.7-hour capture, 24 sessions carry substantive traffic and all 24 run the entire capture — every one opens within 0.1 minutes of the start, every one is still open at the end, and all 24 are open simultaneously at the midpoint. There is not a single reconnect. The steady state is a permanently-established mesh, so a client should open its connections once and keep them. [W]

Size a panel from the per-listener figure, not this one. The 24 above is the whole capture — every session between every pair of nodes — and sizing a listener from it would be the wrong denominator. What one panel actually holds is measured in §3.9: a peak of 9 concurrent peers on 18 sockets, which in those captures is every other node on the BLN at once. Expect roughly two sockets per peer, and expect them to stay open. [W]

A trap worth naming, because it produced a phantom finding. Dividing a capture's connection count by its duration does not give a reconnect rate — 24 connections over 16.7 hours reads as "a new connection every 42 minutes" and is completely wrong when the 24 are concurrent and permanent. Check whether sessions overlap before treating their count as a rate. The same capture also shows 2,393 single-frame tuples against those 36 real sessions, so a raw tuple count is not a session count either.

7.3.1 Session establishment, in order

Everything below is stated elsewhere in this document; what was missing is the order, and a responder cannot be written from facts scattered across five sections. This is the whole sequence, from TCP connect to steady state. [W][S]

1. Connect. Open TCP to the peer's listener — 5033 for a field panel (§4.1). A supervisor's listener is deployment-specific (§2.1.2); do not infer it from a |PORT identity suffix (§6.4).

2. Send 0x4640 (EBLN_PING / IdentifyBlock) as the first frame. There is no separate handshake opcode: establishment is this exchange (§6.2). Frame it on the second-channel class matching the peer's generation — 0x2E legacy, 0x2F modern (§6.6) — with dir = 0x00, slots [0] and [2] both the BLN name, [1] the destination node name, [3] your own identity. The body is the eBLN_Node block of §10.6: three name TLVs then exactly 16 bytes.

3. The BLN name is the gate, and it is checked before anything else. A wrong BLN name draws a TCP RST from a panel or a graceful FIN from a supervisor listener, before any application processing and with no node-table side effect (§17.2). Nothing else in the frame is examined — not the identity, not the body.

4. A correct BLN name is admitted, and the reply tells you which kind of peer you are. A slot[3] identity already in the receiver's peer list draws a short (~48-byte) second-channel response — effectively a peer offer back. A novel identity draws the longer data-dialect response and writes a Permanent node-table entry at your IP (§5.3.3, §6.2). Registration is gated by BLN-correctness, not by being served data: the data-service identity check is a separate, later gate.

5. Learn the peer's generation once, then stop guessing. Issue CABINET_DISPLAY (0x010C, §10.5) and classify from the returned revision. That one read fixes both the dialect to frame in and how names are encoded for that peer, permanently (§6.6). Do not blind-probe {0x33, 0x34}.

You do not need to decode the whole block to do this. revstring is field 1 — the first TEXT_ TLV in the body — so the generation is three bytes and a string into the response. §10.9 lists this response as not fully decodable, which is true of the other fifty fields and irrelevant here.

6. Hold the connection and keep it alive. Re-send 0x4640 every 10.0 s (§5.1). Sessions here are permanent: 24 of 24 substantive sessions ran an entire 16.7-hour capture with no reconnect (§7.3). Open once and keep it.

7. Expect the reverse connection. The pair is two connections, one per direction (§7.3), so a conformant node also listens and repeats steps 3–4 as the receiver.

Role asymmetry is real and will bite a symmetric implementation. A panel-initiated EBLN_PING into a supervisor's 5033 may be accepted at TCP and answered with zero payload bytes and a FIN while that same supervisor answers its own outbound pings on 10.0 s — 984 such connections in 25 minutes at one observed supervisor (§5.1). Do not treat "the TCP connection was accepted" as "the session was established"; the establishment signal is the 0x4640 reply.

7.3.2 Response timing, measured

Across 306,990 paired request/response exchanges — every request matched to the response echoing its sequence on the reverse direction of the same connection: [W]

A P2 request is essentially always answered. Forty-one unanswered out of 307,031 is the entire corpus-wide total, and that figure only becomes meaningful after excluding connections whose reverse direction was never captured — those contribute 7,224 requests whose replies the tap could not have seen. Counting them produces "2% unanswered", which measures the vantage and not the panel. Restricted to EBLN_PING on connections with both directions visible and 20 or more pings, 268 of 274 connections have zero unanswered, and the six that do have exactly one each, in a capture taken across a deliberate power cycle.

Reaching through to an FLN device costs about 40× a panel-local read, and a client must size its expectations accordingly: [W]

The LOCAL / REMOTE distinction in the 0x422x names is exactly this: local reads the panel's copy, remote crosses the field bus. The remote form's p99 is 3.7 s, which sits well inside the 30-second ClientTrnxTimeout of §4.6 — so a client should not treat a multi-second reply to an FLN-crossing opcode as a fault, and should not apply one timeout to every opcode.

The BLN is a full peer mesh. Every node holds live P2 sessions with the supervisor and with every other node on the BLN — panel↔panel sessions run over panel:5033 just like the supervisor's poll channel (carried by the 0x29/0x2A peer-session band, §6.2). This realizes the self-organizing logical BLN of §5.3 at the connection layer. Inter-panel traffic is only visible at a panel's own switch port, never from the supervisor's vantage — a capture taken at the supervisor sees supervisor↔panel traffic but none of the panel↔panel mesh. [W]

Connection establishment (observed at SYN level). A panel-side switch-port mirror captures the TCP handshakes directly: panels open connections to port 5033 — both to the supervisor (panel → supervisor:5033) and to each other (panel → peer-panel:5033) — and the listener answers with SYN-ACK. In one mirror window a single panel dialed five different peer panels' :5033 plus the supervisor, and other panels dialed back to it, in waves (initial connect, then reconnects). This is the peer mesh forming at the transport layer. The supervisor's own outbound connections to panels are off-vantage in a supervisor-side capture (it is the SYN-ACK side there), so "who initiates" is only directly observable for the connections that cross the mirrored port; what is established is that every panel both listens on 5033 and dials 5033 on its peers. [W] A reconnecting node does not reset its sequence — the first frame on a freshly-opened TCP connection continues the node's prior high sequence value for that channel (§6.5). The first application traffic on a fresh data path depends on the channel role: on a supervisor→panel poll channel (TCP/5033) to a legacy panel it is a periodic database-change poll (0x0959/DBCHANGE family) at a ~5-second cadence; on a panel→supervisor push channel (e.g. TCP/5034) it is typically a COV push/enable (0x0274/0x0271). The constant across all fresh streams is the 0x4640 (EBLN_PING) identity exchange. There is no dedicated P2 "connect handshake" opcode — the TCP handshake plus the message-class context (§6.2) is the session. [W]

                       supervisor "SUP"  (192.0.2.10)
                       listener: TCP/5034
                          ▲              │
        panel→SUP push    │              │  SUP→panel:5033 poll/command
        (announce/COV)    │              ▼
                    ┌─────┴──────┐  ┌────────────┐
                    │   NODE1    │  │   NODE2    │
                    │ (192.0.2.21)│ │(192.0.2.22)│
                    │ TCP/5033   │  │ TCP/5033   │
                    └─────┬──────┘  └─────┬──────┘
                          │   panel↔panel  │
                          └────────────────┘
                    NODE1:5033 ↔ NODE2:5033 (peer mesh,
                    0x29/0x2A band — invisible at SUP)

Each arrow is an independent TCP connection with its own sequence space (§6.5).

8. Body Encoding Primitives

Request and response bodies (everything after the 2-byte AP2 function code on a request frame, or after the routing slots on a response frame) are assembled from a small, fixed set of encoding primitives. This section defines each primitive at the byte level. The opcode/operation grammars in §9 are built entirely from these; the point-model value forms they feed are detailed in §11. All multi-byte integers in P2 bodies are big-endian unless explicitly stated otherwise; header length and sequence fields are big-endian u32, and analog f32 values are big-endian (see §8.3). [W][S]

The primitives are:

8.1 The string TLV

The universal container for a string, name, or scope-name field is a tag-length-value (TLV) structure. It is the single most common primitive in any P2 body. [W]

textType is not always 0x01, and the earlier claim that it was could not have detected otherwise. A previous edition of this table read "always 0x01 in the corpus" on the strength of a scan that located TLVs by looking for the byte 0x01 — so a TLV with any other type could not appear in its output, and the 1,223,162 figure it produced is a count of 0x01 bytes, not a census. Re-run by structural position instead — reading whatever byte sits at each place a structure requires a TEXT_ — the corpus gives: [W]

Every one of the 24 has textLen = 0 and no content, so 00 00 00 and 01 00 00 are two encodings of the empty string and no non-empty value of another type has been seen. The practical rule: a decoder must take the TLV from its position in the structure and must never test textType == 0x01 to decide whether one is present — a parser that does will desynchronise on an empty field, which is exactly how twelve point bodies in this corpus fail to decode. textType is a [OPEN] discriminator: the firmware's own string handling distinguishes RAD-50 from ASCII (§8.4), which is the obvious candidate for what it selects, but no non-0x01 value with content exists here to confirm it.

The length is two bytes, not one. An earlier edition of this section described the primitive as a fixed 2-byte prefix 01 00 followed by a one-byte length. Every observed TLV is consistent with that reading, because the protocol's own type system defines the field as

TEXT_ :  textType : UNSIGNED_8      textLen : UNSIGNED_16      text : Byte[]

so the 00 that looked like the second half of a constant tag is the high byte of a 16-bit length. The two readings coincide for every string shorter than 256 bytes, and no string in the corpus is longer: 1,223,162 TLVs, every one with a zero high byte. (That scan located TLVs by their 0x01 type byte, which invalidates it as a census of textType above but not as a test of the length, which is what it was built for — and the 24 TLVs it could not see are all zero-length.) The longest content observed from vendor traffic is 183 bytes; the only 255-byte TLV in the corpus is a deliberately maximal test name of our own.

An implementer must use the 16-bit reading anyway, because the one-byte reading is only accidentally correct here and fails destructively where it is not: the codec's own string caps put message text, license strings, point descriptions and PPCL program-line text in a band around 248–257 bytes (§8.4), straddling the boundary. A decoder that reads one byte will take a 256-byte line's length as 0x00, emit an empty string, and then resynchronise in the middle of the text — silently, on the most variable-length field in the protocol.

[OPEN] — no observed frame settles it from the wire alone. The falsifying test is cheap and safe, and is the same shape as the name-length probes already run: present a name TLV of 256 or more bytes and observe whether the panel reads the length as 16-bit. Until then this is [S] from the type system with [W] consistency, not a wire-proven width.

Worked examples (verbatim wire bytes): [W]

01 00 04 53 59 53 54         ->  "SYST"   (length 4)
01 00 0A <10 content bytes>  ->  a 10-byte name
01 00 00                     ->  ""       (empty TLV, length 0)

Properties an implementer must honor:

• Content is NOT NUL-terminated. The length byte alone bounds the content. This is the inverse of the four routing slots in the header (see §6), which are NUL-terminated and carry no length prefix. The two MUST NOT be conflated. [W]
• A single TLV's content is bounded by textLen, a 16-bit field, so the structural cap is 65,535 bytes rather than 255. What actually bounds a field is the codec's per-field maximum (§8.4) — 31 bytes for object and point names, ~13 for a short descriptor, ~248–257 for free text — not the length field. Standard P2 name fields are far under either. [S][W]
• The empty TLV 01 00 00 (length 0) is common and serves as a positional placeholder inside request bodies — reserving or separating a field that carries no value in a given request (for example a device-name slot left empty to address a BLN-virtual point). [W]

Notation used throughout §9: S<n> abbreviates a string TLV — <textType> <n:u16 BE> <n content bytes> — and S() abbreviates the empty placeholder TLV. Worked examples render these as 01 00 <n> … and 01 00 00 because they are verbatim capture bytes and textType is 0x01 in 113,499 of the 113,523 TLVs measured. Read the notation as positional, not literal: the leading byte is a type, the empty form occurs on the wire as 00 00 00 as well as 01 00 00, and a decoder must take each TLV from its structural position rather than matching the leading byte (§8.1). [W][I]

The TLV's TEXT_ content is what realizes a logical name on the wire. In the vendor's own ASDU field model (§8.5) a name field decomposes into a name_space selector plus name and suffix TEXT_ fields; on the wire each TEXT_ field is a string TLV, and a multi-component name is carried as consecutive TLVs. [S]

8.2 Scope tag and command priority

Most addressable requests open with a scope tag: a scope-name string TLV (§8.1) immediately followed by a 5-byte selector of the form <scope_byte> 3F FF FF FF. [W]

01 00 04 53 59 53 54   23 3F FF FF FF
|------- TLV "SYST" --| |- selector -|
                        scope_byte=0x23, then wildcard mask 3F FF FF FF

This block is a User_profile, and reading it as one explains every field. The structure catalog defines User_profile as user_logon : TEXT_, point_priority : Point_priority, access_class : BITSTRING32 — a name, a priority and a 32-bit rights mask — which is exactly the TLV + byte + four bytes seen here. [S][W]

So the "scope names" are logon identities: SYST and NONE are what the stack presents for system-originated work, and a human login appears in the same field when a person drives the operation. The single 0xBFFFFFFF came from a panel operation issued while an operator was logged into that panel's Telnet CLI — same mask as the system contexts plus the top bit, i.e. a different access-rights set for a privileged session, not a different mask format. A parser should therefore read all three fields rather than matching a fixed prologue: an unfamiliar name in the first TLV is an operator, not a parse failure. [W] The leading scope_byte is the command priority at which the operation acts — it is not a separate flag. The same byte both sets the priority a write commands the target at, and (through the read-vs-write handler split) selects the body grammar that follows. [W][S]

Defined scope-name TLVs observed on the wire: [W]

8.2.1 The command-priority ladder [S]

The scope_byte takes its values from the User_command_priority enumeration, the command-priority ladder. Higher numeric value = higher priority; acceptance of a command at a point is a >= gate against the priority already held at that point. [S]

The same five priority names are exposed in the PPCL control language as the literals @NONE, @PDL, @EMER, @SMOKE, @OPER, and the field-controller priority field is a single byte (GetPriority -> BYTE), confirming scope_byte is exactly the 1-byte command priority. [D]

Priority semantics an implementer must honor:

• A write commands the target at the priority in scope_byte; a read uses 0x00 (none). The read-vs-write body shape for a polymorphic scoped opcode is discriminated by scope_byte (0x23 write vs 0x00 read) together with traffic direction — never by TCP port and never by the message class. [W][S]
• Priority is held until released. A command placed at a given priority holds the point at that priority. A held priority MUST be explicitly released (commanded back to none) before a lower-authority source — for example a PPCL program commanding at NONE — can reclaim control of the point. A PPCL NONE command does not override a higher held priority. [D][I]

8.2.2 Point priority overlay (BACnet 16-level band) [S]

The Point_priority_enum superset extends the command ladder of §8.2.1 with the BACnet 16-level priority array, values 101–116 (bacnet_1 … bacnet_16), where bacnet_1 (101) is highest within that band.

The translation between the two ladders is a documented, and configurable, table. When a P2 control program commands a BACnet point, the supervisor maps the P2 priority onto a BACnet level: [D]

The ordering survives the translation — BACnet numbers ascend as priority falls, so OPER at 8 outranks NONE at 16, exactly as 35 outranks 0 on the P2 ladder (§8.2.1). What an implementer must not do is treat the mapping as fixed: it is overridable per project by a plain-text configuration file, so a tool that infers a P2 priority from an observed BACnet level, or the reverse, is reading a site setting rather than a protocol constant.

Later, BACnet-capable controllers also expose an MMI/BACnet priority band in the 8–16 region (APP_PRIORITY / MMI_PRIORITY enums on BACnet-TEC platforms). A point on such a controller resolves its effective command from the combined ladder: the legacy P2 command priorities (0–35) and the BACnet array (101–116) coexist in one priority space, with the same higher-value-wins >= arbitration. The classic P2 wire scope_byte carries only the 0–35 legacy band; the 101–116 band is reached through the point's BACnet command path on controllers that implement it. [S][I]

8.3 Numeric value fields

8.3.1 Integers [W]

Integer fields embedded in bodies are big-endian. Both 16-bit (u16 BE) and 32-bit (u32 BE) fields occur — 2-byte error codes, 2-byte record markers and element counts, and 4-byte counts or identifiers in enumeration and routing bodies. (Header total_len, msg_type, and sequence are u32 BE; the AP2 function code and the error code are u16 BE — see §6.) The vendor field model uses the signed/unsigned 8/16/32 widths of the Native_type_enum (§8.3.3), and counts are typically UNSIGNED16 / UNSIGNED_16, e.g. an array length preceding a variable-length element list. [W][S]

8.3.2 Floating-point (analog) values [W][S]

Analog point values are IEEE-754 single-precision (32-bit) floats in big-endian byte order (f32 BE), embedded directly in the body with no scaling on the wire. Example: the bytes 41 EB 3C 0C decode to 29.404. Runs of f32 values appear inside multi-value response bodies (setpoint and limit tables, schedule data). [W]

Values are raw engineering units as the point holds them; any slope/intercept conversion to display units is applied by the client from a per-point table, not from any wire field. Each analog point carries a Slope and Intercept (and a Sensor Type) in its configuration; display value = slope * raw + intercept, with the device-range ↔ signal-range mapping (PointDeviceHigh/Low ↔ PointSignalHigh/Low) defining the conversion. This metadata is not on the value wire; it lives in the point database. (See §11 for the full point-read value-block layout that wraps the f32.) [D][S]

This BLN/P2 f32 value form is distinct from the FLN/P1 raw-count analog representation: an FLN field device reports an analog as an integer raw count whose width is governed by P1MaxRange (most commonly an 8-bit count, 0–255), which the parent panel converts to engineering units using the point-team scaling before presenting the point as a P2 f32. An implementer reading P2-over-TCP sees the f32 form; the raw-count form appears only across the P1 fieldbus and in FLN-device point definitions (cross-ref §11). [D][I]

8.3.3 Native primitive types [S]

The vendor's Native_type_enum enumerates the primitive value types a point or field may take. An implementer mapping a typed field to wire bytes uses this set:

The analog wire value (§8.3.2) is NVT_TYPE_FLOAT (12). The width and byte order of every other primitive follows the table above, big-endian for all multi-byte forms. [S]

8.3.4 Date/time stamp [W]

Event records (alarm prints, §13.6, and trend/log samples) carry an absolute timestamp as a packed 8-byte calendar field, one byte per component, in order:

<year-1900> <month> <day> <day-of-week> <hour> <minute> <second> <centisecond>
   u8         u8     u8        u8         u8      u8       u8         u8

The year byte is the calendar year minus 1900 (so 0x7E = 126 → 2026); month is 1–12, day is 1–31, day-of-week is 1 = Monday … 7 = Sunday, then 0-based hour (0–23) / minute (0–59) / second (0–59) and a trailing hundredths-of-a-second byte. Worked example: 7E 06 19 04 0C 3B 23 48 → 2026-06-25, day-of-week 4 (Thursday — which is the true weekday of that date, an independent check on the field order), 12:59:35.72. [W] A record may carry more than one such stamp — an alarm report (§13.6) carries three: an event time, a reference time, and a created/configured time; a second observed stamp 7C 01 1E 02 10 0B 0A 59 decodes to 2024-01-30, day-of-week 2 = Tuesday, 16:11:10, again weekday-consistent (a recurring "created" base). [W]

The weekday byte makes the field order self-checking, so it was checked on everything rather than on two examples. Taking every 8-byte window in the corpus whose year, month, day, hour, minute, second and centisecond are all plausible — and ignoring the weekday byte while selecting — gives 738 distinct stamps, spanning 2020 to 2026. The day-of-week byte matches the true calendar weekday of the decoded date in 738 of 738.

That is the discriminating result rather than a restatement, because a wrong field order does not survive it: swap month and day and every date with a day past the 12th becomes invalid while the rest decode to the wrong weekday, and a weekday byte that was really something else would agree about one time in seven. 100% against a 14% null is the field order, confirmed. [W]

This wire form is distinct from the eBLN_Node baseTime/offset clock-sync fields (§10.6), which are a separate u32 time base plus a u16 zone offset used for replication time alignment, not a calendar stamp. [W][S]

8.4 String character encoding — RAD-50 vs ASCII

String content inside a TLV (§8.1) is carried in one of two character encodings, selected per firmware platform, not per frame. The encoding in force is a fixed property of the device's firmware revision (STRING_TYPE = RAD50 | ASCII, keyed per platform class in the firmware revision library). A node uses one string encoding for its whole revision. [D]

8.4.1 The RAD-50 codec [S]

RAD-50 packs three characters into a single 16-bit word, drawing from a fixed 40-character alphabet. The alphabet (index → character) is: [S]

index:  0                                              39
char:   " ABCDEFGHIJKLMNOPQRSTUVWXYZ$.?0123456789"

Three characters c0 c1 c2 (each mapped to its index 0–39) pack into one unsigned 16-bit word: [S]

word = ((c0 * 40) + c1) * 40 + c2

The maximum packed word is 39*40*40 + 39*40 + 39 = 63999 (0xF9FF), so every RAD-50 word fits a u16. To unpack, decode c2 = word % 40, c1 = (word / 40) % 40, c0 = (word / 40 / 40) % 40, then map each index back through the alphabet. Names whose character count is not a multiple of 3 are padded with the space character (index 0) in the trailing position(s) — the packer leaves unused positions at index 0 and zero-fills whole trailing words, which is the same thing. [C] Each packed word goes on the wire big-endian: the codec builds the word natively and then writes it through its 2-byte primitive with the byte-reversal flag set, exactly as it does for every other multi-byte field (§8.3). [C] An n-character field therefore occupies 2 × ceil(n / 3) bytes, so a 6-character name is 4 bytes and a 12-character name is 8. [C] RAD-50 appears only on pre-IP field-controller and supervisor revisions, so an implementer targeting P2-over-TCP normally encounters ASCII (§8.4.2) and treats a RAD-50-packed peer as an out-of-scope legacy revision. [S][I]

Only the 40 alphabet characters are representable: uppercase letters, digits, space, and the three symbols $ . ?. Lowercase and other punctuation cannot be RAD-50-encoded, which is consistent with the uppercase-only, restricted character sets of legacy name fields. [S][I]

Two encoder rules that a decoder-only reading of the alphabet misses. The packer uppercases its input first — a lowercase name is silently folded to uppercase, not rejected — so an implementer must uppercase before comparing a round-tripped name with the original. And ? (index 29) is refused on encode: the packer returns an error for it exactly as it does for a character outside the alphabet, which makes ? a decode-only symbol. An over-length source is rejected before a single byte is written, rather than truncated. [C]

8.4.2 ASCII [W][D]

All P2/IP revisions carry plain ASCII in both the length-prefixed TLVs (§8.1) and the NUL-terminated routing slots (§6). This is the encoding observed throughout the TCP/5033 wire traffic. A TCP/5033 implementation is ASCII end-to-end; it does not need a RAD-50 codec to interoperate with current panels. [W][D]

8.4.3 Field length budgets by encoding [D]

String fields have encoding-dependent capacity budgets. Name fields (point name, node name) on RAD-50 platforms are constrained to roughly a 12-character budget (and ~30 for longer object-name fields); free-text fields such as a point Description run to roughly 60 ASCII characters. Concrete name-field limits used by the protocol model: a logical point name up to 15 characters (historically a 6-character field; shorter names interoperate everywhere), a point descriptor up to 12 characters (display-only), and an object/display name up to 30 characters. Node and BLN names also fall in the ~30-character band. These budgets are firmware-platform properties; an implementer should treat the larger limit as the worst case and not assume a fixed width. The ~15-character node-name truncation is consistent with the Base + Suffix decomposition of a system name (the name is split into a base and a suffix, with the base length-bounded). [D][I]

Codec-enforced byte maxima (cross-validated). The ASCII serializer applies a fixed maximum byte length per string field, and the same caps recur across dozens of independent operation bodies — so they are reliable worst-case widths for an encoder, not per-opcode accidents. The dominant cap is 31 bytes (0x1F) for object / point / program-name fields (seen on the command, COV, cabinet, EBLN, and enum families alike — it is by far the most common string cap; this is the byte width of the 30-character object-name field above, i.e. 30 usable characters within a 31-byte budget), with 13 bytes for a short descriptor or secondary name (the 12-character descriptor above in its field budget), roughly 21 bytes for an operator credential / logon identity, and a free-text band of ~248–257 bytes for message text, license strings, point descriptions, and PPCL program-line text. (This 31-byte object-name cap is distinct from the ≤15-byte node-name limit above — they are different fields: the node name is the access-gate identity in the routing slot / node-name table, while the 31-byte cap governs point, object, and program names inside the body.) An encoder SHOULD truncate to these maxima before framing; an over-length field is the most common reason a panel silently rejects an otherwise well-formed write. [D][I]

8.5 ASDU field convention

A P2 body is an Application Service Data Unit (ASDU) — the payload the request/response service carries. Each ASDU body is a sequence of ordered, typed fields in declaration order (an AsnBase-style structure: there are 1,144 such request/response/sub-type structures defined in the vendor type system). There is no per-field tag/name on the wire beyond what each primitive carries; field identity is positional, fixed by the structure definition for that opcode. A parser walks an ASDU left to right, consuming each field per its declared type. [S]

Field-type-to-primitive mapping:

Composite name fields decompose into a name_space selector plus TEXT_ components, each component a string TLV on the wire:

• Name_single = name_space, name (TEXT_), suffix (TEXT_) — addresses one named object. [S]
• Name_response = name_space, name, suffix — the echoed name in a reply. [S]
• Name_search = name_space, name_pattern, suffix_pattern, plus last_name_space/last_name/last_suffix for resumable/paged browse. [S]

A worked structural example — the point-command-value request — shows the convention end to end: [S]

AP2_Point_Cmd_Value_Request =
    user_profile   : User_profile      ; sub-structure (inlined fields)
    name_search    : Name_search       ; name_space + name/suffix TLVs (+ resume fields)
    point_value    : Point_value       ; the f32 value block
    point_priority : Point_priority     ; the command priority (§8.2.1 ladder)

On the wire this serializes as the sub-structure's fields, then the name TLV(s), then the f32 value, then the priority field — in that order, positionally. The command priority here is the same ladder value that a scoped request carries in its scope_byte (§8.2.1); whether the priority rides as a scope-tag selector byte or as a trailing typed field depends on the specific opcode's structure, but the value space is identical. [S][I]

Layout-precision note. ASDU field order and type are definitional truth from the vendor type system ([S]). For the COV annunciate condition/priority block specifically, the offsets are now pinned: the Annunciate_request defines exactly ten status fields after the value and the wire block is exactly ten bytes, so the mapping is one byte per field in schema order (§12.3.3) — position/size/order are [W]/[S], and only the asserted values of the alarm/flag/priority bytes remain to be confirmed from an alarmed capture. For the per-type value arms of All_points the position is now measured rather than open, and it splits by arm. An arm's interior layout is confirmed the moment a body carrying it consumes to the byte, because a wrong interior offset displaces everything after it — so the corpus settles the arms it exercises and says nothing about the rest: [W]

Six of the sixteen arms are confirmed; the other ten are never exercised here and stay [OPEN] — looap, lpaci, l2sp, looal, lfssl, lfssp, ldao, lfmsl, lfmsp, ppcl_lai. That is the same ceiling §10.9 describes: this site runs six point types, and no amount of further reading of this capture set will produce a seventh. [W][OPEN] For the replication change-record framing the interior offsets remain [OPEN]; treat byte-offset claims there as inferred.

For the byte-level grammar of each opcode's request and response ASDU, see §9; for the point-model structures (value blocks, multistate enum tables, FLN-device subpoints, slope/intercept scaling) these primitives compose into, see §11.

9. Function-Code (Opcode) Catalog

Every P2 request, panel-originated push, and response is dispatched on a single 2-byte field, the AP2 function code (the wire opcode). This section catalogs that field. §10 then gives the body (ASDU) structures that follow each opcode.

9.1 The AP2 function code

The AP2 function code is a 16-bit big-endian value that sits on the wire immediately after the fourth NUL-terminated routing slot, in direction == 0x00 frames (requests and panel-originated async pushes). It is the dispatch key the panel exec (CEC) uses to select the operation; the bytes following it are the operation's ASDU body (§10). The opcode is meaningful only in direction == 0x00 frames — reading the post-slot bytes off a 0x01 success or 0x05 error response yields response-payload bytes, not an opcode, and fabricates phantom values (see §6.4). [W][S]

The complete command vocabulary of the protocol is defined by the vendor's AP2_Function_Code enumeration: 641 named members across 630 distinct opcode values (a handful of values carry two names — historical aliases such as AP2_DUMMY_CMD/AP2_REV_STRING at 0x0100, or the CONTROLLER/TEC doublets). The enum's numeric values are the wire opcodes: cross-checking every opcode seen on the wire against the enum, all matched exactly. [S]

Of the 630 defined values, 135 are observed in the capture corpus (621,268 trusted P2 frames across the 121 captures that carry P2; see §9.5 for the counting criteria and for why an earlier figure of 135 was withdrawn); the remaining 495 are defined-but-unobserved (overwhelmingly configuration, database-management, upload, and BACnet/LON-integration operations that a passive supervisor↔panel capture does not exercise). A further 15 opcode values appear on the wire without an enum definition at all and therefore have no catalog row; thirteen of them are real panel operations and two are artifacts of a deliberately malformed test frame (§9.5). Counting those, 148 distinct operations have been observed. Every defined opcode is enumerable from the catalog below; "not observed" means absent from this corpus, not undefined. The corpus combines passive supervisor↔panel and panel↔panel site captures with a smaller set of active read/enumeration test captures; opcode counts are corpus frequencies, not a claim about steady-state operation. [W][S]

Rows that were seen on the wire are tagged [W] and carry their frame count; defined-but-unobserved rows are tagged [S] (struct/metadata-derived from the vendor enum — definitional truth). Wire counts in the catalog come from the corpus census; per-opcode response shapes, error tails, and message-class distributions are in §9.7.

Vantage point bounds every count in this section. Almost all of the corpus was captured at the supervisor, and a supervisor-side tap structurally cannot see a session between two panels — P2 is unicast TCP, so the switch shows that tap only the conversations the supervisor is in. Taps placed on a panel's own switch port — five of them, on two different panels — each show it holding P2 sessions with nine peers, of which the supervisor is one. Read the counts here as frequencies in supervisor-facing P2, and read a zero as "the supervisor does not invoke this," never as "panels do not exchange this." The message-class figures in §9.7 make the difference concrete: class 0x2A is absent from the supervisor-side census and plainly present from a panel-side one. [W]

9.1.1 The wire opcode is the bottom of a three-tier model

An implementer reading only the wire sees one identifier per request. The stack that produces it carries three, and knowing that resolves several things this document previously treated as anomalies. [S]

  __Rpc<Operation>          the supervisor-side operation, by name
        |
        v
  CPI function code         "Common Protocol Interface" dispatch id
        |
        v
  AP2 function code         what appears on the wire (§6)

The command object exposes both lower tiers side by side — GetAP2FunctionCode / SetAP2FunctionCode alongside GetCPIFunctionCode — so the two codes are genuinely distinct fields, not two names for one value. They are reachable from either end: one factory builds a command from a CPI code, another (BLN2CPI) builds one by parsing a received wire frame and dispatching on the AP2 function code inside it. [S]

Scale: 353 CPI codes carry a recovered operation name, 356 reach a command class, and 347 of those have a request encoder that resolves onto 399 distinct wire opcodes. The names are plainly descriptive (__RpcRegisterCOVxx, __RpcCancelCOVxx, __RpcColdStartCabinet, __RpcMakeNodeOffline, __RpcBACnetWhoIs, __RpcBPing), which makes the CPI tier the most legible statement of what operations exist that this protocol has. [S]

The receive path is narrower than the send path, and by how much is measurable. BLN2CPI dispatches an inbound frame through a chain of twelve range switches, each of which states its own first opcode and its own length. Together they reach 700 opcode values; 97 of those have a dedicated handler and the remaining 603 fall through to a single shared default. [S]

Two properties of this make it usable rather than trivia. An opcode outside every band cannot be dispatched at all by this receive path — 700 of the catalog's values are reachable and the rest are not, which bounds what a peer can meaningfully send to a supervisor. And falling inside a band is not the same as being handled: the 603 defaulted opcodes reach a single address that sets an error rather than decoding a body, so a client that receives a success for one of them is talking to something other than this codec. [S][I]

The map is checked against an artifact that did not produce it: all 97 opcodes with a dedicated handler carry a name in the AP2 function-code enumeration — 97 of 97, against 29% for the defaulted ones. If any band's base or length were off by one, its dedicated set would slide onto neighbouring values and that agreement would collapse toward the background rate. [S]

The opcode carries an operand, which is why the catalog is so large

The obvious model — one operation, one wire opcode — is wrong, and the way it is wrong is useful. The wire opcode is selected while the request is being encoded, not when the command is created. The supervisor builds the body first, and only then reads the function code out of the command object and writes it into the frame. An operation whose parameter can take a few values therefore emits a different opcode per value, and that parameter never appears in the body at all. [S]

The relation, measured across the supervisor's whole operation catalog: [S]

So for the large majority the opcode does identify the operation. The exceptions divide into two kinds, and both are worth knowing.

Kind one: the opcode encodes a parameter. These families are enumerations of one operation, not lists of separate operations:

This is the practical reading of §9.5's catalog: whole runs of consecutive opcodes are one operation with a dial on it. 0x0220, one of the busiest opcodes in any capture, is not "the read opcode" — it is point log with the filter set to value, and 0x0221–0x022C are the same operation asking for points in alarm, failed points, disabled points, points of a given type, and so on. A decoder that treats the run as an enumeration recovers the operand for free.

Which operands live traffic actually uses

Knowing the enumeration exists is half of it; the other half is which values a working supervisor sends. Counting only frames a supervisor originated — research tooling generates enumerations at a rate no supervisor does, and including it would skew exactly this measurement — 18.6% of supervisor request frames carry an opcode-encoded operand (18,520 of 99,752), and the distribution is lopsided: [W]

Three things an implementer can take from this. Uploads in practice are whole-class re-reads, not incremental sync — the added/deleted phases exist and are used, but as a thin live tail against a bulk baseline, which matches what §5.3 describes for replication. COV subscribe and unsubscribe arrive in near-equal numbers, so a panel implementation must expect subscriptions to churn rather than accumulate. And of point log's thirteen filters, only value was ever observed — the other twelve are a defined but unexercised surface, which is worth knowing both for a decoder (do not expect them) and for anyone assessing what a panel will answer that nobody normally asks.

Kind two: a tunnel. 0x0313 AP2_P1_ROUTE is emitted by 16 distinct operations — a P1 pass-through, TEC point and revision reads, and the whole unitary-controller upload/define set including its time-set and trace-clear. Sixteen operations, sixteen command classes, one shared encoder: the wire opcode does not name the operation because its job is to say route this onto P1. The operation is inside the payload. 0x0314 AP2_P1_LINETEST pairs with it and is shared by two. 0x0136 AP2_P2_ROUTE is the same idea for the panel-local serial link of §6.8. [S]

For a dissector: labelling a frame from its AP2 opcode alone is right for the great majority, wrong for 0x0313 in particular — where it collapses sixteen operations into one name — and incomplete for the enumerated families, where the opcode also carries a parameter the label should mention.

How much of this to trust. The structure above is read out of the supervisor's own dispatch and encoders: each operation reaches a command class, and that class's request encoder writes the opcodes listed for it. The value, the class and the opcode all come from one path, so the pairing cannot drift — an earlier version of this section relied on a mapping that paired two separately collected lists and was displaced by one entry, which is why it reported eight many-to-one opcodes and fifteen operations on 0x0313. Cross-checks: 86 of the 125 wire-attested opcodes in the corpus are accounted for here, and when the operation names are deliberately shifted by one entry the agreement between operation names and opcode names collapses eightfold. Where a derived name still disagrees with what a panel was observed to do, the observed behaviour wins. [S]

The second selector exists - and never reaches the wire

The command object carries a second 16-bit selector beside the opcode: the AP2 function code sits at object offset +0x04 and this value at +0x06, and it is tempting to call it a sub-opcode and go looking for it in the body.

It is the CPI function code — the middle tier of the model above. The supervisor's accessors settle it: one reads the halfword at +0x04 and is named for the AP2 function code, the next reads the halfword at +0x06 and is named for the CPI function code. The two identifiers of a command sit four bytes apart in the same object, which is also why a command can be built either from a CPI code or by parsing a wire frame — the supervisor has a factory for each direction. [S]

And it is not in the body. Nine operations with a known selector value were checked against their captured request bodies - 0x0271 (0x0010), 0x0273 (0x0011), 0x0272 (0x0012), 0x0241 (0x0030), 0x0294 (0x0704), 0x0295 (0x0702) among them. In none of them does the value appear anywhere in the request body; the single apparent hit was a TLV length header matching by coincidence. The field is internal to the sender and is dropped before framing. [W][S]

That is a more interesting result than a sub-opcode would have been, because of what it implies for the many-to-one opcodes above. The receiving panel does not get the selector either. Where several operations share one wire opcode the panel cannot be distinguishing them by a discriminator field - it must be dispatching on the shape and content of the body itself, or the operations are genuinely identical from the panel's point of view and differ only in how the supervisor handles the reply. For 0x0313 that fits the tunnel reading: the panel forwards to P1 and does not care which supervisor operation asked. [W/I]

An implementer should therefore not go looking for a hidden selector byte on the wire. There is not one.

The message-structure catalog, and three command shapes

The supervisor's own symbol vocabulary names 505 structures on a strict convention: an operation contributes <OPERATION>_REQ (343 of them) and, where it answers with data, <OPERATION>_RESP (158), with shared field groups as <NAME>_TYPE (4) — 343 + 158 + 4 = 505. Only the 343 are requests; the read/write split below is taken over those, which is why it counts 343 and not 505. That is a second, coarser view of the same surface the type-system catalog of §10.1 describes in 1,144 structures; the two use different suffixes because they come from different layers of the stack, and neither count contradicts the other. The names track the families of §9.4 exactly - ALARM_ACK_REQ/_RESP, ANNUNCIATE_COV_REQ, BACKUP_FLASH_DBASE_REQ, BACNET_MGT_READ_BBMD_REQ/ _RESP, ADD_CONTROLLER_REQ. [S]

Every operation is wrapped in one of exactly three command shapes, and the shape is declared rather than inferred: [S]

This is worth more to an implementer than the name convention, because it answers a question you otherwise have to discover by sending: will this operation come back with data? For 189 of 340 the answer is no, and a client that waits for a body will wait forever. The four response-only structures are the counterpart - messages a panel emits with nothing having asked, which is the same category as the COV and alarm notifications of §12 and §13.

A rough read/write split falls out of the verb the operation name starts or ends with. Of 343 request structures, roughly 112 are unambiguously reads (REPORT 63, UPLOAD 61, READ, GET, ENUM, LOOK, DISPLAY, QUERY), 170 are writes (DEFINE 38, DELETE, ADD, REMOVE, REPLACE, SET, MODIFY, CLEAR, RESET, INITIALIZE, COLDSTART), 23 are notifications (POST 21, ANNUNCIATE), and 38 resist classification by name alone (PASS_THROUGH, NET_MGT, CHARACTERIZE, OSTRACIZE_NODE, LON_WINK and similar). [S/I]

Do not turn that split into a safety allowlist. The verb classification is a property of the operation name; a tool needs the wire opcode, and the name-to-opcode binding is exactly the layer shown unreliable above. A classification that is 90% right is worse than none when the 10% contains a write. Safety allowlists in this project are built per-opcode from observed behaviour, and should stay that way.

9.2 Naming, families, and value layout

Opcode names follow the form AP2_<FAMILY>_<operation>. The value space is grouped: contiguous blocks share a family and an operation-style suffix vocabulary that recurs across families:

• _LOG / _DISPLAY / _LOOK / _QUERY_* — reads (return data, no state change).
• _ADD / _REMOVE / _MODIFY / _COPY / _REPLACE / _DELETE — definition / configuration writes.
• _CMD_* — runtime command (commands a live point or object).
• _ENABLE / _DISABLE — toggle.
• UPL_ALL_* / UPL_ADDED_* / UPL_DEL_* — the three-phase upload (bulk read of a whole object class / incremental adds / incremental deletes) used for supervisor↔panel database synchronization.
• DBCHANGE_* — database-change notification (panel tells the supervisor a class changed).

The high byte of the opcode tracks the family band, and it does so structurally rather than descriptively: the supervisor's AP2 command factory selects which command subclass to build by switching on opcode & 0xFF00 — 0x0000, 0x0100, 0x0200, 0x0300, 0x0600, 0x0E00 and the higher bands each take their own branch. So the band is a real classification in the implementation and not merely a pattern noticed after the fact. [S] The bands: 0x00xx node/cabinet/license, 0x02xx point and COV, 0x03xx session/database/user/EMS/ENVELOPE, 0x04xx enum/alarm/calendar/language, 0x09xx upload + DBCHANGE, 0x28xx/0x38xx RACS, 0x40xx team/PPCL/program, 0x42xx TEC/UC, 0x43xx–0x44xx LON, 0x46xx EBLN + session keepalive, 0x48xx–0x4Bxx BACnet integration, 0x50xx EQS, 0x53xx I/O-module / FLN-topology / flash / HOA, 0x70xx web. The catalog (§9.5) is grouped by these families and sorted by value within each.

9.3 Destructive and sensitive operations

A subset of opcodes mutate panel firmware state, node-table membership, point values, or device configuration. These are flagged DESTRUCTIVE in the catalog and must be blocklisted in any read-only scanner or bridge (refuse to emit, even behind a flag). They are documented here for completeness; this is a reference, not an exploitation aid, and no attack code is given. [S/W]

Panel lifecycle (reboot / firmware). AP2_CABINET_COLDSTART (0x010A) and AP2_CABINET_WARMSTART (0x010B) reboot the panel; AP2_CABINET_BOOT_MONITOR (0x0108) drops it to the boot monitor. Correction of record: 0x010A is the cold-start (reboot) command — not a benign "GetRevString sibling" as an earlier behavioral reading guessed; the firmware-revision string read is AP2_CABINET_DISPLAY (0x010C, §10.5). The cold-start display/history operations are distinct from the restart commands: AP2_CABINET_COLDSTART_DISPLAY (0x012A) is read-only, while AP2_CABINET_COLDSTART_CLEAR_HISTORY (0x012B) clears the cold-start history and is therefore state-changing (flag it; not read-only). [S]

Node-table / cabinet membership. AP2_CABINET_ADD (0x0041), AP2_CABINET_REMOVE (0x0042), AP2_CABINET_ONLINE (0x0046), AP2_CABINET_OFFLINE (0x0047), AP2_SET_NODE_STATE (0x0034), AP2_SET_COMPLETE_NODE_STATE (0x0035). These add, remove, force-online, force-offline, and evict a cabinet's node-table membership; the eviction case force-removes a peer from the logical BLN (a node-eviction denial-of-service mechanism). Adding/removing entries here is the same node-table surface that registration touches (see §5 addressing and the registration-vs-impersonation footprint asymmetry). [S][I]

EBLN panel reconfiguration. AP2_EBLN_FP_NAME_SET (0x4620), AP2_EBLN_FP_IP_CONFIGURE (0x4621), AP2_EBLN_FP_SITE_NAME_SET (0x462A), AP2_EBLN_FP_BLN_NAME_SET (0x462B), AP2_EBLN_FP_MULTICAST_CONFIGURE (0x462C), AP2_EBLN_HOSTTABLE_ENTRY_ADD/REMOVE (0x462D/0x462E), AP2_EBLN_MAC_ADDRESS_SET (0x4638), AP2_EBLN_TELNET_ENABLE/DISABLE (0x4644/0x4645). These rewrite the panel's network identity (IP, MAC, names) and management surface. [S]

Point command (write). AP2_POINT_CMD_VALUE (0x0240) and AP2_POINT_CMD_PRIORITY (0x0241) command a live point's value/priority — the primary actuation write path (§10.3). High wire volume (32,044 / 101) confirms these as the routine supervisor write opcodes. The full AP2_POINT_CMD_* band (0x0240–0x024E) includes alarm-state forcing, limit setting, totalizer/trouble commands, and RELEASE. [W]

Database / flash / memory / license / COLBAS. AP2_RESTORE_FLASH_DBASE (0x5331, overwrites the panel flash DB), AP2_CLEAR_FLASH_DBASE (0x5332, erases it), AP2_CABINET_MEMORY_MODIFY (0x012F, direct memory write), AP2_LICENSE_MANAGER_DELETE/DELETE_ALL (0x0111/0x0112), AP2_COLBAS_WRITE/ABORT (0x4A03/0x4A04). AP2_BACKUP_FLASH_DBASE (0x5330) is a read/export and is not destructive. [S]

Correction of record (COV pair). AP2_COV_ENABLE (0x0271) and AP2_COV_DISABLE (0x0273) are the change-of-value subscription enable/disable pair — not "ReadExtended"/"PointExistenceProbe" as an earlier behavioral reading labeled them. AP2_COV_ANNUNCIATE (0x0274) is the actual COV report (the highest-volume opcode in the corpus, 53,101 request frames under the §9.5 criteria), and AP2_COV_DELETE_STUB (0x0272) tears down a subscription stub. These are not destructive but are corrected here because the wrong names propagated into earlier notes. [W][S]

9.4 Family overview

• NODE/STATE (0x0030–0x0035, 0x5301/0x5304, logger-state) — BLN global data get/set, remote node check, node-state get/set, FLN/MEC-expansion topology query. The destructive members are the set-node-state pair.
• CABINET (0x003E–0x0131, plus report-descriptor) — per-panel identity, lifecycle, and link configuration: timeouts, add/remove/online/offline, boot-monitor/cold/warm start, CABINET_DISPLAY (the firmware/identity block, §10.5), per-link baud setters (MMI/FLN1-3/BLN), P-bus and modem state, memory display/modify/available, cold-start history.
• BLN/DIAG (0x005B/0x005C) — BLN diagnostic counter display and reset.
• LICENSE (0x010F–0x0116) — license manager display/add/delete/db-change/message-send (FlexLM-style feature licensing).
• ROUTING (0x0136, 0x030E, 0x0310) — P2 route, route-object, P-bus poll. Inter-BLN/cross-trunk brokering rides this family (the source of the multi-slot [BLN,dst,BLN,src] routing seen in cross-BLN frames).
• PBUS (0x0140–0x0143) — peripheral-bus module display, diagnostics reset, line test.
• POINT (0x0200–0x0309) — the point lifecycle: typed POINT_ADD_* per L-type, the POINT_LOG_* read family, the POINT_CMD_* command family (writes), modify/look/remove/definition, totalizer enable/disable/display, set-prefix, save. Read core is POINT_LOG_VALUE (0x0220); write core is POINT_CMD_VALUE (0x0240).
• COV (0x0271–0x0275) — change-of-value subscription enable/disable/delete-stub, the annunciate report, and the COV cross-reference display.
• MONITOR (0x0280–0x0282) — name-based monitor add/remove/start (point watch lists).
• TREND (0x0290–0x02A9) — trend setup add/delete/enable/disable, data and definition display, multipoint, copy/modify/look, query families, archive setup/upload, and the trend-event subfamily. Data read is TREND_DATA_DISPLAY (0x0295, §10).
• TOD/TIME (0x0301/0x0302, 0x4500–0x450F) — panel time display/set/software-clock, and the time-of-day scheduling point/command add/remove/enable/disable/display family.
• MISC (0x0303–0x0311) — message send, quick keys, development toggle, print-error.
• SESSION (0x0304/0x0305) — LOGON_CEC / LOGOFF_CEC operator session establish/teardown at the panel exec.
• DATABASE (0x0307/0x0308/0x030B) — whole-database load/save and tape trailer (legacy archive).
• PPCL (0x030A, 0x4100–0x4138) — Powers Process Control Language program editing: add/edit/remove/enable/disable lines, clear trace, program log/search/query/display (incl. unresolved-reference display), modify/copy/setup-modify/look lines, PDL reset/init/display, and the PROGRAM_* wrapper ops. PPCL is the panel's resident control-logic language layered over P2.
• COLBAS (0x030D, 0x4A00–0x4A06) — COLBAS scripting: immediate/connect/disconnect/write/abort/upload. The write/abort members are destructive.
• P1/FLN (0x030F–0x0317, 0x4230–0x4232) — Protocol-I fieldbus operations: P1 poll/route/line-test/reset-counters, FLN scan enable/disable, P1 diagnostics log. P1 is the fieldbus tier below P2 (§3.8).
• ENVELOPE (0x0316, 0x031B–0x0320) — message-envelope open/close for destination, text, and user lists (alarm/report routing envelopes).
• LOGGER (0x0325/0x0327) — event-logger and buffer-alarm setup.
• USER/ACCESS (0x0330–0x0358) — user-account log/display/add/modify/copy/delete/look and db get/replace; access-group log/modify/db get/replace. The operator-credential database.
• EMS (0x0360–0x0368) — Energy Management System dial enable/disable, db replace/get/display, entry replace, dial-flags / destinations get, print.
• ENUM (0x0401–0x040E) — enumeration-type and enumeration-element add/delete/modify/display/look/log and db get/replace. Backs LENUM multistate text tables.
• ALARM (0x0500–0x056A) — alarm setup add/remove/copy/modify/display, alarm point query lists, alarm ack (+ pending query), the alarm-mode subfamily (mode add/copy/list-by-*/definition/modify/query/delete), the category subfamily (0x0540–0x054D: add/remove/descriptor/dial+print enable/disable/db-get/log/nodes-append/nodes-remove/query/default-db-get/replace), and the alarm-message subfamily (0x0560–0x056A: look/enable/disable/delete/copy/add/query/log/modify).
• CAL/DST (0x0600–0x0615) — calendar date/db add/reset/display/get (holiday spec + other), and daylight-saving year/db add/delete/display/get.
• LANGUAGE (0x0900–0x0902) — localized string/prompt get and report-data (the multilingual UI string service).
• UPL (0x0950–0x09C3, 0x4131–0x4133) — the bulk upload engine: DOWNLOAD_ME, and per-object-class UPL_DEL_* / UPL_ADDED_* / UPL_ALL_* triplets for point, alarm-setup, alarm-mode, trend, PPCL, TEC, EQS (zone/cmd-table/mode-sched/override), loop, alarm-message, SSTO (general/start/stop/night), port, partner, UC, TOD point/cmd, LON, command/miscdata report, MSTP-device, and program. This is how a supervisor pulls a panel's whole configured database.
• DBCHANGE (0x0951–0x09C0, 0x4130, 0x5356) — the panel→supervisor change-notification mirror of the upload classes (point, alarm, trend, PPCL, controller, EQS, SSTO, port, partner, UC, TOD, LON, reports, MSTP-device, program, HOA-map).

How the 0x09xx bank is organised, and why the opcode is not a simple sum. The bank is one object-class list crossed with a small set of transfer operations, and a supervisor selects an opcode from a triple: the database section (point, alarm-setup, alarm-mode, trend, PPCL, TEC, EQS zone / cmd / mode / override, SSTO general / start / stop / night, TOD point / cmd, LON, program, terminal-def, reports, MSTP-device, BACnet schedule / change, …), the transfer direction and scope (download-all, download-changes, upload-all, upload-changes), and the record state (added, deleted, modified). The last of those maps straight onto the wire families — added ↔ UPL_ADDED_*, deleted ↔ UPL_DEL_*, modified ↔ DBCHANGE_* — over the section list. [S][D]

That is worth stating because the obvious shortcut does not work: the section list and the opcode bank are independently ordered, so an opcode cannot be computed as a base plus a section index. The correspondence holds for the first few classes and then breaks. Dispatch on the opcode, never on an arithmetic relationship to a section number. [S] - RACS (0x2824, 0x3800–0x382A) — Remote Access / Communication System partner, port, and system add/copy/delete/disable/display/enable/log/look/modify/statlog (dial-up / WAN inter-site connectivity management). - TEAM (0x4000–0x4018) — point-team / application descriptor and member operations: team-desc and member-desc add (analog/digital/enum/LPACI/L2SL), team/member/report log/list, descriptor uploads and db-changes. A "point team" is a logical point whose default member is the logical point value (see §11 point model). - TEC (0x4200–0x4225) — Terminal Equipment Controller (FLN device) operations: controller/TEC log/add/copy/modify/remove/look/query/definition, member/report log, and the local/remote init-value log/set/restore/initialize/update family (TEC application init values). - UC (0x4241–0x4249) — Unitary Controller add/remove/look/member-log. - LON (0x4300–0x4452) — LonWorks integration: device log/add/modify/remove, member/report log, init-value family, diagnostics, send-service-pin, get/set-domain, request-wink, status-clear, agent db export/import, peak-db-clear. - EBLN (0x461F–0x464C) — Ethernet-BLN management: field-panel names display, name/IP/TCP-ports/site/BLN/multicast/MAC set/configure, host-table add/remove/display, trunk-settings replace/display, the replication subfamily (notify/pull/pull-more/changes/diag-nodelist), point-location-get, MII configure/display, IP/ports/multicast/MAC display, telnet enable/disable, and EBLN_PING (0x4640) — the session-establish/keepalive opcode (see §9.6 and §10.6). - WEB (0x465D, 0x700C) — embedded web-server and ApogeeEdit get-state. - BACNET (0x4821–0x4B03) — BACnet-side integration carried over P2: BBMD add/remove/display, object-id log, application-priority and device-name replace/remove/display, COV-table, BACnet trend-log, MSTP-device (BNMSTP) family, and BNEEO. This is the BACnet bridge configuration surface, distinct from the native P2 point model. - EQS (0x5000–0x5054) — Equipment Scheduling: zone, command-table, mode-entry, and override add/modify/remove/look/enable/disable; display variants; zone log; and the SSTO (Start-Stop Time Optimization) setup/look/display/reset/enable/disable subfamily. - IO (0x5300/0x5303/0x5305) — global and local I/O-module display (incl. MEC expansion bus). - FLASH (0x5330–0x5332) — flash-database backup (read), restore (overwrite), clear (erase). - HOA (0x5351/0x5354/0x5355) — Hand-Off-Auto map modify/look/add (physical HOA-switch mapping).

9.4.1 Which of these does a panel actually implement?

The catalog that follows joins a supervisor-side enumeration with a wire census. Both are one-sided. The enumeration says what a supervisor knows how to ask; the census says what one particular supervisor happened to ask during the captures. Neither answers the question an implementer actually has, which is whether a controller will do anything with a given function code.

There is a third source, and it sits on the other end of the wire. Controller firmware images carry tables pairing a 16-bit function code with a 16-bit id, laid out as 4-byte records:

  00 c1 02 20     id 0x00c1  <-  opcode 0x0220
  00 c1 02 29     id 0x00c1  <-  opcode 0x0229
  00 a1 02 73     id 0x00a1  <-  opcode 0x0273
  00 b4 05 47     id 0x00b4  <-  opcode 0x0547

The same table is present in images built for two different instruction sets — 68000-family and PowerPC — at the same size and with the same contents. That is what identifies it as protocol data rather than compiled code. [F]

What the id is for. An earlier reading of this section called these dispatch tables. Disassembly shows otherwise, and the difference matters. The lookup result is not a jump target: it is handed to a two-byte write against a serialisation buffer object — one carrying a base pointer, a write cursor, a capacity and an overflow flag — which memcpys it and advances the cursor. The id is emitted into an outgoing message. A miss yields -1, which is a sentinel a translator writes, not an index a dispatcher could use.

So the panel converts a wire opcode into some other number and emits it. Two questions follow — whether that number reaches the wire, and what it is — and both are now answered.

It does not reach the wire. Every trusted request frame in the capture corpus whose opcode has a mapping was searched for its own id as a 16-bit big-endian value at every body offset, against a shuffled-pairing control: 83,771 frames, 69 opcodes, 3 real hits against 2 control. Repeating it on the panel's replies — paired back to their request by sequence number, since a response carries no opcode — gives 83,876 pairs, 72 opcodes, 1 real hit against 315 control. The real mapping scored worse than its own control. Whatever the panel writes the number into, it is not a P2 frame. [W]

Coverage, since a negative is only as good as its denominator. The corpus holds 764 capture files, 271 distinct by content, of which 121 carry P2 and hold 621,268 trusted frames between them — and all 121 were in scope, 100% of frames. Both ports are represented: 432,368 frames on 5033 and 188,900 on 5034, so the result is not an artifact of testing only the supervisor-facing channel. [W]

It is a two-stage internal operation number. The default table maps an opcode to a group; where the group needs finer resolution, that group has its own table mapping the same opcodes to an ordinal. The group id and the second table's selector are the same value, which is why the eight selectors are themselves ids in the default table. 0xB6 is the plainest case — the default assigns it to nine CABINET_SET_* opcodes, and table 0xB6 numbers exactly those nine 1…11:

0x0120 SET_MMI1_BAUDRATE -> 1     0x0126 SET_BLN_BAUDRATE -> 6
0x0121 SET_MMI2_BAUDRATE -> 2     0x0128 SET_BLN_ADDRESS  -> 7
0x0123 SET_FLN1_BAUDRATE -> 3     0x0129 SET_MODEM_STATE  -> 8, 9
0x0124 SET_FLN2_BAUDRATE -> 4     0x0127 SET_PBUS_STATE   -> 10, 11
0x0125 SET_FLN3_BAUDRATE -> 5

Seven of the eight group tables hold only opcodes the default assigns that group. Group 0xC1 is the catch-all — 144 of 317 opcodes, across every family — and needs no second stage; 61 groups contain a single opcode each, skewed toward the specific and destructive (SET_NODE_STATE, CABINET_ADD/REMOVE, CABINET_COLDSTART, CABINET_MEMORY_MODIFY, the point limit and totaliser commands). [F]

The translation runs both ways, and the duplicates are a parameter. A second function decodes: it reads a group byte, reads a 16-bit ordinal, and scans the same table the other way — matching the ordinal and returning the opcode. Which means the ordinal is genuinely deserialised from a link, even though §9.4.1's wire tests rule out that link being P2.

The decode path also explains the duplicates. 0x0129 SET_MODEM_STATE occupies ordinals 8 and 9, 0x0127 SET_PBUS_STATE occupies 10 and 11, and decoding ordinal 8 or 10 — the first of each pair — sets a flag byte on the constructed operation that decoding 9 or 11 leaves clear. The duplicate ordinal carries the on/off argument, rather than the body carrying it. The encoder's first-match scan always produces the flag-set form; the second form exists for the decoder. So a group's ordinals are dense and small because they enumerate operation variants, not opcodes. [F]

Add and copy share an ordinal. Only two groups reuse an ordinal across different opcodes, and the pattern is the same each time — ALARM_MODE_ADD with ALARM_MODE_COPY, ALARM_SETUP with ALARM_SETUP_COPY, ALARM_MESSAGE_ADD with ALARM_MESSAGE_COPY. The encoding cannot tell an add from its copy variant, which is consistent with copy being "add, with a source" and distinguished by the body — the same conclusion this section reaches from the other direction. [F]

A panel-only opcode band: 0x1002–0x1005

One group pairs four otherwise-unknown opcodes with named alarm operations at identical ordinals:

These four appear nowhere else — not in the supervisor function-code enumeration, not in any capture, and the whole 0x10xx band is empty in both of those sources. They are known only from controller firmware, which places them as a parallel numbering of the alarm setup/remove and alarm-mode add/delete operations. Stated at the confidence the evidence supports: grouped with, not identical to — a shared ordinal shows the decoder treats them as the same variant, which is weaker than shared semantics. A tool should not emit them: nothing has been observed accepting one. [F]

Why this matters to an implementer, given it is never transmitted. §9.1.1 records the supervisor carrying a second 16-bit selector per operation that likewise appears in no captured body. Both ends of the wire maintain a sub-operation number, and neither serialises it. So where several operations share one wire opcode, a receiver is not reading a sub-code off the frame — it is dispatching on the body. Build a decoder the same way: key on (opcode, body shape), never on a sub-field that is not there. [W][F]

There is more than one table, and a class code selects between them. The firmware stores each table's length in a 16-bit word immediately after it, so the layout is exact rather than inferred — in one image, ten tables laid end to end, 513 records in total, each stored count matching its span:

The selector comes from a method on the calling object, and the default table applies when no group-specific one matches. [F]

Presence in these tables says the panel firmware knows the function code and carries a translation for it. It does not by itself prove the panel implements the operation — for that, §9.5's rule still holds: classify by what the panel did when asked.

Across 42 images spanning firmware revisions 1.3 to 2.6 and the MEC, MBC, FLN, SV5, PPC, LON and MECF product lines, 164 function codes appear both in a panel's opcode tables (in at least 28 of the 42 images) and in the supervisor enumeration. For sets of that size drawn from a 16-bit space, chance overlap would be about 2.5. Those 164 are the subset of the catalog that is confirmed implemented at both ends. [F][S]

A caution on reading the tables directly. The blob holds several adjacent sub-tables that do not share a 4-byte phase, and its tail reverses the field order to (code, handler). An extractor that assumes one layout will mis-split a minority of records. This is why the count above is stated as the intersection with an independent source rather than as a raw table read: 234 further codes appear in the firmware tables alone, and those are candidates, not findings.

The supervisor vocabulary has real gaps, and the firmware measures them

Correction. An earlier edition of this subsection asserted that seven function codes seen on the wire — 0x0203, 0x0204, 0x0260, 0x0274, 0x0508, 0x4500, 0x5038 — were missing from the supervisor enumeration, and rested its argument on 0x0274, the COV value push. That is wrong. All seven are defined in the enumeration, and §9.5's catalog, which is generated by joining that enumeration with the census, names every one of them — | 0x0274 | AP2_COV_ANNUNCIATE | …. The two sections contradicted each other. The conclusion below is unchanged, but it needed different evidence, and the correct evidence is considerably stronger.

Resolving every opcode value known from any source across the three independent authorities — the supervisor's AP2_Function_Code enumeration (630 values under 641 names, eleven of which are aliases), the ten count-validated panel-firmware dispatch tables of one image, and the wire census: [W][S][F]

Three things follow, and the middle one is the point:

82 opcodes are in the panel firmware and not in the supervisor enumeration. That is the measured width of the gap. The panel's vocabulary is not a subset of the supervisor's; a name list derived from supervisor binaries is a list of what a supervisor knows how to ask for, and it is 82 codes short of what this panel image knows how to answer. This is the concrete form of the rule in §9.5: classify an operation by what the panel did with it, never by its absence from a derived name list.

Fifteen wire values are in neither authority — and the panel answered eight of them with structured success responses (§9.5). They are absent from the enum and from this image's tables, which is exactly what one expects when the captured panel and the disassembled image are different devices.

No opcode is in the firmware tables and on the wire but missing from the enum. Where the panel image and the wire agree that an operation exists, the enumeration knows about it. The enumeration is incomplete as a specification, but it is not arbitrary.

One scope note that applies to all three: the firmware column is a single image. An opcode absent from it may well be present in another panel generation, so "firmware only" and "wire only" are statements about this image, not about APOGEE panels in general. [F]

The high bands are a later protocol generation

Coverage by the firmware tables splits sharply by the function code's high byte:

That is not a gap in the extraction. These images are revision 2.6 and earlier; the absent bands are present in the newer supervisor stack and are answered by current panels on the wire. The 0x46xx, 0x48xx and 0x50xx families are a later addition to the protocol. [F][W]

For the unnamed 0x4646–0x4650 block this settles one question and reframes another: these images cannot name it, and its absence from them is evidence of the block's age rather than of its non-existence.

9.5 The catalog

The catalog below is generated by joining the vendor AP2_Function_Code enum (the 630 distinct opcode values) with the corpus census. A recount under stated criteria — trusted frames only, dir == 0x00 only, content-deduplicated captures — gives 150 distinct opcode values across 314,273 request/push frames, of which 135 carry a name from the enum. Two of the 150 are not operations at all (below), so 148 distinct operations have been observed. (Three further values appear only in frames the parser marked untrusted after a resynchronisation: 0x0631, 0x1826, 0x2226. 0x1826 is precisely the fictitious opcode a mid-record resync manufactures — a TLV length 0x18 followed by ASCII & — and is the reason the trusted flag exists. Editions of this document have cited 135, then 125, then 127; each was the honest count over the corpus held at the time, and the corpus has twice grown. The current figure is reproducible from the stated criteria by re-running the census.) Columns: hex opcode, name(s), observed wire count (or -), notes (destructive flag where applicable), and evidence tag ([W] wire-observed, [S] enum-defined). Within each family, rows are sorted by opcode value. Fifteen wire values do not appear in the catalog, because the enum does not define them, and they fall into three groups rather than one. Four are artifacts. 0x0C44 and 0x4443 are slot-walk misalignments of 0x4640; 0x0000 and 0xFFFF are the opcode field of a deliberately malformed test frame whose routing slots read GARBAGEBLN / garbagenode / GARBAGE15CHARSXX, sent once each to probe the handshake gate and never answered. Neither is an operation, and a reader reproducing the census should expect to see them and discard them. [W] One is unimplemented: 0x0510 drew not_found. [W] The remaining ten — 0x4641, 0x4642, 0x4643, 0x4647, 0x464A, 0x464B, 0x464D, 0x464E, 0x464F, 0x4650 — are real panel operations, and an earlier reading of this document that dismissed them as noise is withdrawn. Absence from AP2_Function_Code proves nothing: that enum is the supervisor-side vocabulary and does not describe what a panel implements. Classify by what the panel did. 0x464A–0x4650 each answered dir=0x01 success with distinct structured bodies (0 B, 22 B, 125 B, a 12,073-byte declared node table, 117 B, 26 B, 217 B respectively), and 0x4641 answered success, while 0x0510 — equally absent from the enum — answered not_found from the same panel in the same campaign. The 0x464D reply is the sharpest case and needs stating precisely: the panel answered, and its response header declared 12,073 bytes of node table, of which 4,380 arrived before the client reset the connection. No complete frame exists, so a strict framer reports the exchange as unanswered — it was not. A panel that begins streaming 12 KB of structured node table for one value and answers not_found to another is not treating them alike. 0x4642/0x4643 answered not_supported, i.e. a handler was reached and refused; 0x4647 returned nothing at all and remains [OPEN]. Low frame count is not evidence of unreality — it measures how often the supervisor uses an operation, and a panel-side operation the supervisor never invokes is expected to appear exactly once, when probed. [W]

Family: NODE/STATE

Family: CABINET

Family: BLN/DIAG

Family: LICENSE

Family: ROUTING

Family: PBUS

Family: POINT

Family: COV

Family: MONITOR

Family: TREND

Family: TOD/TIME

Family: MISC

Family: SESSION

Family: DATABASE

Family: PPCL

Family: COLBAS

Family: P1/FLN

Family: ENVELOPE

Family: LOGGER

Family: USER/ACCESS