Dzień dobry.
Czy ktoś chciałby pomóc odkodować wartość wodomierza przesyłanej w wiadomości?
Tło jest takie, że UE narzuciła na wielkich dostawcach mediów i energii zdalne odczyty i chyba od przyszłego roku ma być 100% takich odczytów, a na pewno ma być historia na rachunku za ostatni rok. Do odczytu danych jest do tego dedykowany sprzęt i soft, dużych dostawców stać na nie. Natomiast ja, jako zwykły user i jednocześnie fan zbierania danych z różnych urządzeń też postanowiłem zebrać dane z mojego wodomierza. Akurat u mnie dane idą w eter, łatwo i tanio można je odczytać, niestety ale producent nadajnika swój soft sprzedaje za grube tysiące i nie opłaca mi się zakupu do pojedynczego punktu, ponadto pomimo deklaracji użycia OMS (otwartego i i standaryzowanego protokołu) w rzeczywistości tak nie jest, producent nakładki stosuje swój własny zakodowany ciąg znaków. Jest to zagrywka nie fair bo inni producenci nie mają problemów z trzymaniem się standardu jeśli się na niego powołują. Niestety, ale wodociągi dostarczają nakładkę na wodomierz, nie mam na to wpływu.
Na podstawie obserwacji wskazań wodomierza i przechwyconej transmisji zidentyfikowaniem w 29 bitowym telegramie co najmniej 4 bajty odpowiedzialne za aktualne wskazania wodomierza (wg dokumentacji w telegramie jest jeszcze aktualny timestamp oraz ostatnie rozliczeniowe wskazanie z datą, zazwyczaj jest to pierwszy dzień miesiąca i flagi ewentualnych błędów urządzenia, ale na tą chwilę ta cała reszta jest mniej istotna).
Jest jeszcze jeden bajt, ale on cały czas ma stałą wartości w hex 0x2E przed poniżej pokazanymi danymi.
Przykładowo wartość 370,783 m3 w telegramie
(2E) 03 02 6F 91. (To są wartości szesnastkowe)
Być może stałe 2E z lewej strony trzeba uwzględnić lub nie, nie wiem, na razie je pomijam w analizie. Ogólnie mam dane za kilka dni odczyty co 10s lub 60s zależnie od godziny (nakładka sama wysyła dane).
Dodam, że wartość zapisana w 4 bajtach (bez stałego 2E) od lewej pierwszy bajt to wartości zmieniające się najszybciej, a z prawej najwolniej. Ponadto pierwszy z 4-ech bajtów od lewej i jego pierwszy oktet ma zawsze 0, zmienia się tylko drugi oktet od 0 do F wraz ze zużyciem wody. Ale wg pewnej reguły, będzie o tym później.
Dla drugiego bajta od lewej pierwszy oktet rośnie normalnie ze zużyciem wody tj 0, 1,2,....9,A,B,...,F, ale drugi oktet rośnie tak
1, 0, 3, 2, 5, 4, 7, 6, 9, 8, B, A, D, C, F, E
i po przejściu w/w sekwencji od 1 do E następuje zmiana +1 w pierwszym oktecie w bajcie. Ten dziwny ciąg zmian drugiego oktetu ma związek z parzystością.
Co do wspomnianego już pierwszego bajtu od lewej i jego drugiego oktetu zmienia się jego wartości, ale w odwrotnej kolejności niż w drugim bajcie i drugim oktecie tj wraz ze zużyciem wartości przechodzą wg poniżej kolejności:
E, F, C, D, A, B, 8, 9, 6, 7, 4, 5, 2, 3, 0, 1
Odnośnie 3-go bajtu od lewej to wraz ze zużyciem pierwszy oktet idzie normalnie tj 0,1,2...,E,F. Natomiast drugi oktet idzie tak jak w bajcie nr 2 od lewej tj.:
1, 0, 3, 2, 5, 4, 7, 6, 9, 8, B, A, D, C, F, E
Ostatni 4 bajt od lewej (pierwszy z prawej) na ciągle wartość 91 w hex w moim przypadku (albo jest to 00 w Dec, albo 003 w Dec) i nie wiem jak się zmienia, musiałbym chyba baseny olimpijskie zużyć, aby była to zmiana widoczna, ale od innych osób, które też walczą otrzymałem takie wskazania:
4,156 m3 (lub 7 na końcu bo na wodomierzu wartość pomiędzy 6, a 7) to w hex 01 8A 39 40
Dla 451,793 m3 to 05 1B 0E 95
Może ktoś pomoże zdekodować sposób kodowania liczb? Jeśli potrzeba więcej informacji dostarczę. Mogę dostarczyć więcej mapowań wskazanie wodomierza: wartości w telegramie.
Pozdrawiam, Krzysiek
Dodano po 12 godzinach 33 minutach 5 sekundach:
Dodatkowe info
Zmiana wartości na trzecim bajcie licząc od lewej następuje, gdy drugi bajt zmienia się z 0x7E na 0x81 przykładowo:
(2E) 09 7E 6C 91
(2E) 06 81 6F 91
Czyli zmiana następuje po przejściu pierwszego oktetu drugiego bajtu z 7 ->8 czyli jakby to było "zero" /przepełnienie licznika.
Idąc tym tokiem rozumowania 4 bajt od lewej wartość z 0x91 zmieni się na 0x90, gdy trzeci bajt będzie zmieniał wartość z 0x7E na 0x81, ale to tylko teoria, musi dużo wody upłynąć.
Drugi bajt zmienia się zgodnie z tym dziwnym ciągiem zmian w pierwszym bajcie tj. jeśli pierwszy bajt zmienia się z 0x0E na 0x01.
Ciekawa zagadka dla pasjonatów liczb. Jak wspomniałem cały telegram na 29 bajtów (w sumie to 35 bajtów z CRC), ale pozostałe bajty co odczyt się zmieniają przy braku zużycia wody, a tylko te wspomniane są stałe, więc ich nie pokazuję, ale jeśli potrzeba mogę wkleić cały telegram.