Xin lỗi, trình duyệt của bạn không hỗ trợ JavaScript!
Đăng nhập

Nhận dữ liệu năng lượng IAMMETER trên máy chủ của riêng bạn

Nhận dữ liệu năng lượng IAMMETER trên máy chủ của riêng bạn

Đồ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:

  • dựng một bộ nhận thử nghiệm;
  • bắt gói dữ liệu đầu tiên từ đồng hồ;
  • xác định đồng hồ và các kênh đo;
  • chuẩn hóa và lưu trữ dữ liệu;
  • ước tính khối lượng dữ liệu thu nhận;
  • chuẩn bị bộ nhận cho việc triển khai production.
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.

1. Chọn kiến trúc bộ nhậ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.

2. Bắt đầu nhanh: nhận gói dữ liệu đầu tiên qua HTTP

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.

2.1 Khởi chạy bộ nhận thử nghiệm

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ó:

  • thu thập phần body của yêu cầu HTTP;
  • in URL của yêu cầu;
  • in phần body được tải lên;
  • trả về trạng thái HTTP 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.

2.2 Đảm bảo bộ nhận có thể truy cập được

Trước khi cấu hình đồng hồ, hãy xác nhận rằng:

  • máy chủ đang lắng nghe trên đúng giao diện và cổng mong muốn;
  • tường lửa cho phép kết nối;
  • đồng hồ có thể phân giải tên miền khi dùng tên miền;
  • mọi đường NAT, reverse proxy hoặc VPN đều hoạt động;
  • URL cuối cùng dẫn tới đúng tuyến ứng dụng dự định.

Đố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ủ.

2.3 Trỏ đồng hồ tới bộ nhận

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

Cấu hình endpoint HTTP nhận dữ liệu trong WebUI IAMMETER hiện hành

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.

3. Hiểu gói dữ liệu IAMMETER gửi đến

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:

3.1 Xử lý theo từng model

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:

  1. giải mã ở tầng truyền;
  2. kiểm tra hợp lệ JSON;
  3. nhận diện đồng hồ và kênh;
  4. quy đổi tỷ lệ hoặc chuẩn hóa theo model;
  5. lưu trữ và tính toán nghiệp vụ.

4. Thiết kế mô hình dữ liệu thu nhận

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.

4.1 Tách riêng dữ liệu thô và dữ liệu đã chuẩn hóa

Với các hệ thống production, hãy cân nhắc duy trì:

  • một bản ghi dữ liệu thu nhận thô bất biến hoặc có thời gian lưu ngắn;
  • các số đọc đã chuẩn hóa theo từng kênh mà ứng dụng sử dụng;
  • các giá trị tổng hợp theo giờ, ngày và tháng.

Đ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.

4.2 Dùng thời gian máy chủ nhận một cách cẩn trọng

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.

5. Triển khai các loại bộ nhận khác

5.1 Bộ nhận MQTT hoặc MQTTS

Với việc thu nhận qua MQTT, hệ thống của khách hàng cần cung cấp:

  • một MQTT broker có thể truy cập được;
  • các quy tắc xác thực và kiểm soát truy cập;
  • một subscriber hoặc dịch vụ consumer;
  • kiểm tra hợp lệ và lưu trữ bền vững gói dữ liệu;
  • giám sát tình trạng hoạt động của broker và consumer.

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.

5.2 Bộ nhận TCP

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:

  • quản lý vòng đời kết nối;
  • đệm và kiểm tra hợp lệ gói dữ liệu;
  • xử lý an toàn các đoạn socket bị chia nhỏ hoặc gộp chung;
  • nhận diện thiết bị;
  • lưu trữ bền vững và xử lý lỗi;
  • giám sát và giới hạn tài nguyên có kiểm soát.

Đừ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.

5.3 Bộ nhận TLS

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.

6. Lập kế hoạch khoảng thời gian tải lên và năng lực máy chủ

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:

  • số kết nối đồng thời ở đỉnh;
  • số yêu cầu hoặc thông điệp mỗi giây;
  • chi phí phân tích JSON;
  • sự nhân lên số dòng theo từng kênh;
  • chỉ mục và thời gian lưu giữ của cơ sở dữ liệu;
  • bảng điều khiển và các truy vấn tổng hợp;
  • log, các lần thử lại và kho lưu trữ dead-letter;
  • lưu lượng sao lưu và nhân bản.

Đố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.

7. Xử lý độ tin cậy và chất lượng dữ liệu

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.

7.1 Kiểm tra hợp lệ mọi gói dữ liệu

Tối thiểu hãy kiểm tra:

  • cú pháp JSON;
  • các trường nhận diện bắt buộc;
  • cấu trúc mảng mong đợi;
  • kiểu số và khoảng giá trị hợp lý;
  • ánh xạ model hoặc kênh được hỗ trợ;
  • các biến thể trường phụ thuộc firmware.

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ệ.

7.2 Dự liệu trước tình huống tải lên trùng lặp và thiếu sót

Đừ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ẽ:

  • phát hiện các bản ghi trùng lặp;
  • nhận diện các khoảng thiếu dữ liệu;
  • phân biệt đồng hồ im lặng với bộ nhận bị lỗi;
  • tránh tính điện năng bằng cách cộng mù quáng các thanh ghi kWh tích lũy;
  • đối chiếu điện năng tích lũy sau một lần gián đoạn.

7.3 Giám sát toàn bộ đường dữ liệu

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:

  • thời điểm gói dữ liệu cuối cùng của mỗi đồng hồ;
  • số lượng gói dữ liệu không hợp lệ;
  • thời gian phản hồi và tỷ lệ lỗi của bộ nhận;
  • số kết nối TCP/TLS đang hoạt động;
  • độ trễ của MQTT consumer;
  • độ trễ ghi cơ sở dữ liệu;
  • độ sâu hàng đợi;
  • dung lượng đĩa và các tác vụ lưu giữ dữ liệu.

8. Bảo mật hệ thống nhận

Với một bộ nhận hướng ra Internet:

  • ưu tiên phương thức truyền được mã hóa mà bản triển khai hỗ trợ;
  • hạn chế các cổng và nguồn mạng được phép truy cập khi có thể;
  • áp dụng xác thực MQTT và phân quyền theo topic;
  • bảo vệ các endpoint HTTP bằng kiến trúc bảo mật mạng hoặc ứng dụng xung quanh;
  • quản lý chứng chỉ TLS và khóa riêng tư một cách an toàn;
  • tránh ghi thông tin xác thực hoặc toàn bộ gói dữ liệu nhạy cảm vào log ứng dụng;
  • giới hạn tần suất và cô lập lưu lượng sai định dạng hoặc lạm dụng;
  • cập nhật hệ điều hành, môi trường chạy và các thư viện phụ thuộc.

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.

9. Danh sách kiểm tra triển khai production

Đồng hồ và mạng

  • Đã ghi nhận và kiểm tra phiên bản firmware
  • Đã ánh xạ số sê-ri đồng hồ tới đúng vị trí và các kênh
  • Đã xác minh địa chỉ và cổng đích
  • Đã kiểm thử đường DNS, tường lửa, NAT hoặc VPN
  • Đã xác nhận khoảng thời gian tải lên cần thiết

Bộ nhận

  • Đã bắt gói dữ liệu thô từ mọi model đồng hồ trong phạm vi
  • Đã tạo các bài kiểm thử parser từ dữ liệu mẫu thực tế
  • Đã xử lý gói dữ liệu một kênh và nhiều kênh
  • Đã kiểm tra xử lý tỷ số CT của WEM3046T/E khi áp dụng
  • Đã cô lập an toàn các gói dữ liệu sai định dạng và không được hỗ trợ
  • Bộ nhận trả về hoặc duy trì hành vi mà phương thức truyền đã chọn mong đợi

Lưu trữ và vận hành

  • Đã ghi tài liệu về chính sách timestamp
  • Đã ghi tài liệu về chính sách xử lý dữ liệu trùng lặp và thiếu sót
  • Đã tính toán năng lực cơ sở dữ liệu theo số thiết bị và khoảng thời gian
  • Đã bật log, số liệu đo và cảnh báo lần cuối nhận dữ liệu theo từng đồng hồ
  • Đã kiểm thử việc lưu giữ, sao lưu và khôi phục
  • Đã xem xét chứng chỉ, thông tin xác thực và quy tắc truy cập
  • Đã kiểm thử gián đoạn mạng và khởi động lại bộ nhận

10. Tài liệu liên quan

11. Ảnh chụp màn hình cấu hình phía đồng hồ (phiên bản cũ)

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.

Trang TCP phiên bản cũ

Cấu hình máy chủ TCP IAMMETER phiên bản cũ

Trang TLS phiên bản cũ

Cấu hình máy chủ TLS IAMMETER phiên bản cũ

Trang HTTP/HTTPS phiên bản cũ

Cấu hình máy chủ HTTP/HTTPS IAMMETER phiên bản cũ

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

Lên đầu