Skip to main content

Platform overview & architecture

How the Vemcount platform is built: the company, location and sensor structure, white-label brands, and the six layers from sensors to alerts and connected devices.

V
Written by Vemco Group

Vemcount is a cloud platform for people counting, visitor analytics and IoT-based space management. It serves retailers, shopping centres, offices and facilities, and partners who offer it under their own brand. This article explains how the platform is built. It is written for technical admins, partners and integration teams.

How your account is structured

  • The structure is Company > Location > Sensor. Locations can be grouped with groups and tags.

  • Users are given access at company level or at location level, together with roles and permissions.

  • A partner or customer admin only sees their own companies.

  • Partner (white-label) brands have their own login address, look and feature settings.

  • Sales and turnover can be reported in many currencies, with exchange rates updated daily.

The six layers

1. Sensors. Sensors from many manufacturers, for example Xovis, Brickstream, Axis, Hikvision, Hanwha, Eurecam, Elsys and IMBuildings. They are mounted at entrances, zones, queues and parking areas and send counts, occupancy, demographics and IoT values.

2. Data transport. Sensors send data out to the Vemcount cloud over TCP 80/443. Sites with closed networks can use an on-premises server. Gateways handle LoRaWAN and other non-IP sensors. A secure bridge allows remote access to sensors for setup and diagnostics (see the Device Manager article). Live data typically reaches the dashboard about 2 seconds after the event.

3. Vemcount platform. Dashboards with real-time and historical widgets, reports (custom, snap, scheduled and forecast), Maps 2.0 with live heatmaps and visitor tracking, the Tenant module for shopping centres, IoT widgets, admin settings, partner branding and Microsoft Entra ID single sign-on.

4. Alert engine. Health Checks per company, which run on a schedule, and alerts on each dashboard widget with min/max limits, a reset threshold and an optional schedule.

5. Output channels. Visual (in the browser, with optional sound), email, SMS, WhatsApp, webhook (GET or POST to any web address) and MQTT.

6. Connected devices. Webhook and MQTT alerts can trigger physical devices through a Raspberry Pi, ESP32, Home Assistant or any MQTT/HTTP controller. Examples: a siren when occupancy is too high, a chime when someone enters, an SMS when a fire door opens, a sliding door command when the queue is long, a WhatsApp message when waiting time is too long, or a live update on a digital sign.

In short: sensors feed the platform, the alert engine checks the limits, and the output channels can act on the physical space.

Related articles

  • Device Manager: remote connection, validation & documentation

  • Health Checks

  • Widget alerts & IoT automation

When to contact support

For architecture or integration questions that this article does not answer, for example on-premises servers or network design, email support@vemcogroup.com with your company name and a short description of your setup.

Did this answer your question?