Encja Meter reading, zamiast _energy_used powinna mieć identyfikator z sufixem _meter_reading (to stan licznika), bo obecnie to myli się z _energy_consumed.
Encje _consumed i _produced powinny inaczej się nazywać.
Konsumpcja to suma energii pobranej z sieci oraz energii zużytej z własnej instalacji PV.
Licznik nie mierzy całej konsumpcji a tylko energię pobraną z sieci.
Natomiast energia wyprodukowana z własnej instalcji PV to suma energii zużytej na miejscu oraz energii oddanej do sieci.
Licznik nie mierzy całej energii wyprodukowanej a tylko energię oddaną do sieci.
Moja propozycja poprawki sufixów to _grid_import i _grid_export.
Należy też poprawić nazewnictwo w kreatorze konfiguracji
Brakujące informacje o produkcji i zużyciu (w HA do integracji inną metodą)
Jeżeli ktoś sobie zintegruje dane z inwertera lub podlicznika instalacji PV, to będzie mógł uzupełnić brakujące informacje o całkowitej produkcji swojej instalacji i to będzie _production
Jeżeli ktoś sobie pomierzy całkowite zużycie czyli _total_consumption, to będzie mógł wyliczyć autokonsumpcję ze swojej fotowoltaiki. Przyjmijmy, że to można nazwać _self_consumption = _total_consumption - _grid_import
Piszę o tym, bo do takiego właśnie modelu dążę a na początek mam to co dają integracje typu Energa My Meter 😎
Nazewnictwo stref taryfowych
Czy nie lepiej jakby strefowość taryf była określona cyfrą? czyli _strefa_1 i _strefa_2. Tak jest na portalu a poza tym entity_id by było krótsze.
W integracji teraz mamy _strefa_calodobowa. To znaczy, że dla taryfy G12 lub C12 trzeba użyć dwóch kolejnych nazwy np. strefa_szczyt i strefa_pozaszczyt a na portalu mojlicznik mamy:
To znaczy, że strefa całodobowa z G11 to jest to samo co strefa szczyt z G12 czyli w encji byśmy mieli _strefa_1.
Gdy ktoś zmieni taryfę z G11 na G12, to dojdzie mu encja _strefa_2 a w encji _strefa_1 będzie miał ciągłość danych.
Chociaż muszę przyznać, że tu nie jestem do końca pewny, bo w GUI mamy Strefa 1 i Strefa 2 a JSON API przewidziane są 3 pola:
"zones": [
285.07,
null,
null
]
Numer identyfikacyjny dla encji
Liczniki podlegają wymianie a ich numery będą się zmieniać. Dlatego są nadane też inne identyfikatory:
Miałem ostatnio wymianę licznika i byłem ciekaw czy na portalu historię będę miał pod starym numerem a świeże odczyty pod nowym numerem i będę musiał dodać sobie nową encję w HA i to by było słabe. Na szczęście wszystkie dane historyczne i aktualne są pod jednym meterPoint.
W przypadku tej integracji po wymianie licznika, numery w nazwie entity_id to już nie będzie numer licznika. Jak w takiej sytuacji zachowa się integracja?
Powinna się zachować tak jak platforma mójlicznik, czyli zachować ciągłość danych pod jednym identyfikatorem.
Sformułowania w identyfikatorach encji
_energy_used
powinna mieć identyfikator z sufixem_meter_reading
(to stan licznika), bo obecnie to myli się z_energy_consumed
._consumed
i_produced
powinny inaczej się nazywać.Moja propozycja poprawki sufixów to
_grid_import
i_grid_export
.Originally posted by @paki111 in https://github.com/thedeemling/hass-energa-my-meter/issues/2#issuecomment-2478630562
Należy też poprawić nazewnictwo w kreatorze konfiguracji
Brakujące informacje o produkcji i zużyciu (w HA do integracji inną metodą)
_production
_total_consumption
, to będzie mógł wyliczyć autokonsumpcję ze swojej fotowoltaiki. Przyjmijmy, że to można nazwać_self_consumption
=_total_consumption
-_grid_import
Piszę o tym, bo do takiego właśnie modelu dążę a na początek mam to co dają integracje typu Energa My Meter 😎
Nazewnictwo stref taryfowych
Czy nie lepiej jakby strefowość taryf była określona cyfrą? czyli
_strefa_1
i_strefa_2
. Tak jest na portalu a poza tym entity_id by było krótsze. W integracji teraz mamy_strefa_calodobowa
. To znaczy, że dla taryfy G12 lub C12 trzeba użyć dwóch kolejnych nazwy np. strefa_szczyt i strefa_pozaszczyt a na portalu mojlicznik mamy:To znaczy, że strefa całodobowa z G11 to jest to samo co strefa szczyt z G12 czyli w encji byśmy mieli
_strefa_1
. Gdy ktoś zmieni taryfę z G11 na G12, to dojdzie mu encja_strefa_2
a w encji_strefa_1
będzie miał ciągłość danych.Chociaż muszę przyznać, że tu nie jestem do końca pewny, bo w GUI mamy Strefa 1 i Strefa 2 a JSON API przewidziane są 3 pola:
Numer identyfikacyjny dla encji
Liczniki podlegają wymianie a ich numery będą się zmieniać. Dlatego są nadane też inne identyfikatory:
Miałem ostatnio wymianę licznika i byłem ciekaw czy na portalu historię będę miał pod starym numerem a świeże odczyty pod nowym numerem i będę musiał dodać sobie nową encję w HA i to by było słabe. Na szczęście wszystkie dane historyczne i aktualne są pod jednym
meterPoint
. W przypadku tej integracji po wymianie licznika, numery w nazwie entity_id to już nie będzie numer licznika. Jak w takiej sytuacji zachowa się integracja? Powinna się zachować tak jak platforma mójlicznik, czyli zachować ciągłość danych pod jednym identyfikatorem.Originally posted by @paki111 in https://github.com/thedeemling/hass-energa-my-meter/issues/2#issuecomment-2481435166