Vaillant vc-206/5-5 problem z raportowanie zużycia gazu

Mam piec, jak w temacie.
Od dłuższego czasu zmagałem się z problemem odczytu rejestru dotyczącego zużycia gazu. W końcu z pomocą jednego z użytkowników innego forum udało mi się to rozwiązać. Okazało się, że problemem była wartości rejestru bai PrEnergySumHc1 = 4294967237 czyli bliska 2^32. Po zresetowaniu rejestru wszystko ruszyło. Niestety chyba nie tak jak powinno. U mnie licznik osiągnął wartość 4294967237 po około roku. Nie wiem dokładnie kiedy, ale piec mam 2,5 roku, a od ponad roku miałem problem z odczytywaniem rejestrów Hc. Tak jak już wcześniej pisałem, udało mi się zresetować liczniki, ale ich przyrost dzienny przeraża.W ciągu 18-stu godzin przyrost wynosi 6278832, czyli średnio 348824 na godzinę. Nie ważne już czy to m3, kw czy coś innego. W tym tempie wartość 4294967296 będę miał po 12 312 godzinach czyli po 513 dniach, a trzeba pamiętać, że temperatury są na plusie :slight_smile: . Nie jest to chyba normalne.

Czy macie jakiś pomysł dlaczego ten licznik tak szybko przyrasta ?

PS. znalazłem tu ładny opis jak resetować rejestry - może komuś się przyda. Tam też zadałem pytanie.

Witam, trochę pobocznie możesz podać jak dodałeś Vaillant ebus do Ha. ?
Mam zamiar też to zrobić, ale na razie wiem, że gdzieś dzwony biją…

tak pokrótce to wyglada to tak :slight_smile: :

  • zainstalowałem ebusd i uruchomiłem demona z takimi parametrami w pliku /etc/default/ebusd -
    EBUSD_OPTS="--scanconfig -d /dev/ebus -p 8888 --latency=0 --configlang=EN --configpath=/etc/ebusd --logareas bus --loglevel debug --mqtthost=192.168.1.88 --mqttport=1883 --mqttjson -l /var/log/ebusd.log"
  • potem skorzystałem w HA z integracji poprzez plik configuration.yaml
ebusd:                                                                             
  host: 192.168.1.88                                                               
  circuit: "bai"                                                                   
  name: "Vaillant"                                                                 
  monitored_conditions:                                                            
    - HotWaterTemperature                                                          
    - OutdoorsTemperature                                                          
    - StorageTemperature                                                           
    - DesiredStorageTemperature                                                    
    - WaterPreasure                                                                
    - HeatingSwitch                                                                
    - DesiredFlowTemperature                                                       
    - FlowTemperature                                                              
    - Flame                                                                        
    - PowerEnergyConsumptionHeatingCircuit                                         
    - PowerEnergyConsumptionHotWaterCircuit                                        
    - RoomThermostat                                                               
    - HeatingPartLoad                                                              
    - StateNumber                                                                  
    - ModulationPercentage      
  • mam tez kilka wpisów poprzez mqtt
sensor:
  - platform: mqtt                                                              
    name: Central Heating Pressure                                              
    state_topic: "ebusd/bai/WaterPressure"                                      
    value_template: "{{ value.split(';')[0] }}"                                 
    unit_of_measurement: Bar                                                    
  - platform: mqtt                                                              
    name: Central Heating Flow Temperature                                      
    state_topic: "ebusd/bai/FlowTemp"                                           
    value_template: "{{ value.split(';')[0] }}"                                 
    unit_of_measurement: "°C"                                                   
  - platform: mqtt                                                              
    name: Central Heating Desired Flow Temperature                              
    state_topic: "ebusd/bai/FlowTempDesired"                                    
    value_template: "{{ value.split(';')[0] }}"                                 
    unit_of_measurement: "°C"                                                   
  - platform: mqtt                                                              
    name: Central Heating Return Temperature                                    
    state_topic: "ebusd/bai/ReturnTemp"                                         
    value_template: "{{ value.split(';')[0] }}"                                 
    unit_of_measurement: "°C"                             
  • no i najważniejsze, trzeba mieć odpowiedni moduł “gadający” z piecem

jakoś to działa, ale nie mam się za bardzo czym pochwalić jeżeli chodzi i jakiś dashboard.
Pewnie kiedyś to ogarnę, ale narazie nikomu oprócz mnie to nie jest potrzebne :slight_smile:

Wpis rozpoczałem, bo martwi mnie tempo przyrostu licznika zużycia gazu/energii
gdzieś w niecie widziełm wpis usera który pisze, ze mu się ten licznik “przekręcił” po 9 latach uzytkowania pieca. U mnie dynamika przyrostu wskazuje na około rok. Wydaje mi sie, że nie jest to normalne i może winna jest zła konfiguracja pieca od strony “instalatorskiej”

Byłbym wdzięczny gdyby ktos pochwalił się doświadczeniem w tym temacie

Edit:

Zrobiłem rano pomiar.
Licznik gazu w ciagu dwóch godzin zarejestrował 1,52m3 pobranego gazu.
Przy współczynniku konwersji 11,17 daje to 16,9784 kW - prawie 17
W tym czasie dwa rejestry wskazały zmianę :

  • PrEnergySumHc1 - 903794
  • PrEnergySumHwc1 - 157732
    Suma to 1061526

jak to się ma do 17 kW ?

Udało ci się ogarnąć ten temat ?

A Tobie się udało to ogarnąć?

Panowie, jest komponent niestandardowy vaillant w HACS

Cześć,

Wiem, że temat jest już bardzo stary, ale dalej czegokolwiek bym nie znalazł w internecie na temat liczników PrEnergySum[Hc|Hwc]{n} to mam wrażenie, że chyba nie bardzo komukolwiek udało się odrobić lekcję do końca.

Na wstępie uprzedzam, że poniższe wyliczenia, które posłużyły mi do wyjaśnienia co potencjalnie reprezentują sobą liczniki PrEnergySum[Hc|Hwc]1 (dla sterfy 1) to pewnego rodzaju inżynieria wsteczna, aczkolwiek wnioski jakie z niej płyną wydają się całkiem sensowne.

Czytałem sobie trochę o różnych zmaganiach z wyznaczaniem jakichś współczynników przeliczeniowych z tychże liczników na zużycie gazu w m^3 i postanowiłem sam zbadać temat.
W okresie przejściowym, przy niezbyt niskich temperaturach zewnętrznych kiedy na zasilaniu C.O. miałem dosyć niską temperaturę, tak max. 38st.C (mam mocno przewymiarowane grzejniki) przełączałem na zmianę tryb pracy kotła pomiędzy wyłącznie CO oraz wyłącznie CWU - przy CWU temperatura zasilania wężownicy to ok. 70st.C (default max. fabryczne to 75st.C).
Jednocześnie spisywałem w miarę dokładnie stan licznika gazowego oraz stan rejestrów PrEnergySum[Hc|Hwc]1

I tak dla przykładu w trybie CO-only:

Zmiana PrEnergyCountHc1: 36500
Zmiana PrEnergySumHc1: 5108197
Zużycie gazu: 5,1145 m^3

oraz dla CWU-only:

Zmiana PrEnergyCountHwc1: 2221
Zmiana PrEnergySumHwc1: 612479
Zużycie gazu: 0,6776 m^3

Kombinując z “Sum” zacząłem od przeliczenia ilości zużytego gazu na różne jednostki energii. Żeby skrócić swój wywód od razu przejdę do kWh. I teraz tak - to co jest na fakturze podane jako współczynnik konwersji to jest ciepło spalania gazu wyznaczone w warunkach laboratoryjnych, przy założeniu odzyskania całej energii ze wszystkich produktów spalania podane dla 1 m^3 gazu prawdopodobnie w warunkach normalnych. Zostawmy go i weźmy tzw. wartość opałową, jako bardziej realną a przede wszystkim taką, która stanowi referencję dla wyznaczania tzw. współczynnika sprawności kotła, który to z kolei bywa większy niż 100% ponieważ wartość opałowa nie uwzględnia zysku z kondensacji pary wodnej. Tutaj pojawił się pewien problem, ponieważ różne źródła podają różne wartości ciepła spalania i wahają się one od 9,5 do 10,4 kWh/m^3 nawet dla gazu wysokometanowego. Trudno powiedzieć skąd takie rozbieżności - można to np. wynikać z tego dla jakich warunków to podajemy, np. współczynnik przeliczeniowy dla objętości gazu z teperatury 20st.C na 0st.C (warunki normalne) wynosi 0,93168 (https://www.gaz-system.pl/pl/dla-klientow/uslugi-w-sgt/jakosc-paliwa-gazowego-sgt.html). Ogólnie Gaz System podaje w wymaganiach dla ciepła spalania 11,082 kWh/m3 wartość opałową 9,3040 kWh/m^3. Ja akurat bazując na danych z różnych źródeł przyjąłem do obliczeń wartość 9,56 kWh/m^3.

I tak dla CO-only mamy:
5,1145 m^3 * 9,56 kWh/m^3 = 48,8946 kWh

A dla CWU-only:
0,6676 m^3 * 9,56 kWh/m^3 = 6,3823 kWh

Zacząłem kombinować z tymi wartościami i tak znowu skracając:

Dla CO-only:
((5108197 / 100000) / 48,8996) * 100% = 104%

Dla CWU-only:
((612479 / 100000) / 6,3823) * 100% = 96%

Odwracając teraz całą ta logikę - wygląda na to, że liczniki PrEnergySum[Hc|Hwc]1 prezentują ilość całkowitego ciepła wytworzonego przez kocioł z uwzględnieniem uzysku z kondensacji, po podzieleniu przez 100000 wyrażoną w kilowatogodzinach. Inaczej mówiąc jest to wartość opałowa przemnożona przez sprawność kotła w określonych warunkach pracy (chwilową). Ja ten eksperyment powtarzałem i dla CO w zależności od temperatury zasilania (tzn. czy wynosiła ona 42st.C czy 37st.C) ten współczynnik procentowy wahał się tak od 101% do 105%. Dla CWU gdzie wysoka temperatura zasilania, praca kotła na dużej mocy i większa strata kominowa oraz większa temperatura powrotu znacząco osłabiały jeśli nie eliminowały zysku z kondensacji ten współczynnik wynosił od 93% do 96%. Dla pracy hybrydowej (sumowane liczniki SumHc1 i SumHwc1) wychodziło w okolicach 100%.

Oczywiście sa to przybliżone obliczenia obarczone różnymi błędami wynikajacymi czy to z jakiegoś przybliżonego szacowania wartości opałowej, czy to z faktu nieuwzglednienie różnych strat, niepewności pomiaru itp., ale wydaje mi się, że moja hipoteza co do znaczenia tych wartości jest bliższa rzeczywistości, niż jakieś stałe kalibracyjne do przeliczania wartości tych rejestrów na zużycie gazu, gdzie sami autorzy przyznają, ze w dłuższym okresie się to i tak rozjeżdża i wymaga korekty. Ano, wymaga, bo przelicznik jest dynamiczny, zależy od warunków pracy kotła (chociażby temp zasilania i powrotu, aktualnej mocy palnika, obrotów wentylatora).
Innymi słowy ten magiczny współczynnik to nie jest jakaś magiczna stała tylko funkcja, której wartością jest sprawność kotła wyznaczona dla pewnych argumentów, którymi mogą być wcześniej przytoczone przeze mnie parametry, niekoniecznie wszystkie oczywiście.

Teraz “Count” - tu było trudniej, ponieważ początkowo brakowało spójności pomiędzy CO a CWU, ponieważ o ile CO pracuje względnie w spośób cioągły o tyle CWU chwilowo.
Dodatkowo HA zbiera te dane w pewnych interwałach, itd. Ogólnie, zmierzając do brzegu, analiza danych z bazy LTSS pokazała, że “Count” reprezentuje liczbę sekund pracy kotła w danym trybie.

Tak więc na koniec mam takie wnioski:

PrEnergySumHc1 / 100000 - jest to całkowita wyprodukowana energia w trybie CO w [kWh]
PrEnergySumHwc1 / 100000 - jest to całkowita wyprodukowana energia w trybie CWU w [kWh]
PrEnergyCountHc1 - całkowity czas pracy w trybie ogrzewania w [s]
PrEnergyCountHc1 - całkowity czas pracy w trybie podgrzewania zasobnika CWU w [s]

Mając już te wartości można stworzyć sobie różne pochodne statystyki, czy to liczniki mediów pokazujące np. dobową ilość wyprodukowanej energii na potrzeby CO/CWU, czy też dzieląc deltę energii z rejestru Sum przez deltę czasu z rejestru Count obliczyć średnią moc pracy kotła w danym okresie. Oczywiście odczytując odpowiednio często te wartości (ebusd niestety standardowo czyta je co kilkanaście minut) to nawet można mówić wręcz o mocy chwilowej.

Czy da się z tego wyliczyć zużycie gazu, bo w sumie chyba w większości takie jest oczekiwanie względem tych wartości?

Tak, ale przy założeniu opracowania nie tyle stałej do kalibracji jak robi to większość osób, ale funkcji zwracającej współczynnik sprawności kotła na podstawie innych dostępnych parametrów jako argumentów takiej funkcji (temp. zasilania/powrotu, aktualnej mocy, itp.). No i jakiejś sensownej wartości opałowej jako referencji do przeliczeń, czyli wyprodukowana_energia/sprawność/wartość_opałowa np. 60 kWh / 1,05 / 9,5 kWh/m^3 = 6,01m^3 gazu.

To na tyle z moich wypocin. W sumie to większość tych eksperymentów robiłem już ponad 2 lata temu, ale dopiero teraz zmobilizowałem się, żeby do tego wrócić. Ma nadzieję, że to chociaż trochę pomoże w zrozumieniu skąd moga braś się takie a nie inne wartosci.

1 polubienie

Przeczytałem z dużym zainteresowaniem; też kiedyś próbowałem wymyślić, a jakich jednostkach kocioł liczy energię, ale poległem. Posługiwałem się “współczynnikiem konwersji” z faktury i to był błąd - mimo że rozumiałem, że jest to liczba, zasadniczo, fikcyjna, która w długiej perspektywie wyłącznie rośnie :slight_smile: Także wielkie dzięki za pokazanie, że kocioł jednak liczy w normalnych jednostkach.

Na pewno masz rację, pisząc że współczynnik powinien być funkcją a nie stałą i wtedy szacunki zużycia byłyby dokładniejsze. Z drugiej strony, stała może być dla kogoś zupełnie wystarczająca. Przy podłogówce efektywność c.o. praktycznie będzie niemal stała. Ja, mimo że mam grzejniki, nawet nie rozbijam współczynnika na c.o. i ciepłą wodę - używam 1, wyznaczony oczywiście w czasie sezonu grzewczego i wynoszący 136700. Uwzględnia on oficjalny wsp. konwersji, który staram się na bieżąco aktualizować.

Miesięczne rachunki za gaz w sezonie są w granicach 1k zł; rozliczenie co 2 miesiące, a błąd w stosunku do szacunków… ~20 zł. Z kolei latem, gdy zużycie wynosi ~0,5m3 na dobę, nawet 10% niedoszacowanie jest nieistotne po przeliczeniu na zł.


Teraz do mnie dotarło, że z tą nową wiedzą, mógłbym rozdzielić/rozplątać obliczenia zużycia od wysokości rachunku. I to jest faktycznie coś wartego wysiłku, więc jeszcze raz dzięki! :slight_smile: