Skip to content

Support for broadcast endpoint (0xff) #1614

@Nerivec

Description

@Nerivec

0xff is the broadcast endpoint.

Sending with it should bypass all device.getEndpoint, "exist"-type validations and such (e.g) and just use the raw 0xff value. It should also bypass all checks for supported clusters, as this one has no specific cluster attached for obvious reasons.

Receiving with it should map to appropriate clusters on appropriate endpoints.

Need to further investigate the behavior per Zigbee spec to determine the full scope.
Also need to investigate impact on other repos (in particular, Z2M, which is likely preventing use entirely due to non-existing Endpoint).


ZCL R8 spec:

2.3.2.1 Broadcast Endpoint

The device processing a message sent to the broadcast endpoint (0xff) SHALL:

  1. only deliver a copy of the message to the endpoints supporting the cluster indicated in the APS Header.
  2. follow the Default Response command behavior described in section 2.5.12.2 (no response for non-unicast messages).
  3. not generate error response messages, except when required by the Default Response command behavior.

2.3.2.2 Broadcast Endpoint Recommendations

Broadcast Endpoint Behavior Recommendations for Avoiding Network Congestion:

  1. A device SHOULD NOT send a broadcast message to the broadcast endpoint where a response is expected from every active endpoint. It is recommended to use discovery to determine the specific endpoint(s) per device and then send individual messages that target those specific endpoints.
  2. A device processing a message sent to the broadcast endpoint SHOULD jitter messages that are sent in response, especially when the nature of the message is such that it generates many responses (i.e. synchronization message).

NOTE: Multicast group messages do not include an endpoint

Metadata

Metadata

Assignees

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions