LW IT Solutions logo LW IT Solutions logo LW IT Solutions
« Przegląd bloga /Smart Home / Panel energii w Home Assistant: device_class, jednostka...
Ten artykuł w innych językach:

Panel energii w Home Assistant: device_class, jednostka i state_class w komunikacie discovery

Panel energii w Home Assistant: device_class, jednostka i state_class w komunikacie discovery
Spis treści
  1. Dopasowanie wielkości do pola panelu
  2. Klasa stanu zależy od resetów
  3. Pełny przykład discovery jednego czujnika
  4. Dostępność i świeżość to osobne kontrole
  5. Kontrola statystyk przed użyciem
  6. Pytania i odpowiedzi
  7. Źródła

Czujnik MQTT może pokazywać zmienne wartości w historii, a mimo to nie występować w określonym polu panelu energii. Klasa urządzenia, jednostka i klasa stanu muszą odpowiadać pomiarowi. Znaczenie mają również poprawna konfiguracja discovery, rejestrowanie i błędy statystyk. Pola opisują dane; zmiana etykiety nie zamienia watów w kilowatogodziny.

Metadane energii, poprawne odczyty i świeżość muszą być zgodne.
Metadane energii, poprawne odczyty i świeżość muszą być zgodne.

Dopasowanie wielkości do pola panelu

Dla skumulowanego odczytu energii właściwe są device_class: energy, obsługiwana jednostka, np. kWh, oraz odpowiednia klasa stanu typu total. Pisownia ma znaczenie: kwh nie jest standardowym symbolem kWh. Jednostka musi także pasować do wybranego pola panelu. Nieprawidłowe kombinacje mogą powodować wpisy w logach lub błędy statystyk; problem nie musi być niewidoczny.

Moc jest tempem przepływu energii wyrażonym w watach. Aktualne wersje Home Assistant udostępniają w panelu energii osobne pola pomiaru mocy z device_class: power i state_class: measurement. Taki odczyt jest tam użyteczny, ale nie stanowi skumulowanego licznika energii. Zmiana W na kWh bez całkowania w czasie fałszuje pomiar.

Klasa stanu zależy od resetów

  • measurement opisuje pomiary, np. mocy lub temperatury. Może generować długoterminowe minimum, maksimum i średnią, ale nie sumę licznika energii.
  • total obsługuje wartości całkowite rosnące i malejące. Licznik całego okresu użytkowania, który nigdy się nie zeruje, może używać total bez last_reset. Przy znanych granicach resetu integracja musi dostarczać właściwe informacje o zerowaniu.
  • total_increasing odpowiada nieujemnemu licznikowi rosnącemu z możliwym ponownym startem od zera. Nie wymaga last_reset. Rozpoznany spadek rozpoczyna nowy cykl; pierwszy odczyt nowego cyklu jest liczony od zera.

Pierwszy zaobserwowany stan jest punktem odniesienia, a nie automatycznie całym historycznym zużyciem. Sekwencja 1000, 1005, 0, 1006 może jednak po wyzerowaniu błędnie dodać 1006. Nie każdy mały spadek oznacza reset: aktualna dokumentacja deweloperska opisuje tolerancję spadków poniżej 10%. Nie zastępuje to wykrywania starych lub nieprawidłowych odczytów.

Pełny przykład discovery jednego czujnika

Poniższy sensor.json opisuje licznik faktycznie zgodny z total_increasing. Temat stanu oczekuje liczby kWh, np. 123.456, bez jednostki w wartości. Nadajnik musi dostarczać komunikaty dostępności online/offline oraz poprawne odczyty odpowiednio często dla przykładowego wygasania po 300 sekundach.

{
  "name": "Energy",
  "unique_id": "example_meter_energy",
  "state_topic": "example/meter/energy",
  "device_class": "energy",
  "unit_of_measurement": "kWh",
  "state_class": "total_increasing",
  "availability_topic": "example/meter/status",
  "payload_available": "online",
  "payload_not_available": "offline",
  "expire_after": 300
}

Poniższe polecenia publikują konfigurację albo, osobno, usuwają dokładnie tę konfigurację przykładową. BROKER jest symbolem zastępczym; dane dostępu, port i TLS muszą odpowiadać brokerowi testowemu. Usunięcie jest odrębną operacją administracyjną, nie obowiązkowym krokiem po każdym utworzeniu.

mosquitto_pub -h BROKER -r -t "homeassistant/sensor/example_meter_energy/config" -f sensor.json

mosquitto_pub -h BROKER -r -t "homeassistant/sensor/example_meter_energy/config" -n

Discovery pojedynczego komponentu ma postać <prefiks>/<komponent>/[<node_id>/]<object_id>/config. Segment węzła jest opcjonalny. Zachowana konfiguracja może zostać dostarczona po ponownej subskrypcji. Alternatywnie nadajnik może ponownie wysłać discovery po komunikacie Birth Home Assistanta. Zachowanie konfiguracji nie zachowuje automatycznie bieżących odczytów ani nie potwierdza dostępności urządzenia.

Pusta zachowana wiadomość usuwa tę zapisaną konfigurację. Trwałe wycofanie wymaga także zatrzymania ponownego ogłaszania przez nadajnik; urządzenie z innymi encjami może pozostać. Stabilny unique_id umożliwia identyfikację w rejestrze i dostosowanie encji. Jest obowiązkowy przy discovery całego urządzenia, ale nie stanowi samodzielnego uniwersalnego warunku statystyk energii. Niepoprawne wymagane pola mogą spowodować odrzucenie konfiguracji; zasadniczo ignorowane są nieznane klucze.

Dostępność i świeżość to osobne kontrole

Wiadomość offline typu Last Will pomaga wykrywać utratę połączenia MQTT. Nie wykrywa każdego zamrożonego pomiaru przy nadal połączonym nadajniku. expire_after może ujawniać brak aktualizacji, jeśli znany jest zwykły interwał publikacji. Wielokrotne wysyłanie starej liczby nadal może obchodzić kontrolę wieku wiadomości; nadajnik powinien sprawdzać świeżość pozyskania danych.

Zachowane wartości stanu wymagają szczególnej uwagi: odtworzenie po restarcie Home Assistanta może sprawić, że wygasły odczyt wygląda na aktualny. Dokumentacja MQTT Sensor odradza zachowywanie komunikatów stanu przy kontroli wygaśnięcia; Home Assistant może sam odtworzyć stan i pozostały czas. Konfiguracja discovery nadal może być zachowana.

Kontrola statystyk przed użyciem

Sprawdzenie rzeczywistych atrybutów i wartości encji, następnie Ustawienia → Narzędzia → Statystyki oraz logów. Rejestrowanie musi obejmować czujnik. Statystyki krótkoterminowe powstają co pięć minut, a agregaty godzinowe tworzą statystyki długoterminowe. Poprawienie discovery nie rekonstruuje automatycznie wszystkich brakujących historycznych wartości energii.

Narzędzia statystyk mogą poprawiać zapisane anomalie, ale nie odtwarzają brakujących pomiarów z pustego przedziału. Zmiany sum skumulowanych mogą wpływać na późniejsze przesunięcia i sąsiednie różnice. Potrzebna jest kontrola otaczającego przebiegu i zachowanie kopii przed korektą. Późniejszy stan licznika może ujawnić całkowity przyrost podczas awarii bez ujawnienia rzeczywistego podziału godzinowego.

Pytania i odpowiedzi

Czy z mocy może powstać licznik energii?

Pomocnik Integral przybliża energię na podstawie próbek mocy w czasie. Dla źródła w W prefiks k i jednostka czasu h dają kWh. Metoda lewa może odpowiadać poprawnie raportowanym skokom i stabilnym poziomom; trapezy mogą pasować do gładkich, często próbkowanych przebiegów. Żadna metoda nie naprawia brakujących pomiarów. Wiarygodny sprzętowy licznik energii jest lepszym wyborem, jeśli jest dostępny.

Czy każde zero należy odrzucać?

Nie. Zero może oznaczać poprawny nowy odczyt lub reset. Błąd łączności powinien być reprezentowany jako niedostępność lub stan nieznany, nie fikcyjne zero. Filtry wymagają statusu urządzenia, znaczników czasu i wiarygodnych zmian oraz jawnej obsługi wymiany licznika. Ogólny szablon „większe od zera” ukrywałby również poprawne zera i nie rozwiązuje wszystkich problemów ze starymi odczytami.

Źródła

Lukas Wójcik

Lukas Wójcik

Systems architect and technology enthusiast specializing in scalable tracking solutions, GMP Stack (GA4 & GTM), and robust backend architectures. Advocate for clean code and privacy-first design.

Kontakt

Masz pytanie lub pomysł na projekt internetowy? Napisz krótko, o co chodzi. Formularz korzysta z reCAPTCHA do ochrony przed spamem.

Napisanie komentarza

Doświadczenia z innymi urządzeniami lub integracjami oraz pytania o konfigurację są tu mile widziane.

Adres e-mail nie jest publikowany. Pola obowiązkowe oznaczono gwiazdką.