Od ogółu do szczegółu, czyli liczymy użycie energii

dn.

W ostatnim poście opisywałem proces integracji urządzeń smart home w Home Assistant. Zdecydowałem, że warto pociągnąć pokrewny temat, związany z dość specyficznym detalem, dotyczącym działania jednego z urządzeń systemu.

Jak zatem policzyć te kilowaty?

Mowa tutaj o module Energy Monitor, który zlicza rotacje tarczy mechanicznego licznika energii elektrycznej. Krótko mówiąc, jest to urządzenie, które zaprojektowałem, by móc śledzić zużycie energii elektrycznej w czasie rzeczywistym i tym samym dodać możliwości znane ze świata IoT, do produktu niemal starszego ode mnie.

Moduł sensora odbiciowego używanego w urządzeniu Energy Montior.

Na początku szło zbyt łatwo...

Ucząc się nieprzerwanie nowych zagadnień z elektroniki, wpadłem na pomysł liczenia obrotów tarczy licznika elektrycznego. Idea była prosta - bierzemy gotowy czujnik odbiciowy, działający w podczerwieni, który da się ustawić na odpowiedni próg aktywacji i reagujemy na zmianę stanu wyjścia. Liczymy różnicę czasu, podstawiamy pod wzór i po robocie - mamy aktualne użycie w watach. Dodając do siebie zliczone obroty i wiedząc, że 375 obrotów to jedna kilowatogodzina - mamy kilowatogodziny. Dzięki podczerwieni powinno to działać także w nocy, nie oświetlając światłem widzialnym niepotrzebnie pomieszczenia. Proste prawda?

Blask słońca obnażył jednak ponurą prawdę...

Licznik powieszony jest w miejscu, które zwykle nie jest zbyt nasłonecznione - i w pierwszej iteracji projektu, gdy zamocowałem wszyskto na miejscu (a było to na jesieni, gdy praktycznie codziennie jest szaro). Całość działała, tak jak zakładałem. Potem, po zimie, przyszła wiosna i cały misterny plan w... psu na budę poszedł.

Okazało się, że często otworzenie drzwi w słoneczny dzień powoduje przeskoczenie progu aktywacji i wyłapywanie impulsu. To w zasadzie zrozumiałe, gdyż nasza gwiazda emituje również promieniowanie podczerwone. Zdarzało się też, zwykle podczas letniego wieczoru, iż słońce świeciło w taki sposób, że odczyty falowały w okół "granicy" i przeskakiwały raz powyżej, raz poniżej poziomu aktywacji, generując absurdalne wyniki.

A gdyby tak rzucić wszystko?

Pierwsza iteracja projektu działała bodaj przez kilkanaście miesięcy. Po powrocie z wakacji w 2020 r., naładowany pozytywną energią przygotowałem drugą wersję płytki, zaprojektowałem oprogramowanie, które udoskonalam do dziś (o czym w następnym akapicie), złożyłem zamówienie na PCB a po zlutowaniu wrzuciłem informację o projekcie na portal Hackaday. Temat podchwycił zespół redakcyjny magazynu Elektronika Praktyczna  - i, gdy przeczytałem w magazynie o swoim projekcie, po raz kolejny złapałem bakcyla do dalszego jego rozwoju.

Zdjęcie notki w magazynie Elektronika Praktyczna.
Wkradł się tam mały błąd, gdyż projekt używa ESP8266 a nie ESP32.

O obrotach tarcz liczników mechanicznych...

Pomysł, który przyszedł mi do głowy, to coś w rodzaju kroczącej autokalibracji. Stwierdziłem, że oprogramowanie, by nie mylić obrotu licznika z zamknięciem drzwi, powinno jakoś "mądrze" analizować wartości - tj. ich trend - a nie tylko sprawdzać, czy aktualna wartość jest powyżej lub poniżej sztywnego progu aktywacji.

Pomysł analizy trendu wartości (wykres stricte poglądowy).

Po kilkunastu niezliczonych małych iteracjach rozrysowywania i programowania, doszedłem do wniosku, że następujący algorytm będzie odpowiednio skuteczny do zadanych warunków.
  • Po uruchomieniu urządzenia zbieramy dobraną doświadczalnie ilość odczytów do bufora co dobraną doświadczalnie ilość milisekund. Wyszło, że optymalnym jest pamiętać 400 wartości odczytywanych co 50 milisekund.
  • Po wypełnieniu tablicy początkowymi wartościami, cały czas co 50 ms odczytujemy kolejną wartość i zamieniamy z najstarszą próbką. Każdorazowo analizujemy "odchylenie" odczytu względem dominanty, dzieląc odczytaną wartość przez aktualnie wyliczoną dominantę.
  • Jeśli obliczona wartość dla kilku próbek z rzędu daje wynik poniżej 1,1 - oznacza to, że "linia wykresu" ustabilizow. Między dwiema górkami, oznaczającymi czarny obszar na tarczy, odczytywana wartość zwykle względem dominanty ani nie spada ani nie rośnie znacząco. Wystarczy odczekać, aż kilka takich wartości wystąpi z rzędu.
  • Gdy osiągnęliśmy stabilne odczyty, czekamy na "górkę" - czyli znaczne odchylenie, wzrost wyniku powyżej 1,75. W tym momencie "łapiemy" czarny obszar na tarczy. Różnica czasowa między aktualną a poprzednią "górką" pozwala nam obliczyć zużycie energii a także zarejestrować sam obrót tarczy. Przechodzimy do poprzedniego kroku, tym samym definiując ciągłą pracę urządzenia.
Celem ułatwienia pracy z sensorem, wykorzystałem prostą konstrukcję, przypominającą maszynę stanów. Dzięki temu udało się w widoczny sposób odseparować warunki przejść pomiędzy stanami a także uczynić kod bardziej przejrzystym.

Obsługa wykrywania etapów obrotu tarczy.

Ostatnim usprawnieniem detekcji było usprawnienie procesu obliczania dominanty. Zamiast co odczyt wartości budować tablicę ilości wystąpień dla wartości historycznych, zdecydowanie wydajniej jest manipulować od razu na ilości wystąpień. Mając bufor wartości historycznych oraz aktualną wartość próbki, możemy po prostu odjąć wystąpienie wartości najstarszej, zamienić ją z wartością aktualnie odczytaną i zwiększyć ilość wystąpień aktualnej wartości.

Kod wykonywany dla kazdej nowej próbki.

Dzięki optymalizacji, unikamy zbędnych iteracji. Do znalezienia wartości dominującej wystarczy w zasadzie przejście po tablicy wystąpień i znalezienie najwyższej wartości. Najwyższa wartość oznacza ilość wystąpień a indeks tej wartości w tablicy będzie, przy tej implementacji, najczęściej występującą wartością. Kod nie obsługuje kilku takich wartości - to znaczy znajdzie pierwszą, niemniej przy normalnej pracy taka sytuacja nie powinna mieć miejsca.

Algorytm znajdowania najczęściej występującej liczby.

Teraz już wystarczy policzyć stosunek dominanty do wartości aktualnie odczytywanej a potem porównać do odpowiednich, stałych wartości progowych. W ten sposób mamy zadowalające wykrywanie obrotów tarczy licznika. Rozwiązanie nie jest wolne od wad, jednak koniec końców fałszywe odczyty zdarzają się niezmiernie rzadko. Nadal istnieje pole do optymalizacji, choćby poprzez zmniejszenie precyzji wartości ale na ten moment nie ma potrzeby rozważania tej możliwośći.

Mając precyzyjne odczyty, wystarczy już tylko obsłużyć sam fakt odnotowania obrotu. Począwszy od drugiego wykrycia czarnej linii/obszaru na tarczy licznika, mając tym samym obie składowe do działania odejmowania, jesteśmy w stanie obliczyć czas obrotu.

Kod wykonywany po wykryciu obrotu tarczy.

Na koniec pozostaje cieszyć się odczytanymi wartościami w Home Assistant.

Chwilowe użycie energii.

Zużycie energii w ujęciu dziennym oraz koszt, na podstawie poglądowej ceny za kWh.

Referencje:

Komentarze

Prześlij komentarz