You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@mrjerryjohns has presented weave event spec in TSG data model team, and received the broad agreement on it. I am working on the initial porting, leverage and prototype for event on CHIP.
Eventing: Motivation
--A way to provide a historical record/log of notable ‘happenings’
--Capture every single ‘edge’ / change
--Send it reliably to interested observers
--Can contain rich metadata
For the existing zcl, there exists 3 gaps
Gap 1: Inconsistent queuing semantics with attribute reporting
--Different queuing constructs observed between ZCL clusters
Gap 2: Lack of meta-model construct to be able to define events
--ZCL today defines in two ways:
Circular ‘tables’ in attributes
‘Notification’ Commands
Need a better construct
Gap 3: Protocol mapping is inefficient, not scalable
--No durable ID per event
--No batching
--No timestamps
We will leverage weave event implementation, create new meta-model construct for Events:
All events have:
Cluster ID + Event Type ID
64-bit unique ID for each event instance, monotonically vended
Importance Levels
Timestamp (system time OR wall-time)
We will modify Reporting protocol to support shuttling batched Events as well
Custom interest set for events
Batched payloads
Synchronization
Event ID optimization
The text was updated successfully, but these errors were encountered:
@mrjerryjohns has presented weave event spec in TSG data model team, and received the broad agreement on it. I am working on the initial porting, leverage and prototype for event on CHIP.
Eventing: Motivation
--A way to provide a historical record/log of notable ‘happenings’
--Capture every single ‘edge’ / change
--Send it reliably to interested observers
--Can contain rich metadata
For the existing zcl, there exists 3 gaps
Gap 1: Inconsistent queuing semantics with attribute reporting
--Different queuing constructs observed between ZCL clusters
Gap 2: Lack of meta-model construct to be able to define events
--ZCL today defines in two ways:
Circular ‘tables’ in attributes
‘Notification’ Commands
Need a better construct
Gap 3: Protocol mapping is inefficient, not scalable
--No durable ID per event
--No batching
--No timestamps
We will leverage weave event implementation, create new meta-model construct for Events:
All events have:
Cluster ID + Event Type ID
64-bit unique ID for each event instance, monotonically vended
Importance Levels
Timestamp (system time OR wall-time)
We will modify Reporting protocol to support shuttling batched Events as well
Custom interest set for events
Batched payloads
Synchronization
Event ID optimization
The text was updated successfully, but these errors were encountered: