Đồng hồ năng lượng Wi-Fi IAMMETER có thể gửi dữ liệu đo trực tiếp đến máy chủ, MQTT broker hoặc nền tảng dữ liệu do khách hàng kiểm soát. Điều này cho phép các nhà phát triển và đơn vị tích hợp hệ thống tự xây dựng EMS, BMS, dịch vụ IoT, cơ sở dữ liệu hoặc bảng điều khiển giám sát của riêng mình mà không cần dùng IAMMETER-Cloud làm nơi nhận dữ liệu.
Hướng dẫn này tiếp cận việc tích hợp từ phía máy chủ nhận:
IAMMETER meter
│
│ HTTP/HTTPS, MQTT/MQTTS or TCP/TLS
▼
Customer ingestion service
│
├── Raw-payload log
├── Time-series or relational database
├── EMS / BMS / ERP
└── Dashboard, report and alarm services
Về khả năng của firmware phía đồng hồ và định dạng địa chỉ, hãy xem Hướng dẫn API cục bộ và giao diện mở IAMMETER. Để chọn kiến trúc, xem Tự phát triển hệ thống giám sát năng lượng của bạn.
Đồng hồ có thể đẩy số liệu đo qua nhiều phương thức truyền. Hệ thống nhận nên chọn một đường thu nhận chính.
| Phương thức truyền | Thành phần phía bộ nhận | Phù hợp để bắt đầu với |
|---|---|---|
| HTTP / HTTPS | Web endpoint | Backend REST và tích hợp đầu tiên đơn giản nhất |
| MQTT / MQTTS | MQTT broker và subscriber | Các nền tảng IoT sẵn có và đường ống xử lý message |
| TCP / TLS | Trình lắng nghe socket | Bộ thu thập chuyên dụng và dịch vụ giao thức tùy chỉnh |
HTTP thường là cách dễ nhất để kiểm tra gói dữ liệu đầu tiên vì bộ nhận thử nghiệm chính thức có thể được khởi chạy bằng một ví dụ Node.js nhỏ. MQTT là lựa chọn mạnh khi hệ thống đã có sẵn broker. TCP/TLS mang lại tích hợp socket ở mức thấp hơn nhưng đòi hỏi nhiều công sức kỹ thuật phía bộ nhận hơn.
Các phương thức truyền bảo mật và định dạng cổng tùy chỉnh được duy trì trong hướng dẫn firmware hiện hành, thay vì được lặp lại ở đây.
IAMMETER cung cấp một ví dụ bộ nhận HTTP bằng Node.js chính thức để kiểm thử tích hợp.
Tải ví dụ từ:
Chạy:
node Server.js
Ví dụ này lắng nghe trên cổng 8000. Khi có yêu cầu đến, nó:
200 kèm một JSON phản hồi thành công nhỏ.Ví dụ này được thiết kế tối giản có chủ đích. Nó không cung cấp xác thực, lưu trữ bền vững, kiểm tra hợp lệ, giới hạn tần suất hay bảo mật cho môi trường production.
Trước khi cấu hình đồng hồ, hãy xác nhận rằng:
Đối với thử nghiệm trong LAN, đồng hồ và bộ nhận có thể dùng chung mạng nội bộ mà không cần Internet. Với bộ nhận từ xa, vị trí đặt đồng hồ phải có đường tới máy chủ.
Trong WebUI hiện hành của đồng hồ, hãy chọn chế độ chạy HTTP và nhập đích đến, ví dụ:
{server-address}:8000/upload

Endpoint HTTPS có thể dùng cổng mặc định hoặc cổng tùy chỉnh. Các quy tắc địa chỉ hiện hành, bao gồm https://host:port, được ghi trong phần firmware HTTP/HTTPS.
Sau khi lưu cài đặt, hãy kiểm tra bảng điều khiển của bộ nhận để xem đường dẫn yêu cầu và JSON được tải lên. Hãy giữ gói dữ liệu thô đầu tiên này làm dữ liệu mẫu cho các bài kiểm thử parser và cơ sở dữ liệu về sau.
IAMMETER dùng một cấu trúc JSON đo lường cốt lõi nhất quán trên các phương thức truyền được hỗ trợ. Phương thức truyền chỉ thay đổi cách gói dữ liệu đến, còn mô hình đo lường vẫn nhất quán.
Một gói dữ liệu thường bao gồm các trường cấp thiết bị như:
SN — số sê-ri đồng hồ dùng để nhận diện thiết bị;version — phiên bản firmware của đồng hồ;method — phương thức thông điệp hoặc loại gói dữ liệu;Data hoặc Datas — mảng số liệu đo.Data được dùng cho một kênh đo duy nhất. Datas chứa nhiều mảng số liệu đo cho đồng hồ nhiều kênh hoặc ba pha.
Ví dụ cấu trúc một kênh:
{
"method": "uploadsn",
"mac": "B0F8932A295C",
"version": "i.75.98.71y",
"server": "em",
"SN": "12345678",
"Data": [228.91, 1.61, 225, 15066.47, 0]
}
Đừng cố định cứng số lượng phần tử mảng cho mọi đồng hồ. Số kênh và các trường khả dụng phụ thuộc vào model đồng hồ và các tính năng đo được bật.
Hãy dùng định nghĩa chính thức khi triển khai parser:
Hãy tách phần xử lý riêng theo model ra khỏi bộ nhận ở tầng truyền.
Ví dụ, WEM3046T và WEM3046TE đo đầu ra thứ cấp 5 A của biến dòng bên ngoài. Giá trị của chúng phải được quy đổi theo tỷ số CT áp dụng để có được số đo phía sơ cấp. Đây là đặc tính của đồng hồ và CT, không phải khác biệt giữa HTTP, MQTT hay TCP.
Vì vậy, một đường ống thu nhận thực tế sẽ tách riêng:
Hãy lưu đủ thông tin để có thể tái tạo và chẩn đoán số đọc gốc.
Một mô hình tối thiểu hữu ích bao gồm:
| Trường | Mục đích |
|---|---|
| Meter SN | Ánh xạ gói dữ liệu tới thiết bị đã đăng ký |
| Chỉ số kênh hoặc pha | Phân biệt dữ liệu một pha, hai pha và ba pha |
| Thời gian máy chủ nhận | Cung cấp mốc thời gian thu nhận nhất quán |
| Điện áp | Số liệu đo điện |
| Dòng điện | Số liệu đo điện |
| Công suất tác dụng | Đầu vào cho tính toán công suất thời gian thực hoặc phụ tải |
| kWh nhập | Điện năng tích lũy nhập |
| kWh phát | Điện năng tích lũy phát |
| Phiên bản firmware | Hỗ trợ xử lý sự cố và tương thích parser |
| Gói dữ liệu thô | Cho phép phát lại, kiểm toán và sửa parser |
Các trường bổ sung như tần số, hệ số công suất và các số đo công suất phản kháng nên được lưu khi model và cấu hình được chọn cung cấp chúng.
Với các hệ thống production, hãy cân nhắc duy trì:
Điều này giúp việc sửa logic phân tích hoặc tỷ số CT trở nên dễ dàng hơn mà không làm mất gói dữ liệu gốc.
Hãy ghi lại thời điểm máy chủ chấp nhận gói dữ liệu. Nếu hệ thống nghiệp vụ cũng dùng timestamp của thiết bị hoặc nguồn, hãy lưu cả hai giá trị riêng biệt thay vì thay thế giá trị này bằng giá trị kia.
Độ trễ mạng, việc kết nối lại và xử lý trong hàng đợi có thể khiến thời gian thu nhận khác với thời gian đo. Hãy xác định rõ timestamp nào được dùng cho biểu đồ, tính phí và cảnh báo trước khi triển khai production.
Với việc thu nhận qua MQTT, hệ thống của khách hàng cần cung cấp:
IAMMETER công bố dữ liệu thời gian thực theo một topic thiết bị như:
device/{SN}/realtime
Hãy dùng hướng dẫn chuyên biệt để biết cách cấu hình broker, thông tin xác thực, topic và các lưu ý về MQTTS:
MQTT Discovery của Home Assistant không bắt buộc cho việc tích hợp máy chủ khách hàng nói chung.
IAMMETER cung cấp một trình lắng nghe TCP tối giản bằng Node.js:
Ví dụ này lắng nghe trên cổng 8000 và in dữ liệu nhận được. Một bộ nhận TCP cho production còn phải cung cấp thêm:
Đừng mặc định rằng một sự kiện data của socket luôn tương ứng với đúng một thông điệp ứng dụng hoàn chỉnh.
Ví dụ TLS chính thức minh họa một trình lắng nghe TLS với khóa và chứng chỉ máy chủ:
Trước khi dùng cho production, hãy thay các chứng chỉ và cài đặt minh họa bằng chứng chỉ, cơ chế quản lý khóa và cấu hình bảo mật đã được tổ chức phê duyệt. Bộ nhận nên ghi log các lỗi TLS tách biệt với các lỗi kiểm tra hợp lệ gói dữ liệu.
Định dạng địa chỉ phía đồng hồ cho TCP và TLS được duy trì trong hướng dẫn giao diện firmware.
Firmware hiện hành hỗ trợ khoảng thời gian tải lên bên thứ ba tối thiểu 2 giây. Khoảng thời gian ngắn chỉ hữu ích khi hệ thống nhận, kho lưu trữ và ứng dụng thực sự cần độ phân giải tăng thêm.
Số bản ghi xấp xỉ được tạo ra cho mỗi đồng hồ:
| Khoảng thời gian tải lên | Số bản ghi mỗi đồng hồ mỗi ngày | 100 đồng hồ mỗi ngày | 1.000 đồng hồ mỗi ngày |
|---|---|---|---|
| 60 giây | 1.440 | 144.000 | 1.440.000 |
| 10 giây | 8.640 | 864.000 | 8.640.000 |
| 2 giây | 43.200 | 4.320.000 | 43.200.000 |
Những con số này thể hiện số sự kiện tải lên, không nhất thiết là số dòng trong cơ sở dữ liệu. Một gói dữ liệu ba pha có thể được chuẩn hóa thành nhiều bản ghi theo kênh, và các chỉ mục, việc lưu giữ dữ liệu thô hay lưu trữ nhân bản sẽ làm tăng khối lượng cơ sở dữ liệu thực tế.
Việc lập kế hoạch năng lực nên bao gồm:
Đối với điều khiển hoặc tự động hóa trong một giây trên cùng một LAN, hãy cân nhắc dùng Modbus TCP thay vì đường ống tải lên từ xa.
Một bộ nhận production nên dự liệu trước các lỗi mạng và lỗi ứng dụng.
Tối thiểu hãy kiểm tra:
Hãy giữ các gói dữ liệu sai định dạng trong một đường chẩn đoán có kiểm soát, không để chúng chặn các thiết bị hợp lệ.
Đừng mặc định rằng mỗi khoảng thời gian luôn tạo ra đúng một bản ghi được lưu vĩnh viễn. Gián đoạn mạng, hành vi kết nối lại, việc máy chủ thử lại hoặc xử lý của ứng dụng có thể tạo ra các sự kiện thu nhận bị thiếu hoặc lặp lại.
Hãy xác định cách hệ thống nghiệp vụ sẽ:
Hãy giám sát nhiều hơn chỉ tiến trình web hoặc socket. Các tín hiệu hữu ích bao gồm:
Với một bộ nhận hướng ra Internet:
Hãy xem lại hành vi firmware hiện hành đối với MQTTS, TLS và HTTPS trong hướng dẫn firmware và giao diện mở trước khi chọn phương án bảo mật.
Phiên bản gốc của tài liệu này tập trung vào việc cấu hình firmware đồng hồ đời cũ. Những ảnh chụp màn hình này chỉ được giữ lại cho người dùng đang nhận diện một hệ thống đã lắp đặt sẵn. Với các tích hợp mới, hãy dùng WebUI hiện hành và firmware mới nhất.



Tài liệu firmware trước đây cũng dùng phương thức cấu hình cục bộ /api/uploadinterval và mô tả mức tối thiểu là sáu giây. Firmware hiện hành hiển thị khoảng thời gian này trong WebUI và hỗ trợ mức tối thiểu được ghi nhận là 2 giây.
Cập nhật lần cuối: 16 tháng 7, 2026
Đồng hồ năng lượng Wi-Fi ba pha (WEM3080T)
Đồng hồ năng lượng Wi-Fi một pha (WEM3080)
Đồng hồ năng lượng Wi-Fi ba pha (WEM3046T)
Đồng hồ năng lượng Wi-Fi ba pha (WEM3050T)