Protokollreife
Heute technisch unterstützte Protokolle sind anders zu planen als Coming-Soon-Integrationen oder projektspezifische Erweiterungen.
Plattform · Erweiterbarkeit
Modbus, KNX, MQTT und kommende BACnet-Integration, eine Plattform für reale Gebäudeinfrastruktur.
MonitoringHive unterstützt heute Modbus TCP/IP, Modbus RTU, KNX, MQTT / REST sowie API-basierte Datenanbindung über Data Ingress / Push API. BACnet, M-Bus und OPC UA sind in Vorbereitung. Weiterführende Plattform-, Partner- oder OEM-APIs werden projektbezogen definiert und schrittweise ausgebaut.
Gewachsene Infrastruktur ist normal.
Gebäude bestehen selten aus einem sauberen, einheitlichen System. Es gibt alte Steuerungen, neue Gateways, Herstellerportale, Spezialgeräte, Datenlücken und unterschiedliche Protokolle. MonitoringHive ist dafür gedacht, diese Realität kontrolliert anzubinden, ohne jedes Projekt als Sonderfall zu behandeln.
Deshalb trennen wir klar: was heute technisch unterstützt ist, was direkt qualifiziert werden kann, was in Vorbereitung ist und was projektspezifisch modelliert werden muss.
Vier Integrationsstufen
Was heute technisch unterstützt ist, wo direkte Pfade bestehen, was in Vorbereitung ist und was projektspezifisch qualifiziert wird.
Integrationsreife ist bewusst sichtbar. Statt eines diffusen „kann theoretisch alles" gibt es vier klar getrennte Stufen, passend zur Reife und Spezifität der jeweiligen Quelle. Jede Stufe wird im Projektkontext anhand von Gerätetyp, Schnittstelle, Datenpunkten, Datenqualität und Betriebsart qualifiziert.
STUFE 01 · BASIS HEUTE TECHNISCH UNTERSTÜTZT
Unterstützte Basisprotokolle
MonitoringHive startet mit einer klaren technischen Basis für reale Integrationsprojekte. Diese Protokolle sind technisch hinterlegt und werden im Projektkontext qualifiziert.
- Modbus TCP/IP
- Modbus RTU
- KNX
- MQTT / REST
STUFE 02 · DIREKTER PFAD CODEGESTÜTZTER INTEGRATIONSPFAD
Direkte Integrationspfade
Für LAMPEC und TSE bestehen direkte, codegestützte Integrationspfade. Sie können projektspezifisch für Monitoring, Alarme, Datenqualität und Studio-Auswertungen qualifiziert werden, ohne daraus eine formale Herstellerpartnerschaft oder öffentliche Referenz abzuleiten.
- LAMPEC, direkter Integrationspfad
- TSE, direkter Integrationspfad
- Projektbezogen qualifizierbar
- Keine formale Partnerschaft impliziert
STUFE 03 · BALD VERFÜGBAR IN VORBEREITUNG
Bald verfügbar
Diese Integrationspfade sind vorgesehen und sollten bei Projektplanung früh berücksichtigt werden. Sie werden aber nicht als heute unterstützte Basis kommuniziert.
- BACnet, geplant
- M-Bus, geplant
- OPC UA, geplant
STUFE 04 · PROJEKTSPEZIFISCH ERWEITERBAR
Projektspezifisch erweiterbar
Wenn ein System nicht über die unterstützte Basis oder einen direkten Integrationspfad angebunden werden kann, wird es als projektspezifische Erweiterung behandelt: Adapter, Geräteprofil, Datenpunktmodell, Alarm- und Qualitätslogik werden bewusst definiert.
- Proprietäre Schnittstellen
- Herstellerspezifische Geräteprofile
- Kundenspezifische Datenmodelle
- Spezielle lokale Anforderungen
Erweiterbarkeit bedeutet nicht beliebige Ad-hoc-Anbindung. Erweiterbarkeit bedeutet: kontrolliert modellieren, sauber integrieren und langfristig auswertbar machen.
Heute technisch unterstützt
Eine klare technische Basis für reale Integrationsprojekte.
MonitoringHive startet mit einer klaren technischen Basis. Die unterstützten Basisprotokolle sind technisch hinterlegt und werden im Projektkontext anhand von Gerätetyp, Schnittstelle, Datenpunkten, Datenqualität und Betriebsart qualifiziert. Für LAMPEC und TSE bestehen zusätzlich direkte, codegestützte Integrationspfade. BACnet, M-Bus und OPC UA sind in Vorbereitung. Weiterführende Plattform-, Partner- oder OEM-APIs werden projektbezogen definiert und schrittweise ausgebaut.
Heute technisch unterstützt
Technisch unterstützt · projektbezogen qualifiziert
Unterstützte Basisprotokolle.
Diese Protokolle sind Bestandteil der Plattformlogik und werden für reale Integrationsprojekte technisch unterstützt. Im Projekt werden Gerätetyp, Schnittstelle, Datenpunkte, Datenqualität und Betriebsart konkret qualifiziert.
Modbus TCP/IP
Für IP-basierte Geräte, Zähler, Steuerungen und Gateway-Anbindungen.
Modbus RTU
Für serielle Geräte- und Feldbusanbindungen.
KNX
Gebäudeautomation, Gruppenadressen, Zustände, Schalt- und Messinformationen.
MQTT / REST
Gateway- oder Systemdaten über strukturierte Nachrichten und Webschnittstellen.
Direkte Integrationspfade
Codegestützte Pfade für konkrete Systeme
Direkter Integrationspfad.
Für LAMPEC und TSE bestehen direkte, codegestützte Integrationspfade. Sie können projektspezifisch für Monitoring, Alarme, Datenqualität und Studio-Auswertungen qualifiziert werden, ohne daraus eine formale Herstellerpartnerschaft oder öffentliche Referenz abzuleiten.
LAMPEC DIREKTER PFAD
Direkter Integrationspfad für Bluetooth- und drahtgebundene Systemdaten, strukturierte Erfassung von Zuständen, Telemetrie und servicerelevanten Datenpunkten.
TSE DIREKTER PFAD
Direkter Integrationspfad für System- und Notlicht-/Sicherheitsbeleuchtungsdaten, Telemetrie und Zustandsdaten in das Datenmodell integriert.
Weitere Systeme PROJEKTBEZOGEN
Weitere Integrationen entstehen projektgetrieben. Welche Hersteller, Geräte oder Spezialsysteme abgebildet werden, hängt vom konkreten Projektrahmen ab.
Kein OEM- und kein Partnerstatus wird daraus abgeleitet. Welche Geräte oder Spezialsysteme für Ihr Projekt relevant sind, prüfen wir vor Projektstart und ordnen sie einer der vier Integrationsstufen zu.
Vertragsmodell
Klare Verträge zwischen Quelle, Adapter und Plattform.
Erweiterbarkeit funktioniert nur, wenn die Verantwortlichkeiten zwischen den Schichten sauber geschnitten sind.
Quelle
Anlage / System
Hersteller-Eigenheiten, Protokoll-Spezifika, Statuscodes.
protokoll-spezifisch
herstellereigene Codes
Anlagenkontext
→ ADAPTER
VERTRAG
VERTRAG
Adapter
Profil / Integration
Übersetzt Eigenheiten in das Plattform-Datenmodell.
Datenpunkte mappen
Statuscodes normalisieren
Profile versionieren
→ PLATTFORM
API
API
Plattform
Datenmodell & Telemetrie
Stabiles, herstellerunabhängiges Modell. Quellen bleiben austauschbar.
Standorte / Anlagen / Datenpunkte
Mandantenfähig
Versionierte API
Beispiele
Was darüber typischerweise angebunden wird.
Eine Auswahl realer Anbindungsszenarien, mit zugeordnetem Integrationspfad. Der konkrete Stand wird im Projekt abgestimmt.
Quelle
Schnittstelle
Datenpunkte (typisch)
Stufe
Modbus-Zähler-Familie
BASIS
KNX-Gebäudeautomation
BASIS
Gateway / IoT-System
BASIS
LAMPEC-Systeme
DIREKT
TSE-Systeme
DIREKT
Gebäudetechnik (BACnet)
BALD VERFÜGBAR
Zähler-/Verbrauchsdaten
BALD VERFÜGBAR
Industrielle Leitsysteme
BALD VERFÜGBAR
Proprietäre Schnittstelle / CMMS
PROJEKTSPEZIFISCH
API-basierte Datenanbindung · heute nutzbar
Data Ingress / Push API, kontrollierte Datenübergabe.
Für Systeme, die Daten aktiv liefern sollen, steht eine kontrollierte Data-Ingress-/Push-Schnittstelle zur Verfügung. Dadurch können definierte Datenpunkte an MonitoringHive übergeben werden, ohne Quellsysteme unnötig breit zu öffnen.
- 01
Definierte Datenpunkte aktiv übergeben
Quellsysteme übergeben festgelegte Werte und Zeitreihen über einen kontrollierten Pfad an MonitoringHive, ohne breite Netzöffnung der Quelle.
- 02
Reduzierte Angriffsfläche
Push-basierte Datenübergabe kann die Angriffsfläche reduzieren, weil Quellsysteme nicht zwingend direkt abgefragt oder für externe Zugriffe geöffnet werden müssen.
- 03
Weiterführende APIs projektbezogen
Weiterführende Plattform-, Partner- oder OEM-APIs werden projektbezogen definiert und schrittweise ausgebaut, nicht als allgemeines öffentliches Produktversprechen.
Heute nutzbar als kontrollierter Ingress-/Push-Pfad. Umfang, Authentifizierung und Datenmodell werden pro Anbindung qualifiziert.
Tragfähigkeit
Erweiterbarkeit muss im Projekt tragfähig sein.
Ein unterstütztes Protokoll reduziert den Einstieg. Der langfristige Wert entsteht aber erst, wenn Gerätetyp, Datenpunkte, Zustände, Datenqualität, Betriebsmodell und Wiederverwendbarkeit sauber geklärt sind.
Gerätetyp & Herstellerlogik
Zwei Geräte mit gleichem Protokoll können unterschiedliche Datenpunkte, Register, Fehlercodes oder Zustandslogiken benötigen.
Datenmodell
Preis- und Projektumfang steigen, wenn Daten nicht nur angezeigt, sondern als Zustände, Alarme, Reports oder Studio-Auswertungen nutzbar werden sollen.
Wiederverwendbarkeit
Ein sauber modellierter Adapter kann später für weitere Standorte, Kunden oder Gerätefamilien wiederverwendet werden.
Offline-Betrieb braucht Vorplanung
Offline braucht Vorplanung.
Bei offline gehärteten Installationen ist die Integrationsliste besonders wichtig, weil spätere Erweiterungen nicht einfach remote nachgeladen werden können.
01
Systeme & Schnittstellen
Welche Anlagen, Protokolle, Geräte und Schnittstellen sollen angebunden werden?
02
Datenpunkte & Zustände
Welche Werte, Einheiten, Zustände, Grenzwerte und Alarmregeln sind relevant?
03
Rollen & Zugriff
Wer darf welche Daten sehen, bedienen oder auswerten?
04
Reports & spätere Erweiterungen
Welche Berichte, Exporte und späteren Ausbauschritte müssen vorbereitet werden?
Detaillierte Vorbereitungsliste anzeigen
Systeme & Hersteller
Welche Anlagen-, Geräte- und Systemfamilien beim Start angebunden werden, und welche Hersteller dabei eine Rolle spielen.
Protokolle
Welche der heute unterstützten Protokolle und welche direkten Integrationspfade vor Ort tatsächlich gebraucht werden.
Gerätetypen
Welche Geräteklassen, Steuerungen, Zähler oder Subsysteme im Datenmodell abgebildet werden sollen.
Schnittstellen
Welche Industrie- oder Spezialschnittstellen am Standort vorhanden sind und welche Vorbereitung sie benötigen.
Datenpunkte
Welche Datenpunkte erfasst, normalisiert und bewertet werden sollen, inkl. Datenqualität und Bewertungslogik.
Alarm- und Zustandslogik
Welche Schwellen, Zustände und Servicefälle als Standard und welche projektspezifisch definiert werden.
Nutzerrollen
Wer Lese-, Schreib- oder Servicerechte hat, Betreiber, Service, OEM, externe Partner.
Reporting / Export
Welche Auswertungen, Reports oder Exporte aus dem gehärteten Betrieb herausgeführt werden dürfen.
Spätere Erweiterungen
Welche absehbaren Erweiterungen jetzt schon mitgedacht werden müssen, um sie später sauber einzubringen.
Kontakt
Integrationsbedarf strukturiert besprechen.
Wir klären mit Ihnen, welche Quellen über unterstützte Basisprotokolle, welche über direkte Integrationspfade und welche projektspezifisch sinnvoll angebunden werden, und in welcher Reihenfolge. Für offline gehärtete Installationen prüfen wir die Integrationsliste vor Projektstart.