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

Czujnik dociera. Pokazuje liczbę, liczba się zmienia, historia rysuje linię. Potem otwiera się panel energii, lista możliwych źródeł jest krótka, a czujnika w niej nie ma – bez komunikatu o błędzie gdziekolwiek, bo z punktu widzenia systemu nic się nie popsuło.

Brakuje zgodności trzech pól ładunku wykrywania. Każde z nich jest nieobowiązkowe, każde zostaje przyjęte z osobna, a dopiero kombinacja rozstrzyga, czy encja jest liczbą na wykresie, czy wielkością, którą da się zsumować.

Dokąd idzie ładunek i dlaczego tam zostaje

Wykrywanie to wiadomość na temacie, który broker zachowuje: homeassistant/<komponent>/<węzeł>/<obiekt>/config, opublikowana z ustawioną flagą retain. Zachowana znaczy, że broker doręcza ją Home Assistantowi po każdym restarcie – dlatego urządzenie MQTT przeżywa restart, choć samo nic nie wysyła.

# utworzenie, zachowane
mosquitto_pub -h broker -r -t "homeassistant/sensor/zaehler01/energie/config" -m "$(cat sensor.json)"

# usunięcie: pusty ładunek na ten sam temat, znowu zachowany
mosquitto_pub -h broker -r -t "homeassistant/sensor/zaehler01/energie/config" -m ""

Drugiego polecenia zwykle brakuje. Usunięcie encji w interfejsie kasuje ją do najbliższego restartu; wtedy broker odtwarza zachowaną konfigurację i urządzenie wraca. Encja MQTT znika dopiero wtedy, gdy pusty jest temat, który ją utworzył.

Trzy pola, które rozstrzygają wszystko

device_class deklaruje, o jaką wielkość chodzi, i tym samym ustala dopuszczalne przy niej jednostki. Dla energy są to Wh, kWh i MWh. Dla power są to W i kW, a czujnik mocy nie wchodzi w rachubę jako źródło energii bez względu na resztę ładunku – wat jest tempem, a panel sumujący tempa byłby po prostu błędny.

unit_of_measurement porównuje się dosłownie. kWh przechodzi, kwh i KWH nie, a skutkiem nie jest odrzucony ładunek, tylko encja, której jednostka nie pasuje do klasy i której przez to nie da się wybrać. To zdecydowanie najczęstsza przyczyna i jest niewidoczna na każdym ekranie poza tym, na którym encja się nie pojawia.

state_class rozstrzyga, czy w ogóle powstaje statystyka długoterminowa. Bez tego pola wartość zostaje w krótkiej historii i nigdzie indziej; z błędnym – tak samo. Tylko total i total_increasing wytwarzają sumy godzinowe, z których czyta panel energii.

total_increasing, total, measurement

total_increasing jest pomyślane dla liczników liczących wyłącznie w górę. Spadek odczytuje się jako wymianę licznika – wymienione urządzenie, oprogramowanie startujące od zera – i nowa wartość liczy się od tego miejsca, zamiast jako ujemne zużycie. Nie potrzebuje last_reset i dla niemal każdego licznika energii jest wyborem właściwym.

total jest dla wartości, które mogą też spadać, na przykład bilansu, i oczekuje znacznika last_reset, by wiedzieć, kiedy zaczął się okres. measurement jest dla wszystkiego, co jest stanem, a nie sumą: temperatury, mocy, wilgotności. To ustawienie, po które sięgają wszyscy, bo brzmi neutralnie, i to powód, dla którego nienaganny stan licznika daje ładny przebieg i nigdy ani jednej kilowatogodziny.

Jeden szczegół total_increasing warto znać, zanim wystąpi: wartość skacząca w dół zostaje przy dostatecznie dużym skoku odczytana jako wymiana licznika, a cały nowy stan księguje się w tej godzinie jako zużycie. Licznik, który sporadycznie melduje starszą, niższą wartość, daje więc nie mały błąd, tylko szczyt wysokości całego stanu licznika.

Który objaw pochodzi z którego wiersza

Pięć z sześciu objawia się jako coś innego niż błąd. Taki jest kształt całego problemu: ładunek wykrywania przyjmuje się albo pomija pole po polu, a pominięte pole nie zostawia po sobie śladu poza zdolnością, której bezgłośnie odmówiło.

Czujnik, który zachowuje ostatnią wartość na zawsze

Czujnik MQTT bez obsługi dostępności nie zna stanu offline. Ostatnia otrzymana wartość zostaje na ekranie, a przy stanie licznika jest to gorsze niż luka: liczba wygląda wiarygodnie, przebieg jest płaski, a panel energii melduje gospodarstwo, które od wtorku nic nie zużyło.

availability_topic z ostatnią wolą po stronie urządzenia jest rozwiązaniem czystym, expire_after zgrubnym – liczbą sekund, po których stan uznaje się za niedostępny, jeśli nic nowego nie dotarło. Dla licznika nadającego co dziesięć sekund trzysta jest hojne, a martwe urządzenie i tak wychwyci w ciągu pięciu minut.

Statystyka nie patrzy wstecz

Statystyki długoterminowe powstają raz na godzinę ze stanów zapisanych w tej godzinie. Ładunek poprawiony w piątek nie wytwarza statystyki za poniedziałek do czwartku, bo nie było z czego – stany istniały, tylko nikt nie zarządził ich sumowania.

Dziurę da się zamknąć ręcznie w edytorze statystyk pod narzędziami dla programistów, który potrafi zmieniać pojedyncze sumy, i przy liczniku, na którego stanach zależy, warto to zrobić. To zarazem powód, by trzy pola sprawdzić w dniu konfiguracji, a nie na koniec miesiąca: cała reszta ładunku wykrywania daje się poprawić później bez żadnej straty.