Fluke Process Instruments

This programming guide discusses the HTTP POST message format provided from Irisys Vector units.

HTTP POST is just one of the many different methods of retrieving count data from a Vector device. Alternative data retrieval methods are the REST API, MQTT, BACnet and relay outputs via the optional USB IO module.

HTTP Post works by pushing out selected data fields at a fixed interval over HTTP for use in your own data reporting software. The data is provided in JSON format.

Using the HTTP POST Data

There must be an application that accepts the HTTP POST data messages and decodes the json that is received. This is something that you will most likely have to create yourself, based on your own count data usage requirements.

There are many free websites that can accept the HTTP POST calls which can be used for test purposes, if required.

We have some code examples on how to integrate with HTTP Post, as well as REST API and MQTT functionality stored online at the GitHub repository. Go to: https://github.com/IrisysUK

HTTP Post Header

it should be noted that enabling the Authentication or Authorization Token options will enable a secret token to be transmitted in the HTTP Post header. The intention of this is to allow other Posts received that don't contain the token can therefore be rejected. 

Header examples:

Data Format

A complete example of the JSON data format is as follows:

{  "CountLogs": [    … see description below  ],  "DeviceID": "VM1",  "DeviceName": "TestVM",  "EnableDST": false,  "FriendlyDeviceSerial": "V4D-18160003",  "HistogramLogs": [   … see description below  ],  "IPv4Address": "0.0.0.0",  "IPv6Address": "::",  "SiteID": "IRISYS",  "SiteName": "Swan Valley",  "TimeZone": "Europe/Moscow",  "UserString": "Test Vector!",  "macAddress": "00:21:AC:04:00:14" }

The CountLogs and HistogramLogs are described in subsequent sections. The rest of the values may be present or not, depending on the selected settings when configuring the HTTP POST (see separate document “V4D9 – HTTP POST Settings Guide”).

Note that the IP Address is either the statically assigned value or the one assigned by DHCP, depending on configuration.

Count Logs

The expanded CountLogs section is as follows:

{  "CountLogs": [    {      "Counts": [        {          "LogPeriodValue": 18,          "Name": "Line 1",          "RegisterId": 0,          "Tags": [            "direction=IN"          ],          "UUID": "",          "Value": 444        },        {          "LogPeriodValue": 17,          "Name": "Line 2",          "RegisterId": 1,          "Tags": [            "direction=OUT",            "group=xnxbn"          ],          "UUID": "",          "Value": 443        },        {          "LogPeriodValue": 17,          "Name": "zone",          "RegisterId": 2,          "Tags": [],          "UUID": "",          "Value": 443        },        {          "LogPeriodValue": 17,          "Name": "zone2",          "RegisterId": 3,          "Tags": [],          "UUID": "",          "Value": 443        }      ],      "LogEntryId": 14065,      "StartTimestamp": "2020-03-17T15:15:00Z",      "StartTimestampLocaltime": "2020-03-17T18:15:00+03:00",      "Timestamp": "2020-03-17T15:16:00Z",      "TimestampLocaltime": "2020-03-17T18:16:00+03:00"    }  ], }

The data fields are as follows:

• Counts[]: an array of count values – essentially the array of registers as defined in the Vectors configuration.
• LogPeriodValue: The incremental value of the specific register over the logging period.
• Name: The configured register name
• RegisterId: The index into the list of registers – note that this will change if the position in the list changes (e.g. if registers are deleted)
• Tags: A list of tags to give meaning to this register, as configured in RIFT. At time of writing, these will be “Direction” (IN or OUT), or “Group” (a user-defined string).
• UUID: a unique identifier, assigned when the register is created. This will not change, even if the register name changes or its position in the register list changes.
• Value: The cumulative value for this register since power-on.
• LogEntryId: the unique database index for this entry (increases every log period)
• StartTimestamp: the timestamp (UTC) for the start of the logging period this data was captured for.
• StartTimestampLocaltime: the StartTimestamp value converted into the time zone the device has been configured for.
• EndTimestamp: the timestamp (UTC) for the end of the logging period this data was captured for (effectively, this is the time when the data was sent at the end of the logging period)
• EndTimestampLocaltime: the EndTimestamp value converted into the time zone the device has been configured for.

Note that you may receive different/additional fields dependent on your particular HTTP POST configuration.

Histogram Data

The Vector device can be configured to produce the distribution for heights or wait times for a given line/zone. In other words, the device can give a breakdown for how many people have waited in the zone for varying time lengths (e.g. 0-30 seconds, 30-60 seconds, etc), or how many people of a given height band have crossed the line (e.g. 140-150cm, 150-160cm etc). This data is essentially a frequency histogram and can be configured to be delivered over HTTP POST.

The expanded HistogramLogs section is as follows:

{  "HistogramLogs": [    {      "Histograms": [        {          "Name": "Line 1",          "RegisterId": "0",          "Tags": [            "direction=IN"          ],          "UUID": "",          "Values": [            {              "config": {                "binWidth": 10,                "minVal": 130,                "nBins": 8,                "type": "height"              },              "periodic_result": [                0,                0,                6,                0,                6,                0,                0,                6              ],              "result": [                0,                0,                148,                0,                148,                0,                0,                148              ]            }          ]        },        {          "Name": "zone",          "RegisterId": "2",          "Tags": [],          "UUID": "",          "Values": [            {              "config": {                "binWidth": 25,                "minVal": 100,                "nBins": 4,                "type": "height"              },              "periodic_result": [                0,                0,                6,                6              ],              "result": [                0,                0,                148,                148              ]            },            {              "config": {                "binWidth": 10,                "minVal": 0,                "nBins": 5,                "type": "total wait"              },              "periodic_result": [                0,                0,                17,                0,                0              ],              "result": [                0,                0,                443,                0,                0              ]            }          ]        },        {          "Name": "zone2",          "RegisterId": "3",          "Tags": [],          "UUID": "",          "Values": [            {              "config": {                "binWidth": 25,                "minVal": 100,                "nBins": 4,                "type": "height"              },              "periodic_result": [                0,                0,                6,                6              ],              "result": [                0,                0,                148,                148              ]            }          ]        }      ],      "LogEntryId": 14064,      "StartTimestamp": "2020-03-17T15:15:00Z",      "StartTimestampLocaltime": "2020-03-17T18:15:00+03:00",      "Timestamp": "2020-03-17T15:16:00Z",      "TimestampLocaltime": "2020-03-17T18:16:00+03:00"    }  ], }

The data fields are as follows:

• Name, RegisterId, UUID, Tags: these are all the same as described earlier in the CountLogs section
• LogEntryId, StartTimestamp, Timestamp: these are all the same as described earlier in this document.
• Config{} : this section describes how each individual histogram was configured, and has the following fields:
  • nBins: the number of ‘bins’ in the histogram, as configured in RIFT
  • binWidth: the size of each ‘bin’, as configured in RIFT. This will either be a value in cm or a value in seconds, depending on the type of histogram you created.
  • minVal: the starting point of the histogram, again either in seconds or cm, depending on type of histogram.
  • type: either “height” or “total wait” depending on the type of histogram you created in RIFT.
• result[]: the total cumulative array of values for the histogram since power-on – the number of values in the array will be ‘nBins’ as above.
• periodic_result[]: the array of values for the histogram over the last logging period only – the number of values in the array will be ‘nBins’ as above

Processing Histogram Data

The histogram data that comes back in the HTTP POST Message is particularly useful for understanding the dwell characteristics of the monitored environment.

For example, you can use the data to compute the average customer dwell time over a period, for a given dwell limit (i.e. “for all people who wait up to 1 hour, what is the average time a customer spends in the zone?”) – this is particularly useful to filter out staff/cashiers/other people that are present far beyond what a customer would be.

To compute the average dwell time for those who left during the last logged period:

1. For each entry in the periodic_result[] array:
   • Calculate the average value for that ‘bin’ (this is simply the midpoint of that bin – so, if the bin covers 10-20 seconds, multiply by 15) – so for the n-th entry, this would be minVal + binWidth/2 + n * binWidth.
   • Multiply this by the entry in the array
2. Divide the total by the number of bins (nBins)

For reference, the equation for this is: