The Monitoring Box, local handover point between asset and platform.
An industrial edge component connected on site to assets. It speaks their protocols, identifies itself to the platform, and transports telemetry over a controlled, secured connection.
Device identity and configurable local buffering are part of the Box baseline; in connected operation, transmission runs over an mTLS-secured connection.
The physical anchor point on site.
The Monitoring Box separates asset communication from the internet, and thereby becomes the controlled handover point: inward it speaks asset protocols, outward only the platform.
Speak protocols on site
The Monitoring Box is designed for real building-systems connections. Technically supported today are Modbus TCP/IP, Modbus RTU, KNX, MQTT / REST, plus API-based data connection via Data Ingress / Push API. The Push variant is especially interesting where a system should hand over defined data securely without exposing itself to direct queries. LAMPEC and TSE have direct integration paths. BACnet, M-Bus, and OPC UA are in preparation. Further platform, partner, or OEM APIs are defined per project and rolled out step by step. For offline-hardened installations this integration list is especially important, because new connections cannot simply be loaded remotely, required protocols, devices, data points, and later extensions should be cleanly defined before project start.
Identity & encryption
Its own cryptographic identity and an mTLS connection to the platform, no open asset ports facing outward.
Configurable local buffering & health
On connection loss, the Monitoring Box can buffer data locally and transmit it traceably after reconnection. Scope and behaviour depend on operating mode, storage limits, and project configuration.
Industrial design, aligned with real site conditions.
Interfaces
Industrial ports for the asset bus and network. Additional interfaces (e.g. M-Bus) are in preparation.
Protocols
Base protocols and API-based data connection technically supported today. LAMPEC and TSE have direct integration paths. BACnet, M-Bus, and OPC UA are in preparation. Further platform, partner, or OEM APIs as well as webhooks are defined per project and rolled out step by step.
Security
Cryptographically anchored identity, signed updates.
Buffering & updates
Configurable local buffering and secure OTA updates.
The asset network and the internet stay separated.
The Monitoring Box is the only component that knows both sides, and this separation is deliberate. Assets speak their protocols only locally to the Box; outward only an authenticated, outbound platform channel.
Inward: asset protocols
Today Modbus TCP/IP, Modbus RTU, KNX, MQTT / REST, plus API-based connection via Data Ingress / Push API. LAMPEC and TSE have direct integration paths. BACnet, M-Bus, and OPC UA are in preparation. Further platform, partner, or OEM APIs and webhooks are defined per project and rolled out step by step, only inside the local network, with no internet exposure of the assets.
Outward: one channel
Encrypted outbound connection to the platform. No open inbound ports on site, no direct external access to the asset.
Robust locally
On connection loss, the Monitoring Box can buffer data locally and transmit it after reconnection. Scope and behaviour depend on operating mode, storage limits, and project configuration. Assets remain locally operable independently of the platform connection.
The Box is part of the monitoring itself.
Sites without a visible gateway have blind spots. MonitoringHive therefore shows the state of every Monitoring Box explicitly.
A dedicated state channel per Box.
Connection, asset communication, buffering, and firmware are dedicated indicators. So you can see whether a data outage lies with an asset, or at the handover point.
- Connection to the platform, continuously monitored.
- Asset-bus status per connected bus.
- Buffer fill level visible on reconnection.
- Firmware level for update and security context.
Device identity, secure connection, data provenance, as the baseline.
The Monitoring Box is not a generic gateway. It is the trusted anchor point between asset network and platform. Identity, secure connection, clearly defined data points, and platform-side data-quality checking are part of every connection, not afterthoughts.
Unique device identity
Each Monitoring Box authenticates itself to the platform with a unique identity. Data can be traced back to a Box, a site, and an asset.
Defined data points
Which data points are connected is set per project, no uncontrolled asset communication, no implicit access.
Platform-side quality check
Incoming data is checked platform-side for gaps, dropouts, and plausibility. Data quality is made visible and is part of the trust foundation.
Also locally usable, as a deliberately chosen mode of operation.
The Monitoring Box can also be used in a fully local or offline-hardened mode. This is not a transitional state, but a deliberately chosen mode of operation with clear properties, and clear consequences if you want to extend later.
Local value without external data transmission.
Even without external connection, the Box creates a clear local view: connected assets, structured data points, configurable local buffering, local data quality.
- Local state and alarm view
- Structured data points on site
- Configurable local buffering on connection loss
- No external data transmission
Deliberate hardening, not arbitrariness.
In offline-hardened operation, all required protocols, data points, device profiles, and integrations must be cleanly defined up front. Extensions happen in a controlled way on site through a trusted technician, nothing is loaded remotely.
- Protocols and device profiles agreed up front
- Security boundaries clearly anchored
- Extension only through controlled on-site work
- No remotely loadable components
- Alarm and service logic defined per product
How the Monitoring Box is integrated on site.
New site
For a first connection, the Box takes over the initial capture of assets. Data points are defined in the platform, thresholds are added over time.
Extend existing assets
Existing assets that were not previously connected are integrated via additional bus ports or adapters, without interfering with the asset control.
Service container
Optionally, the Box can run light on-site logic, e.g. pre-aggregation or filtering, before data goes to the platform.
When a Monitoring Box on site makes sense.
You want to connect real assets reliably
- Assets speak Modbus TCP/IP, Modbus RTU, KNX, or MQTT / REST, or data is handed over via Data Ingress / Push API (BACnet, M-Bus, OPC UA in preparation)
- Asset network and internet should remain deliberately separated
- Sites have different connectivity conditions
- Operational reliability and local buffering matter
- Device identity and data provenance must be traceable
When there is no local data source and no integration need
Existing manufacturer portals don't have to be a deal-breaker. MonitoringHive can be useful where operators, partners, or OEMs need their own data foundation, local view, additional analysis, or a controlled integration layer.
- No local data source and no integration need
- No additional operator, partner, or service view wanted
- No site infrastructure in place or planned
The Box is the controlled data access.
The Monitoring Box makes real building infrastructure connectable: local protocols, device identity, defined data points, gateway health, and controlled data handover. The full MonitoringHive value then unfolds in the interplay with platform, dashboard, alarms, reports, and Studio.
Price and project scope depend mainly on the number of boxes, sites, integrations, data points, operating model, and service scope.
In offline-hardened installations, protocols, devices, data points, and later extensions must be defined up front.
Discuss the connection of your sites.
We review with you which assets, protocols, and site conditions are relevant, and what a first rollout of the Monitoring Box would look like in concrete terms.