Terima Data Energi IAMMETER di Server Anda Sendiri

Terima Data Energi IAMMETER di Server Anda Sendiri

Meter energi Wi-Fi IAMMETER dapat mengirim data pengukuran langsung ke server, broker MQTT, atau platform data yang dikendalikan oleh pelanggan. Hal ini memungkinkan pengembang dan integrator sistem membangun EMS, BMS, layanan IoT, basis data, atau dasbor pemantauan mereka sendiri tanpa menggunakan IAMMETER-Cloud sebagai tujuan data.

Panduan ini membahas integrasi dari sisi server penerima:

• menyiapkan penerima uji;
• menangkap payload meter pertama;
• mengidentifikasi meter dan kanal pengukuran;
• menormalisasi dan menyimpan data;
• memperkirakan volume ingest;
• mempersiapkan penerima untuk penerapan produksi.

Meter IAMMETER
      │
      │ HTTP/HTTPS, MQTT/MQTTS atau TCP/TLS
      ▼
Layanan ingest pelanggan
      │
      ├── Log payload mentah
      ├── Basis data time-series atau relasional
      ├── EMS / BMS / ERP
      └── Layanan dasbor, laporan, dan alarm

Untuk kemampuan firmware di sisi meter dan format alamat, gunakan Panduan API Lokal dan Antarmuka Terbuka IAMMETER. Untuk pemilihan arsitektur, lihat Kembangkan Sistem Pemantauan Energi Anda Sendiri.

1. Pilih Arsitektur Penerima

Meter dapat mengirimkan hasil pengukurannya melalui beberapa transport. Sistem penerima sebaiknya memilih satu jalur ingest utama.

Transport	Komponen penerima	Titik awal yang baik untuk
HTTP / HTTPS	Endpoint web	Backend REST dan integrasi pertama yang paling sederhana
MQTT / MQTTS	Broker dan subscriber MQTT	Platform IoT yang sudah ada dan pipeline pesan
TCP / TLS	Socket listener	Kolektor khusus dan layanan protokol kustom

HTTP biasanya merupakan cara termudah untuk memeriksa payload pertama karena penerima uji resmi dapat dijalankan dengan contoh Node.js yang kecil. MQTT adalah pilihan yang kuat ketika broker sudah menjadi bagian dari sistem. TCP/TLS menyediakan integrasi socket tingkat lebih rendah tetapi memerlukan rekayasa sisi penerima yang lebih banyak.

Transport aman dan format port kustom dipelihara di panduan firmware terkini, dan tidak diulang di sini.

2. Mulai Cepat: Terima Payload Pertama melalui HTTP

IAMMETER menyediakan contoh penerima HTTP Node.js resmi untuk pengujian integrasi.

2.1 Jalankan Penerima Uji

Unduh contoh dari:

• Contoh Server HTTP IAMMETER di GitHub

Jalankan:

node Server.js

Contoh ini mendengarkan pada port 8000. Saat permintaan tiba, program tersebut:

• mengumpulkan body permintaan HTTP;
• mencetak URL permintaan;
• mencetak body yang diunggah;
• mengembalikan status HTTP 200 dengan respons JSON sukses yang kecil.

Contoh ini sengaja dibuat minimal. Contoh ini tidak menyediakan autentikasi, persistensi, validasi, pembatasan laju, atau keamanan produksi.

2.2 Pastikan Penerima Dapat Dijangkau

Sebelum mengonfigurasi meter, pastikan bahwa:

• server mendengarkan pada antarmuka dan port yang diharapkan;
• firewall mengizinkan koneksi;
• meter dapat me-resolve nama domain saat domain digunakan;
• jalur NAT, reverse proxy, atau VPN berfungsi;
• URL akhir mencapai rute aplikasi yang dituju.

Untuk pengujian LAN, meter dan penerima dapat menggunakan jaringan lokal yang sama tanpa akses Internet. Untuk penerima jarak jauh, lokasi tersebut harus memiliki rute ke server.

2.3 Arahkan Meter ke Penerima

Di WebUI meter terkini, pilih mode jalan HTTP dan masukkan tujuan seperti:

{server-address}:8000/upload

Endpoint HTTPS dapat menggunakan port default atau port kustom. Aturan alamat terkini, termasuk https://host:port, didokumentasikan di bagian firmware HTTP/HTTPS.

Setelah menyimpan pengaturan, periksa konsol penerima untuk melihat jalur permintaan dan JSON yang diunggah. Simpan payload mentah pertama ini sebagai fixture pengujian untuk pengujian parser dan basis data selanjutnya.

3. Pahami Payload IAMMETER yang Masuk

IAMMETER menggunakan struktur JSON pengukuran inti yang konsisten di seluruh transport push yang didukung. Transport mengubah cara payload tiba, tetapi model pengukurannya tetap konsisten.

Payload biasanya mencakup field tingkat perangkat seperti:

• SN — nomor seri meter yang digunakan untuk mengidentifikasi perangkat;
• version — versi firmware meter;
• method — metode pesan atau jenis payload;
• Data atau Datas — array pengukuran.

Data digunakan untuk satu kanal pengukuran. Datas berisi beberapa array pengukuran untuk meter multi-kanal atau tiga fase.

Contoh struktur satu kanal:

{
  "method": "uploadsn",
  "mac": "B0F8932A295C",
  "version": "i.75.98.71y",
  "server": "em",
  "SN": "12345678",
  "Data": [228.91, 1.61, 225, 15066.47, 0]
}

Jangan meng-hard-code jumlah array yang sama untuk setiap meter. Jumlah kanal dan field yang tersedia bergantung pada model meter dan fitur pengukuran yang diaktifkan.

Gunakan definisi resmi berikut saat mengimplementasikan parser:

• Definisi Data JSON Meter Energi IAMMETER

3.1 Pemrosesan Khusus Model

Pisahkan pemrosesan khusus model dari penerima transport.

Misalnya, WEM3046T dan WEM3046TE mengukur keluaran sekunder 5 A dari transformator arus eksternal. Nilainya harus dikonversi dengan rasio CT yang berlaku untuk mendapatkan pengukuran sisi primer. Ini adalah karakteristik meter dan CT, bukan perbedaan HTTP, MQTT, atau TCP.

Pipeline ingest yang praktis karena itu memisahkan:

1. dekode transport;
2. validasi JSON;
3. identifikasi meter dan kanal;
4. penskalaan atau normalisasi khusus model;
5. penyimpanan dan perhitungan bisnis.

4. Rancang Model Data Ingest

Simpan informasi yang cukup untuk mereproduksi dan mendiagnosis pembacaan asli.

Model minimum yang berguna mencakup:

Field	Tujuan
Meter SN	Memetakan payload ke perangkat yang terdaftar
Indeks kanal atau fase	Membedakan data satu fase, split-phase, dan tiga fase
Waktu penerimaan server	Memberikan stempel waktu ingest yang konsisten
Tegangan	Pengukuran listrik
Arus	Pengukuran listrik
Daya aktif	Input perhitungan impor/ekspor waktu nyata atau beban
kWh impor	Energi impor kumulatif
kWh ekspor	Energi ekspor kumulatif
Versi firmware	Mendukung pemecahan masalah dan kompatibilitas parser
Payload mentah	Memungkinkan replay, audit, dan koreksi parser

Field tambahan seperti frekuensi, faktor daya, dan pengukuran reaktif harus disimpan ketika model dan konfigurasi yang dipilih menyediakannya.

4.1 Pisahkan Data Mentah dan Data Ternormalisasi

Untuk sistem produksi, pertimbangkan untuk menyimpan:

• catatan ingest mentah yang tidak dapat diubah atau disimpan dalam waktu singkat;
• pembacaan tingkat kanal yang sudah dinormalisasi yang digunakan aplikasi;
• nilai agregat per jam, harian, dan bulanan.

Hal ini memudahkan koreksi logika parsing atau rasio CT tanpa kehilangan payload asli.

4.2 Gunakan Waktu Penerimaan Server dengan Hati-hati

Catat waktu saat server menerima payload. Jika sistem bisnis juga menggunakan stempel waktu perangkat atau sumber, simpan kedua nilai secara terpisah alih-alih menggantikan satu dengan yang lain.

Penundaan jaringan, koneksi ulang, dan pemrosesan dalam antrean dapat membuat waktu ingest berbeda dari waktu pengukuran. Tetapkan stempel waktu yang digunakan oleh grafik, penagihan, dan alarm sebelum penerapan produksi.

5. Implementasikan Jenis Penerima Lainnya

5.1 Penerima MQTT atau MQTTS

Untuk ingest MQTT, sistem pelanggan menyediakan:

• broker MQTT yang dapat dijangkau;
• aturan autentikasi dan kontrol akses;
• layanan subscriber atau consumer;
• validasi dan persistensi payload;
• pemantauan kesehatan broker dan consumer.

IAMMETER memublikasikan data waktu nyata di bawah topik perangkat seperti:

device/{SN}/realtime

Gunakan panduan khusus untuk konfigurasi broker, kredensial, topik, dan pertimbangan MQTTS:

• Publikasikan Data IAMMETER ke Broker MQTT Anda

Home Assistant MQTT Discovery tidak diperlukan untuk integrasi server pelanggan secara umum.

5.2 Penerima TCP

IAMMETER menyediakan socket listener TCP Node.js minimal:

• Contoh Server TCP IAMMETER di GitHub

Contoh ini mendengarkan pada port 8000 dan mencetak data yang diterima. Penerima TCP produksi juga harus menyediakan:

• manajemen siklus hidup koneksi;
• buffering dan validasi payload;
• penanganan aman untuk potongan socket yang parsial atau gabungan;
• identifikasi perangkat;
• persistensi dan penanganan kesalahan;
• pemantauan dan batas sumber daya yang terkendali.

Jangan mengasumsikan bahwa satu peristiwa data socket selalu sama dengan satu pesan aplikasi yang lengkap.

5.3 Penerima TLS

Contoh TLS resmi menunjukkan socket listener TLS dengan kunci dan sertifikat server:

• Contoh Server TLS IAMMETER di GitHub

Sebelum penggunaan produksi, ganti sertifikat dan pengaturan demonstrasi dengan sertifikat, manajemen kunci, dan konfigurasi keamanan yang disetujui organisasi. Penerima harus mencatat kegagalan TLS secara terpisah dari kegagalan validasi payload.

Format alamat sisi meter untuk TCP dan TLS dipelihara di panduan antarmuka firmware.

6. Rencanakan Interval Unggah dan Kapasitas Server

Firmware terkini mendukung interval unggah pihak ketiga hingga 2 detik. Interval pendek hanya berguna jika sistem penerima, penyimpanan, dan aplikasi memerlukan resolusi tambahan tersebut.

Perkiraan catatan yang dihasilkan per meter:

Interval unggah	Catatan per meter per hari	100 meter per hari	1.000 meter per hari
60 detik	1.440	144.000	1.440.000
10 detik	8.640	864.000	8.640.000
2 detik	43.200	4.320.000	43.200.000

Angka-angka ini mewakili peristiwa unggah, bukan selalu baris basis data. Payload tiga fase dapat dinormalisasi menjadi beberapa catatan kanal, dan indeks, retensi payload mentah, atau penyimpanan yang direplikasi akan menambah volume basis data yang sebenarnya.

Perencanaan kapasitas harus mencakup:

• koneksi bersamaan puncak;
• permintaan atau pesan per detik;
• biaya parsing JSON;
• perkalian baris tingkat kanal;
• indeks dan retensi basis data;
• dasbor dan kueri agregasi;
• log, percobaan ulang, dan penyimpanan dead-letter;
• trafik cadangan dan replikasi.

Untuk kontrol atau otomasi satu detik pada LAN yang sama, pertimbangkan Modbus TCP alih-alih menggunakan pipeline unggah jarak jauh.

7. Tangani Keandalan dan Kualitas Data

Penerima produksi harus mengantisipasi kegagalan jaringan dan aplikasi.

7.1 Validasi Setiap Payload

Validasi setidaknya:

• sintaks JSON;
• field identitas yang wajib;
• struktur array yang diharapkan;
• tipe numerik dan rentang yang wajar;
• pemetaan model atau kanal yang didukung;
• variasi field yang bergantung pada firmware.

Simpan payload yang tidak valid di jalur diagnostik yang terkendali tanpa membiarkannya menghambat perangkat yang valid.

7.2 Rencanakan Unggahan Duplikat dan Hilang

Jangan mengasumsikan bahwa setiap interval menghasilkan tepat satu catatan yang tersimpan permanen. Gangguan jaringan, perilaku koneksi ulang, percobaan ulang server, atau pemrosesan aplikasi dapat menghasilkan peristiwa ingest yang hilang atau berulang.

Tetapkan bagaimana sistem bisnis akan:

• mendeteksi catatan duplikat;
• mengidentifikasi celah data;
• membedakan meter yang diam dari penerima yang gagal;
• menghindari penghitungan energi dengan menjumlahkan register kWh kumulatif secara membabi buta;
• merekonsiliasi energi kumulatif setelah gangguan.

7.3 Pantau Seluruh Jalur Data

Pantau lebih dari sekadar proses web atau socket. Sinyal yang berguna meliputi:

• waktu payload terakhir per meter;
• jumlah payload tidak valid;
• waktu respons dan tingkat kesalahan penerima;
• koneksi TCP/TLS aktif;
• lag consumer MQTT;
• latensi penulisan basis data;
• kedalaman antrean;
• penggunaan disk dan tugas retensi.

8. Amankan Sistem Penerima

Untuk penerima yang menghadap Internet:

• utamakan transport terenkripsi yang didukung oleh penerapan;
• batasi port dan sumber jaringan yang terbuka bila memungkinkan;
• terapkan autentikasi MQTT dan otorisasi topik;
• lindungi endpoint HTTP dengan arsitektur keamanan jaringan atau aplikasi di sekitarnya;
• kelola sertifikat TLS dan kunci privat dengan aman;
• hindari menulis kredensial atau payload sensitif lengkap ke log aplikasi;
• batasi laju dan isolasi lalu lintas yang tidak valid atau berbahaya;
• selalu perbarui sistem operasi, runtime, dan dependensi.

Tinjau perilaku firmware MQTTS, TLS, dan HTTPS terkini di panduan firmware dan antarmuka terbuka sebelum memilih desain keamanan.

9. Daftar Periksa Penerapan Produksi

Meter dan jaringan

• Versi firmware dicatat dan divalidasi
• SN meter dipetakan ke lokasi dan kanal yang benar
• Alamat dan port tujuan diverifikasi
• Jalur DNS, firewall, NAT, atau VPN diuji
• Interval unggah yang diperlukan dikonfirmasi

Penerima

• Payload mentah diambil dari setiap model meter dalam cakupan
• Pengujian parser dibuat dari fixture payload nyata
• Payload satu dan multi-kanal ditangani
• Pemrosesan rasio CT WEM3046T/E divalidasi bila berlaku
• Payload tidak valid dan tidak didukung diisolasi dengan aman
• Penerima mengembalikan atau mempertahankan perilaku yang diharapkan oleh transport yang dipilih

Penyimpanan dan operasi

• Kebijakan stempel waktu didokumentasikan
• Kebijakan data duplikat dan data hilang didokumentasikan
• Kapasitas basis data dihitung untuk jumlah perangkat dan interval
• Log, metrik, dan alarm last-seen per meter diaktifkan
• Retensi, pencadangan, dan pemulihan diuji
• Sertifikat, kredensial, dan aturan akses ditinjau
• Gangguan jaringan dan mulai ulang penerima diuji

10. Dokumentasi Terkait

• Kembangkan Sistem Pemantauan Energi Anda Sendiri
• Gunakan IAMMETER Tanpa Internet atau IAMMETER-Cloud
• API Lokal dan Antarmuka Terbuka IAMMETER
• Integrasi Meter Energi MQTT
• Definisi JSON Pengukuran IAMMETER
• Ikhtisar Integrasi Self-hosted dan Open-source

11. Tangkapan Layar Konfigurasi Sisi Meter Versi Lama

Versi asli dokumen ini berfokus pada konfigurasi firmware meter yang lebih lama. Tangkapan layar ini dipertahankan hanya untuk pengguna yang mengidentifikasi instalasi yang sudah ada. Untuk integrasi baru, gunakan WebUI terkini dan firmware terbaru.

Halaman TCP versi lama

Halaman TLS versi lama

Halaman HTTP/HTTPS versi lama

Dokumentasi firmware sebelumnya juga menggunakan metode konfigurasi lokal /api/uploadinterval dan menyebutkan minimum enam detik. Firmware terkini menampilkan interval di WebUI dan mendukung minimum yang terdokumentasi sebesar 2 detik.

Terakhir diperbarui: 16 Juli 2026