[Anonymous]

#40449

I’m attempting to utilize the groups feature of the addressing of the ZigBee protocol through the ZBPServer, but I can’t seem to address the group when sending a ClusterCommand.

I add the group id ‘aaaa’ to a light device, with the following:

Node_ClusterCommand1858d0140[aa,aa]8840

Node_ClusterCommand0884066b0aa33-324f-4a39-a20e-a6e45d9af59f

Node_ClusterCmdRsp3258d01400[00,aa,aa]

The light device seems to report back that it has that group id:

Node_ClusterCommand1858d0142[0]8840

Node_ClusterCommand0884066b0aa33-324f-4a39-a20e-a6e45d9af59f

Node_ClusterCmdRsp3258d01420[07,01,aa,aa]

But when I try to utililze that group id, I get the following:

Node_ClusterCommand17aaaa160[]11163

Node_ClusterCommand21116366b0aa33-324f-4a39-a20e-a6e45d9af59f

What could I be doing wrong?

Thank you,
Johnny Elliott

[Anonymous]

#44420

Use Scenes! Try it with the iSmartenit App first.

[Anonymous]

#44421

@Dhawal wrote:

Use Scenes! Try it with the iSmartenit App first.

u8Mode	- Bits 0:1 - Indicate if DstAddr is 16 bits ShortAddress (0x02), or 16 bits GroupAddress (0x01) 

So, is this unimplemented or does it mean something else?

Thank you,
Johnny

[Anonymous]

#44422

It is definitely implemented. Can you please print the TX and RX debug from ZBPServer? That would help us find the issue.

Additionally, we can try to verify using the RAW Mode:
Example for Sys_Ping.
ZBP_SystemSys_RAWMsg[02,00,00,00,00,FF]100

[Anonymous]

#44423

@Dhawal wrote:

It is definitely implemented. Can you please print the TX and RX debug from ZBPServer? That would help us find the issue.

This:

ZBP_NodeNode_ClusterCommand1858d0142[0]8840

ZBP_NodeNode_ClusterCommand08840b161d611-391d-4e28-bb68-126d9ef9e61fNodeNode_ClusterCmdRsp3258d01420[07,01,aa,ab]

produces:

Oct  2 20:02:14 raspberrypi ZBPServer[3316]: ZBP_packet:: [TX] (00) Cmd: 0030 len: 08 data: 02 00 30 08 12 d4 25 01 00 04 02 00 dc

Oct  2 20:02:14 raspberrypi ZBPServer[3316]: ZBP_packet:: [RX] (00) Cmd: 1030 len: 0b data: 32 d4 25 01 00 04 02 07 01 aa ab CRC: e8

But this:

ZBP_NodeNode_ClusterCommand17aaab160[]11163

ZBP_NodeNode_ClusterCommand211163b161d611-391d-4e28-bb68-126d9ef9e61f

does not produce any output in the zbp.log file.

Additionally, we can try to verify using the RAW Mode:
Example for Sys_Ping.
ZBP_SystemSys_RAWMsg[02,00,00,00,00,FF]100

I’m not familiar with the raw message format, but this is what I can gather:
0:4 – unknown to me
5:6 – address but not in the same format as u16DevAdd, how does 58d0 = d4 25?
7 – endPointID
8:9 – clusterID
11 – command
12: – payload
last byte – crc

[Anonymous]

#44424

To be honest, We haven’t tested the Groups on the GE Light Bulbs. We tested and support the Scenes, which uses Groups for the Broadcast. While I test and reproduce the packets and API, do you mind telling me some details of your application?

[Anonymous]

#44425

From what I gather, it appears that the zbpserver isn’t sending a message out to the zigbee network at all. I’m guessing that the zbpserver verifies against an internal database whether an address valid to send out to the zigbee network, since it seems to return right away with an invalid destination address. I doesn’t seem like it would be an issue with just the GE Light bulbs since it never sends the group broadcast message to the zigbee network. Maybe the zbpserver is not picking up the fact that I’m manually adding a group through clustercmd.

As far as my application, I’m learning the zigbee protocol and that was next on my list to learn. I’ll play around with the scenes next.

[Author]

Posts