Prosument (mnożnik 0,7 lub 0,8) i netbilling

[mmarcines]

@PiotrMachowski czy byłaby szansa dorobienia jakiegoś helper'a (pomocnika) w HA w postaci np. dropdown menu, który implementowałby mnożnik dla prosumentów (0,8 <10kW lub 0,7 >10kW)? Dla netbillingu ten mnożnik mógłby być ignorowany lub też ustawiony na 1.

Idealnie by było również zaimplementować kolejny helper (pomocnik) w HA o typie numer (zapas) by każdy kto produkuje mógł wpisać wartość energii w magazynie z okresu przed implementacją ww.

Sumaryczne obliczenie ilości energii w "banku energii" wyglądać by mogło wówczas tak: (zapas) + (daily_energy_generation * <mnożnik> - daily_energy_consumption)

[PiotrMachowski]

Czy to nie jest coś, co w prosty sposób by się dało ogarnać zwykłymi helperami, automatyzacjami i template sensorami? Nie chcę przesadzić z komplikowaniem integracji.

Osobiście nie mam instalacji PV, także nie do końca się orientuję jak działa ta cała matematyka

[convicte]

Czy to nie jest coś, co w prosty sposób by się dało ogarnać zwykłymi helperami, automatyzacjami i template sensorami? Nie chcę przesadzić z komplikowaniem integracji.

Osobiście nie mam instalacji PV, także nie do końca się orientuję jak działa ta cała matematyka

Oczywiście da się wszystko praktycznie zrobić w opisany powyżej sposób z jednej/dwóch zmiennych w tym wypadku. Mogę zgodzić się z @mmarcines, że dobrym rozwiązaniem byłoby, aby od czasu do czasu 'bank energii' był kalibrowany przez sprawdzenie z licznikiem poprzez API.

Z doświadczenia wiem, że przykładowo, mierząc gaz i wodę analogowo przez impulsometry, co jakiś czas muszę poprawiać zmienne, żeby doszacować wszystkie restarty/awarie/aktualizacje, etc.

Jeżeli jest opcja aby pobierać pomiary dla obecnego stanu banku (nie wiem co daje API), to byłoby na pewno świetne. Przemnożenia przez 0.8 jest komediowo proste w template_sensor albo helper.

[mmarcines]

Czy to nie jest coś, co w prosty sposób by się dało ogarnać zwykłymi helperami, automatyzacjami i template sensorami? Nie chcę przesadzić z komplikowaniem integracji.

Osobiście nie mam instalacji PV, także nie do końca się orientuję jak działa ta cała matematyka

@PiotrMachowski Ty tutaj rządzisz :-) Może i racje nie każdy ma PV i nie każdy jest prosumentem.

[PiotrMachowski]

Jeżeli jest opcja aby pobierać pomiary dla obecnego stanu banku (nie wiem co daje API), to byłoby na pewno świetne.

@convicte a widać takie coś w eLiczniku?

[convicte]

Nie widzę, więc chyba najlepszym sposobem będzie po prostu, aby każdy kto chce taki odczyt wrzucił sobie prosty template z dziennym lub godzinowym trigger, i tyle.

[PiotrMachowski]

Ogólnie, to używane przeze mnie API to nie jest prawilne API z dokumentacją itd., tylko źródło danych dla interfejsu eLicznik. Jeśli czegoś tam nie ma, bądź nie da się wyliczyć na podstawie dostępnych tam danych (tak zrobiłem z bilansem), to nie jestem w stanie tego wyczarować.

Dodanie funkcjonalności, którą zaproponował @mmarcines jest możliwe, ale bym potrzebował dokładniejszego opisu. Dodatkowo nie wiem, czy to gra warta świeczki, jeśli się okaże, że da się coś takiego w 5m wyklikać domyślnymi helperami.

[convicte]

Jasne!

Policzenie tego co chciałby @mmarcines jest niezwykle proste:

(yearly_energy_produced * `opłata magazynowa`) - yearly energy consumed = current_energy_bank_balance

Opłata magazynowa jest tak jak powyżej 20 lub 30% stąd wspomnienie o helperze select.

Dla zabawy kazałem ChatGPT napisać template_sensor and automatyzacje:

[PiotrMachowski]

Oki, to w takim razie moim zdaniem nie ma sensu dodawanie tego do integracji.

Swoją drogą, setup powyżej nie do końca jest prawidłowy, bo:

• używa starej wersji szablonów
• używa podejścia states.domain.entity.state zamiast states('domain.entity')
• automatyzacja ani update_interval nie są tu potrzebne, wystarczy domyślne przeliczanie przy każdej zmianie encji składowych

Ja bym to zrobił tak:

input_number:
  initial_energy_bank:
    min: 0
    max: 100000000 # tutaj do dostosowania
    step: 0.01
    mode: box
template:
  - sensor:
      - name: energy_difference
        state: "{{ states('input_number.initial_energy_bank') | float(0) + states('sensor.tauron_amiplus_123_yearly_energy_generation') | float(0) * 0.8 - states('sensor.tauron_amiplus_123_yearly_energy_consumption') | float(0) }}"
        unit_of_measurement: "kWh"
        availability: "{{ states('sensor.tauron_amiplus_123_yearly_energy_generation') in ['unknown', 'unavailable'] or states('sensor.tauron_amiplus_123_yearly_energy_consumption') in ['unknown', 'unavailable'] }}"

[Arekgor]

Dokładnie, nie ma co komplikować. Ja dodatkowo ręcznie koryguje sobie wartość tego sensora o nadwyżkę z poprzedniego roku (o ile jest) - narazie zakładam, że stary bufor zużyje przed upływem 12 miesięcy od wyprodukowania.

[PiotrMachowski]

@Arekgor o ile dobrze rozumiem, to chyba taki był zamysł input_numbera initial_energy_bank

[convicte]

Oki, to w takim razie moim zdaniem nie ma sensu dodawanie tego do integracji.

Swoją drogą, setup powyżej nie do końca jest prawidłowy, bo:

• używa starej wersji szablonów
• używa podejścia states.domain.entity.state zamiast states('domain.entity')
• automatyzacja ani update_interval nie są tu potrzebne, wystarczy domyślne przeliczanie przy każdej zmianie encji składowych

Ja bym to zrobił tak:

input_number:
  initial_energy_bank:
    min: 0
    max: 100000000 # tutaj do dostosowania
    step: 0.01
    mode: box
template:
  - sensor:
      - name: energy_difference
        state: "{{ states('input_number.initial_energy_bank') | float(0) + states('sensor.tauron_amiplus_123_yearly_energy_generation') | float(0) * 0.8 - states('sensor.tauron_amiplus_123_yearly_energy_consumption') | float(0) }}"
        unit_of_measurement: "kWh"

Masz oczywiście rację - poprawki zrobiłem po przekopiowaniu, ale i tak jest to niesamowite, co AI potrafi zrobić z jednym zdaniem zapytania.

Ciekawe podejście do input_number: - nie znałem go i chętnie przestudiuje. Chyba step: 0.01 kWh to lekka przesada, ale jeżeli ktoś chce się bawić w takie aptekarstwo... ;)

Przydałby się jeszcze availability: dla pewności, żeby nie tworzyć krzaków w sensorze i to wszystko.

To chyba dobry wątek do zachowania gdzieś (po zamknięciu tej sprawy), żeby w przyszłości ludzie mogli skorzystać. Może chciałbyś dorzucić tę informację do readme?

[convicte]

Mój ostateczny sensor banku wygląda tak, jeżeli ktoś chciałby go wykorzystać:

template:
    - sensor:
        - name: Tauron energy bank
          state_class: total
          unit_of_measurement: "kWh"
          device_class: energy
          unique_id: tauron_energy_bank
          icon: mdi:home-battery-outline
          state: "{{ (states('input_number.initial_energy_bank') | float(0) + states('sensor.tauron_yearly_energy_generation') | float(0) * 0.8 - states('sensor.tauron_yearly_energy_consumption') | float(0)) | round(2) }}"
          availability: "{{ states('sensor.tauron_yearly_energy_generation') | is_number and states('sensor.tauron_yearly_energy_consumption') | is_number }}"

Pozostawiłem parametr prosumencki na 80%, ale jeżeli ktoś płaci Tauron 30%, to śmiało podmieńcie na 0.7.

Mój input_number dla energii pozostającej z poprzedniego roku (która u mnie się nie zdarza - za mała farma na dachu), tutaj:

[mmarcines]

@convicte a czy state nie powinien byc tak liczony? input_number.initial_energy_bank = ((generation'2022 0,8) - consumption'2022) state: "{{ states('input_number.initial_energy_bank') | float(0) + (states('sensor.tauron_yearly_energy_generation') | float(0) 0.8 - states('sensor.tauron_yearly_energy_consumption') | float(0)) | round(2) }}"

imho bank to nie jest Generation'2022 - Consumption'2022 tylko (Generation'2022 * 0,8 - Consumption'2022)? A jesli tak jest to juz initial_energy_bank nie mnozymy przez "mnoznik".

[Jordan87]

Pisalem o tym w innym watku wiec wspomne i tutaj. Nie powinniscie brac informacji z wartosci normalnych tylko z bilansowanych. Od kiwetnia 2022 wszyscy dostawcy maja najpierw bilansowac energie godzinowo a dopiero pozniej rozliczac. Interesuja was atrybuty sum_generation oraz sum_consumption.

[tomasz-soltysik]

Dane te są dostępne pod tym samym adresem co normalne (https://elicznik.tauron-dystrybucja.pl/energia/api), tylko trzeba podać inną wartość w type (netto dla pobranej, netto_oze dla oddanej)

[tomasz-soltysik]

Przykład odpowiedzi dla

from: 17.11.2023
to: 17.11.2023
type: netto
profile: full time

[tomasz-soltysik]

I jeszcze przykład dla całego roku, bo to nas najbardziej interesuje:

from: 1.01.2023
to: 31.12.2023
type: netto_oze
profile: year

(W formie zakodowanej: from=1.01.2023&to=31.12.2023&type=netto_oze&profile=year)