# Why XBee ZB sends unicast command as broadcast?

**URL:** <https://forums.digi.com/t/why-xbee-zb-sends-unicast-command-as-broadcast/15258>\
**Category:** XBee - Zigbee\
**Tags:** smt, s2c, frame, api, 16-bit\
**Created:** [August 11, 2015, 12:09pm UTC](https://forums.digi.com/t/why-xbee-zb-sends-unicast-command-as-broadcast/15258 "2015-08-11T12:09:44Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![pahanela](https://avatars.discourse-cdn.com/v4/letter/p/ee7513/32.png) [@pahanela](https://forums.digi.com/u/pahanela)\
**Post date:** [August 11, 2015, 12:09pm UTC](https://forums.digi.com/t/why-xbee-zb-sends-unicast-command-as-broadcast/15258/1 "2015-08-11T12:09:44Z")

</div>

I am using XBee ZigBee SMT S2C module.  
Sending 0x11 Explicit Addressing Command Frame as 16-bit unicast and 64-bit broadcast (0x0000000000FFFF):

```auto
7E 00 14 11 01 00 00 00 00 00 00 FF FF 5E 10 01 01 00 01 C0 FB 00 00 C3

```

For some reason I see broadcast message in RF (see captured packet below). Why it is happening?

```auto
[16:08:04.682651]	Power Configuration	41-88-6E-F1-84-FF-FF-00-00-08-10-FF-FF-00-00-1E-90-C1-54-9B-40-00-A2-13-00-08-01-01-00-FB-C0-01-39-2F-91-36-DC-45-55-D4-68-CB-8F-49-3B-BB-81-27-C3-B6-9C-AC-EC-13-AD-06-42-62-FF-FF
Frame Information: (60 bytes)
	Packet Number: 97
	Protocol: ZigBee
	Timestamp: 16:08:04.682651
	Time Delta: 0.831544
	Channel: 15
	Length: 60
	Link Quality: -35 dBm
	Source: USB8621
	Layer: Custom
	Status: Normal
MAC Header: (9 bytes)
	Frame Control: 0x8841
		···· ···· ···· ·001 = Frame Type: [0x1] Data
		···· ···· ···· 0··· = Security Enabled: [0x0] No
		···· ···· ···0 ···· = Frame Pending: [0x0] No
		···· ···· ··0· ···· = Acknowledgement Request: [0x0] No
		···· ···· ·1·· ···· = Intra-PAN: [0x1] Yes
		···· ··00 0··· ···· = Reserved: 0x0
		···· 10·· ···· ···· = Destination Addr Mode: [0x2] 16-bit Short Address
		··00 ···· ···· ···· = Reserved: 0x0
		10·· ···· ···· ···· = Source Addr Mode: [0x2] 16-bit Short Address
	Sequence Number: 110
	Destination PAN ID: 0x84F1
	Destination Address: 0xFFFF
	Source Address: 0x0000
MAC Payload: (49 bytes)
	NWK Header: (16 bytes)
		Frame Control: 0x1008
			···· ···· ···· ··00 = Frame Type: [0x0] Data
			···· ···· ··00 10·· = Protocol Version: 0x2
			···· ···· 00·· ···· = Route Discovery: [0x0] Suppressed
			···· ···0 ···· ···· = Multicast Flag: [0x0] Unicast or Broadcast
			···· ··0· ···· ···· = Security Enabled: [0x0] No
			···· ·0·· ···· ···· = Source Route Included: [0x0] No
			···· 0··· ···· ···· = Destination IEEE Address Included: [0x0] No
			···1 ···· ···· ···· = Source IEEE Address Included: [0x1] Yes
			··0· ···· ···· ···· = Device Initiator: [0x0] No
			00·· ···· ···· ···· = Reserved: 0x0
		Destination Address: 0xFFFF
		Source Address: 0x0000
		Radius: 0x1E
		Sequence Number: 144
		Source IEEE Address: 00:13:A2:00:40:9B:54:C1
	NWK Payload: (33 bytes)
		APS Header: 0x3901C0FB00010108
			Frame Control: 0x08
				···· ··00 = Frame Type: [0x0] Data
				···· 10·· = Delivery Mode: [0x2] Broadcast
				···0 ···· = Acknowledgement Format: 0x0
					Format: [0x0] Data Frame
				··0· ···· = Security Enabled: [0x0] No
				·0·· ···· = Acknowledgement Request: [0x0] No
				0··· ···· = Extended Header Present: [0x0] No
			Destination Endpoint: 0x01
			Cluster ID: [0x0001] General: Power Configuration
			Profile ID: [0xC0FB] Private
			Source Endpoint: 0x01
			APS Counter: 57
		APS Payload: (25 bytes)
			ZCL Header: 0xDC36912F
				Frame Control: 0x2F
					···· ··11 = Frame Type: [0x3] Reserved
					···· ·1·· = Manufacturer Specific: [0x1] Manufacturer Code Included in the ZCL Frame
					···· 1··· = Direction: [0x1] From Server to Client
					···0 ···· = Disable Default Response: [0x0] No
					001· ···· = Reserved: 0x1
				Manufacter Code Field: 0x3691
				Transaction Sequence Number: 220
			ZCL Payload: (21 bytes)
				Private Payload: (21 bytes)
MAC Footer: 0xFFFF
	Frame Check Sequence: 0xFFFF

```

---

<div class="post-metadata">

**Author:** ![mvut](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.digi.com/mvut/32/31_2.png) [@mvut](https://forums.digi.com/u/mvut)\
**Post date:** [August 11, 2015, 3:20pm UTC](https://forums.digi.com/t/why-xbee-zb-sends-unicast-command-as-broadcast/15258/2 "2015-08-11T15:20:34Z")

</div>

That is because a 64 bit address of 0xFFFF is the broadcast address.

---

<div class="post-metadata">

**Author:** ![bogprs](https://avatars.discourse-cdn.com/v4/letter/b/fbc32d/32.png) [@bogprs](https://forums.digi.com/u/bogprs)\
**Post date:** [December 29, 2015, 3:48pm UTC](https://forums.digi.com/t/why-xbee-zb-sends-unicast-command-as-broadcast/15258/3 "2015-12-29T15:48:36Z")

</div>

What should be put to 64-bit address when only 0xFF FF, 0x00 00, and a full address are supported?

Why not 0x FF FE (unknown) is not supported?

---

<div class="post-metadata">

**Author:** ![mvut](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.digi.com/mvut/32/31_2.png) [@mvut](https://forums.digi.com/u/mvut)\
**Post date:** [January 4, 2016, 8:10am UTC](https://forums.digi.com/t/why-xbee-zb-sends-unicast-command-as-broadcast/15258/4 "2016-01-04T08:10:51Z")

</div>

Address 00 00 00 00 00 00 00 00 and FF FF are not the only ones supported. They are just special addresses. The first, 00 00 00 00 00 00 00 00 is indicating the Coordinator of the network where as 00 00 00 00 00 00 FF FF is the broadcast address. Anything else would be the 64 bit MAC address of the node you want to send a Unicast message to.