This document outlines the changes to the BitBrew platform and management APIs that will be released October 31, 2018. Changes to existing behavior should be carefully read and understood.
Table of Contents
New Read-Only Role
Role Enhancements
Delayed Messages Report for Destinations
Enhanced Support for Impact Events
New Read-Only Role
A new role is available for users, called readOnlyMember. A user with this role can view all of a tenant's resources, but cannot create or delete resources, with the exception of clients.
A read-only member can create a client that will also have read-only permissions. If you need programmatic access that is restricted to read-only, you can invite a user and use that user to create a client.
Role Enhancements
An admin can now select a role for new teammates that they are inviting to join their organization.
Platform Roles
Admin: Admins have permissions to take any action within their tenant.
Member: Members have all permissions except user management.
Read-Only: Read-only members can only view resources, but cannot create, modify, or delete them. They can, however, create a client for programmatic read-only access.
Additionally, an individual user's role information is now viewable in the Account tab of the Settings menu item.
Delayed Messages Report for Destinations
Every destination entity now contains a report on the number of events that are pending delivery.
This report is visible under the Destinations Nav item.
If there is an issue with a destination (throughput settings exceeded or incorrect configuration), the platform will not be able to deliver events, and the number of events pending delivery will grow.
It's important to understand that each event has a 48-hr TTL, and will expire if it cannot be delivered within that window.
For more information, read about common destination errors that lead to delivery delays.
Enhanced Support for Impact Events
BitBrew's support for Datalogger events has been enhanced to include a new event type called Impact. Customers who have defined impact criteria in their configuration will now receive Impact events in their data stream when that criteria is met.
Example Event
The Impact Event is generated using 100Hz accelerometer sampling and can provide
readings up to 16g. The threshold for triggering the impact event, the number of
milliseconds the threshold must be maintained, and the minimum number of samples
needed to verify the impact event are all configurable.
Accelerometer samples have been truncated in this example for the sake of brevity.
{
"header": {...},
"body": {
"type": "ImpactEvent",
"timestamp": "2018-06-04T19:01:58-04:00",
"tripNumber": 103,
"imei": "333607123098821",
"gpsReading": {
"heading": 156,
"horizontalDilutionOfPrecision": 0,
"latitude": 43.34887,
"longitude": -83.04490,
"numberOfSatellites": 7,
"hemisphere": "NorthWest",
"fixQuality": "Standard"
},
"configuredSecondsOfReportingPriorToEvent": 2,
"configuredSecondsOfReportingAfterEvent": 10,
"thresholdValue": 3000,
"triggerValue": 3609,
"vehicleSpeedAtTimeOfImpactInMph": 39.700000762939,
"secondsRelativeToTrigger": 10,
"accelerometerDataType": "Normalized",
"accelerometerSamplesInMg": [
{
"z": 992,
"y": 15,
"x": -15
},
{
"z": 988,
"y": 19,
"x": -23
},
{
"z": 976,
"y": 23,
"x": -23
},
{
"z": 980,
"y": 15,
"x": -19
},
...
{
"z": 941,
"y": 15,
"x": 335
}
]
}
}