/// mod-edit - wydzielono z wątku na inny temat…
Czym jest wersja “v5 od Kuby”? Mam SX1267 i czy można do niej zmigrować?
W pierwszej linii readme.md SzczepanLeon @4 masz taki wiersz: Version 5 based on Kuba’s dirty fork…
Po naciśnięciu zostaniesz przeniesiony do githuba: GitHub - IoTLabs-pl/ESPHome-Components.
Pierwsze zbudowałem obraz z użyciem V5 od Szczepana. Mieszkam w bloku gdzie tylko w mojej klatce mam 36 różnych liczników (ciepłomierze + liczniki wody) i układ na SX1276 w porywach dwa razy na godzinę dekodował ramki. Mam również RTL-SDR i miałem porównanie jaki jest ruch w eterze. Po zainstalowaniu wersji od Kuby co sekundę, co dwie układ odbiera i dekoduje ramki z eteru.
Mój YAML. Nie mam sekcji sensors itd ponieważ mój układ nie jest zintegrowany z asistantem - odbieram i analizuję wiadomości mqtt.
esphome:
name: nowysx1276
friendly_name: NowySX1276
platformio_options:
upload_speed: 921600
external_components:
- source:
type: git
url: https://github.com/IoTLabs-pl/esphome-components
esp32:
board: esp32dev
framework:
type: esp-idf
logger:
id: component_loger
level: DEBUG
baud_rate: 115200
ota:
- platform: esphome
password: "19bbb3a5a185d53ba756c99add5a42f8"
wifi:
networks:
- ssid: !secret wifi_ssid
password: !secret wifi_password
api:
web_server:
version: 3
time:
platform: sntp
id: time_sntp
spi:
clk_pin: GPIO18
mosi_pin: GPIO23
miso_pin: GPIO19
mqtt:
broker: 192.168.1.201
port: 1883
client_id: dm
wmbus_common:
# drivers: all
# or specify specific drivers
drivers:
- apator162
- iwmtx5
- hydrocalm3
wmbus_radio:
radio_type: SX1276
cs_pin: GPIO15
reset_pin: GPIO27
irq_pin: GPIO14 # DIO01
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: 3
then:
- output.turn_on: status_led
- delay: 100ms
- output.turn_off: status_led
- delay: 100ms
- mark_as_handled: True
then:
- mqtt.publish:
topic: telemetria/telegram_rtl
payload: !lambda return frame->as_rtlwmbus();
wmbus_meter:
- id: cold_water_supply
meter_id: 25319203
type: iwmtx5
mode: T1
on_telegram:
- wmbus_meter.send_telegram_with_mqtt:
topic: telemetria/gw/licznik_wody/zimna
- id: hot_water_supply
meter_id: 25318091
type: iwmtx5
mode: T1
on_telegram:
- wmbus_meter.send_telegram_with_mqtt:
topic: telemetria/gw/licznik_wody/ciepla
- id: heat_meter
meter_id: 05285311
type: iwmtx5
mode: T1
on_telegram:
- wmbus_meter.send_telegram_with_mqtt:
topic: telemetria/gw/licznik_ciepla
- id: public_water_supply_system
meter_id: 06861073
type: apator162
mode: T1
key: "00000000000000000000000000000000"
on_telegram:
- wmbus_meter.send_telegram_with_mqtt:
topic: telemetria/dm/licznik_wody/woda_z_wodociagow
- id: own_water_supply_system
meter_id: 06861531
type: apator162
mode: T1
key: "00000000000000000000000000000000"
on_telegram:
- wmbus_meter.send_telegram_with_mqtt:
topic: telemetria/dm/licznik_wody/woda_z_wlasnego_ujecia
output:
- platform: gpio
id: status_led
pin: GPIO25
Na jakiej płytce odpalasz ta wersje od Kuby?
Tak właśnie probowałem coś zrobić z esp32s3mini i cc1101 i to nie działa(V4) nie wiem z jakiego powodu dlatego tez pytam jaki HW by cos innego sprawdzonego kupić 
Skorzystaj z drugiego wątku, gdzie się podpiąłeś - “wersja Kuby”, czyli IoTLabs-pl jest dedykowana wyłącznie dla SX1276, jeśli się wczytasz w repozytorium to się dowiesz nawet jaka to konkretnie płytka prototypowa (sorry nie pamiętam konkretów, ale coś ze stajni Heltec bodajże).
A jedyne co mogę sugerować, by być fair, to byś kupił gotowy odbiornik właśnie u niego (link do ogłoszenia sprzedaży, bo realnie trudno to znaleźć).
Tak widziałem heltec_wifi_lora_32_V2 tylko to teraz ciezko kupic w wersji V2 wiekszosć to V3 i V4 niestety :(.
A więc czytanie dokumentacji wita. Jeśli znajdziesz wszystkie różnice między wersjami tych płytek (a jakie właściwie są?) to sobie dostosujesz YAMLa. Oczywiście to MUSI być SX1276 868MHz.
Oprócz tego sugeruję MCU “S3” (to jest chyba coś, przed czym się bronisz) na płytce wyposażonej w PSRAM.
Ale jak pisałem wyżej - uważam, że dobrą robotę trzeba wspierać, a cena sprzętu u niego nie jest wygórowana…
Piszemy w niewłaściwym wątku przenoszę posty. przeniesione
1 Like
Narazie zamówiłem ESP32 inne niz te mini, czytajac watek o EspHome mam duzo watpliwosci czy sie skompiluje i w sumie nie wiem czy moj licznik wody w ogole odczyta (DIEHL) . wiec szukam alterantywy na 2 krok
Zupełnie nie łapię kontekstu, nie rozmawialiśmy nigdzie o żadnych “mini”.
Za to zmusiłeś mnie do przekopania dokumentacji Helteca,
zamiast jasno napisać, że ich wypusty Heltec wifi lora 32 v3 i Heltec wifi lora 32 v4 mają radio SX1262 (niekompatybilne z tu opisywanym komponentem).
Proponuję byś wybierał za każdym razem właściwy wątek do treści, które chcesz napisać, bo naprawdę mamy tu już wystarczająco dużo bałaganu z komponentami pochodzącymi od rożnych autorów (a raczej z osobami postującymi w losowo wybranych wątkach…).
Tym bardziej nie rozumiem twoich kombinacji - spytaj te osoby które produkują te czytniki - nikt nie będzie bardziej zorientowany od nich czy dany model daje się odczytać (ale jak znam życie, to do Diehl, o ile w ogóle to jest wersja wM-Bus, musisz znać klucz szyfrowania, a duzi dostawcy wody mają jakiś betonowo-mentalny problem z udostępnianiem klucza swojemu klientowi, więc szanse oceniam na niskie jeśli nie pojawi się w końcu uregulowanie prawne dające konsumentom prawo do dostępu do danych o własnym zużyciu wszelkich mediów na równi z dostawcami).
Dziekuje za wyjasnienia. napisze do iotlabs bo na stronie nic nie znalazlem o DIEHL niestety.
Bo do DIEHL są zakładane nakładki IZAR i w 99 procentach użycia są bez kodowania.
Licznik Wody Diehl Aries IS IZAR - Home Assistant - ArturHome
P.S.
Prześlij mi foto nakładki radiowej na PW, to porównam ze swoimi.
1 Like
Próbowałeś może odpalać kod swojego komponentu pod Arduino framework? Masz gdzieś projekt?
Twoje rozwiązanie na integrację z Suplą GitHub - IoTLabs-pl/wM-Bus-Gateway-for-Supla zainstalowane z Twojej strony działa jak powinno, natomiast próba zbudowania tego pod frameworkiem Arduino po oczywistym pozbyciu się zależności do ESPHome się kompiluje i uruchamia, ale nie odbiera w ogóle poprawnych ramek. Strzelam, że problem leży w obsłudze przerwań, aczkolwiek może Ty wiesz dokładnie.
Testuje na sx1276
Niestety nie.
W IDFie mam bardziej bezpośrednią kontrolę nad komunikacją tasków odbiorczego i przetwarzającego i dlatego chciałem to zrobić jak najbliżej samego IDFa. Nie mam zasadniczo pojęcia dlaczego pod Arduino to nie działa, bo Arduino też przecież jest pośrednio nakładką na IDF.
Na ten moment, ramka jest akumulowana na stercie przez wątek odbiorczy, a gdy mamy prawo przypuszczać że jest kompletna, przerzucamy wskaźnik na nią przez kolejkę do main loopa, który robi wszystkie wmbusmetersowo-ciężkie sprawy na niskim priorytecie.