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
• 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.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
• 7. Service Model & Message Types
• 7.1 The ASDU service model
• 7.2 Success vs error responses
• 7.3 Connection and session model
• 8. Body Encoding Primitives
• 8.1 The string TLV [W]
• 8.2 Scope tag and command priority [W][S]
• 8.3 Numeric value fields [W][S]
• 8.4 String character encoding — RAD-50 vs ASCII [S][D]
• 8.5 ASDU field convention [S]
• 9. Function-Code (Opcode) Catalog
• 9.1 The AP2 function code
• 9.2 Naming, families, and value layout
• 9.3 Destructive and sensitive operations
• 9.4 Family overview
• 9.5 The catalog
• 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.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 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.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.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
• 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.3 Application catalog (controller applications)
• 16.4 Reading a controller application from a live panel
• 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
• 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. 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] 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). Whether 5034 is a distinct co-installed supervisor product or simply the same supervisor's second listener for that reverse channel is not determinable from traffic alone — either way it is deployment-specific configuration, not a protocol-standard port. [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]

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. On at least one analyzed network it originates entirely from a Ubiquiti/UniFi gateway (gateway source IP and OUI, 4-byte payload, ~10.5 s cadence); 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, 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.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; 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 conceptual identity of a point and the form in which point databases store it. It is not 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]

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]

An implementer targeting a TCP/5033 (EBLN) deployment uses ASCII throughout and may use the full ≤30-character node name; the ≤15 limit applies only to legacy RAD-50 platforms and to fields that retain the packed budget. 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 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]

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 (§ handshake) 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]

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] Serial-BLN P2 link framing bytes. Only the line parameters (8/N/1, baud tiers, trunk numbering) are established for the dedicated serial BLN. The byte-level link framing that carries a P2 logical frame over RS-485 (start/sync delimiting, address byte, CRC/checksum, the medium's segmentation) is not observed in the present evidence and is not specified here. An AEM Channel-1 capture (TCP/3001) would expose these bytes, 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.

[OPEN] 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, so a single frame's total_len is bounded only by the u32 length field (§6.7) [W]. The P2 application layer still carries an explicit more-follows segmentation flag and segment-mapping at the ASDU layer for results large enough to exceed an implementation ceiling [S], but the exact segmentation threshold and the more-follows flag offset/reassembly rules are not pinned on the wire. Needs a multi-segment upload capture for confirmation.

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.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 one of the two highest-frequency opcodes in the capture corpus (second only to the COV value-push 0x0274) — the steady ~10-second per-peer heartbeat, present in the tens of thousands of frames in any multi-hour supervisor capture [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 message classes 0x29/0x2A/0x2E/0x2F/0x33/0x34 and on both observed ports 5033/5034. Its success-response body length is variable — 35 + node-name length (so 40 B for a 5-char name, 41 B for 6, 45 B for 10, 47 B for 12 — all observed); a parser MUST treat the length as variable, not as one of two fixed sizes. Every 0x4640 request in the corpus drew a reply (no no-response outcome was observed on the wire). [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).

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 (every matched 0x4634 response in the capture was empty: the digest request carries the full version vector, the response is just an ack). [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) — also exist and appear in the corpus, but rarely and with empty bodies, and did not fire during captures that contained live DB changes; treat them as the formal mechanism while recognizing that observed record propagation went via the DBCHANGE_*/UPL_ADDED_*/UPL_DEL_* family. [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.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.

[OPEN] Exact replication payload offsets. The replication opcodes (0x4633–0x4636) and their roles are wire-confirmed, but the byte-level layout of the pull-response roster and the changed-records delta (record framing, per-entry fields, the COV/condition block carried in change records) is not fully mapped from the read-only corpus. The vendor ASDU structures (AP2_Ebln_Repl_*) define the field set [S]; confirming the exact on-wire offsets needs a capture of an active add/remove replication event.

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]

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                                reserved (2 bytes)                [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 0x29/0x2A.) [W]

The session / second-channel band. The low-byte values 0x29–0x2F form a session / second-channel band (0x29 peer maintenance carrier, 0x2A peer COV-subscribe 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 (maintenance / COV-subscribe), 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 (maintenance: heartbeat + replication gossip + COV management) and 0x2A (panel↔panel COV subscription) are visible only from a panel-side mirror, never from the supervisor's own vantage. [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 ≈ 262,142; 0x01 ≈ 261,466; 0x05 ≈ 7,103. [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 (01 00 <len>) used inside bodies; the two MUST NOT be conflated. [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; the doubled [BLN, dst, BLN, src] shape reflects an inter-BLN cross-trunk broker in the routing layer. [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 never appears in any slot. 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 9 requests outstanding observed before their responses arrive (9 is a capture-bound maximum, not a protocol limit; treat it as "at least 9"). 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. [W][I]
5. Cache and reuse. The record is stored against the peer and reused for every subsequent frame; it is refreshed only when the peer's firmware identity changes. [I]

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,587 bytes — roughly a 1,530-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 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,587 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 ~1,587 B frame ceiling 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]

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]

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): 121,446 frames in the corpus — 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]

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 9 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.2 Observed wire error codes

These 2-byte codes appear as the dir == 0x05 error tail in the corpus. Distribution across 530,715 P2 frames (7,103 of which are error responses): 0x0003 ≈ 6,860; 0x00AC ≈ 163; 0x0E15 ≈ 40; 0x0002 ≈ 30; 0x0E11 ≈ 6; 0x0E12 ≈ 3; 0x0009 ≈ 1. [W]

[OPEN] The exact code↔class pairing is wire-confirmed only for 0x00AC (not supported). The remaining wire codes (0x0003, 0x0002, 0x0E11, 0x0E12, 0x0E15, 0x0009) are observed as raw 2-byte tails with empirically-derived meanings from the operations that produced them, but are not yet mapped to a specific named AP2 error class from a capture. Pinning the full table requires either a codec-level decode of the error-class→code constants or controlled captures eliciting each class with a known stimulus. [W][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. [W][I]

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]

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 [W]

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]

The tag is the literal prefix 0x01 0x00. The third byte is a one-byte length, and exactly that many content bytes follow. 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 caps at 255 content bytes because the length is one byte. A payload longer than 255 bytes is carried as multiple consecutive TLVs. Standard P2 name fields (point names, node names, BLN names, descriptors) are all well under this cap; only free-text and table dumps approach it. [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 01 00 <n> <n content bytes>, and S() abbreviates the empty placeholder TLV 01 00 00. [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 [W][S]

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

The trailing 3F FF FF FF is a fixed wildcard mask. 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. 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 [W][S]

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] 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 [S][D]

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 packing word is stored in the platform's native word order; 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]

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 [S]

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 other composite blocks (e.g. the per-type value arms of All_points, and the replication change-record framing), the exact interior byte offsets are still [OPEN] pending a labeled capture or codec confirmation; treat byte-offset claims for those as inferred until then.

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 (530,715 P2 frames across 108 captures); 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). 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.

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 loosely tracks the family band: 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, 121,446 frames), 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 (§see topology).
• 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).
• 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.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 (135 wire-observed values, by frame count). 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. The 16 wire values that do not appear here — 0x0000, 0x0002, 0x0453, 0x0510, 0x0C44, 0x4443, 0x4641, 0x4642, 0x4643, 0x4647, 0x464A, 0x464B, 0x464D, 0x464E, 0x464F, 0x4650 — are not real function codes: 0x0000/0x0002 are below the enum's first defined value, 0x0C44/0x4443 are slot-walk misalignments of 0x4640, and the rest are single-shot speculative probe artifacts from active test captures (they resolve to no enum member and should be treated as parser noise, not undocumented operations). [W][S]

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

Family: EMS

Family: ENUM

Family: ALARM

Family: CAL/DST

Family: LANGUAGE

Family: UPL

Family: DBCHANGE

Family: RACS

Family: TEAM

Family: TEC

Family: UC

Family: LON

Family: EBLN

Family: WEB

Family: BACNET

Family: EQS

Family: IO

Family: FLASH

Family: HOA