Jak narazie jest OK
1 polubienie
No i po pięciu godzinach restart 
Oto moja końcowa propozycja.
Jeśli naprawdę musicie używać tej wersji ESPHome to polecam skorzystać z mojego forka i ograniczyć kod do minimum.
innego rozwiązania nie widzę.
Takie uptime-y sa do przezycia
Rozwiązanie jest bo wszyscy idziecie nie tą drogą ( na tę chwilę mam połowe ). .
Doszedłem to tego droga dedukcji.
Czyli używamy ESP do tego do czego ma służyć czyli czytać.
INFO Starting log output from wmbus_bridge/debug
INFO Connected to MQTT broker!
[10:15:31][I][wmbus_sx1276:147]: RAW DATA: B937B1E087C3C9DCFB0BDC81E20DE78C7F0E5B364BD7884772F479F081F987A3
[10:15:34][I][wmbus_sx1276:147]: RAW DATA: 6411DF1E7C7E84E985EC44F18FF889E2910080071D81E137D10F3401F36FF80D
[10:15:35][I][wmbus_sx1276:147]: RAW DATA: C71CFD8A62400862F341EDFCDD127598C4AF8FD3FA099ED87DEF8FCE65F93C27
[10:15:35][I][wmbus_sx1276:147]: RAW DATA: F780C7FE1B9F6E0C3C00583F10E23DB15FF3700F9F1675E46FB67FA689369D47
Kod i to szybko napisało mi AI.
Moja koncepcja do której doszedłem to wrzucenie RAW do WMBUSMETERS.
Problem polega na tym iż obecnie od 2 dni zmuszam AI do klepania mostu który czyta ten RAW i wrzuci na STDIN WMBUSMETERS.
Tak - WMBUSMETERS to potrafi tylko twórcy ADDONA zabetonowali to na USB ( bo chciałem aby nie stawiać WMBUSMETERS poza HA ).
Więc prostsza droga to WMBUSMETERS poza HA i on to wyśle do Brokera.
Jestem JEDEN a sądzę że są tu ludzie którzy mają wiedzę której Ja nie mam.
Co to daje ?
To z czym wszyscy walczycie czyli każda zmiana w ESP powoduje że nie możecie kompilować bo do układu trafia cały dekoder który nie jest odporny na zmiany w ESP i tak w koło Macieju.
Wklejam kod z mojej płytki ( TO PRZYKŁAD bo się Wam nie skompiluje ) :
esphome:
name: ultimatereader-5a16c4
friendly_name: Ultimate Reader
platformio_options:
board_build.arduino.memory_type: qio_qspi
on_boot:
priority: 800
then:
- output.turn_on: board_power
- delay: 100ms
- logger.log: "=== Power ON, Radio Starting ==="
esp32:
board: esp32-s3-devkitc-1
framework:
type: arduino
external_components:
- source:
type: local
path: components
# ============================================
# SIECI I KOMUNIKACJA
# ============================================
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
ap:
ssid: "wMBus-Setup"
password: "12345678"
mqtt:
broker: !secret mqtt_broker
username: !secret mqtt_user
password: !secret mqtt_password
topic_prefix: "wmbus_bridge"
# USUNIĘTO BŁĘDNĄ SEKCJĘ on_message
captive_portal:
# api: wyłączone dla czystego MQTT
# encryption:
# key: !secret api_encryption_key
ota:
- platform: esphome
# ============================================
# LOGOWANIE
# ============================================
logger:
level: INFO
logs:
wmbus_sx1276: INFO
# ============================================
# SPRZĘT (LILYGO T3-S3)
# ============================================
spi:
clk_pin: GPIO5
mosi_pin: GPIO6
miso_pin: GPIO3
output:
- platform: gpio
id: status_led
pin: GPIO15
- platform: gpio
id: board_power
pin: 37 # Ignorujemy ostrzeżenie, bo LilyGO tak ma
# ============================================
# SENSORY DIAGNOSTYCZNE
# ============================================
sensor:
- platform: uptime
name: "Reader Uptime"
update_interval: 60s
- platform: wifi_signal
name: "Reader WiFi Signal"
update_interval: 60s
text_sensor:
- platform: version
name: "Reader ESPHome Version"
- platform: wifi_info
ip_address:
name: "Reader IP Address"
mac_address:
name: "Reader MAC Address"
# ============================================
# RADIO WMBUS - TU JEST SERCE
# ============================================
- platform: wmbus_sx1276
name: "wM-Bus Raw Data"
id: wmbus_raw_teleg
cs_pin: 7
reset_pin: 8
irq_pin: 33
frequency: 868.95
Nie wiem czy dobrze rozumiem, ale to potrafi ten komponent od samego początku. Bazuje na tym projekcie:
Czy aby na pewno?
Nie. To jest ta droga ( jeżeli w tej chwili GPT mnie nie okłamał po analizie repo ) którą ja chce zmienić. Ja nie chce dekodować WMBUS w ESP bo to jest uzależnione od forków , repo etc…
U mnie ESP robi za RTL-SDR i wysyła ramki .
Czyli ja założyłem że nieważne jaki sprzęt , jaka wersja ESP czyli to co jest wałkowane na wątku tym i podobnych.
Tak - sprawdziłem addon w HA czy można mu podstawić coś innego niż USB. Nie chciał. Ma to wymuszone - mam to w logach z GPT ale nie każ mi szukać.
Dlatego napisałem - jestem JEDEN , nie jestem w stanie sprawdzić wszystkich koncepcji czy możliwości.
WMBUMETERS na Linuksie czyli to co Ja kombinuje STDIN:
echo "33839FD937072E6AE811D831E38760C3FBF80CBF89D8BE0CFD613891664CEE0B" | wmbusmeters --useconfig=/etc --overridedevice=stdin:hex:t1
No such key: name
No such key: type
No such key: id
No such key: key
Started config hextty on stdin listening on t1
No meters configured. Printing id:s of all telegrams heard!
Po dzisiajszej aktualizacji Esphome oraz update mojej kompilacji juz jest duzo lepiej. Z opisu update wynika ze chyba cos tam majstrowali przy mbus oraz wifi. Niemniej jednak od rana od godz 5 mialem dwa restarty. Modul w tej chwili jest na:
external_components:
- source:
type: git
url: https://github.com/AllonGit/esphome-components
ref: main
components: [wmbus_common, wmbus_radio, wmbus_meter]
refresh: 0s`
Mam drugi moduł na którym zaraz załaduje repo szczepana i zobaczymy
tu masz kawałek dokumentacji z v2
@_Szczepan jak pamiętam dokładał obsługę do wmbusmeters jeszcze wcześniej
Chyba mnie zabiłeś w tym momencie …
Podpisuje sie pod tym. Mam RTL-SDR juz dwa lata i zapomnialem ze on tam wogole jest. Zero problemow. Czyta liczniki jak marzenie.
Ta funkcja jest od początku.
To nie to samo.
Czyli to co opisałem do czego zmierzam. ESP jest RTL_SDR i niczym więcej.
Czyli zmiana płytki to tylko nowy kod radia a nie nowy kod z licznikami bo reszta siedzi w wmbusmeters.
Czyli pytanie po co ESP skoro to samo robi RTL-SDR.
Bo uznałem iż ktoś może mieć z tym problem u łatwiej mu bedzie umieścić układ ESP tam gdzie chce i nie wywali się to po każdym updajcie ESP.
Moje testy użycia addon z USB stick dawały ok. 3-4W większe zużycie prądu dla hosta z HAOS przy odpalonym dodatku WMBUMETERS, o większej utylizacji CPU i RAM nie będę nawet pisał. Dla porównania ESP32 i CC1101 pobiera ok. 0,5W.
P.S. nie jestem fanem aktualizacji urządzeń z ESPHome jeśli nie muszę. Tylko dlatego, że pojawia się nowa wersja.
3 polubienia
Dokładnie - jako pierwsze pojawiła sie opcja wysyłania odebranych telegramów do zewnętrznego Wmbusmetersa.
Na pewno jest opcja stream po TCP/UDP
Tak mozna mu podstawic nie tylko USB - sam pchałem tam na to poptawkę.
Dokładnie - to poszło dawno temu do HA.
Czyli Ja odkrywam Amerykę na nowo - OK
@_Szczepan podpowiesz jak skonfigurować dodatek wmbusmeters w HA w parametrze “device”?
Czytaliście stara dokumentacje?
Uruchomiłem v5 na ttgo t-beam 1.2 z sx1276. Na razie tylko żeby znaleźć mój licznik (CC1101 i RTL USB) nie widziały. Ten też widzi liczniki z 8 innych domów w wiosce, ale nie mój 
Jakiś pomysł?
Poniżej działający yaml z konfiguracją.
esphome:
name: t-beam
friendly_name: T-Beam
esp32:
board: esp32dev
framework:
type: esp-idf
logger:
level: DEBUG
baud_rate: 115200
logs:
wmbus: DEBUG
component: DEBUG
i2c: NONE
external_components:
- source: github://SzczepanLeon/esphome-components@main
components: [ wmbus_radio, wmbus_meter, wmbus_common ]
api:
encryption:
key: "R9Ss2ITqYQYQT4fDfz+******************************="
ota:
- platform: esphome
password: "64f71b494498*******************************"
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
ap:
ssid: "T-Beam Fallback Hotspot"
password: "********************"
font:
- file: "ComicSansMS3.ttf"
id: my_font
size: 14
i2c:
sda: GPIO21
scl: GPIO22
display:
- platform: ssd1306_i2c
model: "SSD1306 128x64"
rotation: 180
# reset_pin: D0
address: 0x3C
#lambda: it.printf(0, 25, id(my_font), "Czas: %s", id(time_sntp).now().strftime("%H:%M:%S").c_str());
lambda: |-
// it.printf(0, 0, id(my_font), "Woda: %.3f m3", id(woda_dom).state); // Zakomentowane
it.printf(0, 25, id(my_font), "Czas: %s", id(time_sntp).now().strftime("%H:%M:%S").c_str());
spi:
clk_pin:
number: GPIO5
ignore_strapping_warning: true
mosi_pin: GPIO27
miso_pin: GPIO19
time:
- platform: sntp
id: time_sntp
wmbus_radio:
radio_type: SX1276
reset_pin: GPIO23
cs_pin:
#ignore_strapping_warning: true
number: GPIO18
irq_pin: GPIO33
# VCC: 3.3V #1 czarny
# GND: GND #2 brązowy
# mosi_pin: GPIO2 #3 biały
# clk_pin: GPIO14 #4 żółty
# miso_pin: GPIO12 #5 fioletowy
# gdo2_pin: GPIO36 #6 brązowy
# gdo0_pin: GPIO25 #7 czarny
# cs_pin: GPIO15 #8 biały
#led_pin: GPIO13
#led_blink_time: "1s"
# frequency: 868.950 #co 8 sekund do 500m
# frequency: 868.30 #co 15 minut do 1500m
# frequency: 868.625 #co 15 minut do 1500m
# frequency: 868.950
# all_drivers: True
# sync_mode: True
# log_all: True
# mqtt_raw: true
# mqtt_raw_prefix: "lillygo" # Prefix topic
# mqtt_raw_format: RTLWMBUS # Format dla wmbusmeters
# mqtt_raw_parsed: true # Dodaje /parsed/ z dekodowanymi danymi
on_frame:
- then:
- logger.log:
format: "RSSI: %ddBm T: %s (%d) %s"
args: [ frame->rssi(), frame->as_hex().c_str(), frame->data().size(), toString(frame->link_mode()) ]
- then:
- mqtt.publish:
topic: "lillygo/wmbus/raw"
payload: !lambda |-
return frame->as_hex();
wmbus_common:
drivers: all
mqtt:
broker: 192.168.1.34
username: *******
password: **********
# sensor:
# - platform: wmbus
# meter_id: 0x414fd125
# type: izar
# sensors:
# - name: "woda_dom"
# id: woda_dom
# field: "total"
# accuracy_decimals: 3
# unit_of_measurement: "m³"
# device_class: "water"
# state_class: "total_increasing"
# icon: "mdi:water"
output:
- platform: gpio
pin: GPIO2 # Dodaj status_led, jeśli masz pin LED
id: status_led
Wadliwa nakładka, brak poboru wody, oczywiście o ile masz 100% pewności, że masz taką samą nakładkę jak sąsiedzi i że pracuje w tym samym trybie (ten sam czas wymiany waszych liczników i nakładek przez dostawcę wody).
I mało prawdopodobne, ale jednak - jesteś z odbiornikiem za blisko nakładki i masz za wysoki sygnał.