Bmetry Configuration
- Benedict Häfeli
Bmetry solutions provide a frontend configuration for managing the running of sequences and delivery destination of the images. They also provide an API in order to facilitate 3rd-party automation of image delivery. It is in development and will be extended in the future, but these endpoints should remain mostly stable.
To familiarize yourself with the core concepts bmetry solutions are built on, please read the first chapter in the API documentation:
If you’re looking for information on how bmetry images are displayed in the portal, go here:
https://avisec.atlassian.net/wiki/x/D4Cuuw
Configuration
The images sent by a bmetry solution take another path than images sent by other cameras. Bmetry images are not visible in the portal, as the content of individual images is rarely of interest. As such, the browse page of a bmetry camera will be empty, or merely show the images that were captured the “regular” way by a schedule or manually, but you can still use the portal to configure your solution by clicking on the configure menu option:
We are working on replacing the empty browse page with a data summary for a quick overview over what the solution has been doing and what images are available, but at this point in time you will need to query the API to get that information (see here).
Properties of a bmetry solution must be configured through the master. To make a camera the master of a solution, activate the bmetry peripheral in its peripheral configuration:
This peripheral must be configured in addition to the webcam controller, and the tethering mode. The tethering mode must be activated for every remote in a bmetry solution, no matter whether they are a master or not, but the bmetry peripheral is only required for the master. Activating this peripheral will enable the following configuration options:
Capture duration: The length of the sequence to capture, in seconds. This serves as a timeout for the entire capture operation after cameras are tethered and ready.
Capture frequency: How many times per second the cameras in the solution should capture an image. Currently this is the same setting for the entire solution, without distinguishing individual remotes.
Capture control: If set to start on motion, cameras will only start capturing once they detect motion in the crane. In this case, capture duration serves as a timeout. If set to start on command, cameras will start to capture as soon as they are ready and do so until capture duration is up.
Automatic upload: If active, all available images in a sequence from all remotes will immediately be uploaded once a sequence is finished. If you deactivate this, no images will be uploaded by default. They will remain on the camera until an upload command is sent through API. This is intended to provide an interface for upload automation and pre-filtering of images and is the recommended way to manage uploads from bmetry solutions. However, if you have no automation in place, activating this option will serve as a (often wasteful) substitute.
Attention! Cameras will clean themselves and delete all stored images after midnight. If you do not upload your images, they will be gone the next day!
Remotes: Here you can configure the remotes belonging to a solution. Just enabling tethered mode for all remotes is not enough, you need to group them together to a solution here, otherwise they don’t know who may talk to whom. The identifier for the remote is the serial number of its camera controller, which is the same thing you use as a username in the portal:
The serial of the master itself is added implicitly and does not need to be configured.
Endpoint configuration
As bmetry images are routed differently and never go through the usual post-processing steps as other images do, configuring a forwarding endpoint in a table configuration has no effect. Instead, you need to configure the endpoint you want the images forwarded to for processing here. If you do not configure an endpoint here, you will not receive any images!
Endpoint configuration otherwise is very similar as it is for table configurations:
You can forward to either an FTP server, or to an AWS S3 bucket under your control. Do not configure both. If you do, the FTP server takes priority, the S3 bucket will receive nothing.
FTP configuration
Host: The fully qualified domain name of your FTP server.
Port: The port to send the request to. 21 by default, change if your server expects communication on another port.
User and Password: Credentials to log into the FTP server for the file transfer.
S3 configuration
Bucket: Name of the bucket to send to.
Key and Secret: Access key and Secret key of an AWS user that has putObject permission for the bucket.
Common configuration
These fields affect both FTP and S3 uploads the same:
Server folder: A subfolder to write to. In case of an FTP server, the user will need permission for that folder. In case of an S3 bucket, this value will be prepended to the object key with a /.
Filename: The filename (ftp) or object key (S3) the image will be uploaded as. You can name this whatever you like, but you should always include the template variables {C} and {T} which will be replaced with the sending camera’s code and the images' timestamp. This is important as otherwise all it will become difficult to differentiate the exact origin of the image. And without a timestamp, your images will end up with identical names and overwrite each other. The time written into the timestamp is the original time read from the exif data of the image, together with its subsecond component.
Time format: You can choose a format for the timestamp as it will be inserted into the filename. These include milliseconds, as for some bmetry-solutions a resolution of one second may not be enough. Choose whatever time format suits you best.
API Documentation
The API documentation has moved here: Bmetry API documentation