IAMMETER-Wi-Fi-Energiezähler können Messdaten direkt an einen vom Kunden kontrollierten Server, MQTT-Broker oder eine Datenplattform senden. Dies ermöglicht Entwicklern und Systemintegratoren, ihr eigenes EMS, BMS, IoT-Service, ihre eigene Datenbank oder ihr eigenes Überwachungs-Dashboard aufzubauen, ohne IAMMETER-Cloud als Datenziel zu verwenden.
Diese Anleitung nähert sich der Integration von der empfangenden Serverseite aus:
IAMMETER-Zähler
│
│ HTTP/HTTPS, MQTT/MQTTS oder TCP/TLS
▼
Kunden-Ingestion-Dienst
│
├── Rohdaten-Log
├── Zeitreihen- oder relationale Datenbank
├── EMS / BMS / ERP
└── Dashboard, Berichts- und Alarmdienste
Informationen zu den Fähigkeiten der Zähler-Firmware und zu den Adressformaten finden Sie im IAMMETER Local API and Open Interface Guide. Zur Auswahl der Architektur siehe Develop Your Own Energy Monitoring System.
Der Zähler kann seine Messwerte über verschiedene Transportwege übertragen. Das empfangende System sollte einen primären Erfassungspfad wählen.
| Transport | Empfängerkomponente | Guter Einstiegspunkt für |
|---|---|---|
| HTTP / HTTPS | Web-Endpunkt | REST-Backends und die einfachste erste Integration |
| MQTT / MQTTS | MQTT-Broker und Abonnent | Bestehende IoT-Plattformen und Nachrichtenpipelines |
| TCP / TLS | Socket-Listener | Dedizierte Sammelsysteme und benutzerdefinierte Protokolldienste |
HTTP ist normalerweise der einfachste Weg, um die erste Nutzlast zu inspizieren, da der offizielle Test-Empfänger mit einem kleinen Node.js-Beispiel gestartet werden kann. MQTT ist eine gute Wahl, wenn bereits ein Broker im System vorhanden ist. TCP/TLS bietet eine Socket-Integration auf niedrigerer Ebene, erfordert aber mehr Aufwand auf der Empfängerseite.
Die sicheren Transporte und benutzerdefinierten Portformate werden im aktuellen Firmware-Guide gepflegt und hier nicht wiederholt.
IAMMETER bietet ein offizielles Node.js-HTTP-Empfängerbeispiel für Integrationstests.
Laden Sie das Beispiel herunter von:
Führen Sie aus:
node Server.js
Das Beispiel lauscht auf Port 8000. Wenn eine Anfrage eintrifft, wird:
200 mit einer kleinen JSON-Erfolgsantwort zurückgegeben.Das Beispiel ist bewusst minimal gehalten. Es bietet keine Authentifizierung, Persistenz, Validierung, Ratenbegrenzung oder Produktionssicherheit.
Bevor Sie den Zähler konfigurieren, stellen Sie sicher, dass:
Für einen LAN-Test können der Zähler und der Empfänger dasselbe lokale Netzwerk ohne Internetzugang nutzen. Für einen entfernten Empfänger muss die Site eine Route zum Server haben.
Wählen Sie in der aktuellen Zähler-WebUI den HTTP-Ausführungsmodus und geben Sie ein Ziel wie folgt ein:
{server-adresse}:8000/upload
HTTPS-Endpunkte können den Standardport oder einen benutzerdefinierten Port verwenden. Die aktuellen Adressregeln, einschließlich https://host:port, sind im HTTP/HTTPS-Firmware-Abschnitt dokumentiert.
Nachdem Sie die Einstellung gespeichert haben, überprüfen Sie die Empfängerkonsole auf den Anforderungspfad und das hochgeladene JSON. Bewahren Sie diese erste rohe Nutzlast als Testvorlage für spätere Parser- und Datenbanktests auf.
IAMMETER verwendet eine konsistente Kern-Mess-JSON-Struktur über alle unterstützten Übertragungswege hinweg. Der Transportweg ändert, wie die Nutzlast ankommt, aber das Messmodell bleibt konsistent.
Eine Nutzlast enthält normalerweise feldspezifische Informationen wie:
SN — Seriennummer des Zählers zur Identifizierung des Geräts;version — Firmware-Version des Zählers;method — Nachrichtenmethode oder Nutzlasttyp;Data oder Datas — Messarrays.Data wird für einen einzelnen Messkanal verwendet. Datas enthält mehrere Messarrays für einen Mehrkanal- oder Dreiphasenzähler.
Beispiel für eine Einzelkanalstruktur:
{
"method": "uploadsn",
"mac": "B0F8932A295C",
"version": "i.75.98.71y",
"server": "em",
"SN": "12345678",
"Data": [228.91, 1.61, 225, 15066.47, 0]
}
Hartcodieren Sie nicht eine Array-Anzahl für jeden Zähler. Die Anzahl der Kanäle und verfügbaren Felder hängt vom Zählermodell und den aktivierten Messfunktionen ab.
Verwenden Sie die maßgebliche Definition bei der Implementierung des Parsers:
Halten Sie die modellspezifische Verarbeitung vom Transportempfänger getrennt.
Beispielsweise messen WEM3046T und WEM3046TE die 5-A-Sekundärausgabe eines externen Stromwandlers. Ihre Werte müssen mit dem entsprechenden CT-Übersetzungsverhältnis umgerechnet werden, um die primärseitige Messung zu erhalten. Dies ist eine Eigenschaft des Zählers und des Stromwandlers, kein Unterschied zwischen HTTP, MQTT oder TCP.
Eine praktische Erfassungspipeline trennt daher:
Speichern Sie ausreichend Informationen, um die ursprüngliche Messung reproduzieren und diagnostizieren zu können.
Ein nützliches Minimalmodell umfasst:
| Feld | Zweck |
|---|---|
| Zähler-SN | Ordnet die Nutzlast einem registrierten Gerät zu |
| Kanal- oder Phasenindex | Unterscheidet Einzelphasen-, Split-Phasen- und Dreiphasendaten |
| Server-Empfangszeit | Liefert einen konsistenten Erfassungszeitstempel |
| Spannung | Elektrische Messung |
| Strom | Elektrische Messung |
| Wirkleistung | Echtzeit-Import/Export oder Lastberechnungseingabe |
| Import-kWh | Kumulierte importierte Energie |
| Export-kWh | Kumulierte exportierte Energie |
| Firmware-Version | Unterstützt Fehlerbehebung und Parser-Kompatibilität |
| Rohdaten-Nutzlast | Ermöglicht Wiedergabe, Prüfung und Parser-Korrektur |
Zusätzliche Felder wie Frequenz, Leistungsfaktor und Blindleistungsmessungen sollten gespeichert werden, wenn das ausgewählte Modell und die Konfiguration diese bereitstellen.
Für Produktionssysteme sollten Sie in Betracht ziehen, Folgendes getrennt zu halten:
Dies erleichtert die Korrektur von Parsing- oder CT-Übersetzungslogik, ohne die ursprüngliche Nutzlast zu verlieren.
Zeichnen Sie die Zeit auf, zu der der Server die Nutzlast akzeptiert hat. Wenn das Geschäftssystem auch einen Geräte- oder Quellzeitstempel verwendet, speichern Sie beide Werte getrennt, anstatt einen durch den anderen zu ersetzen.
Netzwerkverzögerungen, Wiederverbindungen und Warteschlangenverarbeitung können die Erfassungszeit von der Messzeit unterscheiden. Legen Sie den Zeitstempel fest, der von Diagrammen, Abrechnungen und Alarmen verwendet wird, bevor Sie in Produktion gehen.
Für die MQTT-Erfassung stellt das Kundensystem bereit:
IAMMETER veröffentlicht Echtzeitdaten unter einem Gerätethema wie:
device/{SN}/realtime
Verwenden Sie die dedizierte Anleitung für die Broker-Konfiguration, Anmeldedaten, Themen und MQTTS-Überlegungen:
Home Assistant MQTT Discovery ist für eine allgemeine Kunden-Server-Integration nicht erforderlich.
IAMMETER bietet einen minimalen Node.js-TCP-Listener:
Das Beispiel lauscht auf Port 8000 und gibt empfangene Daten aus. Ein TCP-Produktionsempfänger muss zusätzlich Folgendes bereitstellen:
Gehen Sie nicht davon aus, dass ein einziges Socket-data-Ereignis immer einer vollständigen Anwendungsnachricht entspricht.
Das offizielle TLS-Beispiel demonstriert einen TLS-Listener mit einem Serverschlüssel und -zertifikat:
Ersetzen Sie vor dem Produktionseinsatz die Demonstrationszertifikate und -einstellungen durch die genehmigten Zertifikate, Schlüsselverwaltungs- und Sicherheitskonfigurationen der Organisation. Der Empfänger sollte TLS-Fehler getrennt von Nutzlastvalidierungsfehlern protokollieren.
Die zählerseitigen Adressformate für TCP und TLS werden im Firmware-Interface-Guide gepflegt.
Die aktuelle Firmware unterstützt ein Drittanbieter-Upload-Intervall bis hinunter zu 2 Sekunden. Ein kurzes Intervall ist nur dann nützlich, wenn das empfangende System, der Speicher und die Anwendung die zusätzliche Auflösung benötigen.
Ungefähre Datensätze pro Zähler:
| Upload-Intervall | Datensätze pro Zähler pro Tag | 100 Zähler pro Tag | 1.000 Zähler pro Tag |
|---|---|---|---|
| 60 Sekunden | 1.440 | 144.000 | 1.440.000 |
| 10 Sekunden | 8.640 | 864.000 | 8.640.000 |
| 2 Sekunden | 43.200 | 4.320.000 | 43.200.000 |
Diese Zahlen stellen Upload-Ereignisse dar, nicht unbedingt Datenbankzeilen. Eine Dreiphasen-Nutzlast kann in mehrere Kanaldatensätze normalisiert werden, und Indizes, Rohdatenaufbewahrung oder replizierter Speicher erhöhen das tatsächliche Datenbankvolumen.
Die Kapazitätsplanung sollte Folgendes umfassen:
Für Ein-Sekunden-Steuerung oder Automatisierung im selben LAN ziehen Sie Modbus TCP in Betracht, anstatt eine entfernte Upload-Pipeline zu verwenden.
Ein Produktionsempfänger sollte Netzwerk- und Anwendungsfehler erwarten.
Validieren Sie mindestens:
Halten Sie fehlerhafte Nutzlasten in einem kontrollierten Diagnosepfad, ohne dass sie gültige Geräte blockieren können.
Gehen Sie nicht davon aus, dass jedes Intervall genau einen dauerhaft gespeicherten Datensatz erzeugt. Netzwerkunterbrechungen, Wiederverbindungsverhalten, Server-Wiederholungen oder Anwendungsverarbeitung können fehlende oder wiederholte Erfassungsereignisse erzeugen.
Legen Sie fest, wie das Geschäftssystem:
Überwachen Sie mehr als nur den Web- oder Socket-Prozess. Nützliche Signale umfassen:
Für einen internetzugänglichen Empfänger:
Überprüfen Sie das aktuelle MQTTS-, TLS- und HTTPS-Firmwareverhalten im Firmware- und Open-Interface-Guide, bevor Sie ein Sicherheitsdesign auswählen.
Die ursprüngliche Version dieses Dokuments konzentrierte sich auf die Konfiguration älterer Zähler-Firmware. Diese Screenshots werden nur für Benutzer beibehalten, die eine bestehende Installation identifizieren. Verwenden Sie für neue Integrationen die aktuelle WebUI und die neueste Firmware.
Die frühere Firmware-Dokumentation verwendete auch die lokale /api/uploadinterval-Konfigurationsmethode und beschrieb ein Minimum von sechs Sekunden. Die aktuelle Firmware zeigt das Intervall in der WebUI an und unterstützt ein dokumentiertes Minimum von 2 Sekunden.
Zuletzt aktualisiert: 16. Juli 2026
Dreiphasiger Wi-Fi-Energiezähler (WEM3080T)
Einphasiger Wi-Fi-Energiezähler (WEM3080)
Dreiphasiger Wi-Fi-Energiezähler (WEM3046T)
Dreiphasiger Wi-Fi-Energiezähler (WEM3050T)