Skip to content

WestPoint · Rhombus

Built for whoever comes in through the console.

Rhombus does cloud-native video security: cameras with memory of their own, analysis inside the camera and one console where everything is — video, doors, sensors and alerts. It is one of the most comfortable to use, and the one that forces you to ask the most questions about the company behind it.

The video system the IT person uses.

It explains a lot to know who buys it: very often it is not the security department.

There are organisations with several locations, technical people at head office, none at the branches and no control room with shifts: medium-sized companies, schools, logistics, clinics. For them video is a tool you look at when something happens, and nobody watches the sixteen-camera mosaic.

Rhombus is built for that. The cameras record inside themselves, analyse what they see in the camera itself and send up the light stuff: what it saw, when, and one image. The video is fetched when somebody asks for it. You search by what happened instead of rewinding, and you administer it from a browser like any other tool in the company.

And it adds what an organisation like that needs together: doors, temperature or humidity sensors, an alert for a door left open or for noise, and the alerts arriving where those people already work —the company chat, the email, the mobile—. That is not one more function: it is what makes somebody actually read the alert.

How it is built.

A cloud architecture with the heavy work in the camera.

  • The camera records and thinks: memory inside for however many days the model and the quality allow, and the analysis running right there. That is what lets an ordinary line carry the system, because what goes up continuously is data and thumbnails.
  • There is no recorder and no server at the site, so there is nothing to size in there. The network does have to be sized: switch ports and power, consumption per camera and upload for when several people watch at once.
  • Retention: the camera's, plus whatever is contracted in the cloud to keep it longer or to have a second copy. Which cameras deserve it is a risk decision and it is taken one by one — if a camera is torn off the wall, whatever was inside it and had not been copied went with it.
  • Access control, intruder detection and sensors live in the same console and come from the same house: they share users, log and alerts, so a forced door brings its video with no integration. If you already have a big access control platform, then it is integrated over the API and you have to check what can be done in both directions.
  • API and alerts: an open programming interface, outgoing alerts to other systems and sign-in with the company's identity directory. For an IT team that wants video to be one more piece and not an island, that is worth more than half a function list.

The five questions about the cloud.

And here there is a sixth, which is about the company and not about the product.

Where the recordings live: the video in the camera; the index, the users, the permissions and whatever is archived, in the supplier's cloud — which by design has an administration route in. What you should demand is the same as with the others: minimum permissions, compulsory two-factor, a visible access log and, in writing, who can see what from the supplier's side.

If the line goes down the camera carries on recording and what goes down is the live view from outside, the alerts and the search. When it comes back, the cloud catches up. It works for nearly everything except live monitoring.

The cost of uploading video: low and steady while nobody watches. The peak turns up when somebody watches and when archiving to the cloud — if a lot is archived and from a lot of cameras, the sustained flow stops being small. It is worked out with the list of what is going to be archived in front of you.

RGPD and international transfers: a supplier from outside the EU, with everything that drags along —a processor contract, guarantees for the transfer, the region in writing, a prior assessment where it applies, information given to the staff—. And a question that with young platforms gets asked plainly: which region you get, with your contract, and what happens if the supplier changes it.

The dependency, and the sixth question. Its own cameras are not reused with another system, so leaving means changing hardware; third-party ones stay. And the one that is not technical: it is a younger and smaller manufacturer than the big names on this list, which brings good things —they develop fast, you can get through to support— and makes you ask about support and replacements in your country, about the references in Europe and about what would happen if the company is sold.

The subscription, and how it grows.

Camera and licence by term, with the console, the updates and the support inside. The cloud archive and any functions contracted above the base go separately.

As you grow two things get forgotten and both show up in year three. The dates: if the cameras went in in batches, the renewals get scattered across the calendar. And the archive: it is contracted for a few critical cameras, it grows without anyone deciding it and it ends up being half the bill. That is why we ask for the estimated five-year cost in writing, which is the number you have to compare a perpetual licence plus its maintenance against.

Who it fits, and who it does not.

It has a very defined profile. When it fits, it fits a lot.

It fits if…

IT or the operations director is in charge more than a classic security department. If there are several locations with nobody technical, if you want video, doors and sensors in one console, if it matters to you that the alerts reach the chat and the mobile of whoever has to act, and if you are going to integrate over the API. Also if the installation is new and the manufacturer's own hardware is not a problem.

It does not fit if…

You have a control room with operators watching live and driving domes: it is not for that. If the specification demands recording on the customer's premises, a European supplier or a long list of local references. If there is a large stock of recent cameras that do not come in as third-party. Or if the house has a rule about not depending on a single supplier for hardware and software.

Analytics: what comes with it, what you can add and where the ceiling is.

It comes with a fair amount and working from day one: people and vehicles, search by what was seen instead of by the time, number plates and faces on the models and licences that include it, zones, timetables, loitering, a door left open, occupancy. It runs in the camera, so there is no analytics server to buy.

About the part that recognises faces, two things: it is subject to strict data protection rules, in many workplaces it cannot be switched on without a properly built legal basis, and switching it on «because it comes included» is the kind of decision you pay for in an inspection. It is decided with the data protection officer in the room and it is documented.

The ceiling: it is analytics of categories and of search. It knows there is a person, a car, an open door. It does not understand a scene with several things at once, nor situations belonging to an industrial process, and there is no setting that takes it there. What you can do is pull the events out over the API and let another system decide.

And the part we disclose: in the same house there is IRIS Neural, the NVMS from Infinity Neural —the other company in the group, so we recommend it with an interest of our own and we say so right here—. In many installations they live together: the VMS governs cameras and recording, IRIS brings the understanding of the scene. With the manufacturer's own cameras you have to be specific: if there are third-party cameras, IRIS takes those same streams; if everything is the manufacturer's hardware, the normal thing is to put cameras of our own at the points that have to be understood, or to check first what access to the video your licence allows.

What we do.

With no servers to build, everything that decides the result happens before anything is switched on.

  • The design point by point: what each camera has to see, at what height, with what lens, what can be seen from there at night and how many days it has to keep. And which areas the chosen model does not cover well, said before and not after.
  • The sizing of what is left: network, switch ports and power, available upload, and the cloud archive calculation camera by camera instead of one package for all of them.
  • The contract and data part, which here is technical work: terms and renewals, the storage region, the processor contract, support and equipment replacement in your country, and the estimated five-year cost.
  • The implementation: registering the locations, sign-in with the company directory, two-factor with no exceptions, profiles by job, and the alerts connected where somebody is going to read them —with the list of who receives what and at what time, written down—. Plus the API integrations, tested against the real system.
  • The migration and the maintenance: running side by side with what was there, exporting whatever has to be kept before switching off, and after that fields of view, the night image, cameras that have stopped seeing well, permissions that are surplus and the cloud archive that grew on its own.

Who operates it after we leave.

It is the platform that most comfortably stays in the customer's hands. And the one that most needs somebody in charge of the permissions.

  • IT, which here usually carries nearly everything: identity and two-factor, sign-in with the company directory, the network and the power for the cameras, and reviewing the access log. It is one more tool in the IT catalogue.
  • Security, or whoever plays that role: the day-to-day use and the judgement. What counts as an alert, what gets done when one arrives, what gets exported and how a piece of evidence is handed over. IT cannot decide that, because it is not a technical decision.
  • The important nuance, and here more than anywhere: when giving access is easy, too much of it gets given. The system ends up with people watching cameras that are not theirs to watch, and that is no longer an IT problem: it is a data protection one, with someone answerable and with a fine. Profiles written down and reviewed twice a year by somebody with a name.
  • It demands less installation of the integrator and more judgement: choosing the points, building the alerts so that somebody reads them, connecting it to what the customer already uses and holding up the data protection conversation. Anyone who only knows how to hang cameras contributes little here.
  • Training: a morning for whoever uses it, and a session with IT and with the data protection officer on permissions, the access log, what analytics get switched on and on what legal basis. That second one is the one nobody asks for and the one that avoids the expensive problems.
  • Documentation: a sheet per camera with what it sees and the days it keeps, a map of locations and profiles, a list of alerts with recipient and timetable, what analytics are switched on and why, the storage region and the processing contract, a table of renewals, and the administrator accounts in the customer's name.

Get started

Who is going to administer this in two years' time?

With Rhombus that question decides more than the data sheet: it works very well when there is somebody in IT who adopts it, and it stops halfway when nobody makes it theirs. Tell us how many locations you have, what is installed and who is going to run it.