Teraz wydaje się że jest ok, co prawda łapie prawidłowy pakiet co około 20 minut ale jest prawidłowy żadnych dziwnych pików 
niestety po jakiś 40 minutach esp przestaje odbierać jakiekolwiek pakiety i wtedy tylko restart pomaga 
(nie to że się zawiesza, bo działa i z poziomu www jak i HA jest widoczny,po prostu przestaje odbierać pakiety)
Moze jeszcze śpi. Za dnia nadają częściej.
Potestuje u mnie dłużej apatora. Z Izarem działa od momentu jak założyłem ten temat
Mam problem, wodomierze zdefionowene tak:
meters:
- |-
name=cieppla_duza_s
driver=apator162
id=1608150
key=00000000000000000000000000000000
- |-
name=zimna_duza_s
driver=apator162
id=1759628
key=00000000000000000000000000000000
A w logach błąd:
Running wmbusmeters …
Not a valid meter id nor a valid meter match expression “1759628”
Started config rtlwmbus listening on none using CMD(/usr/bin/nc -lku 9011)
No meters configured. Printing id:s of all telegrams heard!
Edit:
Już wiem, w wmbusmeters id trzeba definiowac z 0 na początku
W przypadku repo Mariusza chodziło bez 0,ale w wmbusmeters opartym o rtl_sdr mam z 0
Dobrze że coś przechodzi 
Patrz teraz w integracji MQTT w konfiguracji. Dajesz tam subskrypcje na # i słuchasz czy działa. Jak masz Apatora 16-2 to możesz załączyć też MQTT discovery. Po pewnym czasie powinny automatycznie pojawić się encje z nazwą wodomierza.
Pełen sukces (przynajmniej na razie 
) na konfiguracji Szczepana z licznikami:
- Gaz Apator G6G AT-WMBUS-G-01 (unismart)
- Woda Apator AT-WMBUS-08
Sprzęt:
- ESP8266 - d1_mini
- CUL - CC1101 868Mhz
Konfiguracja wg. opisu Szczepana:
How to use wmbusgw with wmbusmeters HA addon
Podłączenie u mnie (piny esp8266 w configu poniżej)
Mój config dla ESP:
logger:
id: component_logger
level: DEBUG
baud_rate: 0
time:
- platform: sntp
id: time_sntp
external_components:
- source: github://SzczepanLeon/esphome-components@main
components: [ wmbusgw ]
wmbusgw:
mosi_pin: GPIO13
miso_pin: GPIO12
clk_pin: GPIO14
cs_pin: GPIO2
gdo0_pin: GPIO5
gdo2_pin: GPIO4
clients:
- name: "wmbusmeters"
ip_address: "192.168.1.100"
port: 7022
format: RTLWMBUS
transport: TCP
Config dla wmbusmeters:
data_path: /config/wmbusmeters
enable_mqtt_discovery: false
conf: |-
loglevel=normal
device=rtlwmbus:CMD(/usr/bin/nc -lk 9022)
donotprobe=/dev/ttyAMA0
logtelegrams=false
format=json
logfile=/dev/stdout
shell=/wmbusmeters/mosquitto_pub.sh "wmbusmeters/$METER_NAME" "$METER_JSON"
meters:
- |-
name=LicznikGaz
driver=unismart
id=00021290
key=00000000000000000000000000000000
- |-
name=Licznikwoda
driver=apator08
id=00033cab
key=00000000000000000000000000000000
mqtt: {}
Plus ustawienie portu:
3 polubienia
Wydaje mi się że nie z “0” na początku a całe osiem miejsc, czyli jak ID za małe to uzupełniamy zerami z początku do wymaganych ośmiu.
Słuchajcie , jak wygląda sprawa z przesyłam tej samej wartości do HA? Wydaje mi się, że taka sama wartość nie jest przesyłana bo na wodzie mam nawet kilkanaście min. przerwy a pakiety latają.
No rtl’u wartość wskakiwała za każdym razem.
Taka sama wartość jest przesyłana do HA, ale HA jej nie rejestruje. Gdzieś na stronach HA jest to pisane.
No teraz zwątpiłem puki co nie chce mi się wracać do rtl’a.
Czyli co? Bez rtl HA się nudzi?
Tu jest o tych niezmieniajacych sie wartosciach:
Ogarnąłem temat
Usunąłem tego twojego if-a i filtr wstawiłem w to miejsce:
ESP_LOGI(“Info”, “Meter state: %d L”, v);
if (MeterID == ApatorID_1 and v > 0 and v < 10000000) {
Apator_state_1->publish_state(v);
Apator_id_1->publish_state(MeterID);
}
if (MeterID == ApatorID_2 and v > 0 and v < 10000000) {
Apator_state_2->publish_state(v);
Apator_id_2->publish_state(MeterID);
Działa perfekcyjnie, nie łapie błędnych wartości i wydaje się że działa cały czas tzn nie przestaje odbierać ramek po jakimś czasie.
Nie wiem czy to eleganckie rozwiązanie ale działa
2 polubienia
I właśnie tak czlowiek staje się programistą 
Po dobie zabawy zestawem Szczepana chyba przy niej zostaje. Wprawdzie irytuje mnie trochę, że tak naprawdę przeniosłem tylko wmbusmetersa z maliny na maszynę z HA, zamieniając tylko rtl’a na “sieciowe” cc1101, ale ma to ten plus, że bazuje na dopieszczonym dekodowaniu eliminującym błędy zbyt dużych wartości. Bo niestety dałem poprawkę Mariusza z kilku postów wyżej no i dałem filtr na 50000 to się okazało, że prześlizgnęła się wartość 10000 i trzeba by tak zgadywać jak ustawić filtr Ale może kiedyś wrócę do układu, gdzie dekoduje ESP, bo jednak jest to bardziej logiczne rozwiązanie
2 polubienia
To teraz jak to dodać do zakładki “energia”? Utworzyłem encję ale niestety nie pokazuje się tam gdzie konfigurujemy licznik wody.
Musisz też dodać atrybut
state_class: total_increasing
Jak dodaje to sypie błędami:
Invalid config for [sensor.template]: [state_class] is an invalid option for [sensor.template]. Check: sensor.template->sensors->woda_zimna->state_class. (See ?, line ?).
Na liczniku umieszczony jest maksymalny możliwy przepływ np. Q 1.6m3/h.
Znając okres odczytów z licznika można oszacować jaki jest możliwy przepływ pomiędzy pomiarami.
Wystarczy pamiętać poprzedni odczyt i porównywać z obecnym.
Różnica nie może być ujemna i większa od możliwego (oszacowanego wcześniej) max przepływu.
Wtedy pomiar można uznać za prawidłowy.
Ta wartość w rzeczywistych warunkach domowych jest oczywiście dużo mniejsza.
Coś musisz mieć skopane w definicji, może stary format ?
Nie korzystam z mqtt w tym wypadku. Wszystko oparte jest o rozwiązanie @Mariusz_Woszczyński i działa super.
W konfiguracji, zakładka sensor utworzyłem taki wpis:
woda_zimna:
friendly_name: "licznik zimna"
state_class: total_increasing
unit_of_measurement: 'm³'
unique_id: wodomierz_zimna
device_class: water
value_template: "{{ states('sensor.stan_licznika_wody_zimnej')|float/1000 }}"
W narzędziach deweloperskich klikam w “sprawdź konfiguracje” to wali błędem który pokazywałem wcześniej. Wersja HA aktualna (wcięcia są prawidłowe, te powyżej trochę się rozjeżdżają)
Widać że wszystko działa bo pokazuje prawidłowe wartość,natomiast nie przyjmuje kompletnie state_class: total_increasing
Ja mam template w configuration.yaml:
template:
- sensor:
- name: "Całkowite zużycie wody m3"
unit_of_measurement: "m³"
device_class: water
state_class: total_increasing
state: >
{{ states('sensor.calkowite_zuzycie_wody')|float * 0.001 }}
i do tego dodany pomocnik: sensor.calkowite_zuzycie_wody, jako licznik mediów bez cyklu resetowania
Zastanawiam się, skąd biorą się te błędne wartości.
Od wczoraj rana leci u mnie odczyt apatora i żadnej wartości błędnej nie mam.
Może ma to związek z siłą sygnału/odległością od licznika, bo u mnie leży na stole przy kompie.