Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Zdalny odczyt licznika wody z nakładką IZAR

krzbor 16 Jul 2021 14:04 8844 23
  • Zdalny odczyt licznika wody z nakładką IZAR Budując inteligentny dom stwierdziłem, że przydały by się odczyty wodomierzy (mam główny i podlicznik na ogród). Głównie chodziło mi o ogród, aby zoptymalizować podlewanie. Jednak odczyt głównego licznika umożliwia dodatkową analizę ewentualnych wycieków. Oba liczniki wyposażone są w nakładki IZAR. Licznik główny w IZAR CP R 3.5 868MHz, a licznik ogrodowy ma zupełnie nową nakładkę i ta jest w wersji IZAR RC 868 i R4 PL. Najpierw postanowiłem przeszukać internet w celu znalezienia informacji, jak odczytywać dane i jak je dekodować i ewentualnie odszyfrować.
    Pomocna okazała się elektroda, gdzie dowiedziałem się, że informacje są transmitowane jako wireless M-BUS oraz, że do odbioru i dekodowania nadaje się program wmbusmeters.
    Oto strona projektu: https://github.com/weetmuts/wmbusmeters

    Odbiornik
    Ponieważ z bezprzewodowym M-BUS nie miałem do czynienia najpierw należało się zaopatrzyć w jakiś odbiornik. Ogólnie są trzy rozwiązania:
    - dedykowany odbiornik wireless M-BUS np. iM871A-USB (należy sprawdzić te urządzenia na stronie projektu wmbusmeters)
    - układ typu CUL (właściwie nanoCUL) – konstrukcja oparta o Arduino Nano z układem FTDI i odbiornikiem CC1101
    - układ oparty o odbiornik DVB-T



    To ostatnie rozwiązanie jest najtańsze, jednak dekodowaniem sygnału musi zajmować się procesor komputera. Planowałem podłączenie układu do Pi i wolałem go nie męczyć takimi rzeczami, tym bardziej, że realizuje już inne funkcje (odbiór i dekodowanie temperatury z serii czujników INODE BT).
    Rozwiązanie pierwsze wygląda na najprostsze, ale zdziwiła mnie cena tych odbiorników (ponad 300zł). Zdecydowałem się na rozwiązanie środkowe – nanoCUL. Jego zaletą jest zewnętrzna antena. Zakup na ebay był bezproblemowy:
    Zdalny odczyt licznika wody z nakładką IZAR
    Są też dostępne trochę tańsze wersje bez obudowy. Niestety, jak się później okazało ten odbiornik nie działa właściwie z wmbusmeters – ma inny firmware. Na stronach często jest informacja o możliwości wgrania odpowiedniego firmware do MBUS, czego wcześniej nie doczytałem. Na całe szczęście na stronie: Link jest firmware nanoCUL-MBUS.hex, który można pobrać i za pomocą XLOADERa Link wgrać.

    Oprogramowanie
    Oprogramowanie wmbusmeters instalowałem na Pi:
    Code:

    git clone https://github.com/weetmuts/wmbusmeters.git
    cd wmbusmeters
    sudo apt install librtlsdr-dev
    sudo apt install libncurses-dev
    ./configure
    make
    sudo make install

    Jak widać najpierw pobieramy źródła, dodatkowe aplikacje, a następnie kompilujemy i instalujemy.
    Teraz możemy podłączyć nasz odbiornik MBUS.
    Aby odczytać dane ze wszystkich widocznych liczników (skan) wydajemy komendę:
    Code:
    wmbusmeters auto:t1 MyWater auto '*' NOKEY

    i musimy trochę poczekać. Jeśli wszystko jest OK powinny być widoczne odczytane informacje. U mnie wskazania licznika mechanicznego i elektronicznego zgadzały się co do litra.
    Tu drobna uwaga – w trybie „auto” wmbusters skanuje wszystkie porty. Niestety źle się to kończy dla BT na Pi – po prostu przestaje działać (BT na Pi działa na UART), a ja na BT mam odczyt temperatury. Długo szukałem przyczyny problemu, a winny okazał się tryb „auto” dlatego po jednorazowym rozpoznaniu lokalizacji naszego odbiornika MBUS możemy zrestartować Pi i od tego momentu więcej nie używać „auto” lecz podawać określony port. U mnie jest to /dev/ttyUSB0
    Skanowanie dla urządzenia CUL wygląda zatem tak:
    Code:
    wmbusmeters /dev/ttyUSB0:cul:t1 MyWater auto '*' NOKEY

    Po więcej informacji odsyłam na stronę projektu.
    Skanowanie umożliwia nam zlokalizowanie naszego licznika/liczników np. po numerze licznika lub po odczytanej wartości zużycia wody.
    Gdy już zlokalizujemy nasze liczniki przystępujemy do ostatecznej konfiguracji.
    W folderze etc powinien być wmbusmeters.conf. Oto moja zawartość tego pliku:
    Code:
    loglevel=normal
    
    device=/dev/ttyUSB0:cul:t1
    logtelegrams=false
    format=json
    #meterfiles=/var/log/wmbusmeters/meter_readings
    #meterfilesaction=overwrite
    logfile=/var/log/wmbusmeters/wmbusmeters.log
    shell=curl -X POST 192.168.1.24/woda.php -d "$METER_JSON"

    dane będą wysyłane w formacie json do mojego skryptu woda.php w postaci POST. Jak widać zakomentowane są dwie linie, gdyż zgodnie z opisem na stronie projektu:
    „If you are running on a Raspberry PI with flash storage and you relay the data to another computer using a shell command (mosquitto_pub or curl or similar) then you might want to remove meterfiles and meterfilesaction to minimize the writes to the local flash file system.”
    Oczywiście linie możemy usunąć/zakomentować później, gdyż na etapie testów zapisywane dane mogą być bardzo przydatne.

    W folderze /etc/wmbusmeters.d mam dwa pliki (każdy dla jednego licznika) o nazwach zgodnych z parametrem „name”. Ich zawartość jest bardzo prosta:
    Code:
    name=glowny
    
    id=210b1234
    key=

    oraz
    Code:
    name=ogrod
    
    id=21401234
    key=

    W każdym pliku mamy: nazwę symboliczną, id (ustalone podczas skanowania), oraz klucz potrzebny do dekodowania. Na całe szczęście dla odbiorników IZAR nie ma klucza. Na stronie projektu jest jednak wymieniona cała lista nakładek, z którymi współpracuje wmbusmeter. Niektóre szyfrują algorytmem AES, ale jak można przeczytać na różnych stronach operatorzy sieci często nie zmieniają domyślnego klucza składającego się np. z samych zer :) Tu znajdziemy informacje o nakładce APATOR i odbiorniku DVB-T: Link

    Gdy przygotujemy pliki oraz skrypt/program, który będzie odbierał dane możemy testować uruchamiając wmbusmeters z domyślną konfiguracją:
    Code:
    sudo wmbusmeters --useconfig=/

    Jeśli wszystko jest OK to możemy uruchamiać całość wraz ze startem systemu operacyjnego. W tym celu wydajemy komendę:
    Code:
    sudo systemctl enable wmbusmeters

    Na koniec jeszcze informacja jak odczytać dane POST wysłane do PHP:
    Code: php
    Log in, to see the code

    Tak odczytane dane możemy zapisywać do bazy danych, obrobić i przesłać dalej lub po prostu zapisać do pliku. Dodatkowe informacje o integracji: https://weetmuts.github.io/wmbusmeterswiki/
    Poniżej jeszcze kilka ciekawych linków, z których można się czegoś dowiedzieć:
    https://github.com/zibous/ha-watermeter
    https://github.com/ZeWaren/izar-prios-smart-meter-collector

    Cool? Ranking DIY
    Can you write similar article? Send message to me and you will get SD card 64GB.
    About Author
    krzbor
    Level 23  
    Offline 
    krzbor wrote 896 posts with rating 478, helped 20 times. Been with us since 2004 year.
  • #2
    gruby1
    Level 29  
    Bardzo cenne informacje tutaj kolega przedstawił za co osobiście jestem wdzięczny. Sam ten temat kiedyś badałem ale ze względu na małą ilość informacji i natłok zajęć odpuściłem, a tu wszystko podane na tacy. Kawał dobrej roboty.
  • #3
    krzbor
    Level 23  
    gruby1 wrote:
    Bardzo cenne informacje tutaj kolega przedstawił za co osobiście jestem wdzięczny. Sam ten temat kiedyś badałem ale ze względu na małą ilość informacji i natłok zajęć odpuściłem, a tu wszystko podane na tacy. Kawał dobrej roboty.

    Dziękuję za miłe słowa. Rzeczywiście na początku powstaje problem "jak to ugryźć". Dzięki tematowi z elektrody Link dowidziałem się że "można". Ten temat wskazał mi też rozwiązanie programowe: wmbusmeters.
    Reszta to już zgłębianie tematu. Gdyby go w pełni opisać artykuł musiałby być znacznie większy, ale to co opisałem powinno wystarczyć do zrozumienia idei i lepszego czytania git'a wmbusmeters. Myślę, że ciekawa może być wskazówka co do kłopotów z trybem "auto". Zajęło mi to wiele godzin - nie potrafiłem zrozumieć dlaczego przestał działać BT na Pi. Wiedziałem tylko, że jest to związane z wmbusmeters. Nie mogąc rozwiązać problemu przywróciłem zawartość karty SD (miałem zgrany obraz Pi). Rozpocząłem proces instalacji od nowa, gdyż byłem przekonany, że coś się zepsuło podczas instalacji. Ale nie to było problemem. Wszystko zainstalowałem, a BT nadal działał. Dopiero uruchomienie programu rodziło kłopoty. Wmbusmeters ma ciekawy tryb "debug". Już wcześniej zauważyłem, że otwiera i zamyka porty w poszukiwaniu urządzenia i wtedy mnie oświeciło - BT na UART, a wmbusmeters otwiera je i zamyka. Już wiedziałem co robić i myślę, że innym zaoszczędzę trochę czasu.
  • #4
    mano
    Level 11  
    Dziękuję za inspirację!
    Ten wątek zainspirował mnie aby spróbować moich sił z odczytywaniem stanu wodomierzy. Z pomocą tego wątka odczyt za pomocą RTL-SDR to była bułka z masłem ;)
    Jednak mam trochę inny plan - spróbować odczytać komunikat za pomocą samodzielnego modułu ESP8266 z CC1101. Niestety tutaj sprawa się komplikuje - na razie ugrzązłem na próbie odczytania sygnału. CC1101 cośtam łapie, ale próbując zdekodować to gotowcami z CULFW kończę z niczym.
    Materiałów w internecie mam wrażenie, że jest na lekarstwo.
  • #5
    mano
    Level 11  
    Weekend minął, udało się dokonać paru "odkryć" :)
    Moim celem jest zaczytanie ilości pobranej wody za pomocą na maksa budżetowego rozwiązania - CC1101 + ESP8266
    Oto moje znaleziska, może komuś pomogą:
    1. Po zaaplikowaniu konfiguracji CC1101 stąd: https://github.com/heliflieger/a-culfw/blob/master/culfw/clib/mbus/tmode_rf_settings.h#L45 moduł zaczął "łapać" wiadomości o długości 54 bajty
    2. Część tych wiadomości (od trzeciego do 46-go) daje się odkodować za pomocą kodowania "3 out of 6": https://github.com/heliflieger/a-culfw/blob/master/culfw/clib/mbus/3outof6.c
    3. W odkodowanym strumieniu udało mi się namierzyć ID mojego wodomierza począwszy od trzeciego bajtu (little endian) - sukces!

    I tu się pojawia problem. Patrząc na to jak to robią zawodowcy: https://github.com/weetmuts/wmbusmeters/blob/master/src/meter_izar.cc#L250 wygląda na to, że nr seryjny zaczyna się od piątego bajta. Wiec, z jakiegoś powodu, mój odebrany komunikat zdaje się być ucięty z przodu. Brakuje dwóch bajtów, a więc trzech przed zdekodowaniem "3 out of 6". Z racji, że wypluta z CC1101 wiadomość ma na początku dwa bajty, które nie są zgodne z kodowaniem 3 out of 6, wygląda na to, że jakoś tracę jeden bajt... I od dwóch dni próbuję go odzyskać.
  • #7
    mano
    Level 11  
    Sukces!
    Kolejny weekend minął i udało się dobrać do odczytów z wodomierza za pomocą taniutkiego combo ESP8266 i CC1101.
    Okazało się, że nie wiedziałem jak blisko sukcesu byłem, a moje problemy wynikały głównie z nieumiejętności obsługi CC1101 (potężna bestia).
    Jak już odpowiednio "pogadałem" z CC1101 to potem jest całkiem prosto (oczywiście jak to w przypadku każdej wiedzy - jak się coś już wie to jest prosto ;) ).
    W skrócie:
    1. Odbiór pakietu z CC1101 (preambuła 0x543D)
    2. Odkodowanie "3 out of 6"
    3. Odszyfrowanie danych

    Oczywiście wmbusmeters i rtl-wmbus to były nieodzowne pomoce.

    Dla zainteresowanych swój kod umieściłem na githubie: https://github.com/maciekn/izar_mbus_reader
    Przyznam się też, że wielu rzeczy nadal nie rozumiem, i zrobiłem "na pałę" ale działa ;) Ideą jest to, aby było możliwie prosto, a nie maksymalnie funkcjonalnie.
  • #8
    krzbor
    Level 23  
    mano wrote:
    Sukces!
    Kolejny weekend minął i udało się dobrać do odczytów z wodomierza za pomocą taniutkiego combo ESP8266 i CC1101.

    Bardzo się cieszę, że mój temat był inspiracją do Twojego, bardzo ciekawego projektu. Projekt jest minimalistyczny, ale przez to ma duże walory edukacyjne.
    Jeśli chodzi o ESP8266 to zastanawiałem się jeszcze nad inną koncepcją:
    CC1101+ESP8266 -->TCP (lub UDP) --> WMBUSMETERS
    Innymi słowy zestawowi CC1101+ESP8266 pozostawić tylko zadanie odbioru wiadomości i jego przesłanie do WMBUSMETERS. Oczywiście trzeba by było coś dorobić do WMBUSMETERS aby obsługiwał takie źródło telegramów (telegramy po TCP lub UTP), ale może autor WMBUSMETERS byłby zainteresowany? Zaletą jest obsługa całej listy liczników, a wadą konieczność instalowania WMBUSMETERS.
  • #9
    mano
    Level 11  
    Jeszcze raz dzięki za inspirację i punkty zaczepienia! Temat bardzo pomocny i otwiera całkiem ciekawe możliwości - na przykład ostrzeganie przed cieknącą wodą.

    Co do pomysłu z wmbusmeters, to skoro wmbusmeters już i tak obsługuje różne urządzenia, w teorii by to było całkiem proste przesłać telegram bezpośrednio "pod jego drzwi". Trzeba by tylko zobaczyć jaki jest interfejs do obsługi różnych urządzeń.

    Ja aktualnie znowu idę na skróty i w inną stronę: MQTT bezpośrednio z ESP i potem wizualizacja w grafanie na RaspberryPi.
  • #10
    krzbor
    Level 23  
    mano wrote:
    Co do pomysłu z wmbusmeters, to skoro wmbusmeters już i tak obsługuje różne urządzenia, w teorii by to było całkiem proste przesłać telegram bezpośrednio "pod jego drzwi". Trzeba by tylko zobaczyć jaki jest interfejs do obsługi różnych urządzeń.
    Dokładnie o czymś takim myślałem - uzyskujemy dużą uniwersalność, gdyż za samo dekodowanie odpowiadałby wmbusmeters. Dużą zaletą w stosunku do obecnych rozwiązań wmbusmeters byłby brak podłączania czegokolwiek do Raspberry Pi - telegramy przychodziłyby po sieci.
  • #12
    krzbor
    Level 23  
    Szyszkownik Kilkujadek wrote:
    Quote:
    Tak odczytane dane możemy zapisywać do bazy danych, obrobić i przesłać dalej lub po prostu zapisać do pliku.

    No OK, masz dane z licznika. Coś z tym dalej robisz poza analizą zużycia wody?

    Powiem szczerze - nie wyświetlam nawet odczytu. Wodociągi i tak sobie odczytają. Mnie interesowało zużycie, zwłaszcza na ogrodzie. Tu przykład podlewania:
    Zdalny odczyt licznika wody z nakładką IZAR
    Jak widać 0,524m3. Widać także działanie poszczególnych sekcji. Powiększmy zatem obraz:
    Zdalny odczyt licznika wody z nakładką IZAR
    To odczyt zużycia ostatniej sekcji 0,168m3. Właśnie dzięki analizie danych wydłużyłem czas jej pracy, a skróciłem czasy innych.
    Jeszcze jeden obrazek - tu nie było podlewania (padało):
    Zdalny odczyt licznika wody z nakładką IZAR
    Jak widać mam zużycie 3 litry. Niestety powtarza się to w kolejnych dniach - zużycie 3-5 litrów. Mam gdzieś wyciek, ale 3-5 litrów to tyle co jedna spłuczka - nie będę o to walczył, jednak muszę to monitorować.
    Jak widać dane są przydatne.
  • #13
    _Szczepan_
    Level 4  
    Cześć

    krzbor wrote:
    CC1101+ESP8266 -->TCP (lub UDP) --> WMBUSMETERS


    Koncepcja przedstawiona powyżej jest możliwa do zrealizowania z obecną wersją wmbusmeters.
    Istnieje magiczny parametr:
    stdin, to read raw binary telegrams from stdin. These telegrams are expected to have the data link layer crc bytes removed already!

    Wystarczy odpowiednio wykorzystać nc lub socat i nie powinno być problemu.

    Jutro spróbuję przysiąść nad tym i przetestować (na razie na sucho, z danymi z testów wmbusmeters'a, bo czekam na cc1101 -- chyba że może ktoś mi podesłać jakiegoś RAWa?).
  • #14
    krzbor
    Level 23  
    _Szczepan_ wrote:
    Koncepcja przedstawiona powyżej jest możliwa do zrealizowania z obecną wersją wmbusmeters.
    Istnieje magiczny parametr:
    stdin, to read raw binary telegrams from stdin. These telegrams are expected to have the data link layer crc bytes removed already!

    Rzeczywiście - dobry pomysł i powinno działać. Tym niemniej opcja TCP/IP w wmbusmeters ułatwiałaby konfigurację całości (chodzi mi o łatwą powielalność i spójność).
    Rozwiązanie oparte o ESP ma tę zaletę, że odbiornik może być bliżej nadajnika. Ja w linii prostej mam kilka metrów, ale przez żelbetowy strop. Choć IZAR nadaje co 8s to odczyty są znacznie rzadsze - bywa, że przerwa trwa nawet 8min. Częste odczyty są potrzebne aby zrealizować funkcjonalność wykrywania wycieków.
    W każdym razie - może zrobisz z tego DIY - jak widać po zainteresowaniu tematem jest "popyt" :)
  • #15
    _Szczepan_
    Level 4  
    krzbor wrote:
    Rzeczywiście - dobry pomysł i powinno działać. Tym niemniej opcja TCP/IP w wmbusmeters ułatwiałaby konfigurację całości (chodzi mi o łatwą powielalność i spójność).


    Docelowo wmbusmeters z opcją "net" brzmi fajnie. Tylko trzeba przysiąść i to dopisać albo porozmawiać z autorem toola. Na "już" chodzi mi o taką konfigurację:
    Code: text
    Log in, to see the code

    ESP32 wysyła dane po sieci a socat je odbiera i przekazuje do wmbusmeters'a, który odpalamy np:
    Code: bash
    Log in, to see the code

    Z braku czasu nic na ESP32 nie napisałem więc output z niego symuluję sobie na drugiej konsoli:
    Code: bash
    Log in, to see the code

    Opcję ignoreduplicates dla wmbusmeters'a wykorzystuję bo wysyłam ciągle ten sam pakiet (dojdzie do mnie cc1101 i wygospodaruje troszkę czasu na kodzenie w ESP32 to będę miał dane z licznika).

    Całość bardzo ładnie działa, reconnect'y z strony "ESP32" są poprawne.
  • #16
    krzbor
    Level 23  
    Szkoda, że robisz to na ESP32 - do osiągnięcia celu wystarczy słabszy i tańszy ESP8266 (np. ESP-12). Jednak jak opublikujesz kod, przeróbka na ESP8266 powinna być minimalna. Jestem ciekaw wyników - chodzi głównie o długookresową stabilność rozwiązania.
  • #17
    _Szczepan_
    Level 4  
    krzbor wrote:
    Szkoda, że robisz to na ESP32 - do osiągnięcia celu wystarczy słabszy i tańszy ESP8266

    Akurat taki mam pod ręką razem z ETH. Wolę kabel niż WiFi.
    Wersja na coś mniejszego, tak jak piszesz, nie powinna być problemem - tam nie powinno być nic zależne od sprzętu.
  • #18
    _Szczepan_
    Level 4  
    Bardzo szybko parę (dosłownie) lini naskrobałem TU .
    Standardowo wszystko zahardkodowane, parę dziwnych / testowych rozwiązań itp. Wystarczy podmienić na swoje dane, wgrać do ESP i na maszynie z linuxem odpalić:
    Code: bash
    Log in, to see the code

    Pozostaje tylko czekać na dane:
    Code: bash
    Log in, to see the code

    Można też uruchomić integrację z HA. Fajny przykład jest TU

    btw
    Bajty [10] [11] to jest CRC pierwszego bloku danych
  • #19
    krzbor
    Level 23  
    Fajnie, że umieściłeś kod, ale myślę, że warto od początku wprowadzić trochę porządku. Oprogramowanie nie jest zależne od typu nakładki, gdyż dekodowaniem zajmuje się wmbusmeters. Warto zatem usunąć projekt spod obecnej nazwy i zrobić nowy bez "IZAR" w nazwie (do nazwy można dać ESP8266). W źródłach jest też kod dekodujący IZAR, który chyba nie jest potrzebny. Nie jest potrzebne też sprawdzanie ID licznika (tym zajmuje się wmbusmeters). Warto też z kodu usunąć adres docelowy IP i przenieść go do konfiguracji.
  • #20
    _Szczepan_
    Level 4  
    krzbor wrote:
    Fajnie, że umieściłeś kod, ale myślę, że warto od początku wprowadzić trochę porządku. Oprogramowanie nie jest zależne od typu nakładki, gdyż dekodowaniem zajmuje się wmbusmeters.


    ;-) Jakbym miał więcej czasu wolnego to zamiast porządków tam zakodził bym dwa komponenty do esphome (cc1101 oraz izar) tak aby słały telegramy po MQTT i potem ha-watermeter i HA.
    Niestety na "dziś" to tylko takie hardkode'y mogę wypuścić.

    Oprogramowanie jest zależne od typu telegramu. Np. każdy pakiet o długości większej niż (o ile dobrze pamiętam) 0x19 będzie źle przekazywany do wmbusmeters'a. Tak samo telegramy, które obecnie są słane po TCP zawierają śmieci na końcu (nie ma kontroli ani długości ani CRC).
  • #21
    broarti
    Level 1  
    Cześć wszystkim,

    kombinuję z tymi licznikami IZAR i CC1101 868MHz + ESP8266, chciał bym dane wysyłać do RPi 4 przez WiFi. Czy udało się komuś to zgrać razem, bo ja nie mogę. Może macie jakiś prosty tutorial jak to ogarnąć?

    Dzięki
  • #22
    mano
    Level 11  
    Hej, wszystko zależy od tego jak chcesz ostatecznie to zsetupować.
    Ja w tej chwili bazuję na ESP32 (z innych powodów), ktory wysyła na malinkę odczyty po MQTT. Mój kod masz powyżej.

    Po zmianie modułu radiowego z anteną na 868MHz działa mega stabilnie :)
  • #23
    pawel3110
    Level 15  
    mano
    Zdarzają Ci się fałszywe odczyty? Tzn. zawyżony stan licznika?
    Możesz okazać swój program?
  • #24
    mano
    Level 11  
    @pawel3110
    Faktycznie, zdarzały się jakieś odczyty z czeluści. Niestety nie chciało mi się dochodzić co dokładnie je powodowało, ale z racji że były srogo przekłamane bardziej stawiałem na błąd radia albo moją nieumiejętność poradzenia sobie z protokołem. Wprowadziłem wtedy filtr dolnoprzepustowy, który filtruje odczyty które są dalej niż 300m3 od poprzedniego. Od ponad pół roku korzystania z apki ani jeden dziwak się nie trafił.
    Kod niezmiennie dostępny pod adresem: https://github.com/maciekn/izar_mbus_reader