Draft: BACnet support for events #379
Conversation
✅ Deploy Preview for wot-binding-templates ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
https://deploy-preview-379--wot-binding-templates.netlify.app/bindings/protocols/bacnet/index.html#event-mappings can be used for seeing the rendered version |
| "moreEvents": false | ||
| } | ||
| </pre> | ||
|
|
There was a problem hiding this comment.
Feedback @egekorkan -> add a real-life scenario, e.g. about an AHU, here
| </td> | ||
| </tr> | ||
| <tr> | ||
| <td>AcknowledgeEvent: ActionAffordance.input</td> |
There was a problem hiding this comment.
Feedback @egekorkan -> indicate that this is separate from the low-level acknowledge (confirmation)
There was a problem hiding this comment.
Overall this looks good to me, although I haven't checked all the details in the new tables.
However, I think a few more points should be added to make this work within the conceptual framework of WoT. In general, WoT tries to abstract away from the exact protocols used; for a TD consumer, it should not matter whether they use BACnet or another underlying protocol; the drivers take care of the protocol-specific details.
This PR essentially defines a layer above the BACnet Protocol Binding that allows BACnet alarms to be distributed to TD consumers and for them to acknowledge these alarms. While I am not against the BACnet Protocol Binding and this higher layer being specified in the same document, they should be clearly separated and decoupled. Even though the higher layer will usually be used with the BACnet Protocol Binding, it could in principle also be used with the MQTT Protocol Binding, for example.
Let's say a TD consumer sees an event in a TD and it does not look at the contained form(s):
- How does the consumer recognize that this event delivers BACnet events?
- Should the consumer have the specified data schema hard-coded and compare it to the data schema in the TD, and if they are (almost?) identical, then it's BACnet events?
- How does the consumer recognize that it can/must acknowledge these events?
- How does the consumer know which action to use for confirmation?
- Should the consumer have the identifier of the action hard-coded?
Let's say I'm implementing a WoT/BACnet driver:
- How does the driver know which BACnet protocol element goes into which key-value pair in the JSON data schema? Is this purely based on the key names?
- I suppose the data schema might evolve with future revisions of the document. What should a driver do if there are newly specified key-value pairs in the data schema that it doesn't yet know about, or if pairs that are currently specified are missing?
Nit:
- You wrote that the terms "BACnet Event" and "BACnet Alarm" can be used interchangeably. I would suggest using "BACnet Alarm" throughout the document to avoid any confusion with WoT events.
Bring support for BACnet Events (used interchangeably with Alarms) to WoT BACnet Protocol Binding.
My general approach in this PR is to allow WoT Consumers to interact with EventAffordances in a certain way. I didn't try to cover all features and options of BACnet. I find it better to start simple and add features as they become necessary.
This PR bases on #377, so that one should be merged first.
Preview of rendered doc: https://deploy-preview-379--wot-binding-templates.netlify.app/bindings/protocols/bacnet/index.html#event-mappings