Z tym API to nie wiem, ale jeśli masz taką samą płytkę jak ja, to irq_pin powinien być 33 (irq_pin: GPIO33).
Co to dokładnie za moduł ?
tam gdzie wywołujesz usera jest opisana płytka
LiIygo T3 LoRa32 V1.6.1
ale generalnie to każdy SX1276 na 868MHz (i ESP32 lub nowsze/z większymi zasobami ESP32-xy np. S3)
A mając CC1101 jakie kupić dokładnie samo radio aby zamienić na SX1276 ?
I czy taka płytka też zadziała bo jest jak zasugerowałeś na ESP32-S3 ?
- SX1276 to SX1276 jeśli znajdziesz “luzem” (a widziałem gdzieś), to możesz użyć
- tak, T3 S3 (oczywiście w wersji SX1276 868MHz) też jest OK
taki ?
Wygląda kiepsko, ale tak (z CC1101 w takim szajsowym wykonaniu miałem więcej problemów niż radości - 3 z 5 sztuk były niezdatne do użytku).
Tu jest mój konfig do V5. Przykładowe sensory dość uniwersalne, więc można je dodać do README jak się przyda.
Bardzo fajnie v.5 działa na tym module:
https://pl.aliexpress.com/item/1005006860809926.html
ok na wersji 4 wiem jak przeszukać wszystko żeby znaleźć widoczne liczniki, a jak to zrobić na v5? tj jaki yaml aby w logu pokazało co znajduje
nie definiujesz nic w YAMLu i powinien w logu wyświetlić linki do wmbusmetersa z nieobrobionymi telegramami
problem z “kompilacją” czy tam budowaniem wersji 5 (main) na esphome w Windows.
po utworzeniu pliku YAML z prawidłową konfiguracją na ubuntu obraz zostaje prawidłowo przygotowany, ale to samo na Windowsie nie działa. Błąd:
test na wersji 5.0.5 i wszystko ok.
Poszukałem i problem jest w pliku components\wmbus_common\units.h
a co dziwne wystarczy usunąć “trochę” spacji w blokach:
#define LIST_OF_QUANTITIES
oraz
#define LIST_OF_UNITS
Jeśli w tych dwóch blokach liczba spacji jest mniejsza od 3944
to kompilacja przebiega poprawnie.
Obecnie te dwa bloki zawierają 4501 spacji ![]()
Widzę że to powstało przez użycie autoformatera .Można to jakoś naprawić w nowszych commitach?
Jaką masz wersję Pythona na Linuxie a jaką na Windowsie?
Podzielisz się YAMLem?
Python na windows 3.11.0 oraz 3.13.7
Na Linux 3.12.3
esphome:
name: odczyty
friendly_name: Odczyty
platformio_options:
upload_speed: 921600
esp32:
board: esp32doit-devkit-v1
framework:
type: esp-idf
# Enable logging
logger:
web_server:
local: true
ota: false
mqtt:
broker: 10.1.1.1
port: 1883
client_id: odczyty
time:
- platform: sntp
id: time_sntp
ota:
- platform: esphome
password: ""
wifi:
networks:
- ssid: "BPi"
password: "11111111"
ap:
ssid: "odczyty Fallback"
password: "11111111"
external_components:
- source: github://SzczepanLeon/esphome-components@main
refresh: 0d
spi:
clk_pin: GPIO25
mosi_pin: GPIO26
miso_pin: GPIO27
wmbus_radio:
radio_type: SX1276
cs_pin: GPIO33
reset_pin: GPIO32
irq_pin: GPIO21
on_frame:
- then:
- logger.log:
format: "RSSI: %ddBm T: %s (%d)"
args: [ frame->rssi(), frame->as_hex().c_str(), frame->data().size() ]
- then:
- repeat:
count: 1
then:
- output.turn_on: status_led
- delay: 100ms
- output.turn_off: status_led
- delay: 50ms
- mark_as_handled: True
then:
- mqtt.publish:
topic: wmbus-test/telegram_rtl
payload: !lambda return frame->as_rtlwmbus();
output:
- platform: gpio
id: status_led
pin:
number: GPIO2
ignore_strapping_warning: true
wmbus_meter:
- id: woda_dom
meter_id: 0x02308234
type: mkradio4
sensor:
- platform: wmbus_meter
parent_id: woda_dom
field: total_m3
name: Woda
Długość ścieżki do plików chyba nie powinna być za długa bo mam to w C:\esphome\
@heinzek poprawka poszła - sprawdz czy zadziałało
Teraz wszystko jest OK. Windows i Linux. Dzięki
No właśnie mam identyczny i jakoś mi nie chce trybić. Dałbyś kod? Porównam.
Witam. Dzisiaj spółdzielnia wymieniała licznika apatora z nakładką apator162 na (chyba) nowość na rynku. Nakładka NAXOM OP-04-1a - również apatora.
Czy taka nakładka będzie/jest w ogóle obsługiwana?
Link do strony producenta: https://www.apator.com/nasze-rozwiazania/woda-i-cieplo/system-zdalnego-odczytu-mediow/system-radiowy/op-o4-1-2
Jak będziesz mieć klucz to wygląda na to że w 99%. W końcu zrezygnowali z swojego protokółu na rzecz OMSa
Na wmbusmeters nie ma takiego drivera. Rozumiem, że w najbliższej przyszłości się pojawi czy trzeba użyć innego?

