Komponent wM-Bus do ESPHome radugeo74/esphome-sx1262 - wątek ogólny

Moze miec wplyw. Watomierze raczej wysylaja ramki wieksze niz dostepny bufor w tym SXie.

@bodek85 Możesz powiedziec na jakim sprzęcie to uruchamiasz i w jakiej konfiguracji.
Moje radio milczy jak zaklęte.

esp32d1mini bo taki miałem pod ręką plus głowica SX1262, kod identyczny jak w repozytorium szczepana, oczywiście pinologia inna dopasowana pod esp32d1mini. Szkoda że licznik energii leży, to by była petarda, widać różnice pomiędzy SX1276 a SX1262 gdzie 1262 czyta idealnie wszystkie licznik (izar, apator, usnismart) idealnie w sensie z taką częstotliwością co producent deklaruje. @ _Szczepan zrób coś z watomierzem :wink: postawię dużą flachę mogę podesłać logi co kowiek aby to ruszyło. Dodam że na 1276 watomierz działa a bufor te głowice mają chyba taki sam. Więc obstawiam coś innego.

1 polubienie

Ustawiłem radio w ten sposób.

# module DX-LR30-900M22S
spi:
  mosi_pin: GPIO23  # MOSI I SPI slave input
  clk_pin:  GPIO18  # SCK I SPI clock
  miso_pin: GPIO19  # MISO O SPI slave output

wmbus_radio:
  radio_type: Sx1262
  cs_pin:
    number: GPIO4       # NSS I SPI Slave Select
    # ignore_strapping_warning: true
  reset_pin: GPIO16     # NRESET I Reset signal, active low
  irq_pin: GPIO17       # DIO1 I/O Multi-purpose digital IO
  busy_pin: GPIO21      # Optional but recommended for proper timing
  rx_gain: BOOSTED           # BOOSTED (default) or POWER_SAVING
  rf_switch: true           # Set to true if DIO2 controls RF switch
  has_tcxo: false           # By default, DIO3 controls an external TCXO

logger:
level: VERY_VERBOSE

[12:23:32.498][VV][SX1262:161][radio_recv]: Restarting RX
[12:23:32.506][VV][component:302]: logger loop disabled
[12:23:58.067][VV][api.connection:261]: Sending keepalive PING
[12:23:58.067][VV][api.service:012]: send_message ping_request: PingRequest {}
[12:23:58.078][VV][api.service:016]: on_ping_request: PingRequest {}
[12:23:58.084][VV][api.service:012]: send_message ping_response: PingResponse {}
[12:23:58.087][VV][api.service:016]: on_ping_response: PingResponse {}
[12:24:32.507][VV][app:499]: logger loop enabled from ISR
[12:24:32.512][VV][SX1262:161][radio_recv]: Restarting RX
[12:24:32.517][VV][component:302]: logger loop disabled
[12:24:58.087][VV][api.connection:261]: Sending keepalive PING
[12:24:58.088][VV][api.service:012]: send_message ping_request: PingRequest {}
[12:24:58.096][VV][api.service:016]: on_ping_request: PingRequest {}
[12:24:58.099][VV][api.service:012]: send_message ping_response: PingResponse {}
[12:24:58.102][VV][api.service:016]: on_ping_response: PingRe

A wrzuć sobie taki:

wmbus_radio:
  radio_type: Sx1262
  cs_pin: GPIO4
  reset_pin: GPIO16
  irq_pin: GPIO17
  busy_pin: GPIO21
  rx_gain: BOOSTED
  rf_switch: true
  has_tcxo: false
  frequency: 868.95      # Wymuszenie pasma Izar
  log_all: true          # Diagnostyka

[frequency] is an invalid option for [wmbus_radio]. Please check the indentation.

log_all: true 

to samo

O kurczaki sorry to daj ten popatrzyłem na repo:

wmbus_radio:
  radio_type: SX1262
  cs_pin: GPIO4
  reset_pin: GPIO16
  irq_pin: GPIO17
  busy_pin: GPIO21
  rx_gain: BOOSTED
  rf_switch: true
  has_tcxo: false

wmbus_meter:
  - id: water
    meter_id: #ID 
    type: izar
    mode: 
      - T1
      - C1

Bez zmian.

[13:00:55.501][D][esp32.preferences:155]: Writing 1 items: 0 cached, 1 written, 0 failed
[13:01:19.253][VV][api.service:016]: on_ping_request: PingRequest {}
[13:01:19.254][VV][api.service:012]: send_message ping_response: PingResponse {}
[13:01:54.658][VV][app:499]: logger loop enabled from ISR
[13:01:54.665][VV][SX1262:161][radio_recv]: Restarting RX
[13:01:54.666][VV][component:302]: logger loop disabled
[13:02:19.156][VV][api.service:016]: on_ping_request: PingRequest {}
[13:02:19.159][VV][api.service:012]: send_message ping_response: PingResponse {}
[13:02:54.659][VV][app:499]: logger loop enabled from ISR
[13:02:54.668][VV][SX1262:161][radio_recv]: Restarting RX
[13:02:54.668][VV][component:302]: logger loop disabled
[13:03:19.061][VV][api.service:016]: on_ping_request: PingRequest {}
[13:03:19.064][VV][api.service:012]: send_message ping_response: PingResponse {}

Napewno dałeś ten kod:

wmbus_radio:
  radio_type: SX1262
  cs_pin: GPIO4
  reset_pin: GPIO16
  irq_pin: GPIO17
  busy_pin: GPIO21
  rx_gain: BOOSTED
  rf_switch: true
  has_tcxo: false

wmbus_meter:
  - id: water
    meter_id: #ID jeśli nadal nie działa daj 0xFFFFFFFF
    type: izar
    mode: 
      - T1
      - C1

A jeśli nadalsię nie naprawi to sprawdź te 3 punkty:

  • Błąd w dekodowaniu (CRC/Length): Jest taki wpis: “Add support for SX1262 (with limited frame length)”. Jeśli Izar wysyła bardzo długą ramkę (np. z rozbudowaną historią) radio może ją odrzucić przed wyświetleniem w logach.
  • Fizyczny Pin BUSY: Log Restarting RX sugeruje że komunikacja działa, ale jeśli busy_pin jest źle przylutowany lub ma zimny lut sterownik esp-idf może dostawać błędne sygnały o gotowości układu.
  • Zasilanie/Antena: Ponieważ masz moduł DX-LR30, on wymaga stabilnego 3.3V. Jeśli zasilasz go bezpośrednio z pinu ESP32 przy próbie odbioru (skok poboru prądu) napięcie może spadać co skutkuje brakiem czułości.
1 polubienie

Mamy to. Dzięki pomocy kolegi @Allon .
Przyczyna złe zasilanie z płytki ESP.
Wrażenie niesamowite !
Wodomierz izar w studzience na zewnątrz około 8m od domu plus jakieś 3 do 4 m w domu i czyta jak szalone.

1 polubienie

Pisałem w innym wątku, wczoraj uruchomiłem zakupiony pól roku temu SX1262 i czyta bardzo dobrze telegramy.

Ale problem jest taki, że przez komponent API w ESPHome tworzą się tylko skonfigurowane encje w ESPHome, ale nie przesyłają się związane z nim dane (cały czas jest stan “unknown” w HA). Dodam, że wcześniej na tej samej płytce ESP korzystałem z modułu CC1101 i poprzez komponent API w wersji v4 bez problemu wartości z tych samych liczników się aktualizowały w HA.

I teraz ciekawe. Jak włączyłem w v5 MQTT i skonfiguruje cześć “on_telegram” w komponencie “wmbus_meter” to do brokera MQTT (mosquito) przychodzą zdekodowane dane w JSONie zgodnie z konfiguracją w ESPHome :slight_smile: Szczegóły od tego miejsca w dół:

Nie wiem co siedzi w bebechach tego komponentu, ale mogę tylko podejrzewać, że obsługa ramki C1 dla SX1262 na czymś się wywala i nie przesyła zdekodowanych już danych do komponentu API (sam komponent API działa bo jak pisałem tworzą się encje na jego bazie w HA, ale nie otrzymuje on danych z komponentu wmbus stąd stan “unknown”), jak znajdę czas włączę logowanie VERBOSE albo VERY VERBOSE żeby to sprawdzić co się dzieje, ale programistą nie jestem…

A próbowałeś usunąć urządzenie z Integracji i dodać je ponownie?

Jest jeszcze jeden strzał w kolano który sobie zafundowałeś - twoje encje nie mają unikalnych identyfikatorów (i pewnie stara wersja też nich nie miała, więc nawet jeśli to uruchomisz to historia encji się nie scali z encjami z poprzedniego sprzętu).

Mają unikalne nazwy.

Poza tym utworzyłem nowy projekt ESPHome z innymi nazwami encji, z inną nazwą samego projektu i wewnętrznymi nazwami w komponencie esphome i polami name oraz friendly_name. Ogólnie wszystko co mogłem zmienić z nazwami to zmieniłem.

Potworzyły się nowe encji, ale to nic nie zmieniło jeśli chodzi o aktualizację danych, jak dla mnie jakiś bug.

EDIT:
Działa SX1262, miałem błąd w definicji w polu field, nie dodałem UoM…