{"id":12960,"date":"2026-09-10T18:25:00","date_gmt":"2026-09-10T16:25:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=12960"},"modified":"2026-09-09T13:24:10","modified_gmt":"2026-09-09T11:24:10","slug":"tutorial-publikowanie-komunikatu-mqtt-discovery-ktory-trafia-do-panelu-energii","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/pl\/smart-home-pl\/tutorials-pl-smart-home-pl\/tutorial-publikowanie-komunikatu-mqtt-discovery-ktory-trafia-do-panelu-energii\/","title":{"rendered":"Tutorial: Publikowanie komunikatu MQTT Discovery, kt\u00f3ry trafia do panelu energii"},"content":{"rendered":"

Urz\u0105dzenie zg\u0142aszaj\u0105ce si\u0119 przez MQTT robi to jednym komunikatem. Trafia on na temat, kt\u00f3rego Home Assistant i tak nas\u0142uchuje, niesie JSON i musi mie\u0107 flag\u0119 retained – inaczej istnieje tylko do najbli\u017cszego restartu jednej ze stron.<\/p>\n

Utworzenie encji t\u0105 drog\u0105 to sprawa sze\u015bciu linii. Doprowadzenie do tego, by encja zosta\u0142a przyj\u0119ta jako \u017ar\u00f3d\u0142o energii, to sprawa trzech kolejnych – i w\u0142a\u015bnie tam le\u017cy ca\u0142a praca: ka\u017cde z tych trzech p\u00f3l zostaje po cichu pomini\u0119te, gdy jest ustawione \u017ale, a objaw zawsze wygl\u0105da tak samo, jak pusta lista wyboru.<\/p>\n

\n\"Po
Encja pojawia si\u0119, gdy tylko zawarto\u015b\u0107 jest poprawnym JSON-em. Trzy wyr\u00f3\u017cnione pola rozstrzygaj\u0105 co innego: czy da si\u0119 j\u0105 wybra\u0107 tak\u017ce jako \u017ar\u00f3d\u0142o energii.<\/figcaption><\/figure>\n

Temat decyduje, gdzie pojawi si\u0119 encja<\/h2>\n

Discovery dzia\u0142a przez wzorzec tematu, a nie przez wywo\u0142anie rejestruj\u0105ce. Home Assistant subskrybuje prefiks, a wszystko opublikowane pod nim w odpowiedniej postaci staje si\u0119 encj\u0105.<\/p>\n

homeassistant\/sensor\/kellerzaehler\/energie\/config\n      \u2502          \u2502         \u2502           \u2502\n   prefiks    komponent  node_id    object_id<\/code><\/pre>\n
Prefiks brzmi homeassistant<\/code>, dop\u00f3ki nie zosta\u0142 zmieniony w integracji MQTT. Komponent okre\u015bla typ encji i musi odpowiada\u0107 temu, co opisuje zawarto\u015b\u0107 – sensor<\/code> dla warto\u015bci pomiarowej, binary_sensor<\/code> dla stanu tak-nie, switch<\/code> dla czego\u015b prze\u0142\u0105czalnego.<\/p>\n
Node ID i object ID to dowolny tekst s\u0142u\u017c\u0105cy wy\u0142\u0105cznie zachowaniu niepowtarzalno\u015bci tematu. Nie s\u0105 identyfikatorem encji: ten powstaje p\u00f3\u017aniej z nazwy, a temat zmieniony po fakcie tworzy drug\u0105 encj\u0119, zamiast zmieni\u0107 nazw\u0119 pierwszej.<\/p>\n
Najmniejsza zawarto\u015b\u0107, kt\u00f3ra naprawd\u0119 dzia\u0142a<\/h2>\n
Cztery klucze wystarcz\u0105, aby encja zaistnia\u0142a. Nazwa, temat z nap\u0142ywaj\u0105cymi pomiarami, jednostka oraz identyfikator przetrwaj\u0105cy restarty.<\/p>\n
{\n  \"name\": \"Licznik w piwnicy\",\n  \"state_topic\": \"dom\/piwnica\/licznik\",\n  \"unit_of_measurement\": \"kWh\",\n  \"unique_id\": \"kellerzaehler_energie\"\n}<\/code><\/pre>\n
Z tych czterech szczeg\u00f3lnie op\u0142aca si\u0119 unique_id<\/code>. Bez tego klucza encja wprawdzie si\u0119 pojawia, lecz nie da si\u0119 jej zmieni\u0107 nazwy, przypisa\u0107 do obszaru ani w og\u00f3le wybra\u0107 w panelu energii. Identyfikator musi by\u0107 niepowtarzalny w ca\u0142ej instalacji, dlatego cz\u0119\u015bci tematu dobrze si\u0119 do tego nadaj\u0105.<\/p>\n
Blok device<\/code> jest dobrowolny i zwraca si\u0119 natychmiast: encje z tym samym identyfikatorem zostaj\u0105 zebrane w jedno urz\u0105dzenie, a jedno urz\u0105dzenie z o\u015bmioma pomiarami \u017cyje si\u0119 znacznie wygodniej ni\u017c osiem lu\u017anych encji.<\/p>\n
  \"device\": {\n    \"identifiers\": [\"kellerzaehler\"],\n    \"name\": \"Licznik w piwnicy\",\n    \"manufacturer\": \"Eastron\",\n    \"model\": \"SDM630\"\n  }<\/code><\/pre>\n
Trzy pola, kt\u00f3re czyta panel energii<\/h2>\n
Encja z liczb\u0105 w \u015brodku to jeszcze nie \u017ar\u00f3d\u0142o energii. Trzy pola musz\u0105 do siebie pasowa\u0107, zanim pojawi si\u0119 na li\u015bcie wyboru, a ka\u017cde z nich opisuje co innego.<\/p>\n\n\n\n\n\n\n\n
Pole<\/th>\nWymagana warto\u015b\u0107<\/th>\nZnaczenie<\/th>\n<\/tr>\n<\/thead>\n
device_class<\/td>\nenergy<\/td>\nLiczba jest ilo\u015bci\u0105 energii, nie moc\u0105<\/td>\n<\/tr>\n
unit_of_measurement<\/td>\nWh, kWh, MJ lub GJ<\/td>\nJednostka, w kt\u00f3rej liczona jest ta ilo\u015b\u0107<\/td>\n<\/tr>\n
state_class<\/td>\ntotal_increasing<\/td>\nWarto\u015b\u0107 ro\u015bnie wy\u0142\u0105cznie w g\u00f3r\u0119<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Najcz\u0119\u015bciej nie pasuj\u0105 do siebie dwa pierwsze. Licznik podaj\u0105cy waty jest czujnikiem mocy: device_class<\/code> power, state_class<\/code> measurement, jednostka W. Taki czujnik jest po\u017cyteczny i poprawny, a mimo to nigdy nie pojawi si\u0119 jako \u017ar\u00f3d\u0142o energii, bo moc nie jest energi\u0105. Panel energii szuka stanu licznika, kt\u00f3ry si\u0119 sumuje.<\/p>\n
Trzecie pole rozstrzyga, jak potraktowane zostanie wyzerowanie licznika. Przy total_increasing<\/code> nagle mniejsza warto\u015b\u0107 uchodzi za nowy cykl liczenia, a nie za ujemne zu\u017cycie, i statystyka biegnie dalej. Przy total<\/code> ten sam skok wymaga znacznika czasu last_reset<\/code> do interpretacji, a bez niego z danej godziny robi si\u0119 wyskok. Dla fizycznego licznika, kt\u00f3ry idzie do przodu i czasem zaczyna od nowa, total_increasing<\/code> jest wyborem uczciwym.<\/p>\n
Publikacja r\u0119czna<\/h2>\n
Nic z tego nie wymaga urz\u0105dzenia. Jedno polecenie tworzy encj\u0119, a to samo polecenie z inn\u0105 tre\u015bci\u0105 j\u0105 aktualizuje.<\/p>\n
mosquitto_pub -h 192.168.1.10 -u ha -P tajne -r \\\n  -t \"homeassistant\/sensor\/kellerzaehler\/energie\/config\" \\\n  -m '{\n    \"name\": \"Licznik w piwnicy\",\n    \"state_topic\": \"dom\/piwnica\/licznik\",\n    \"unit_of_measurement\": \"kWh\",\n    \"device_class\": \"energy\",\n    \"state_class\": \"total_increasing\",\n    \"unique_id\": \"kellerzaehler_energie\",\n    \"device\": { \"identifiers\": [\"kellerzaehler\"], \"name\": \"Licznik w piwnicy\" }\n  }'\n\nmosquitto_pub -h 192.168.1.10 -u ha -P tajne -r \\\n  -t \"dom\/piwnica\/licznik\" -m \"18234.7\"<\/code><\/pre>\n
Prze\u0142\u0105cznik -r<\/code> bywa zapominany, a nale\u017cy si\u0119 obu komunikatom z dw\u00f3ch r\u00f3\u017cnych powod\u00f3w. Na temacie konfiguracyjnym sprawia, \u017ce opis przetrwa restart Home Assistant – inaczej encja znika a\u017c do przypadkowego ponownego zg\u0142oszenia urz\u0105dzenia. Na temacie stanu sprawia, \u017ce encja ma warto\u015b\u0107 zaraz po restarcie, zamiast sta\u0107 jako niedost\u0119pna do czasu kolejnego pomiaru.<\/p>\n
Uwaga co do rozmiaru zawarto\u015bci: firmware m\u00f3wi\u0105cy j\u0119zykiem discovery wysy\u0142a zwykle skr\u00f3cone klucze – stat_t<\/code>, dev_cla<\/code>, stat_cla<\/code>, unit_of_meas<\/code>, uniq_id<\/code>, dev<\/code>. Obie pisownie dzia\u0142aj\u0105 i wolno je nawet miesza\u0107. Zawarto\u015b\u0107 pisana r\u0119cznie pozostaje czytelniejsza w postaci pe\u0142nej.<\/p>\n
Gdy encja si\u0119 pojawia i zostaje pusta<\/h2>\n
Encja, kt\u00f3ra istnieje i nic nie pokazuje, to niemal zawsze rozjazd temat\u00f3w: state_topic<\/code> w zawarto\u015bci i temat, na kt\u00f3rym publikowana jest warto\u015b\u0107, r\u00f3\u017cni\u0105 si\u0119 o jeden znak. Subskrypcja z symbolem wieloznacznym pokazuje obie strony naraz.<\/p>\n
mosquitto_sub -h 192.168.1.10 -u ha -P tajne -v -t \"dom\/#\"<\/code><\/pre>\n
Je\u017celi warto\u015b\u0107 dociera, ale tkwi w wi\u0119kszym komunikacie JSON, wyci\u0105ga j\u0105 value_template<\/code> – \"value_template\": \"{{ value_json.total_kwh }}\"<\/code>. Bez tego encja dostaje ca\u0142y obiekt i zg\u0142asza go jako nieznany.<\/p>\n
Do tego ostrze\u017cenie przed polem, kt\u00f3re wygl\u0105da pomocnie: expire_after<\/code> ustawia encj\u0119 jako niedost\u0119pn\u0105, gdy w podanej liczbie sekund nie nadejdzie \u017cadna warto\u015b\u0107. Przy prze\u0142\u0105czniku bywa to u\u017cyteczne. Przy liczniku energii rozrywa statystyk\u0119 d\u0142ugoterminow\u0105, bo ka\u017cda przerwa ko\u0144czy cykl liczenia. Licznik melduj\u0105cy si\u0119 co pi\u0119tna\u015bcie minut radzi sobie lepiej bez tego pola.<\/p>\n
Przy ostatnim kroku pomaga cierpliwo\u015b\u0107. Statystyka d\u0142ugoterminowa powstaje w odcinkach pi\u0119ciominutowych, a panel energii zbiera dane godzinami. \u015awie\u017co utworzony czujnik pozostaje wi\u0119c pusty, dop\u00f3ki nie minie pierwsza pe\u0142na godzina. To nie jest usterka, a ponowna publikacja zawarto\u015bci niczego nie przyspiesza.<\/p>\n
Usuni\u0119cie urz\u0105dzenia bez pozostawiania widma<\/h2>\n
Skasowanie encji w interfejsie dzia\u0142a do najbli\u017cszego restartu – wtedy zachowany komunikat konfiguracyjny tworzy j\u0105 ponownie. Usuni\u0119cie musi nast\u0105pi\u0107 tam, gdzie nast\u0105pi\u0142o utworzenie.<\/p>\n
mosquitto_pub -h 192.168.1.10 -u ha -P tajne -r \\\n  -t \"homeassistant\/sensor\/kellerzaehler\/energie\/config\" -m \"\"<\/code><\/pre>\n
Pusta zawarto\u015b\u0107 z flag\u0105 retained na temacie konfiguracyjnym kasuje jednocze\u015bnie encj\u0119 i zapami\u0119tany komunikat. Temat stanu zachowuje w\u0142asn\u0105 warto\u015b\u0107 retained i najlepiej wyczy\u015bci\u0107 go tak samo – inaczej kolejne urz\u0105dzenie na tym temacie odziedziczy pomiar nale\u017c\u0105cy do czego\u015b innego.<\/p>\n
\n
\u0179r\u00f3d\u0142a<\/h2>\n