Powercalc (dawniej: Power calculation i kilka innych nazw) - wirtualne sensory poboru mocy i zużytej energii [HACS]

Kwestia dotyczy ostatnio modnego tematu - mamy od HA 2021.08 dostępny panel “Energia”, więc warto go wykorzystać maksymalnie.

A wspomniany w tytule projekt właśnie wchodzi w “dojrzałą” fazę rozwoju.

Może zacznę od wątku na oficjalnym forum HA (założonego przez autora tego komponentu niestandardowego):

Konfiguracja wprawdzie wymaga “kilometrowych” wpisów w configuration.yaml (lub poprzez include w jakimś innym pliku), więc warto poczytać dokumentację

Oto króciutki przykład na wykorzystanie wraz z systemową integracją integration czyli całką Riemanna co umożliwi nie tylko odczyt mocy, ale i pobranej energii - tyle potrzeba by mieć wskazania z jednej żarówki lub tzw. lampy zintegrowanej, czyli konstrukcji nierozbieralnej bez wymiennych żarówek (o ile jej pomiary znajdują się już w bazie LUT)

sensor:
## biurko
  - platform: powercalc
    entity_id: light.lampka_biurkowa_biala
#### fragment poniżej nie jest już potrzebny (dlatego go zakomentowałem)
#  - platform: integration
#    source: sensor.lampka_biurkowa_biala_power
#    name: lampka_biurkowa_biala_energy_spent
#    device_class: energy
#    state_class: total_increasing
#    unit_prefix: k
#    round: 2

Obecnie wpisy konfiguracyjne tworzące encję pobranej energii można wygenerować półautomatycznie (opis w dokumentacji), ale wkrótce wykorzystanie integracji całki Riemanna ma nie być konieczne, więc będzie nieco prościej.
Edit: od wersji 0.4.0 encje zużytej energii są domyślnie generowane automatycznie. (na podstawie wpisów konfiguracyjnych integracji powercalc - w przykładzie powyżej to 2 linijki, które są wymaganym minimum, oczywiście w instalacjach bez mostka Hue lub w innych technologiach niż Zigbee trzeba jeszcze zdefiniować modele, czego nie ma w przykładzie powyżej, ale jest w dość dobrej dokumentacji).

Komponent na obecnym etapie rozwoju działa najlepiej (tzn.konfiguracja jest wtedy najprostsza), gdy używamy integracji z mostkiem Philips Hue do sterowania oświetleniem, ale można go używać do zupełnie innych rozwiązań (pierwotnie był adresowany do użytkowników Hue, ale się rozrósł i jest obecnie bardzo elastyczny i naprawdę dość uniwersalny).

W trybach liniowym i stałej mocy (również dostępna jest opcja zależności od stanu innej encji np. media_player) daje się wykorzystać do praktycznie każdego typowego domowego odbiornika energii (którego realny pobór mocy znamy lub sobie wcześniej zmierzymy za pomocą miernika lub smart-plug’a).

W obecnej chwili (od paru miesięcy, ale tego się nie da stworzyć z dnia na dzień, bo pomiary są po prostu czasochłonne) powstaje baza plików LUT (lookup table) zawierających wartości mocy w zależności od jasności, nasycenia i koloru żarówek i lamp zintegrowanych (które z zasady nie raportują własnego poboru mocy) i po prostu potrzeba współtwórców tej bazy.

Więc zapraszam osoby dysponujące odpowiednią wiedzą i sprzętem do wsparcia projektu własnym wkładem pracy (aby nie było, że się obijam - w obecnej chwili koło 1/3 pomiarów przygotowałem osobiście, choć “dla większości niestety” używam głównie mało popularne modele).

Na dziś baza LUT zawiera 15 modeli żarówek/lamp Philips/Signify, 7 Ikea i kilka innych producentów (innr, Sonoff i Belkin konkretnie łącznie 4 modele), w planach jest uzupełnienie bazy modeli również innych firm, oczywiście na miarę możliwości użytkowników, niektóre najświeższe pomiary nie są zatwierdzone, z powodu zbyt “mało gęstej” siatki pomiarów, więc konieczne jest ustalenie nieco ściślejszych reguł dotyczących opomiarowania by zachować możliwie wysoką jakość bazy
(sam mam w przygotowaniu jeszcze przynajmniej 2 modele Ikea, 1 Muller-Licht, 1 Ledvance i 1 Osram oraz być może więcej jeśli uda mi się pożyczyć żarówki Zigbee od znajomych).

Gotowy skrypt autora integracji umożliwia pomiary za pomocą Shelly Plug lub Shelly Plug S (oraz zapewne Shelly 1PM) z użyciem mostka Philips Hue (to załatwia w miarę automatyczne generowanie poprawnych nazw), możliwe są i inne rozwiązania, ale wtedy potrzebna jest wiedza programistyczna (której mi niestety brakuje), jest szansa, że inni autorzy podzielą się swoimi skryptami (widziałem już raporty czego używają programistycznie mądrzejsi i to całkiem różny sprzęt, w tym “mignął” mi np. tp-link HS110, który zdaje się ma całkiem przyzwoity układ pomiarowy).
Shelly Plug S sam wcześniej pomierzyłem z wykorzystaniem przyrządu co do którego mam jako takie zaufanie (więc wiem, że losowo wybrany egzemplarz daje wyniki o w miarę przyzwoitej dokładności, niestety jest pewien problem z Shelly - drobne niedoróbki dotyczące prawdopodobnie firmware lub API, ponieważ korzystając z istniejącego API można uzyskać zaledwie jeden pomiar na około 5 sekund, więc skrypt nie może pracować zbyt szybko).
Niestety w trakcie pomiarów “wypłynęła” dość istotna niedoróbka firmware Shelly - wskazania poniżej około 0,5W są raportowane jako zero (po dłuższym dociekaniu i kolejnej porcji pomiaru wyszło, że ta granica leży w okolicy 0,4W), jak podejrzewam jest to sztucznie ustawiony filtr by ukrywać pewne niedokładności pomiaru w okolicach rzeczywistego zera - a konkretniej moim zdaniem chodzi o likwidację niezerowych wskazań przy całkowitym braku obciążenia (podejrzewam, że taki mechanizm mogą też stosować inni wytwórcy smart-plugów, jako że sama metoda pomiaru dla bardzo małych obciążeń nie jest zbyt pewna ani dokładna).
Nowe wersje skryptów pomiarowych mają umożliwić równoczesne sterowanie grupą żarówek (używając 2 lub 3 żarówek tego samego typu można podnieść sumaryczny pobór mocy powyżej tej granicy nawet w przypadku pracy w standby, gdzie pomiar dla większości żarówek i lamp Zigbee nie jest możliwy, bo zdecydowana większość tego co jest na rynku w tym trybie pobiera w okolicach 0,4W lub nawet znacznie mniej - ostatnie generacje to okolice 0,2W).

Na obrazku poniżej podgląd jak się sprawy mają podczas pomiaru i ile może trwać pomiar jednej żarówki białej z możliwością regulacji odcienia bieli (dla żarówek/lamp w pełni kolorowych trzeba wykonać 2 pomiary i ten drugi dla trybu HS jest wielokrotnie dłuższy…) - na obrazku Ledvance Tibea 2000lm w trakcie pomiarów a właściwie tuż- kilkanaście minut- przed finiszem (jest to lampa “pół-zintegrowana”, czyli dostępna w postaci kompletnego plafonu, lub samej ”żarówki" o wybitnie nietypowym kształcie, ale możliwym do wkręcenia do niektórych żyrandoli z półotwartym kloszem)

Tym razem “w obróbce” tj. w trakcie pomiaru LCT001 (RGB+TW) - jak widać pomiar trybu HS (tak naprawdę to HSB) trwa około 2 doby nawet korzystając z dość zoptymalizowanych ustawień skryptu (a do kompletu potrzebny jest jeszcze color_temp, który trwa kilka godzin)


to co widać na powyższych obrazkach to wartości mocy podebrane z integracji Shelly w HA (ale skrypt w wersji jaką używam odwołuje się bezpośrednio do API Shelly, to powyżej można traktować jedynie jako podgląd czy wszystko przebiega poprawnie)

Miałem wrzucić tylko jeden obrazek poglądowy


Ale tak naprawdę dopiero ta integracja dała mi pogląd na to jak mam nieefektywne oświetlenie :smiley: (stąd pomysł na mierzoną powyżej żarówko-lampę Tibea, chociaż jak wiadomo oszczędności na oświetleniu można osiągnąć jednie pozorne - wydając “wiaderko” kasy zaoszczędzę jakieś 2W, a może i najprawdopodobniej nic - ta zmiana zasadniczo ma na celu redukcję oślepiania) - oto przykłady różnych scen oświetleniowych

ewentualnie można ciekawiej to wyświetlić używając nowych opcji kart wskaźnika (gauge)


kod z edytora kart tego co tu widać (dostosowany pod moje żarówki)

type: grid
cards:
  - type: vertical-stack
    cards:
      - type: light
        entity: light.zyrandol_tv_1
      - type: gauge
        entity: sensor.zyrandol_tv_1_power
        min: 0
        max: 9
        needle: true
        severity:
          green: 0
          yellow: 1
          red: 8
  - type: vertical-stack
    cards:
      - type: light
        entity: light.zyrandol_tv_2
      - type: gauge
        entity: sensor.zyrandol_tv_2_power
        min: 0
        max: 9
        needle: true
        severity:
          green: 0
          yellow: 1
          red: 8
  - type: vertical-stack
    cards:
      - type: light
        entity: light.zyrandol_tv_3
      - type: gauge
        entity: sensor.zyrandol_tv_3_power
        min: 0
        max: 9
        needle: true
        severity:
          green: 0
          yellow: 1
          red: 8
  - type: vertical-stack
    cards:
      - type: light
        entity: light.zyrandol_tv_4
      - type: gauge
        entity: sensor.zyrandol_tv_4_power
        min: 0
        max: 9
        needle: true
        severity:
          green: 0
          yellow: 1
          red: 8
  - type: vertical-stack
    cards:
      - type: light
        entity: light.zyrandol_tv_5
      - type: gauge
        entity: sensor.zyrandol_tv_5_power
        min: 0
        max: 9
        needle: true
        severity:
          green: 0
          yellow: 1
          red: 8
  - type: vertical-stack
    cards:
      - type: light
        entity: light.zyrandol_tv_k
      - type: gauge
        entity: sensor.zyrandol_tv_k_power
        min: 0
        max: 10
        needle: true
        severity:
          green: 0
          yellow: 1
          red: 9
5 polubień

O takie posty na tym forum nic nie robiłem :wink: Dzięki!

To taka mała aktualizacja - projekt ostatnio mocno “ruszył z kopyta”, ale na dziś zalecam instalację v0.4.3
o ile ktoś intensywnie nie potrzebuje opcji dostępnych w v0.5.0 (bo niestety podczas upraszczania kodu wkradły się błędy wymagające poprawek, a było zbyt niewielu testerów wersji beta).

Natomiast baza LUT zawiera już 22 modele lamp i żarówek Zigbee Philps/Signify; 8 modeli żarówek Zigbee Ikea i 6 innych producentów/technologii (w tym chyba 2 w technologii innej niż Zigbee) - to stan z okolic południa, bo wieczorem jest już więcej - pojawiły się PR osób które nie publikowały informacji o modelach w trakcie pomiaru.
Minęły niecałe 2 tygodnie od poprzedniego posta, to tak dla porównania - dziś to łącznie 36 modeli, poprzednio było 26, więc widać w jakim tempie przyrasta baza modeli, ale bez aktywnego wsparcia innych przestanie ona rosnąć gdy przemierzymy wszystkie światła, które mamy w swoich instalacjach.

W ramach githubowych “dyskusji” mamy dział z planowanymi pomiarami (by nie dublować pomiarów które trwają bardzo długo)

Nieco wcześniej powstało dedykowane issue do tego celu, ale dyskusje wydają się być lepsze (można tam omówić ewentualne problemy z pomiarem przed utworzeniem PR)

Realnie jeden współpracownik projektu jest w stanie przygotować 1, góra 2 modele RGBW tygodniowo (gdyby nie miał nic lepszego do roboty :smiley: ) lub nieco więcej świateł białych (o zmiennej temperaturze lub po prostu ściemnialnych), więc konieczne jest wsparcie użytkowników (bo jakoś sobie nie wyobrażam kupowania sprzętu wyłącznie pod kątem pomiaru w projekcie, choć mi się to zdarzyło - ciekawość czasem zwycięża :stuck_out_tongue: ) więc cała nadzieja w ogromnej społeczności użytkowników HA (w końcu to jest “dla nas i przez nas”).

@szopen Można by niebo oświetlać :slight_smile:

Tabela modeli dla których istnieją pliki LUT (lookup table) - dość łatwo ją przeoczyć w dokumentacji, a jest ona automatycznie aktualizowana przy dodawaniu każdego kolejnego wspieranego modelu:

Sytuacja na dziś to już 40 modeli Signify (dawny Philips), 10 Ikea i 7 innych producentów, dla chętnych do przyłączenia się do pomiarów w dyskusjach jest lista zaplanowanych pomiarów powstał też dział na przykładowe konfiguracje (jak na razie można tam znaleźć tylko informacje o poborze mocy przez popularne(?) smart-plug’i, ale jeśli ktoś ma trochę czasu to w zamkniętych issues można wygrzebać jakieś przykładowe konfiguracje użytkowników tego komponentu),

mam żarówki tradfri, tworze sensor dla tych żarówek. W zakładce energia jak dodaje nowo stworzone sensory to jest informacja że są nieobsługiwane. Inne żarówki na wifi smigają bez problemu

A zajrzałeś na listę obsługiwanych modeli?
Ona się sama z powietrza nie bierze, tworzą ją użytkownicy mierząc parametry żarówek - trochę wody w Odrze upłynie zanim uzupełnię bazę o wszystkie żarówki do jakich mam dostęp.

wpisuje moc z palca, tak jak jest w dokumentacji :wink:

To musi działać, wklej konfigurację (przypominam o linijkach z ``` przed i po), jeśli będę w stanie znaleźć błąd to pomogę, jeśli nie, to założysz issue (nie śledzę zmian w projekcie na bieżąco).

Mały UPDATE - potrzebni betatesterzy - komponent się dorobił GUI (nie odzwierciedla ono wprawdzie wszystkich możliwości dostępnych w YAML i jest przynajmniej jak na razie jedynie w języku angielskim).

Aktualnie to wersja v0.24.0-alpha.1 i wymaga do instalacji włączenia wyświetlania wersji beta w HACS (lub ręcznej instalacji, ale wygodniej to zrobić z HACS).

Spostrzeżenia i zgłoszenia błędów należy kierować bezpośrednio do autora (oczywiście po angielsku) zgodnie z zaleceniami:

Tak trochę offtopic ale lubię jego filmy :slight_smile: I trochę przez niego przeszedłem na NAS i wersję na osobnych docerach :slight_smile:

Też trochę offtopic - gdy pierwszy raz trafiłem na ten komponent to nazywał się bodajże “Huepower” (nomeassistant-huepower), ale nazwa zmieniała się parę razy, chyba jednak Powercalc się przyjęło w końcu na stałe, więc znowu zaktualizowałem tytuł wątku.

Co do filmiku, to zasadniczo dokumentacja jest wyjątkowo dobra, a autor projektu wielokrotnie dorabiał ficzery na życzenia użytkowników (więc naprawdę duży szacunek za utrzymanie aktualnej dokumentacji od początku istnienia projektu po dziś, bo stopień jego komplikacji rósł wykładniczo :stuck_out_tongue: gdzie już mamy częściowo działające GUI).

PS jeśli macie jakieś uwagi do tłumaczenia GUI na polski, to można je zgłaszać tutaj (lub przygotować PR z poprawkami - nie zawsze mam czas by uzupełniać braki na bieżąco).

@szopen takie pytanko, bo chyba najbardziej jesteś oblatany w tym temacie. Dodanie w yaml takiego zapisu:

powercalc:
  create_utility_meters: true
  utility_meter_types:
    - daily
    - monthly
  utility_meter_tariffs:
    - peak
    - offpeak

spowoduje automatyczne włączenie liczenia zużycia i podział na taryfy? Oczywiście muszę sam aktywować daną taryfę, tak, jak to robię normalnie dla utility meter?

Nie mam żadnej instalacji z 2 taryfami, ale z tego na ile kojarzę to jakoś tak to wygląda, trzeba by zajrzeć do dokumentacji (a oprócz niej na githubie są włączone dyskusje i wiki, niestety większość bardziej skomplikowanych konfiguracji można znaleźć jedynie w issues, więc jeśli przetestujesz i masz trochę siły na to by klepnąć parę linijek bardziej rozbudowanej dokumentacji z przykładami, to sugeruję uzupełnienie wiki).

Kolejny update - od jakiegoś czasu dostępna jest ulepszona dokumentacja
https://homeassistant-powercalc.readthedocs.io/en/latest/

Zacząłem dodawać sobie różne urządzenia do tego powercalc’a i coś tam nawet działa ale mam kilka lamp do których nie ma LUT’ów.
Kupiłem Shelly Plug S nie tylko w tym celu ale także do monitoringu różnych urządzeń aby mieć świadomość co ile prądu bierze.
Chciałem zrobić pomiary aby wygenerować pliki do posiadanych przeze mnie lamp ale niestety utknąłem na konfiguracji kontenera. Mam małe pojęcie o dockerze, a mój kontener stoi na Container Station na QNAPie który ma mocno ograniczone możliwości konfiguracyjne, do tego mam kontener z Portainerem który daje nieco większe możliwości konfiguracyjne ale coś ewidentnie jeszcze jest nie tak bo wywala mi błąd: “TypeError: Can’t instantiate abstract class ShellyPowerMeter with abstract method process_answers”
Ma ktoś pomysł o co może chodzić ?

Istotna zmiana w wersji 1.8.0 - breaking change, zmienia się format YAMLa i jest dostosowywany do nowej składni innych komponentów
https://homeassistant-powercalc.readthedocs.io/en/latest/configuration/new-yaml-structure.html

Wydanie v1.10.3 powinno zawierać uzupełnienie polskiego tłumaczenia (wymagane do w pełni poprawnej pracy z HA core >=2024.2.0).
Aktualizacja będzie raczej konieczna, ze względu na nowe testy komponentów niestandardowych, które będą wykonywane w nowszych wersjach HA core.


W związku z wprowadzeniem nowego pojęcia playbook zdecydowałem o użyciu go jako anglicyzm (takie decyzje też podjętli tłumaczący Powercalc na inne języki), bo niestety tłumaczenie dosłowne na “podręcznik” moim zdaniem nie ma sensu (nieco podobnie jak entity jest tłumaczone przez spolszczenie na formę encja, a nie jest użyte żadne z wcześniej istniejących tłumaczeń dosłownych tego słowa).
https://homeassistant-powercalc.readthedocs.io/en/latest/strategies/playbook.html

Uwagi do tłumaczeń mile widziane (również sensowne poprawki bezpośrednio w formie PR, wprawdzie jak dotąd niby jestem odpowiedzialny za te tłumaczenia na polski, ale któregoś dnia może mnie zabraknąć…).


Przypominam o zmianie w konfiguracji YAML (przy aktualizacji) jeśli nadal ktoś ma starą wersję (<1.8.0) i używa starej składni.

12 postów zostało podzielonych na nowy temat: ESPHome pośredni pomiar mocy, integracja z Powercalc