Protocol maturity
Technically supported protocols today require different planning than coming-soon integrations or project-specific extensions.
Platform · Extensibility
Modbus, KNX, MQTT, and upcoming BACnet integration, a platform for real building infrastructure.
MonitoringHive supports Modbus TCP/IP, Modbus RTU, KNX, MQTT / REST today, plus API-based data connection via Data Ingress / Push API. 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.
Grown infrastructure is normal.
Buildings rarely consist of a clean, uniform system. There are old controllers, new gateways, manufacturer portals, specialised devices, data gaps, and different protocols. MonitoringHive is designed to connect this reality in a controlled way, without treating every project as a special case.
We therefore separate clearly: what is technically supported today, what can be directly qualified, what is in preparation, and what must be modelled per project.
Four integration tiers
What is technically supported today, where direct paths exist, what is in preparation, and what is qualified per project.
Integration readiness is deliberately visible. Instead of a diffuse "can do anything in theory", there are four clearly separated tiers, matching the maturity and specificity of each source. Each tier is qualified in the project context based on device type, interface, data points, data quality, and operating mode.
TIER 01 · BASE TECHNICALLY SUPPORTED TODAY
Supported base protocols
MonitoringHive starts with a clear technical baseline for real integration projects. These protocols are technically backed and are qualified in the project context.
- Modbus TCP/IP
- Modbus RTU
- KNX
- MQTT / REST
TIER 02 · DIRECT PATH CODE-BACKED INTEGRATION PATH
Direct integration paths
Direct, code-backed integration paths exist for LAMPEC and TSE. They can be qualified per project for monitoring, alarms, data quality, and Studio analysis, without implying a formal manufacturer partnership or public reference.
- LAMPEC, direct integration path
- TSE, direct integration path
- Qualifiable per project
- No formal partnership implied
TIER 03 · COMING SOON IN PREPARATION
Coming soon
These integration paths are planned and should be considered early in project planning. They are not communicated as a baseline supported today.
- BACnet, planned
- M-Bus, planned
- OPC UA, planned
TIER 04 · PROJECT-SPECIFIC EXTENSIBLE
Project-specific, extensible
When a system cannot be connected via the supported baseline or a direct integration path, it is treated as a project-specific extension: adapter, device profile, data-point model, alarm and quality logic are deliberately defined.
- Proprietary interfaces
- Manufacturer-specific device profiles
- Customer-specific data models
- Special local requirements
Extensibility does not mean arbitrary ad-hoc connection. Extensibility means: model in a controlled way, integrate cleanly, and make it analysable over the long term.
Technically supported today
A clear technical foundation for real integration projects.
MonitoringHive starts with a clear technical foundation. The supported base protocols are technically backed and are qualified in the project context based on device type, interface, data points, data quality, and operating mode. For LAMPEC and TSE there are additional direct, code-backed 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.
Technically supported today
Technically supported · qualified per project
Supported base protocols.
These protocols are part of the platform logic and are technically supported for real integration projects. In the project, device type, interface, data points, data quality, and operating mode are concretely qualified.
Modbus TCP/IP
For IP-based devices, meters, controllers, and gateway connections.
Modbus RTU
For serial device and field-bus connections.
KNX
Building automation, group addresses, states, switching and measurement information.
MQTT / REST
Gateway or system data via structured messages and web interfaces.
Direct integration paths
Code-backed paths for specific systems
Direct integration path.
Direct, code-backed integration paths exist for LAMPEC and TSE. They can be qualified per project for monitoring, alarms, data quality, and Studio analysis, without implying a formal manufacturer partnership or public reference.
LAMPEC DIRECT PATH
Direct integration path for Bluetooth and wired system data, structured capture of states, telemetry, and service-relevant data points.
TSE DIRECT PATH
Direct integration path for system and emergency-lighting / safety-lighting data, telemetry and state data integrated into the data model.
Other systems PROJECT-SPECIFIC
Other integrations emerge project-driven. Which manufacturers, devices, or specialised systems are mapped depends on the concrete project scope.
No OEM and no partner status is derived from this. Which devices or specialised systems are relevant to your project, we review before project start and assign to one of the four integration tiers.
Contract model
Clear contracts between source, adapter, and platform.
Extensibility only works when responsibilities between the layers are cleanly cut.
Source
Asset / system
Manufacturer specifics, protocol details, status codes.
protocol-specific
manufacturer-specific codes
asset context
→ ADAPTER
CONTRACT
CONTRACT
Adapter
Profile / integration
Translates specifics into the platform data model.
Map data points
Normalise status codes
Version profiles
→ PLATFORM
API
API
Platform
Data model & telemetry
A stable, vendor-independent model. Sources stay replaceable.
Sites / assets / data points
Tenant-ready
Versioned API
Examples
What is typically connected on top.
A selection of real connection scenarios, with assigned integration path. The concrete status is agreed within the project.
Source
Interface
Data points (typical)
Tier
Modbus meter family
BASE
KNX building automation
BASE
Gateway / IoT system
BASE
LAMPEC systems
DIRECT
TSE systems
DIRECT
Building systems (BACnet)
COMING SOON
Meter / consumption data
COMING SOON
Industrial control systems
COMING SOON
Proprietary interface / CMMS
PROJECT-SPECIFIC
API-based data connection · usable today
Data Ingress / Push API, controlled data handover.
For systems that should deliver data actively, a controlled Data Ingress / Push interface is available. Defined data points can be handed over to MonitoringHive without unnecessarily opening up source systems.
- 01
Hand over defined data points actively
Source systems hand over specified values and time series over a controlled path to MonitoringHive, without broad network exposure of the source.
- 02
Reduced attack surface
Push-based data handover can reduce the attack surface, since source systems do not necessarily have to be queried directly or opened up for external access.
- 03
Further APIs per project
Further platform, partner, or OEM APIs are defined per project and rolled out step by step, not as a generic public product promise.
Usable today as a controlled ingress / push path. Scope, authentication, and data model are qualified per connection.
Sustainability
Extensibility must be sustainable in the project.
A supported protocol lowers the bar to entry. The long-term value, however, only emerges when device type, data points, states, data quality, operating model, and reusability are cleanly clarified.
Device type & manufacturer logic
Two devices with the same protocol may require different data points, registers, error codes, or state logic.
Data model
Price and project scope grow when data should not just be displayed but become usable as states, alarms, reports, or Studio analysis.
Reusability
A cleanly modelled adapter can later be reused for further sites, customers, or device families.
Offline operation needs up-front planning
Offline needs up-front planning.
In offline-hardened installations, the integration list is especially important because later extensions cannot simply be loaded remotely.
01
Systems & interfaces
Which assets, protocols, devices, and interfaces should be connected?
02
Data points & states
Which values, units, states, thresholds, and alarm rules are relevant?
03
Roles & access
Who may see, operate, or analyse which data?
04
Reports & later extensions
Which reports, exports, and later expansion steps must be prepared?
Show detailed preparation checklist
Systems & manufacturers
Which asset, device, and system families are connected at start, and which manufacturers play a role there.
Protocols
Which of the protocols supported today and which direct integration paths are actually needed on site.
Device types
Which device classes, controllers, meters, or subsystems should be represented in the data model.
Interfaces
Which industrial or specialised interfaces exist on site, and what preparation they require.
Data points
Which data points should be captured, normalised, and evaluated, including data quality and evaluation logic.
Alarm and state logic
Which thresholds, states, and service cases are defined as standard, and which are project-specific.
User roles
Who has read, write, or service rights, operator, service, OEM, external partners.
Reporting / export
Which analyses, reports, or exports may be carried out of hardened operation.
Later extensions
Which foreseeable extensions must be considered now to be added cleanly later.
Contact
Discuss your integration scope in a structured way.
We clarify with you which sources are sensibly connected via supported base protocols, which via direct integration paths, and which project-specific, and in what order. For offline-hardened installations we review the integration list before project start.