This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2530: ZStack 3 Linux Gateway - add support for Coordinator Time Cluster

Part Number: CC2530
I am looking to implement the Zigbee Time cluster on our ZigBee Coordinator, which runs ha-gateway.  In order for this to work, we need to create attributes whose values are determined at the time they are read by a ZED. 

How is this best done? If possible, I would like a solution that works via the protobuf interface, with minimal changes to ha-gateway or its configuration files (unless a more substantial change would make this kind of thing easier via the protobuf interface in the general case).

Thanks!
  • Hi Ryan,

    Please elaborate on the use case:

    How accurate do you need the time to be? (Consider the acceptable error indicated by the Time cluster's LastSetTime and ValidUntilTime attributes.)

    You mention using protobuf. Does this mean you need to read the time at the Gateway Application (vs at the HA Gateway Server)?

    By "general case", do you mean the general case for any attribute whose value is determined (and possibly updated) at the time they are read by a ZED?

    Depending on your use case requirements, this effort may require additions across layers (the Gateway Application, the HA Gateway Server protobuf interface, the HA Gateway Server, and the HA Gateway Server configuration file).

    Regards,

    Toby

  • The ZCL doesn't specify how accurate the time should be, so approx 10min should be acceptable.

    The application does not need to read the time, but it does need to write it (I would assume).  Ideally this would be achievable through a protobuf message.  I guess it is possible to have the HA Gateway Server itself keep the attribute updated.  The ideal way I'd like to implement it involves a trick that always responds to the ZED with the correct time.  Consider a message arrives from a ZED requesting the time, instead of reading a stale value, that request is forwarded to the application which then responds with the current time.  However, I doubt this is how the ZCL intended it to be implemented.

    At this point, I'm willing to consider a variety of solutions.

    Thanks!
    Ryan

  • Have you already tried adding the Time cluster in the gateway_config.tlg? I would do this before trying to add onto the protobuf interface.

    Then you could have the gateway application issue a GW_WRITE_DEVICE_ATTRIBUTE_REQ to initialize the Time cluster attributes with the current time.
    For now, I would recommend trying periodic updates (initiated by the gateway application) to the Time cluster attributes.

    To comply with the application's time accuracy, the application can write to the Time cluster attributes and set ValidUntilTime to Time + 10min.
  • >> Have you already tried adding the Time cluster in the gateway_config.tlg?
    I'm not sure how to. I haven't been able to dig up any meaningful references, but I'm sure I've missed some.
  • You might've read these already, but section 9.2 of the Developer's Guide and section 5.3 of the User's Guide mention it a bit.

    In general, each endpoint requires the following in gateway_config.tlg:
    - endpoint    - a description of an endpoint
    - endpointdef - a simple descriptor
    - clusterlist - list of clusters (for either input or output)
    - attrlist    - a list of attributes
    - attr        - a single attribute (to place in attrlist)

    For example, you could add the Time cluster to the On/Off light endpoint by doing something along the lines of:

    endpoint { 7, OnOffLightEpDef, OnOffAttrList }
    
    endpointdef OnOffEpDef { ha_profile, ha_onofflight, 0, OnOffInputClusters, OnOffOutputClusters }
    
    attrlist OnOffAttrList { OnOffAttr, TimeAttr_Time, TimeAttr_TimeStatus, TimeAttr_LastSetTime, TimeAttr_ValidUntilTime }
    
    clusterlist OnOffOutputClusters { onoff, 0x0402 }
    clusterlist OnOffInputClusters { basic, identify, groups, scenes, onoff, 0x0501, 0x000A } // 0x000A is the Time cluster ID
    
    attr OnOffAttr { onoff, 0, boolean, rdonly }
    
    // Time cluster attributes. eg. { clusterID, attrID, datatype, accessControl }
    attr TimeAttr_Time { 0x000A, 0x0000, uint32, rdwr }
    attr TimeAttr_TimeStatus { 0x000A, 0x0001, uint8, rdwr }
    attr TimeAttr_LastSetTime { 0x000A, 0x0008, uint32, rdonly }
    attr TimeAttr_ValidUntilTime { 0x000A, 0x0009, uint32, rdwr }
    // .. any other Time cluster attributes

    Regards,

    Toby