![\"\u0141adunek](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/energieuebersicht-pl.png\")
Dok\u0105d idzie \u0142adunek i dlaczego tam zostaje<\/h2>\n
Wykrywanie to wiadomo\u015b\u0107 na temacie, kt\u00f3ry broker zachowuje: Drugiego polecenia zwykle brakuje. Usuni\u0119cie encji w interfejsie kasuje j\u0105 do najbli\u017cszego restartu; wtedy broker odtwarza zachowan\u0105 konfiguracj\u0119 i urz\u0105dzenie wraca. Encja MQTT znika dopiero wtedy, gdy pusty jest temat, kt\u00f3ry j\u0105 utworzy\u0142.<\/p>\n Jeden szczeg\u00f3\u0142 Pi\u0119\u0107 z sze\u015bciu objawia si\u0119 jako co\u015b innego ni\u017c b\u0142\u0105d. Taki jest kszta\u0142t ca\u0142ego problemu: \u0142adunek wykrywania przyjmuje si\u0119 albo pomija pole po polu, a pomini\u0119te pole nie zostawia po sobie \u015bladu poza zdolno\u015bci\u0105, kt\u00f3rej bezg\u0142o\u015bnie odm\u00f3wi\u0142o.<\/p>\n Czujnik MQTT bez obs\u0142ugi dost\u0119pno\u015bci nie zna stanu offline. Ostatnia otrzymana warto\u015b\u0107 zostaje na ekranie, a przy stanie licznika jest to gorsze ni\u017c luka: liczba wygl\u0105da wiarygodnie, przebieg jest p\u0142aski, a panel energii melduje gospodarstwo, kt\u00f3re od wtorku nic nie zu\u017cy\u0142o.<\/p>\n Statystyki d\u0142ugoterminowe powstaj\u0105 raz na godzin\u0119 ze stan\u00f3w zapisanych w tej godzinie. \u0141adunek poprawiony w pi\u0105tek nie wytwarza statystyki za poniedzia\u0142ek do czwartku, bo nie by\u0142o z czego – stany istnia\u0142y, tylko nikt nie zarz\u0105dzi\u0142 ich sumowania.<\/p>\n Dziur\u0119 da si\u0119 zamkn\u0105\u0107 r\u0119cznie w edytorze statystyk pod narz\u0119dziami dla programist\u00f3w, kt\u00f3ry potrafi zmienia\u0107 pojedyncze sumy, i przy liczniku, na kt\u00f3rego stanach zale\u017cy, warto to zrobi\u0107. To zarazem pow\u00f3d, by trzy pola sprawdzi\u0107 w dniu konfiguracji, a nie na koniec miesi\u0105ca: ca\u0142a reszta \u0142adunku wykrywania daje si\u0119 poprawi\u0107 p\u00f3\u017aniej bez \u017cadnej straty.<\/p>\nhomeassistant\/<komponent>\/<w\u0119ze\u0142>\/<obiekt>\/config<\/code>, opublikowana z ustawion\u0105 flag\u0105 retain. Zachowana znaczy, \u017ce broker dor\u0119cza j\u0105 Home Assistantowi po ka\u017cdym restarcie – dlatego urz\u0105dzenie MQTT prze\u017cywa restart, cho\u0107 samo nic nie wysy\u0142a.<\/p>\n# utworzenie, zachowane\nmosquitto_pub -h broker -r -t \"homeassistant\/sensor\/zaehler01\/energie\/config\" -m \"$(cat sensor.json)\"\n\n# usunięcie: pusty ładunek na ten sam temat, znowu zachowany\nmosquitto_pub -h broker -r -t \"homeassistant\/sensor\/zaehler01\/energie\/config\" -m \"\"<\/code><\/pre>\nTrzy pola, kt\u00f3re rozstrzygaj\u0105 wszystko<\/h2>\n
device_class<\/code> deklaruje, o jak\u0105 wielko\u015b\u0107 chodzi, i tym samym ustala dopuszczalne przy niej jednostki. Dla energy<\/code> s\u0105 to Wh, kWh i MWh. Dla power<\/code> s\u0105 to W i kW, a czujnik mocy nie wchodzi w rachub\u0119 jako \u017ar\u00f3d\u0142o energii bez wzgl\u0119du na reszt\u0119 \u0142adunku – wat jest tempem, a panel sumuj\u0105cy tempa by\u0142by po prostu b\u0142\u0119dny.<\/p>\nunit_of_measurement<\/code> por\u00f3wnuje si\u0119 dos\u0142ownie. kWh<\/code> przechodzi, kwh<\/code> i KWH<\/code> nie, a skutkiem nie jest odrzucony \u0142adunek, tylko encja, kt\u00f3rej jednostka nie pasuje do klasy i kt\u00f3rej przez to nie da si\u0119 wybra\u0107. To zdecydowanie najcz\u0119stsza przyczyna i jest niewidoczna na ka\u017cdym ekranie poza tym, na kt\u00f3rym encja si\u0119 nie pojawia.<\/p>\nstate_class<\/code> rozstrzyga, czy w og\u00f3le powstaje statystyka d\u0142ugoterminowa. Bez tego pola warto\u015b\u0107 zostaje w kr\u00f3tkiej historii i nigdzie indziej; z b\u0142\u0119dnym – tak samo. Tylko total<\/code> i total_increasing<\/code> wytwarzaj\u0105 sumy godzinowe, z kt\u00f3rych czyta panel energii.<\/p>\ntotal_increasing, total, measurement<\/h2>\n
total_increasing<\/code> jest pomy\u015blane dla licznik\u00f3w licz\u0105cych wy\u0142\u0105cznie w g\u00f3r\u0119. Spadek odczytuje si\u0119 jako wymian\u0119 licznika – wymienione urz\u0105dzenie, oprogramowanie startuj\u0105ce od zera – i nowa warto\u015b\u0107 liczy si\u0119 od tego miejsca, zamiast jako ujemne zu\u017cycie. Nie potrzebuje last_reset<\/code> i dla niemal ka\u017cdego licznika energii jest wyborem w\u0142a\u015bciwym.<\/p>\ntotal<\/code> jest dla warto\u015bci, kt\u00f3re mog\u0105 te\u017c spada\u0107, na przyk\u0142ad bilansu, i oczekuje znacznika last_reset<\/code>, by wiedzie\u0107, kiedy zacz\u0105\u0142 si\u0119 okres. measurement<\/code> jest dla wszystkiego, co jest stanem, a nie sum\u0105: temperatury, mocy, wilgotno\u015bci. To ustawienie, po kt\u00f3re si\u0119gaj\u0105 wszyscy, bo brzmi neutralnie, i to pow\u00f3d, dla kt\u00f3rego nienaganny stan licznika daje \u0142adny przebieg i nigdy ani jednej kilowatogodziny.<\/p>\ntotal_increasing<\/code> warto zna\u0107, zanim wyst\u0105pi: warto\u015b\u0107 skacz\u0105ca w d\u00f3\u0142 zostaje przy dostatecznie du\u017cym skoku odczytana jako wymiana licznika, a ca\u0142y nowy stan ksi\u0119guje si\u0119 w tej godzinie jako zu\u017cycie. Licznik, kt\u00f3ry sporadycznie melduje starsz\u0105, ni\u017csz\u0105 warto\u015b\u0107, daje wi\u0119c nie ma\u0142y b\u0142\u0105d, tylko szczyt wysoko\u015bci ca\u0142ego stanu licznika.<\/p>\nKt\u00f3ry objaw pochodzi z kt\u00f3rego wiersza<\/h2>\n
\n\n
\n \nObjaw<\/th>\n Przyczyna w \u0142adunku<\/th>\n<\/tr>\n<\/thead>\n \n Encja jest, nie da si\u0119 jej wybra\u0107 jako \u017ar\u00f3d\u0142a energii<\/td>\n brak state_class<\/code> albo ustawione measurement<\/code><\/td>\n<\/tr>\n\n Encja jest, jednostka widoczna, ale nigdy nie sumowana<\/td>\n jednostka nie pasuje do device_class<\/code>, np. kwh<\/code><\/td>\n<\/tr>\n\n Encji nie da si\u0119 przemianowa\u0107 ani edytowa\u0107<\/td>\n brak unique_id<\/code> – a wraz z tym r\u00f3wnie\u017c \u017cadnego \u017ar\u00f3d\u0142a energii<\/td>\n<\/tr>\n\n Pojedynczy ogromny szczyt w jednej godzinie<\/td>\n total_increasing<\/code> przy liczniku, kt\u00f3ry zameldowa\u0142 ni\u017cej<\/td>\n<\/tr>\n\n Warto\u015b\u0107 stoi od dni, zu\u017cycie wynosi zero<\/td>\n brak availability_topic<\/code> i brak expire_after<\/code><\/td>\n<\/tr>\n\n Usuni\u0119te urz\u0105dzenie wraca po restarcie<\/td>\n zachowanego tematu konfiguracji nigdy nie opr\u00f3\u017cniono<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Czujnik, kt\u00f3ry zachowuje ostatni\u0105 warto\u015b\u0107 na zawsze<\/h2>\n
availability_topic<\/code> z ostatni\u0105 wol\u0105 po stronie urz\u0105dzenia jest rozwi\u0105zaniem czystym, expire_after<\/code> zgrubnym – liczb\u0105 sekund, po kt\u00f3rych stan uznaje si\u0119 za niedost\u0119pny, je\u015bli nic nowego nie dotar\u0142o. Dla licznika nadaj\u0105cego co dziesi\u0119\u0107 sekund trzysta jest hojne, a martwe urz\u0105dzenie i tak wychwyci w ci\u0105gu pi\u0119ciu minut.<\/p>\nStatystyka nie patrzy wstecz<\/h2>\n