Liczniki energii Wi-Fi IAMMETER mogą wysyłać dane pomiarowe bezpośrednio do serwera, brokera MQTT lub platformy danych kontrolowanej przez klienta. Pozwala to programistom i integratorom systemów na budowanie własnych systemów EMS, BMS, usług IoT, baz danych lub pulpitów monitorujących bez używania IAMMETER-Cloud jako docelowego miejsca danych.
Ten przewodnik podchodzi do integracji od strony serwera odbierającego:
Licznik IAMMETER
│
│ HTTP/HTTPS, MQTT/MQTTS lub TCP/TLS
▼
Usługa odbiorcza klienta
│
├── Dziennik surowych przesyłek
├── Baza danych szeregów czasowych lub relacyjna
├── EMS / BMS / ERP
└── Pulpity, raporty i usługi alarmowe
Informacje o możliwościach oprogramowania sprzętowego licznika i formatach adresów znajdziesz w IAMMETER Local API and Open Interface Guide. Informacje o wyborze architektury znajdziesz w Develop Your Own Energy Monitoring System.
Licznik może wysyłać swoje pomiary przy użyciu kilku transportów. System odbiorczy powinien wybrać jedną główną ścieżkę pozyskiwania danych.
| Transport | Komponent odbiornika | Dobry punkt wyjścia dla |
|---|---|---|
| HTTP / HTTPS | Endpoint webowy | Zaplecza REST i najprostsza pierwsza integracja |
| MQTT / MQTTS | Broker MQTT i subskrybent | Istniejące platformy IoT i potoki komunikatów |
| TCP / TLS | Nasłuchiwacz socketów | Dedykowane kolektory i niestandardowe usługi protokołów |
HTTP jest zazwyczaj najłatwiejszym sposobem na sprawdzenie pierwszej przesyłki, ponieważ oficjalny testowy odbiornik można uruchomić za pomocą małego przykładu Node.js. MQTT to dobry wybór, gdy broker jest już częścią systemu. TCP/TLS zapewnia integrację na niższym poziomie, ale wymaga więcej pracy po stronie odbiornika.
Bezpieczne transporty i formaty niestandardowych portów są opisane w bieżącym przewodniku po oprogramowaniu sprzętowym, a nie powtarzane tutaj.
IAMMETER udostępnia oficjalny przykład odbiornika HTTP w Node.js do testowania integracji.
Pobierz przykład z:
Uruchom:
node Server.js
Przykład nasłuchuje na porcie 8000. Po otrzymaniu żądania:
200 z małą odpowiedzią JSON potwierdzającą sukces.Przykład jest celowo minimalistyczny. Nie zapewnia uwierzytelniania, trwałości, walidacji, ograniczania szybkości ani bezpieczeństwa produkcyjnego.
Przed skonfigurowaniem licznika upewnij się, że:
W przypadku testu w sieci LAN licznik i odbiornik mogą korzystać z tej samej sieci lokalnej bez dostępu do Internetu. W przypadku odbiornika zdalnego witryna musi mieć trasę do serwera.
W bieżącym interfejsie WebUI licznika wybierz tryb pracy HTTP i wprowadź miejsce docelowe, takie jak:
{adres-serwera}:8000/upload
Endpointy HTTPS mogą używać domyślnego portu lub niestandardowego portu. Bieżące reguły adresowania, w tym https://host:port, są udokumentowane w sekcji o oprogramowaniu sprzętowym HTTP/HTTPS.
Po zapisaniu ustawienia sprawdź konsolę odbiornika pod kątem ścieżki żądania i przesłanego JSON-a. Zachowaj tę pierwszą surową przesyłkę jako testową próbkę do późniejszych testów parsera i bazy danych.
IAMMETER używa spójnej podstawowej struktury JSON pomiarów we wszystkich obsługiwanych transportach push. Transport zmienia sposób dostarczania przesyłki, ale model pomiarowy pozostaje spójny.
Przesyłka zazwyczaj zawiera pola na poziomie urządzenia, takie jak:
SN — numer seryjny licznika używany do identyfikacji urządzenia;version — wersja oprogramowania sprzętowego licznika;method — metoda komunikatu lub typ przesyłki;Data lub Datas — tablice pomiarowe.Data jest używane dla pojedynczego kanału pomiarowego. Datas zawiera wiele tablic pomiarowych dla licznika wielokanałowego lub trójfazowego.
Przykład struktury jednokanałowej:
{
"method": "uploadsn",
"mac": "B0F8932A295C",
"version": "i.75.98.71y",
"server": "em",
"SN": "12345678",
"Data": [228.91, 1.61, 225, 15066.47, 0]
}
Nie koduj na sztywno jednej liczby elementów tablicy dla każdego licznika. Liczba kanałów i dostępnych pól zależy od modelu licznika i włączonych funkcji pomiarowych.
Użyj autorytatywnej definicji podczas implementacji parsera:
Oddziel przetwarzanie specyficzne dla modelu od odbiornika transportowego.
Na przykład WEM3046T i WEM3046TE mierzą wtórne wyjście 5 A zewnętrznego przekładnika prądowego. Ich wartości muszą zostać przeliczone z odpowiednim przekładem CT, aby uzyskać pomiar po stronie pierwotnej. Jest to cecha licznika i przekładnika CT, a nie różnica HTTP, MQTT czy TCP.
Praktyczny potok pozyskiwania danych rozdziela zatem:
Przechowuj wystarczająco dużo informacji, aby odtworzyć i zdiagnozować oryginalny odczyt.
Przydatny minimalny model obejmuje:
| Pole | Cel |
|---|---|
| Numer SN licznika | Mapuje przesyłkę na zarejestrowane urządzenie |
| Indeks kanału lub fazy | Rozróżnia dane jednofazowe, split-phase i trójfazowe |
| Czas odebrania przez serwer | Zapewnia spójny znacznik czasu pozyskania |
| Napięcie (Voltage) | Pomiar elektryczny |
| Prąd (Current) | Pomiar elektryczny |
| Moc czynna (Active power) | Import/eksport w czasie rzeczywistym lub dane do obliczeń obciążenia |
| Import kWh | Skumulowana energia importowana |
| Export kWh | Skumulowana energia eksportowana |
| Wersja oprogramowania sprzętowego | Wspomaga rozwiązywanie problemów i kompatybilność parsera |
| Surowa przesyłka | Umożliwia odtwarzanie, audyt i korektę parsera |
Dodatkowe pola, takie jak częstotliwość, współczynnik mocy i pomiary mocy biernej, powinny być przechowywane, gdy wybrany model i konfiguracja je udostępniają.
W systemach produkcyjnych rozważ przechowywanie:
Ułatwia to korektę logiki parsowania lub przekładów CT bez utraty oryginalnej przesyłki.
Zarejestruj czas, w którym serwer zaakceptował przesyłkę. Jeśli system biznesowy używa również znacznika czasu urządzenia lub źródła, przechowuj obie wartości oddzielnie, zamiast zastępować jedną drugą.
Opóźnienie sieciowe, ponowne połączenia i kolejkowane przetwarzanie mogą spowodować, że czas pozyskania będzie różnił się od czasu pomiaru. Zdefiniuj znacznik czasu używany przez wykresy, rozliczenia i alarmy przed wdrożeniem produkcyjnym.
W przypadku pozyskiwania przez MQTT system klienta zapewnia:
IAMMETER publikuje dane w czasie rzeczywistym pod tematem urządzenia, takim jak:
device/{SN}/realtime
Skorzystaj z dedykowanego przewodnika dotyczącego konfiguracji brokera, poświadczeń, tematów i kwestii MQTTS:
Home Assistant MQTT Discovery nie jest wymagane do ogólnej integracji z serwerem klienta.
IAMMETER udostępnia minimalny przykład nasłuchiwacza TCP w Node.js:
Przykład nasłuchuje na porcie 8000 i wyświetla odebrane dane. Produkcyjny odbiornik TCP musi dodatkowo zapewniać:
Nie zakładaj, że jedno zdarzenie data socketu zawsze odpowiada jednej kompletnej wiadomości aplikacji.
Oficjalny przykład TLS demonstruje nasłuchiwacz TLS z kluczem serwera i certyfikatem:
Przed użyciem produkcyjnym zastąp przykładowe certyfikaty i ustawienia certyfikatem, zarządzaniem kluczami i konfiguracją bezpieczeństwa zatwierdzoną przez organizację. Odbiornik powinien rejestrować błędy TLS oddzielnie od błędów walidacji przesyłek.
Formaty adresów po stronie licznika dla TCP i TLS są opisane w przewodniku po interfejsie oprogramowania sprzętowego.
Bieżące oprogramowanie sprzętowe obsługuje interwał wysyłania do stron trzecich wynoszący nawet 2 sekundy. Krótki interwał jest przydatny tylko wtedy, gdy system odbiorczy, magazyn i aplikacja potrzebują dodatkowej rozdzielczości.
Przybliżona liczba rekordów generowanych na licznik:
| Interwał wysyłania | Rekordów na licznik dziennie | 100 liczników dziennie | 1 000 liczników dziennie |
|---|---|---|---|
| 60 sekund | 1 440 | 144 000 | 1 440 000 |
| 10 sekund | 8 640 | 864 000 | 8 640 000 |
| 2 sekundy | 43 200 | 4 320 000 | 43 200 000 |
Te liczby reprezentują zdarzenia wysyłania, a niekoniecznie wiersze bazy danych. Przesyłka trójfazowa może być znormalizowana do kilku rekordów kanałów, a indeksy, przechowywanie surowych przesyłek lub replikowany magazyn zwiększają rzeczywistą objętość bazy danych.
Planowanie wydajności powinno obejmować:
W przypadku sterowania lub automatyzacji z interwałem jednej sekundy w tej samej sieci LAN rozważ Modbus TCP zamiast używania zdalnego potoku wysyłania.
Produkcyjny odbiornik powinien oczekiwać awarii sieci i aplikacji.
Waliduj co najmniej:
Przechowuj nieprawidłowe przesyłki w kontrolowanej ścieżce diagnostycznej, nie blokując prawidłowych urządzeń.
Nie zakładaj, że każdy interwał produkuje dokładnie jeden trwale zapisany rekord. Przerwy w sieci, zachowanie przy ponownym połączeniu, ponowne próby serwera lub przetwarzanie aplikacji mogą powodować brakujące lub powtarzające się zdarzenia pozyskiwania.
Zdefiniuj, jak system biznesowy będzie:
Monitoruj więcej niż tylko proces sieciowy lub socketowy. Przydatne sygnały obejmują:
W przypadku odbiornika dostępnego z Internetu:
Przejrzyj bieżące zachowanie oprogramowania sprzętowego MQTTS, TLS i HTTPS w przewodniku po oprogramowaniu sprzętowym i otwartym interfejsie przed wyborem projektu bezpieczeństwa.
Oryginalna wersja tego dokumentu koncentrowała się na konfiguracji starszego oprogramowania sprzętowego licznika. Te zrzuty ekranu są zachowane tylko dla użytkowników identyfikujących istniejącą instalację. W przypadku nowych integracji użyj bieżącego interfejsu WebUI i najnowszego oprogramowania sprzętowego.
Wcześniejsza dokumentacja oprogramowania sprzętowego używała również lokalnej metody konfiguracji /api/uploadinterval i opisywała minimalny interwał sześciu sekund. Bieżące oprogramowanie sprzętowe udostępnia interwał w WebUI i obsługuje udokumentowane minimum 2 sekund.
Ostatnia aktualizacja: 16 lipca 2026 r.
Trójfazowy licznik energii Wi-Fi (WEM3080T)
Jednofazowy licznik energii Wi-Fi (WEM3080)
Trójfazowy licznik energii Wi-Fi (WEM3046T)
Trójfazowy licznik energii Wi-Fi (WEM3050T)