Introduction
Vectors are a modern IoT device providing anything from simple door count numbers, to dwell times of individuals in a configurable zone, through to 'event' and 'X/Y positioning' data stream outputs.
Depending on the use case and amount of data the following data extraction methods are available:
- REST API. This allows you to write software to communicate with the Vector and pull the required logged count data. Vectors support pulling of direct either directly, via an Estate Manager connection. The amount of data that is logged is governed by the Count Logging interval setting. The shortest log period is one-minute intervals, default is 15 minutes.
- HTTP Post. This is where the Vector actively sends you the logged data without you having to request it. Up to three separate HTTP Post connections can be configured in order to send various types of data to multiple different locations, as required. As with the REST API method of retrieving data, HTTP Post can only send logged data - dictated by the Count Logging interval setting - typically within a second of the new log entry being created. Various mechanisms are incorporated to retry and resend in the event of a message send failure.
- MQTT. Similarly to HTTP Post above, this is also where the Vector actively sends you data, but MQTT is designed for real-time data and instead of sending the logged count data it will send the values as, and when, they change. So, whenever someone is counted, and the register increments, you will get a feed from the MQTT ‘broker’. This means you get data within 1 second of the change occurring. It should be noted that some constantly changing registers will generate lots of MQTT messages and correct setup is important. For example the average dwell time register will increase in value every second whilst people are within the configured area and so a corresponding MQTT message will be sent every second. MQTT is very much a Live feed, where as using the REST API or HTTP Post methods use logged data only. As well as sending the register values via an MQTT message, various other MQTT 'topics' can be utilized to; send a stream of positioning information of each person within the available field of view; or a stream of event info, such as every line crossing or zone entry/exit event.
- BACnet. This is used in many building control systems and allows count data to feed into that system to drive changes in heating, cooling, etc.
- Relay outputs. For those still using relay outputs into a dedicated logging system, we offer the optional USB-IO module. This will output relay pulses exactly at the time a count line is crossed. This is not generally used much these days unless you’re interfacing with an older dedicated count logging system, but maybe required when interfacing directly to security access controllers, for example when utilising the Tailgate detection functionality.
Differences
The main differences apart from the actual mechanism involved, is whether data is available live or aggregated. Live data is also known as streamed or real time data, and in these cases whenever someone is counted, or some other register value changes, the data is sent and available immediately, or almost immediately - within a few seconds. Aggregated data, or logged data, simply means that the current value is stored at a regular, configurable, interval and stored internally for later use. By default Vectors will log at 15 minute intervals, and register totals are stored internally at quarter past the hour, i.e. 9:00, 9:15, 9:30 etc. But any log entry down to 1 minute intervals is permissible.
Live/Logged | Notes | |
---|---|---|
REST API | Logged | Count Logs must be requested via software |
HTTP Post | Logged | HTTP Post actively sends logged data as soon as it is available |
MQTT | Live and/or Logged | MQTT can be configured with different topics. One will actively send data as values change, the other sends logged values as soon as they are written |
BACnet | Live | Live values are always accessible over BACnet |
Relay Outputs (USB IO Module) | Live | Each register increment results in a relay pulse as soon as the change is registered. Used for interfacing locally only. |
Choosing the right data retrieval mechanism depends on the application, and it is completely up to the installer/partner/integrator to decide.