Resetowanie rejestru PrEnergySumHc1 i pokrewnych

Temat integracji kotła gazowego Vaillant z systemem automatyki domowej, zwanej czasem inteligentnym domem, pojawiał się na tym blogu wielokrotnie. Jednym z bardziej przydatnych aspektów takiej integracji jest obliczenie zużycia gazu . Mechanizm ten działa u mnie bezawaryjnie dla trzech kotłów od mniej więcej pięciu lat. W tym czasie wystąpił jednak jeden, dość ciekawy problem związany z przepełnieniem rejestru PrEnergySumHc1.

PrEnergySumHc1 wraz z PrEnergySumHwc1 są podstawowym źródłem informacji ile energii wyprodukował kocioł, z czego z kolei można wnioskować z pewnym przybliżeniem, ile gazu zostało zużyte. Kalibracja polega na przełożeniu wzrostu wartości tych rejestrów na zużyte kWh lub m³, które ja preferuję, ze względu na pewność i jednoznaczność. Jeżeli użyjemy odpowiednio długiego okresu do kalibracji zużycia, to szacowanie robi się bardzo dokładne.

W pewnym jednak momencie, zliczanie zużycia wyprodukowanej energii, a co za tym zużycia gazu ustaje. Jest to zwykle związane z ograniczoną maksymalną wartością rejestru PrEnergySumHc1. Jego maksymalna wartość wynosi 4294967236, czyli 2³². No tak, czysto informatyczne ograniczenie.

Co więc zrobić, żeby nie dopuścić do “zatrzymania licznika”? Wyzerować ten rejestr, wraz z pokrewnymi. Można także zaimplementować kasowanie cykliczne - co miesiąc lub po każdym sezonie grzewczym. Trzeba jednak wziąć tę operację pod uwagę przy kalibracji i obliczeniach zużycia gazu.

W jaki sposób zresetować wszystkie 4 rejestry? Przy poprawnie skonfigurowanym ebusd - bardzo prosto. Wystarczy wydać 4 komendy:

ebusctl write -c bai PrEnergySumHc1 0 ebusctl write -c bai PrEnergySumHwc1 0 ebusctl write -c bai PrEnergyCountHc1 0 ebusctl write -c bai PrEnergyCountHwc1 0

I już. Można jeszcze potwierdzić operację przez odczyt komendami:

ebusctl read PrEnergySumHc1 ebusctl `read` PrEnergySumHwc1 ebusctl `read` PrEnergyCountHc1 ebusctl `read` PrEnergyCountHwc1

Wszystkie powinny wskazać wartości bliskie zera. I tutaj zapewne większość osób może zakończyć lekturę tego wpisu i zacząć świętować sukces. Osoby bardziej dociekliwe mogą przeczytać dalszą część, żeby dowiedzieć się, jak diagnozować problemy.

Tak, to zwykle powinno po prostu zadziałać. Ale nie zawsze działa. Przy próbie zapisu rejestru możemy otrzymać na przykład błąd:

ERR: element not found.

Dlaczego? Zacznijmy od początku. Sprawdźmy najpierw czy obwód (urządzenie) jest widoczne przez ebusd:

pi@raspberrypi:/dom $ ebusctl state signal acquired, 47 symbols/sec (115 max), 3 masters

Oznacza to, że mamy sygnał z szyny eBus a w sieci znajdują się 3 urządzenia typu master. Czemu trzy? W moim przypadku jest to adapter eBus v5 , kocioł Vaillant i regulator pogodowy multiMatic VRC 700.

Zobaczmy trochę więcej szczegółów i sprawdźmy czy nie jest to problem wersji:

pi@raspberrypi:/dom $ ebusctl info version: ebusd 23.1.23.1 update check: version 23.2 available, device firmware 1[3a0f] available, vaillant/08.bai.csv: newer version available device: 192.168.102.221:9999, enhanced, firmware 1.1[3501].1[3501] signal: acquired symbol rate: 27 max symbol rate: 115 min arbitration micros: 1 max arbitration micros: 7346 min symbol latency: 0 max symbol latency: 166 reconnects: 0 masters: 3 messages: 663 conditional: 3 poll: 0 update: 10 address 03: master #11 address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0104;HW=7803", loaded "vaillant/bai.308523.inc", "vaillant/08.bai.csv" address 10: master #2 address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0613;HW=6903", loaded "vaillant/15.700.csv" address 31: master #8, ebusd address 36: slave #8, ebusd

Cóż ciekawego widać w odpowiedzi na tę komendę? Zacznijmy od końca, bo pozwoli nam to zrozumieć poprawnie informację o wersjach. Poza eBusd mamy w sieci 2 urządzenia:

address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0613;HW=6903", loaded "vaillant/15.700.csv"

To jest regulator pogodowy. Widać, że producentem jest Vaillant, identyfikator urządzenia to 70000. Mamy też wersję oprogramowania i sprzętu. Na samym końcu jest informacja, jakiego pliku konfiguracyjnego używa ebusd do zamiany naszych komend na komunikaty szyny eBus. W tym pliku zdefiniowane są wszystkie rejestry, które możemy odczytywać i zapisywać. Natomiast w tym przypadku to urządzenie jest dla nas mniej interesujące, ponieważ rejestry PrEnergy[…] nie znajdują się w sterowniku pogodowym, tylko w kotle. Przejdźmy więc do niego:

address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0104;HW=7803", loaded "vaillant/bai.308523.inc", "vaillant/08.bai.csv"

Tak, “bai” to właśnie nasz poszukiwany kocioł. Zobaczmy co ciekawego dowiemy się o nim z wcześniejszego sprawdzenia wersji przez komendę ebusctl info:

update check: version 23.2 available, device firmware 1[3a0f] available, vaillant/08.bai.csv: newer version available

Wygląda na to, że dostępna jest nowsza wersja pliku z definicjami rejestrów kotła. Ponieważ jest to stara instalacja eBusd, prawdopodobnie zawiera jeszcze błąd związany z oznaczeniem rejestrów związanych z wyprodukowaną energią jako “tylko do odczytu”.

Zaczynając od wersji 3.2 pliki konfiguracyjne nie są już składowane na dysku i ściągane ręcznie, tylko usługa domyślnie pobiera je za pomocą https z domeny ebusd.eu. Webservice konfiguracyjny powinien odzwierciedlać ostatnią wersję konfiguracji widocznej w repozytorium. Odnajdźmy więc rejestr w pliku bai.308523.inc:

r;wi,,PrEnergySumHc1,PrEnergySumCH1_DK,,,,"F500",,,ULG,,,Predictive Maintenance data

Pierwsza litera “w” oznacza, że rejestr powinien dać się zapisywać. Zrestartujmy więc ebusd i sprawdźmy, czy konfiguracja zostanie pobrana.

pi@raspberrypi:/etc $ sudo systemctl restart ebusd

Po wykonaniu ebusctl info widać, że program nie narzeka już na nieaktualną wersję konfiguracji:

pi@raspberrypi:/etc $ ebusctl info version: ebusd 23.1.23.1 device: 192.168.2.221:9999, enhanced, firmware 1.1[3501].1[3501] signal: acquired symbol rate: 23 max symbol rate: 103 min arbitration micros: 2 max arbitration micros: 27 min symbol latency: 9 max symbol latency: 39 reconnects: 0 masters: 3 messages: 641 conditional: 2 poll: 0 update: 10 address 03: master #11 address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0104;HW=7803", loaded "vaillant/bai.0010015600.inc" ([PROD='0010021887']), "vaillant/08.bai.csv" address 10: master #2 address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0613;HW=6903", loaded "vaillant/15.700.csv" address 31: master #8, ebusd address 36: slave #8, ebusd

Można więc ponownie spróbować zapisać stan rejestrów:

root@raspberrypi:/etc/ebusd# ebusctl write -c bai PrEnergySumHc1 ERR: element not found

Niestety nadal nic. Poza błędem w programie, który podejrzewamy na końcu, można na chwilę założyć, że może jednak ebusd.eu serwuje złą konfigurację. Bo sama konfiguracja na pewno jest wczytywana, ponieważ odczyt rejestru przebiega bez problemu. Spróbujmy więc podstawić ręcznie ściągnięte repozytorium plików konfiguracyjnych i zobaczyć co się stanie. U mnie ostatnia wersja jest już ściągnięta i znajduje się w domyślnym miejscu: /etc/ebusd/.

Zobaczmy na początek jaki jest status usługi:

pi@raspberrypi:/etc $ systemctl status ebusd ● ebusd.service - ebusd, the daemon for communication with eBUS heating systems. Loaded: loaded (/lib/systemd/system/ebusd.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2023-10-22 12:26:49 CEST; 16min ago Process: 12019 ExecStart=/usr/bin/ebusd $EBUSD_OPTS (code=exited, status=0/SUCCESS) Main PID: 12020 (ebusd) Tasks: 4 (limit: 4915) CGroup: /system.slice/ebusd.service └─12020 /usr/bin/ebusd --scanconfig -d ens:192.168.2.221:9999 --latency=80000

Poza tym, że usługa działa, to widać, jakie ma opcje. Skąd się one jednak biorą? Podejrzyjmy definicję usługi ebusd w systemd. Definicja znadjuje się w pliku ebusd.service:

pi@raspberrypi:/etc $ cat /etc/systemd/system/multi-user.target.wants/ebusd.service [Unit] Description=ebusd, the daemon for communication with eBUS heating systems. After=network-online.target ConditionPathExists=/var/log

[Service] Type=forking Restart=always RestartSec=30 PIDFile=/var/run/ebusd.pid EnvironmentFile=-/etc/default/ebusd ExecStart=/usr/bin/ebusd $EBUSD_OPTS

[Install] WantedBy=multi-user.target

ExecStart wskazuje, że opcje znadują się w zmiennej środowiskowej $EBUSD_OPTS, natomiast środowisko zdefiniowane jest w pliku /etc/default/ebusd. Faktycznie, w tym pliku znajduje się jedna aktywna linijka:

EBUSD_OPTS="--scanconfig -d ens:192.168.2.221:9999 --latency=80000"

Zmieńmy ją dla testu na:

EBUSD_OPTS="--configpath=/etc/ebusd/ --scanconfig -d ens:192.168.2.221:9999 --latency=80000"

Powinno to spowodować odczyt konfiguracji z katalogu /etc/ebusd zamiast jej pobrania z ebusd.eu. Aby odniosło to skutek, trzeba jeszcze zrestartować usługę ebusd.

pi@raspberrypi:/etc $ sudo systemctl restart ebusd

Odczekajmy chwilę żeby urządzenia się odnalazły a konfiguracje wczyrały i spróbujmy ponownie.

pi@raspberrypi:/var/log $ ebusctl write -c bai PrEnergySumHc1 0 done pi@raspberrypi:/var/log $ ebusctl write -c bai PrEnergySumHwc1 0 done pi@raspberrypi:/var/log $ ebusctl write -c bai PrEnergyCountHc1 0 done
pi@raspberrypi:/var/log $ ebusctl write -c bai PrEnergyCountHwc1 0 done

Tym razem mamy sukces. Jasno więc widać, że nie zawsze automatyczne aktualizacje czy wczytywanie konfiguracji z sieci gwarantuje pełną stabilność rozwiązania. A błędy po prostu się zdarzają.

Nie zmienia to oczywiście faktu, że ebusd jest świetnym produktem, dostępnym w dodatku za darmo.