Jak zauważyłeś jest tak samo blisko jak i WIFi (bo jak widać pasma używane przez GSM są radykalnie różne).
A przeredagowując Twoją myśl:
ująłbym ją jakoś tak:
“Im mniejsza wartość bezwzględna w dBm tym lepiej.”
Jak zauważyłeś jest tak samo blisko jak i WIFi (bo jak widać pasma używane przez GSM są radykalnie różne).
A przeredagowując Twoją myśl:
ująłbym ją jakoś tak:
“Im mniejsza wartość bezwzględna w dBm tym lepiej.”
To też prawda 2.4Ghz
rozumiem że udało się dostać do licznika wody ? warto było tyle kasy wydać ?
dostępny już nie jest więc ciekawe że tyle osób chce mieć tylko informację odczytu wody
Tylko w przypadku SDR DVB-T RTL2832U R820T2 wartość rssi_dbm jest dodatnia, im więcej tym lepiej, mam dwa liczniki (mój i … sąsiada) i dla tego dalej wartość jest mniejsza. Natomiast dla iM871A wartość rssi_dbm jest ujemna. Trochę zgłupiałem .
Jest coś zwalone w tej integracji - wartość dodatnia jest nierealna - moim zdaniem tam brakuje minusa przed wartością.
Więc w tym nietypowym wypadku “im mniej tym lepiej” (ale to się mija z prawdą na 100% bo wskazanie jest nieprawidłowo dodatnie).
Sprawdzić można to organoleptycznie - oddalając się od licznika ze sprzętem SDR sygnał słabnie zgodnie z podstawowymi prawami fizyki - za czym muszą też podążać wskazania coraz słabszego sygnału.
Też tak uważam a nie, jak ostatnio usłyszałem: “kto bogatemu zabroni” .
-30 > -66
Czy naprawdę potrzeba tu lekcji matematyki?
W końcu mam trochę więcej czasu, to może uzupełnię, by wszyscy (mam nadzieję) zrozumieli co miałem na myśli wyżej. Kwesta “lepiej = mniej” dotyczyła tego wykresu (uzyskanego na instalacji SDR) bazującego na “lewych” danych - tj. tych w których przed wartością RSSI brakowało minusa, o ile w ogóle to było RSSI, bo parametrów sygnału radiowego bywa więcej, ale np. SNR w tym wypadku jest całkowicie nierealny biorąc pod uwagę wartości rzędu 140dBm na tym wykresie, dlatego uważam, że to RSSI pozbawiony znaku “-” ewentualnie RSRQ (jest wręcz bardziej prawdopodobny, ale oczywiście w tym wypadku również brakuje MINUSA) bo on miewa jeszcze mniejsze wartości - to jest sygnał “netto”, podczas gdy RSSI jest miarą mocy sygnału wraz z zakłóceniami.
Jakkolwiek RSRQ i RSSI są wzajemnie nieporównywalne, to ich trendy są zbliżone (szczególnie gdy sygnał szumu tła jest mniej więcej o stałym poziomie).
Trochę odgrzeję kotleta bo udało mi się zakpić dongle w dobrej cenie:
no i przez to że samo HA trochę lepiej ogarnia WmBusa postanowiłem spróbować… no ale ten pierwszy raz zawsze jest trudny… po zainstalowaniu dodatku wygląda że się uruchomił:
w Logach niby coś się pokazuje ale martwi mnie komunikat “no wm device was detected”:
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
Syncing wmbusmeters configuration ...
Registering meters ...
Generating MQTT configuration ...
Broker core-mosquitto will be used.
MQTT Discovery ...
MQTT Discovery cleanup...
Running wmbusmeters ...
No wmbus device detected, waiting for a device to be plugged in.
No meters configured. Printing id:s of all telegrams heard!
Started auto rtlwmbus[00000001] listening on t1
Received telegram from: 20508014
manufacturer: (SEN) Sensus Metering Systems, Germany (0x4cae)
type: Water meter (0x07) encrypted
ver: 0x68
device: rtlwmbus[00000001]
rssi: 16 dBm
driver: iperl
Started auto rtlwmbus listening on t1
Lost closing rtlwmbus
Started auto rtlwmbus listening on t1
Lost closing rtlwmbus
Started auto rtlwmbus listening on t1
Lost closing rtlwmbus
Started auto rtlwmbus listening on t1
Lost closing rtlwmbus
Started auto rtlwmbus listening on t1
Lost closing rtlwmbus
Started auto rtlwmbus listening on t1
Lost closing rtlwmbus
Received telegram from: 20196060
manufacturer: (SEN) Sensus Metering Systems, Germany (0x4cae)
type: Water meter (0x07) encrypted
ver: 0x68
device: rtlwmbus[00000001]
rssi: 12 dBm
driver: iperl
Received telegram from: 20847864
manufacturer: (SEN) Sensus Metering Systems, Germany (0x4cae)
type: Water meter (0x07) encrypted
ver: 0x68
device: rtlwmbus[00000001]
rssi: 21 dBm
driver: iperl
Received telegram from: 20631227
manufacturer: (SEN) Sensus Metering Systems, Germany (0x4cae)
type: Water meter (0x07) encrypted
ver: 0x68
device: rtlwmbus[00000001]
rssi: 9 dBm
driver: iperl
konfiguracja oryginalna:
data_path: /config/wmbusmeters
enable_mqtt_discovery: true
conf: |-
loglevel=normal
device=auto:t1
donotprobe=all
logtelegrams=false
format=json
logfile=/dev/stdout
shell=/wmbusmeters/mosquitto_pub.sh wmbusmeters/$METER_NAME "$METER_JSON"
meters: []
mqtt: {}
jednak w konfiguracji sprzętowej nie widze nic ze słowem RTL:
no i wszystko co znajduję w necie opiera się na komendach z linuxa … .a u mnie Ha stoi na VirtualBoxie więc trochę trudne jest ogarnięcie komend
z góry dzięki za pomoc !
PS na samej obudowie licznika iperl nie widzę liczb które logi wypluwają żeby móc sprawdzić który z tych telegramów mógłby być mój
Musisz “przekazać” USB z VirtualBoxa do maszyny wirtualnej z HA. Dopóki W HA nie zobaczysz tego Realteca nawet nie ma sensu dyskutować o odczytach, powinieneś tak widzieć tego dongla:
ID_MODEL: RTL2838UHIDIR
ID_MODEL_ENC: RTL2838UHIDIR
ID_MODEL_ID: '2838'
ID_PATH: platform-3f980000.usb-usb-0:1.2.1
ID_PATH_TAG: platform-3f980000_usb-usb-0_1_2_1
ID_REVISION: '0100'
ID_SERIAL: Realtek_RTL2838UHIDIR_00000001
ID_SERIAL_SHORT: '00000001'
ID_USB_INTERFACES: ':ffffff:'
ID_VENDOR: Realtek
ID_VENDOR_ENC: Realtek
ID_VENDOR_ID: 0bda
Z logów dodatku wynika jednak, że dongle wykrywa z eteru liczniki:
Received telegram from: 20196060
manufacturer: (SEN) Sensus Metering Systems, Germany (0x4cae)
type: Water meter (0x07) encrypted
ID tego licznika to 20196060, producent: Sensus Metering Systems, Germany, “użyty” driver do licznika: iperl.
tak udostępnianie mam zrobione - zapomniałem o tym wspomnieć na początku:
z jednej strony wpisy pokazują że nie widzi urządzenia, z drugiej poniżej pokazuje że jakiś telegram odczytał… no i zgłupiałem…
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
Syncing wmbusmeters configuration ...
Registering meters ...
Generating MQTT configuration ...
Broker core-mosquitto will be used.
MQTT Discovery ...
MQTT Discovery cleanup...
Running wmbusmeters ...
No wmbus device detected, waiting for a device to be plugged in.
No meters configured. Printing id:s of all telegrams heard!
Started auto rtlwmbus[00000001] listening on t1
Received telegram from: 20508014
manufacturer: (SEN) Sensus Metering Systems, Germany (0x4cae)
type: Water meter (0x07) encrypted
ver: 0x68
device: rtlwmbus[00000001]
rssi: 16 dBm
driver: iperl
Started auto rtlwmbus listening on t1
Lost closing rtlwmbus
Started auto rtlwmbus listening on t1
Lost closing rtlwmbus
Started auto rtlwmbus listening on t1
Lost closing rtlwmbus
Started auto rtlwmbus listening on t1
Lost closing rtlwmbus
Started auto rtlwmbus listening on t1
Lost closing rtlwmbus
Started auto rtlwmbus listening on t1
Lost closing rtlwmbus
Received telegram from: 20196060
manufacturer: (SEN) Sensus Metering Systems, Germany (0x4cae)
type: Water meter (0x07) encrypted
ver: 0x68
device: rtlwmbus[00000001]
rssi: 12 dBm
driver: iperl
Received telegram from: 20847864
manufacturer: (SEN) Sensus Metering Systems, Germany (0x4cae)
type: Water meter (0x07) encrypted
ver: 0x68
device: rtlwmbus[00000001]
rssi: 21 dBm
driver: iperl
Received telegram from: 20631227
manufacturer: (SEN) Sensus Metering Systems, Germany (0x4cae)
type: Water meter (0x07) encrypted
ver: 0x68
device: rtlwmbus[00000001]
rssi: 9 dBm
driver: iperl
@murcin to teraz dodaj swoj licznik do konfiguracji wmbusmeters.
tak dla pewności - konfiguracja powinna tak wyglądać ? - zakładając oczywiście że 20196060 to mój licznik
data_path: /config/wmbusmeters
enable_mqtt_discovery: true
conf: |-
loglevel=normal
device=rtlwmbus:868.9M:t1
logtelegrams=false
format=json
meterfilesaction=overwrite
meterfiles=/config/wmbusmeters/logs/meter_readings/
logfile=/config/wmbusmeters/wmbusmeters.log
shell=/wmbusmeters/mosquitto_pub.sh wmbusmeters/$METER_NAME "$METER_JSON"
meters:
- |-
name=wodomierz
driver=auto
id=20196060
key=00000000000000000000000000000000
mqtt: {}
ponieważ po dodaniu licznika w logach wpis o braku pliku:
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
Syncing wmbusmeters configuration ...
Registering meters ...
Adding meter-0001 ...
Generating MQTT configuration ...
Broker core-mosquitto will be used.
MQTT Discovery ...
Adding meter: wodomierz ...
File /config/wmbusmeters/etc/mqtt_discovery/auto.json not found.
MQTT Discovery cleanup...
Running wmbusmeters ...
na teraz nic nie odbiera… no ale wiem że to nie działa na bieżąco więc czekam na jakieś odczyty
Po co auto
skoro wiesz czego używasz:
device=rtlwmbus:868.9M:t1
To samo w przypadku licznika:
meters:
- |-
name=wodomierz
driver=iperl
id=20196060
key=00000000000000000000000000000000
field_address=adres-licznika
jeżeli myśllę że znalazłem swój licznik czy są sposoby aby rozszyfrować klucz?
Received telegram from: 20847864
manufacturer: (SEN) Sensus Metering Systems, Germany (0x4cae)
type: Water meter (0x07) encrypted
ver: 0x68
device: rtlwmbus[00000001]
rssi: 28 dBm
driver: iperl
niestety key=00000000000000000000000000000000, nie pasuje bo w logach widziałem informację że korzystam z błędnego klucza…
@macek w twoim wpisie widzę coś nowego field_address - to coś obowiązowego ?
Nie ma takiej możliwości.
Nie, pole opcjonalne, w atrybutach licznika pojawia się informacja o adresie instalacji licznika.
no to pięknie cały plan poszedł w piz… ;(
Generalnie ktoś jest właścicielem tego licznika i on zna klucz.
Powołując się na dyrektywy unijne można próbować przycisnąć gdyby był oporny.
Większość spółdzielni mieszkaniowych leci na defaultowych kluczach (ale czy same zera to default dla tego modelu nie mam pojęcia - pogrzeb po githubie, czasem można znaleźć jakieś powszechnie stosowane klucze).
Jako, że po aktualizacji wmbusmeter licznik udało się dodać chciałem wrócić do odczytu danych,
dostałem informację, że wodomierz iperl nie ma żadnego kodowania i podstawowa ramka odnośnie zużycia jest otwarta
Aktualna konfiguracja:
data_path: /config/wmbusmeters
enable_mqtt_discovery: false
conf:
loglevel: debug
device: rtlwmbus:868.9M:t1
donotprobe: all
logtelegrams: true
format: json
logfile: /config/wmbusmeters/wmbusmeters.log
shell: /wmbusmeters/mosquitto_pub.sh wmbusmeters/$METER_NAME "$METER_JSON"
meterfiles: /config/wmbusmeters/logs/meter_readings/
meters:
- name: wodomierz
driver: iperl
id: "20847864"
mqtt: {}
w logach widać że odczytywane są jakieś dane… ale chyba nie takie jakich json oczekuje…
(serial) EVENT thread interrupted
(serial) received ascii "T1;1;1;2023-02-20 11:11:17.000;11;9;20847864;0x1e44ae4c6478842068077a67001005ff7c7e09c155db73ef4690ebadfe0c18<0A>"
(rtlwmbus) checkRTLWMBusFrame "T1;1;1;2023-02-20 11:11:17.000;11;9;20847864;0x1e44ae4c6478842068077a67001005ff7c7e09c155db73ef4690ebadfe0c18<0A>"
(rtlwmbus) received full frame
(wmbus) parseDLL @0 31
(wmbus) parseELL @10 21
(wmbus) parseNWL @10 21
(wmbus) parseAFL @10 21
(wmbus) parseTPL @10 21
(meter) wodomierz: for me? 20847864 in 20847864
(meter) wodomierz: yes for me
(meter) wodomierz(1) iperl handling telegram from 20847864
(meter) wodomierz 20847864 "1E44AE4C6478842068077A67001005FF7C7E09C155DB73EF4690EBADFE0C18"
(wmbus) parseDLL @0 31
(telegram) DLL L=1e C=44 (from meter SND_NR) M=4cae (SEN) A=20847864 VER=68 TYPE=07 (Water meter) (driver iperl) DEV=rtlwmbus[00000001] RSSI=11
(wmbus) parseELL @10 21
(wmbus) parseNWL @10 21
(wmbus) parseAFL @10 21
(wmbus) parseTPL @10 21
(TPL) num encrypted blocks 1 (16 bytes and remaining unencrypted 0 bytes)
(wmbus) WARNING! no key to decrypt payload! Permanently ignoring telegrams from id: 20847864 mfct: (SEN) Sensus Metering Systems, Germany (0x4cae) type: Water meter (0x07) ver: 0x68
(telegram) TPL CI=7a ACC=67 STS=00 CFG=0510 (AES_CBC_IV nb=1 cntn=0 ra=0 hc=0)
(wmbus) telegram from 20847864 ignored by all configured meters!
(main) rtlsdr device not currently used.
(main) found specified device (rtlwmbus:868.9M:t1) that matches detected device (:rtlwmbus[]:0/0)
(main) opening rtlwmbus:868.9M:t1
Started config rtlwmbus listening on t1 using fq 868.9M
(rtlwmbus) using command: /usr/bin/rtl_sdr -d -1 -f 868.9M -s 1.6e6 - 2>/dev/null | /usr/bin/rtl_wmbus
(rtlwmbus) opening
(serial) EVENT thread interrupted
(bgshell) exec background "/bin/sh"
(bgshell) arg "-c"
(bgshell) arg "/usr/bin/rtl_sdr -d -1 -f 868.9M -s 1.6e6 - 2>/dev/null | /usr/bin/rtl_wmbus"
(serialcmd) opened /bin/sh pid 5351 fd 7 (rtlwmbus)
(main) regular reset of rtlwmbus will happen every 82800 seconds
(wmbus) no alarm (expected activity) for rtlwmbus
(serial) TIMER thread interrupted
(serial) EVENT thread interrupted
(bgshell) 5351 exited with return code 0
(serial) closing non working fd=7 ""
(wmbus) disconnected rtlwmbus
(serialcmd) closed /bin/sh pid=5351 fd=7 (rtlwmbus)
Lost closing rtlwmbus
(wmbus) closing....
(wmbus) deleted rtlwmbus
(serialcmd) closed /bin/sh pid=5351 fd=-1 (rtlwmbus)
zmienną mam skonfigurwaną w pliku mqtt (oczywiście w configuration jest linijka:
mqtt: !include ./configuration/mqtt.yaml
sensor:
- name: "Licznik woda"
state_topic: "wmbusmeters/wodomierz"
value_template: '{{ value_json["total_m3"] }}'
unit_of_measurement: "m³"
device_class: "water"
state_class: "total_increasing"
icon: "mdi:gauge"
licznik woda niestety pusty od początku
a niestety nasłuchiwanie wmbusmeter nic nie daje - pusto przez dłuższy czas…
@murcin nie wszytsko stracone pisze, żeby odwdzięczyć się za cały ten wątek bo bazując na nim udalo mi się skonfigurować odczyt iPerla.
Tak w ogóle to witam
Mam ten sam licznik i miałem ten sam problem. Faktycznie da się odczytać kilka informacji bez klucza, jednak do odczytania max_flow i total_value potrzebujemy klucza.
Zacząłem grzebać w internecie i dotarlem do programu producenta służącego do odczytów. Udało mi się znaleźć bardzo starą wersję, którą po zainstalowaniu bardzo dokładnie przejrzałem “od środka”, gdyż znam tę technologię. Udało mi się wydobyć standardowy klucz i działa on zarówno na moich telegramach jak i na Twoich (bazuję na logu):
(meter) wodomierz 20847864 “1E44AE4C6478842068077A67001005FF7C7E09C155DB73EF4690EBADFE0C18”
WMBusmeters Analyze Telegram <-tutaj odkodowany klucz.
dostałem właśnie informację od wodociągów że urządzenie wysyła dwie ramki, jedna szyfrowana a druga otwarta… no i zużycie licznika miało być na tej otwartej… no jednak widać nie prawda.
jeżeli klucz spasuje bo jednak okaże się to nie mój licznik aktualnie jest na nim ponad 400m3
co nie zmienia jednak faktu że skoro klucz jest uniwersalny to łatwo można ogarnąć z pośród wielu tych liczników w mojej okolicy.
aktualnie wrzuciłem klucz i reset wmbusmeters, więc czekamy na odczyt.