Camera Lifecycle
- Benedict Häfeli
Cameras have an intended lifecycle, from preparation through to decommissioning.
But what is “the camera” actually? There is the physical device that is deployed to a site and is sending images to the portal. Undoubtedly, this is an actual camera in most cases. However, for the remainder of this document, I will refer to it as “the device” to avoid confusion.
Because of course “the camera” is also a data structure in the yellow portal which you use to store its images, configure image post-processing, publication, and in many cases even send orders to the device itself.
This distinction is important because the device will usually have a life before and after the camera. They are merely associated by a username and a password. The device can be put in storage and the camera deleted, or the device can be associated with another camera while the camera it was connected to remains as a static image archive. Or, in case of physical defects, it may also happen that a new device is associated with the same camera because the project has not yet finished and there are more images to be captured.
I’m explaining this in so much detail because I want to make it clear that when we are talking about the lifecycle of a camera, what we mean is the abstract representation in the portal - not the physical device.
Lifecycle stages
The camera moves through several stages in its lifecycle.
At some point it is being staged, i.e. the camera is created and configured in the portal, the device is connected to it, and there’s usually a short test period before the device is deployed to the field.
Once the device is where it needs to be and sending the images you actually want to collect, the camera is operating. It is doing the job it is intended for.
Once a project finishes, you will usually want to get the device back from the field, or immediately on to a new site. For the camera, however, this means that its time has ended. At this stage, you either download your data and delete it, or you may set it to archived, in which case you may keep the images online, but the camera may not receive any further images.
We highly recommend against reusing a camera when the device is used in a new project in a different place. This often leads to data breaches as old images are accidentally left on the camera while new users get access to it. If a project is done, end the camera, and create a new one for the next project. In case there is configuration you wish to preserve, read below for “Reusing camera configurations”.
Lifecycle management
You manage the lifecycle of a camera by setting its status on its configuration page:
There are six statuses a camera can have, some of which we already mentioned. They will be explained in greater detail below:
staged: A camera that is being prepared for deployment
operating: A camera in the field that is doing the work it is intended to do
under maintenance: A camera in the field that needs servicing
paused: A camera that, for intended reasons, is currently not capturing any images
ended: A camera that has done its job and is waiting to be deleted
archived: A camera that is no longer active, but is still used as an online repository for the images captured during its lifecycle.
Lifecycle stages in detail
staged: This is the lifecycle stage your camera will be created in. Staged cameras are not actively monitored, and alarms won’t trigger for them even if they are configured. It is intended to configure your camera and test your device. We recommend to wipe a camera when moving it to operating, but it is not done automatically.
operating: Once you deploy your device and it begins its intended job, set your camera to operating. Only operating cameras are actively monitored and will trigger alarms. This is the stage at which the camera is intended to be most of the time. Once your camera is operating, you cannot switch back to staging.
under maintenance: If a device experiences operational issues and needs servicing, set it to this status. This will disable active monitoring, so you will no longer be bothered with alarm messages, while still letting you know that something needs to be done about it.
paused: For whatever reason, the camera should not take any images right now, but it will again later. This disables active monitoring and alarms for the camera, but it will not automatically refuse image upload for that camera. The difference to “under maintenance” is semantic: In this case, the camera isn’t working but no action is required, while the other case implies that the camera is not working and action is required.
ended: After a camera has collected the images it was supposed to collect, it should be set to ended. This will disable most active features of a camera, and it will receive a special icon in the portal. Ending a camera means that you are about to collect your data and then delete the camera. A camera that was set to ended can not be set to any of the above stages, but it can still be changed to archived.
archived: If a camera is no longer receiving images, but you wish to continue using it to store your data rather than downloading and storing it on your own premises, set the camera to archived. An archived camera enjoys reduced billing, as most of its active features are disabled, while still offering access to your data for you or other users you may have given permission.
Reusing camera configurations
As mentioned initially, we do not recommend reusing a camera for new projects. Yet, oftentimes there is extensive configuration associated with a camera that wouldn’t change much and is time consuming to set up. In these cases, you have two options: Cloning the camera, or migrating it.
You can access these features from the context menu in the camera list, under the “create from this” option:
Cloning a camera
If you have a project that requires configuration that you know you already set up in another camera, but that camera is still in an ongoing project, you can clone it. You will then be presented with a list of options of exact configurations you want the new camera to copy from this one:
The options all have tooltips when you hover over them, so I won’t go deeply into them here. Do be careful with user permissions: Cloning user permissions means that all users that had permission for the camera you’re cloning will also have permissions for the newly created camera. This is only rarely required, and you should take the time to check what users have permission for a camera before cloning their permissions.
Cloning will never duplicate any collected data (i.e. images) of a camera, and it will never copy endpoint configurations, even if you clone its table configuration. The camera you choose to clone will not be affected in any way, and the new camera will always be created with status staged.
Migrating a camera
Camera migration is intended for exactly those situations when you have a device that is relocated to another project. Rather than reusing the camera in the portal, you should migrate it. This process creates an almost exact copy of the camera. It’s like cloning with all the options ticked (user permissions will be copied, but endpoint configurations will not be). However, in addition to that, it will remove the device credentials from the old camera and add them to the new one (in other words, the device will from this moment on be associated with the new camera, and no longer send its images to the old one). It will also set the old camera to ended status. In other words, you get almost the same result as if you deleted all the data on this camera and reused it with the same device for another project, but you still have the old camera and its data around for download, and all of that with fewer clicks!
This operation is potentially destructiveSetti if you apply it to the wrong camera, as it will be set to ended, and you won’t be able to move it back from ended to operating. For this reason, you’ll have to confirm the ID of the camera you intend to migrate.
Automated lifecycle management
coming soon
While most stages of a cameras lifecycle are difficult to infer from data and are best left to a human manager, its end can be automated pretty easily by simply letting a camera know when the project will end:
Setting an end date will automate the entire end of the lifecycle for you, which includes email notifications, generating a download, setting the cameras status to ended and finally deleting the camera. Setting this date will cause the camera to run through a strict series of procedures:
30 days before the set date, all users of level User and above that have not deactivated expiry notifications will receive an email with the information that the camera will end at the set date.
7 days before the set date, the same users will receive another notification.
1 day before the set date, what is identified to be the primary user (see below) of the camera will receive a final notification.
At the set date, the camera will be set to ended, and the login data of its device will be deleted (i.e. the camera will receive no further images). In addition, it will zip up its original table and send download links to its primary user.
7 days after the set date a final message will be sent to the primary user of the camera, and all explicit permissions will be revoked. For everyone but high-level accounts with general permissions, the camera will be gone from this point forward.
30 days after the set date, the camera and all its data will be irrevocably deleted.
Who is the primary user?
The primary user is the user that is identified to be the most likely customer contact for a camera. This decision is made based on several criteria that often find the right match, but if you want to make sure that a certain user will receive the data, you can can do so by adding a tag with this users email address to the camera:
If a camera finds one of its users emails in the tags, it will assume that they are the one to receive the data.