Internet of Things (IoT) and Industrial IoT (IIoT)

 View Only
  • 1.  Zigbee addressing support question

    Posted Jan 14, 2022 08:53 AM
    Edited by sdemets Jan 14, 2022 11:20 AM
    Hi,

    I'm running an AP-505 in IAP setup with AOS 8.9.0.1.
    I've created an IoT setup with IKEA buttons over the internal Zigbee radio and it works using the Zigbee Socket Device (ZSD) method and a websocket-telemetry transport profile.
    For the IKEA Styrbar button I've created the following Zigbee socket-profile:
    inbound 1 1 0104 6
    inbound 1 1 0104 8
    inbound 1 1 0104 5
    And this gives me the appropriate responses on my server (node-red with a websocket input node and a protobuf decoder node using the AOS 8.9 .proto files from ASP) when I press the on/off and left/right buttons.

    However, when I try the same with the (older and cheaper) IKEA Trådfri, I get no response at all from the on/off buttons.
    After sniffing traffic from both buttons, I see the difference is in the Application Support sublayer (APS) delivery mode. The Styrbar uses destination endpoint addressing, while the Trådfri uses group addressing.
    As far as I can tell, there is no way to define a group address as destination in the Zigbee socket-profile.

    Is there any other way to get the AP to take in the Zigbee message and send it to my server?

    Following is a capture of one APS packet from both buttons. The differences are in bold.

    Styrbar (working):
    ZigBee Application Support Layer Data, Dst Endpt: 1, Src Endpt: 1
        Frame Control Field: Data (0x00)
            .... ..00 = Frame Type: Data (0x0)
            .... 00.. = Delivery Mode: Unicast (0x0)
            ..0. .... = Security: False
            .0.. .... = Acknowledgement Request: False
            0... .... = Extended Header: False
        Destination Endpoint: 1
        Cluster: On/Off (0x0006)
        Profile: Home Automation (0x0104)
        Source Endpoint: 1
        Counter: 139

    Trådfri (not working):
    ZigBee Application Support Layer Data, Group: 0x0000, Src Endpt: 1
        Frame Control Field: Data (0x0c)
            .... ..00 = Frame Type: Data (0x0)
            .... 11.. = Delivery Mode: Group (0x3)
            ..0. .... = Security: False
            .0.. .... = Acknowledgement Request: False
            0... .... = Extended Header: False
        Group: 0x0000
        Cluster: On/Off (0x0006)
        Profile: Home Automation (0x0104)
        Source Endpoint: 1
        Counter: 197
    Thanks for any advice/help,

    ------------------------------
    Steven Demets
    ------------------------------


  • 2.  RE: Zigbee addressing support question

    Posted Jan 14, 2022 10:56 AM
    Steven,

    Cool that you tried to set this up and got to this point already. I wasn't even aware that this would work with Nodered; and didn't hear anyone coming as close as you seem to have got. You may, or may not have found this documentation, which I think is useful. From the captures above, it looks like you create a filter from endpoint 1 to endpoint 1, but the Trådfri is doing a kind of group broadcast, which may not be caught by a filter.

    Did you pair these devices? Or are these just factory-default?

    I probably won't be able to help too much as this is beyond what I have done before.

    ------------------------------
    Herman Robers
    ------------------------
    If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

    In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.
    ------------------------------



  • 3.  RE: Zigbee addressing support question

    Posted Jan 14, 2022 11:19 AM
    Edited by sdemets Jan 14, 2022 11:20 AM
    Hi Herman,

    Thanks for the info.
    The devices are indeed paired with the AP:
    AP505# show ap deb zigbee client-table
    
    Zigbee Client Table
    -------------------
    IEEE Address             Name  NWK Address  Radio Seen               Role  Relationship  RSSI  LQI  Last Update  Uptime
    ------------             ----  -----------  ----------               ----  ------------  ----  ---  -----------  ------
    84:2e:14:ff:fe:76:a6:77  --    b336         20:4c:03:ff:fe:a5:f4:7a  ZED   child         --    --   24218s       6h:43m:39s
    0c:43:14:ff:fe:a0:58:40  --    3d6d         20:4c:03:ff:fe:a5:f4:7a  ZED   child         --    --   24218s       6h:43m:39s
    -----------------
    Total Zigbee client(s):2
    ​

    b336 is the Styrbar, 3d6d is the Tråfri. It takes the Trådfri a very long time to associate, but it manages after about 5 or 6 attempts. I haven't done a deep dive on those traces yet.

    Next step is to get the southbound traffic to work, so I can generate a packet in node-red, protobuf encode it and then see it on my Zigbee sniffer. I've gotten so far as to see the packet arrive on the AP, but then it stops.

    Also, if I look at the incoming protobuf packets from the AP, the MAC adresses and the payload are unencoded. They should be base64 encoded, but that doesn't happen.

    Incoming data from AP after protobuf decode:
    {"radioMac":"IEwD//6l9Ho=",
     "report":{
       "mac":"hC4U//52pnc=",
       "e2pc":{
         "destination":{
           "endpoint":1,
           "profileId":260,
           "clusterId":6
         },
         "sourceEndpoint":1
       },
       "payload":"AREB"
     }
    }​

    After manual base64 decoding of the radioMac, mac and payload values in the packet:
    {"radioMac":"204c03fffea5f47a",
     "report":{
       "mac":"842e14fffe76a677",
       "e2pc":{
         "destination":{
           "endpoint":1,
           "profileId":260,
           "clusterId":6
         },
         "sourceEndpoint":1
       },
       "payload":"011101"
     }
    }​

    Could this be a bug? Or am I misunderstanding something?


    Steven

    ------------------------------
    Steven Demets
    ------------------------------



  • 4.  RE: Zigbee addressing support question

    Posted Jan 15, 2022 09:29 AM
    Hi Steven,

    Where are the JSON examples form in you post, from you own server implementation?

    As far as I know the data is not base64 encoded by the Aruba interface itself. But we have a sample server where the examples in the Aruba IoT Websocket Interface Guide come from. This server used base64 encoding for the CLI output and for the HTTPS Post API to generate southbound messages. This might cause confusion. 

    Regards,

    Jens


    ------------------------------
    Jens Fluegel
    ------------------------------



  • 5.  RE: Zigbee addressing support question

    Posted Jan 17, 2022 03:07 AM
    Hi Jens,

    Yes, the first JSON snippet is from my node-red server, right behind the protobuf decode (see image below). The second one is after I run the base64 decode functions I've added later in the flow.


    I use the aruba-8.9-iot-protobuf-spec-AP northbound file for the decoder.

    When I check the incoming protobuf packet (before decoding) the MAC address and payload are received in clear, which according to the protobuf specs shouldn't happen as far as I understand it (according to protobuf documentation). 

    I've only started with the southbound part, but I'll keep you posted if I get it to work.

    Steven

    ------------------------------
    Steven Demets
    ------------------------------



  • 6.  RE: Zigbee addressing support question
    Best Answer

    Posted Jan 15, 2022 09:00 AM

    Hi Steven,

    Wow, great what you have achieved so far using the Aruba IoT ZigBee interface.

    We have done something similar in our Android demo app IoT-Utilities App - ZigBee Demo using Philips Hue lamps.
    But we have been facing the same limitation as you describe with the ZigBee implementation in AOS 8.x. 

    The challenge is that the Aruba API does not expose any ZigBee Device Object (ZDO) services and further more ZDO messages cannot be forwarded via the the Aruba IoT interface to the server (the Zigbee socket device profile only allows endpoint 1-255).

    But ZDO is running on endpoint 0 in every ZigBee device. ZDO, keeps track of the state of the ZigBee device on and off the network and provides an interface to the ZigBee Device Profile (ZDP), a specialized application profile for discovering, configuring, and maintaining ZigBee devices and services on the network.
    On the AP CLI you can use several commands to do ZigBee device discovery and so on but unfortunately not via the API from the server side, a known limitation of the implementation.

    Unfortunately, because of this limitation important functions like BINDING and I also assume GROUP management are not possible because it would require to allow communication via ZDO (via endpoint 0).

    The Aruba ZigBee implementation assumes that ZigBee devices start sending packets to specific addresses after joining the ZigBee network. Unfortunately, this is not always the case.  Therefore only solutions with know communications patterns can be usefully implemented via the Aruba ZigBee implementation.

    Regards,

    Jens



    ------------------------------
    Jens Fluegel
    ------------------------------



  • 7.  RE: Zigbee addressing support question

    Posted Jan 17, 2022 03:23 AM
    Thanks for the explanation, Jens. This could indeed be the cause of why this doesn't work. I do hope they will implement this though.
    By the way in AOS 8.9.0.1, you can only use endpoints 1-254 as 255 is the broadcast endpoint. I see this when I pair a button with the AP, I receive an "Identify" message (ClusterID 3) on the 255 endpoint.
    You don't need to define any socket-device inbound profile to receive this message though, so it doesn't matter that you can't define it.

    Steven

    ------------------------------
    Steven Demets
    ------------------------------



  • 8.  RE: Zigbee addressing support question

    Posted Jan 18, 2022 11:14 AM
    Hi Steven,

    You are right, endpoint 255 can not be configured as source or destination endpoint but if we receive a packet with destination endpoint 255 from Zigbee devices we forward it to any websocket connection that has a matching source endpoint, profile ID and cluster ID in the zigbee socket device profile. 

    Regards,

    Jens

    ------------------------------
    Jens Fluegel
    ------------------------------