Ideas for Potential Improvements to General Driver Framework

[davidraker]

The driver framework has gone a significant time without major updates, and may not currently reflect the full needs of the platform. Some ideas to kick off a discussion of how to improve this:

1. Transforms for all drivers.
   A. Can use code from ModbusTk.

2. Driver agent as a service (instead of installed agent).

   • A. Interactive user interface:
     • i. vctl driver (device?) commands (or utility tool):
       • a. get/set point.
       • b. start/stop devices
       • c. start/stop individual points
       • d. Add and remove driver interfaces (modular).
     • ii. RPC methods for starting and stopping individual points or devices.
     • iii. Status reporting.
   • B. Roll actuator functionality into driver as a feature rather than a separate agent.
   • C. Launch and manage helper processes (e.g., bacnet proxy) from within driver, rather than as a separate agent.

3. Improvements to polling setup:

   • A. Ability to configure all points on a device but only to poll specific ones.
   • B. Ability to turn on/off polling on a point by point and device by device basis.
   • C. Ability to poll different points at different rates (within same device).
     • i. This might include one-time (or very very slow) poll to establish static meta-data.
   • D. Default poll scheduling should spread polling accross all available time.
     • i. Might need optimization to derive a schedule on a a point by point basis.
   • E. Is publish_breadth_first still needed?
     • i. Do we really need separate "all" versions? This may be problematic if various points are polled on separate intervals, since there may be multiple "all" publishes with a subset of devices. Alternately, it may be possible to publish simply without the point name and without "/all" when multiple points are involved. Agents should then check if an individual publish contains the point they are seeking.
     • ii. A thought to distinguish breadth publishes from depth ones would be to publish breadth topics beginning with "points/" instead of "devices/".
     • iii. Would it be feasible to have the pubsub system automatically check for lower level topic information in publishes? i.e., if a publish topic is "devices/Campus/Building/Device", and the keys in the data dictionary are "VAV1", "VAV2", then it should provide this publish to a subscriber which has requested the topic: "devices/Campus/Building/Device/VAV2". This would avoid the subscriber receiving undesired publishes for the same device when the point is not present (e.g., because it is polled less frequently than other points on the same device).

4. Data model integration:

   • A. Ability to look up meta-data about devices, points, etc.
   • B. Load and store static data from devices or by configuration.
   • C. Integrate with tagging.

5. General interface for push protocols along the lines of the current setup for pull protocols.

   • A. e.g., MQTT, BACnet COV, OpenADR event, etc.

6. General interface to provide server-side functionality for protocols:

   • A. expose local data-model or another register mapping as a server by listening to a port for requests.
   • B. i.e., act as a pollable device or peer where requests may originate from other side.
   • C. e.g., DNP3 outstation, BACnet device, Modbus TCP server (or RTU slave).