I contatori energetici Wi-Fi IAMMETER possono inviare i dati di misura direttamente a un server, broker MQTT o piattaforma dati controllata dal cliente. Questo consente a sviluppatori e integratori di sistema di costruire il proprio EMS, BMS, servizio IoT, database o dashboard di monitoraggio senza utilizzare IAMMETER-Cloud come destinazione dei dati.
Questa guida affronta l'integrazione dal lato del server ricevente:
Contatore IAMMETER
│
│ HTTP/HTTPS, MQTT/MQTTS o TCP/TLS
▼
Servizio di acquisizione del cliente
│
├── Log del payload grezzo
├── Database time-series o relazionale
├── EMS / BMS / ERP
└── Dashboard, servizi di reportistica e allarmi
Per le capacità del firmware lato contatore e i formati degli indirizzi, consulta la Guida alle API Locali e alle Interfacce Aperte IAMMETER. Per la scelta dell'architettura, vedi Sviluppa il Tuo Sistema di Monitoraggio Energetico.
Il contatore può inviare le sue misurazioni utilizzando diversi trasporti. Il sistema ricevente dovrebbe selezionare un percorso di acquisizione principale.
| Trasporto | Componente del ricevitore | Buon punto di partenza per |
|---|---|---|
| HTTP / HTTPS | Endpoint web | Backend REST e la prima integrazione più semplice |
| MQTT / MQTTS | Broker MQTT e subscriber | Piattaforme IoT esistenti e pipeline di messaggi |
| TCP / TLS | Listener socket | Collettori dedicati e servizi di protocollo personalizzati |
HTTP è normalmente il modo più semplice per ispezionare il primo payload perché il ricevitore di test ufficiale può essere avviato con un piccolo esempio Node.js. MQTT è una scelta valida quando un broker fa già parte del sistema. TCP/TLS fornisce un'integrazione socket di livello inferiore ma richiede più ingegneria lato ricevitore.
I trasporti sicuri e i formati delle porte personalizzate sono mantenuti nella guida corrente del firmware, piuttosto che essere ripetuti qui.
IAMMETER fornisce un esempio ufficiale di ricevitore HTTP Node.js per i test di integrazione.
Scarica l'esempio da:
Esegui:
node Server.js
L'esempio è in ascolto sulla porta 8000. Quando arriva una richiesta:
200 con una piccola risposta JSON di successo.L'esempio è volutamente minimale. Non fornisce autenticazione, persistenza, validazione, limitazione della frequenza o sicurezza di produzione.
Prima di configurare il contatore, conferma che:
Per un test in LAN, il contatore e il ricevitore possono usare la stessa rete locale senza accesso a Internet. Per un ricevitore remoto, il sito deve avere un percorso verso il server.
Nella WebUI corrente del contatore, seleziona la modalità di esecuzione HTTP e inserisci una destinazione come:
{indirizzo-server}:8000/upload
Gli endpoint HTTPS possono utilizzare la porta predefinita o una porta personalizzata. Le regole correnti per gli indirizzi, inclusi https://host:port, sono documentate nella sezione firmware HTTP/HTTPS.
Dopo aver salvato l'impostazione, controlla la console del ricevitore per il percorso della richiesta e il JSON caricato. Conserva questo primo payload grezzo come fixture di test per i successivi test del parser e del database.
IAMMETER utilizza una struttura JSON di misurazione principale coerente attraverso i trasporti di push supportati. Il trasporto cambia il modo in cui il payload arriva, ma il modello di misurazione rimane coerente.
Un payload normalmente include campi a livello di dispositivo come:
SN — numero di serie del contatore utilizzato per identificare il dispositivo;version — versione del firmware del contatore;method — metodo del messaggio o tipo di payload;Data o Datas — array di misurazioni.Data viene utilizzato per un singolo canale di misurazione. Datas contiene più array di misurazioni per un contatore multicanale o trifase.
Esempio di struttura a canale singolo:
{
"method": "uploadsn",
"mac": "B0F8932A295C",
"version": "i.75.98.71y",
"server": "em",
"SN": "12345678",
"Data": [228.91, 1.61, 225, 15066.47, 0]
}
Non硬编码are un conteggio di array per ogni contatore. Il numero di canali e i campi disponibili dipendono dal modello di contatore e dalle funzionalità di misurazione abilitate.
Utilizza la definizione autorevole quando implementi il parser:
Mantieni l'elaborazione specifica per modello separata dal ricevitore di trasporto.
Ad esempio, WEM3046T e WEM3046TE misurano l'uscita secondaria da 5 A di un trasformatore di corrente esterno. I loro valori devono essere convertiti con il rapporto CT applicabile per ottenere la misurazione lato primario. Questa è una caratteristica del contatore e del CT, non una differenza di HTTP, MQTT o TCP.
Una pipeline di acquisizione pratica quindi separa:
Memorizza informazioni sufficienti per riprodurre e diagnosticare la lettura originale.
Un modello minimo utile include:
| Campo | Scopo |
|---|---|
| SN del contatore | Mappa il payload a un dispositivo registrato |
| Indice del canale o della fase | Distingue i dati monofase, bifase e trifase |
| Ora di ricezione del server | Fornisce un timestamp di acquisizione coerente |
| Tensione | Misurazione elettrica |
| Corrente | Misurazione elettrica |
| Potenza attiva | Ingresso/uscita in tempo reale o input per il calcolo del carico |
| kWh importati | Energia importata cumulativa |
| kWh esportati | Energia esportata cumulativa |
| Versione firmware | Supporta la risoluzione dei problemi e la compatibilità del parser |
| Payload grezzo | Consente replay, audit e correzione del parser |
Campi aggiuntivi come frequenza, fattore di potenza e misurazioni reattive dovrebbero essere memorizzati quando il modello selezionato e la configurazione li forniscono.
Per i sistemi di produzione, considera di mantenere:
Questo facilita la correzione della logica di parsing o del rapporto CT senza perdere il payload originale.
Registra l'ora in cui il server ha accettato il payload. Se il sistema aziendale utilizza anche un timestamp del dispositivo o della sorgente, memorizza entrambi i valori separatamente invece di sostituire l'uno con l'altro.
Il ritardo di rete, le riconnessioni e l'elaborazione in coda possono rendere l'ora di acquisizione diversa dall'ora di misurazione. Definisci il timestamp utilizzato per grafici, fatturazione e allarmi prima della distribuzione in produzione.
Per l'acquisizione MQTT, il sistema del cliente fornisce:
IAMMETER pubblica dati in tempo reale sotto un topic del dispositivo come:
device/{SN}/realtime
Utilizza la guida dedicata per la configurazione del broker, le credenziali, i topic e le considerazioni MQTTS:
La scoperta MQTT di Home Assistant non è richiesta per un'integrazione generale server-cliente.
IAMMETER fornisce un listener TCP Node.js minimale:
L'esempio è in ascolto sulla porta 8000 e stampa i dati ricevuti. Un ricevitore TCP di produzione deve inoltre fornire:
Non assumere che un evento socket data corrisponda sempre a un messaggio applicativo completo.
L'esempio TLS ufficiale dimostra un listener TLS con una chiave del server e un certificato:
Prima dell'uso in produzione, sostituisci i certificati e le impostazioni dimostrative con il certificato, la gestione delle chiavi e la configurazione di sicurezza approvati dall'organizzazione. Il ricevitore dovrebbe registrare separatamente i fallimenti TLS dai fallimenti di validazione del payload.
I formati degli indirizzi lato contatore per TCP e TLS sono mantenuti nella guida delle interfacce del firmware.
Il firmware corrente supporta un intervallo di upload verso terze parti fino a 2 secondi. Un intervallo breve è utile solo quando il sistema ricevente, l'archiviazione e l'applicazione necessitano della risoluzione aggiuntiva.
Record approssimativi generati per contatore:
| Intervallo di upload | Record per contatore al giorno | 100 contatori al giorno | 1.000 contatori al giorno |
|---|---|---|---|
| 60 secondi | 1.440 | 144.000 | 1.440.000 |
| 10 secondi | 8.640 | 864.000 | 8.640.000 |
| 2 secondi | 43.200 | 4.320.000 | 43.200.000 |
Questi numeri rappresentano eventi di upload, non necessariamente righe del database. Un payload trifase può essere normalizzato in diversi record di canale, e gli indici, la conservazione del payload grezzo o l'archiviazione replicata aumentano il volume effettivo del database.
La pianificazione della capacità dovrebbe includere:
Per controllo o automazione al secondo sulla stessa LAN, considera Modbus TCP invece di utilizzare una pipeline di upload remota.
Un ricevitore di produzione dovrebbe aspettarsi guasti di rete e applicativi.
Valida almeno:
Mantieni i payload malformati in un percorso diagnostico controllato senza permettere loro di bloccare i dispositivi validi.
Non assumere che ogni intervallo produca esattamente un record永久emente memorizzato. Interruzioni di rete, comportamento di riconnessione, tentativi del server o elaborazione applicativa possono produrre eventi di acquisizione mancanti o ripetuti.
Definisci come il sistema aziendale:
Monitora più del semplice processo web o socket. Segnali utili includono:
Per un ricevitore esposto a Internet:
Consulta il comportamento corrente del firmware MQTTS, TLS e HTTPS nella guida del firmware e delle interfacce aperte prima di selezionare una progettazione di sicurezza.
La versione originale di questo documento si concentrava sulla configurazione del firmware più vecchio del contatore. Questi screenshot sono mantenuti solo per gli utenti che identificano un'installazione esistente. Per le nuove integrazioni, utilizza la WebUI corrente e il firmware più recente.
La documentazione precedente del firmware utilizzava anche il metodo di configurazione locale /api/uploadinterval e descriveva un minimo di sei secondi. Il firmware corrente espone l'intervallo nella WebUI e supporta un minimo documentato di 2 secondi.
Ultimo aggiornamento: 16 luglio 2026
Contatore di energia Wi-Fi trifase (WEM3080T)
Contatore di energia Wi-Fi monofase (WEM3080)
Contatore di energia Wi-Fi trifase (WEM3046T)
Contatore di energia Wi-Fi trifase (WEM3050T)