Closed mmarcines closed 1 year ago
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
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
.
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.
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?
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.
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.
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:
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:
states.domain.entity.state
zamiast states('domain.entity')
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'] }}"
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.
@Arekgor o ile dobrze rozumiem, to chyba taki był zamysł input_numbera initial_energy_bank
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
zamiaststates('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
?
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:
@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".
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.
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)
Przykład odpowiedzi dla
from: 17.11.2023
to: 17.11.2023
type: netto
profile: full time
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
)
@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)