Support for flowiq2200

[evilmumi]

Hi,

is it possible to add flowiq2200 support? I found something here but dont know how to implement: https://github.com/wmbusmeters/wmbusmeters/blob/master/src/driver_flowiq2200.cc

Log is like:

wMBus-lib: Processing C1 B frame -- NOT supported yet
 FullFrame: 0x54, 0x3D, 0x34, 0x44, 0x37, 0x2C, 0x37, 0x79, 0x71, 0x23, 0x3A, 0x16, 0x8D, 0x20, 0xA0, 0xA0, 0x81, 0x12, 0x3D, 0x48, 0x20, 0x86, 0xA0, 0xA2, 0x57, 0x93, 0x83, 0x8C, 0xD2, 0xDF, 0xDB, 0x41, 0x45, 0xE8, 0x5B, 0x12, 0x1D, 0x72, 0x38, 0x71, 0x82, 0x91, 0x00, 0xF1, 0x8A, 0xA3, 0x9D, 0xD5, 0x67, 0x4F, 0xC3, 0xCF, 0x45, 0xAF, 0xFE, 
wMBus-lib:  Error during decoding 'unknown'

wMBus-lib: Processing C1 B frame -- NOT supported yet
 FullFrame: 0x54, 0x3D, 0x9A, 0x22, 0x1B, 0x96, 0x1B, 0xBC, 0xB8, 0xD8, 0xDE, 0x84, 0xA3, 0x48, 0x29, 0x29, 0x8A, 0xE1, 0xBF, 0x44, 0x93, 0x82, 0x18, 0x64, 0xA8, 0xFA, 0xD9, 0x9B, 0xF4, 0x2C, 0x3B, 0xE4, 0x19, 0x23, 0xBE, 0x10, 0xB9, 0xB9, 0x0B, 0xD1, 0xE1, 0x9D, 0x54, 0x09, 0x7B, 0x3C, 0x42, 0xF3, 0x5B, 0x5B, 0xE3, 0xC0, 0x13, 0x05, 0x8D, 0x21, 0xBF, 0x2D, 0xFF, 0x9C, 0x56, 0x61, 0x36, 0x11, 0xBD, 0xB7, 0x3D, 0x9A, 0x22, 0x1B, 0x96, 0x1B, 0xBC, 0xB8, 0xD8, 0xDE, 0x84, 0xA3, 0x48, 0x29, 0xBC, 0x47, 0x65, 0xA4, 0x2C, 0x5F, 0xFF, 0x81, 0xBB, 0x29, 0xDF, 0x9B, 0xF4, 0x2C, 0x3B, 0xE4, 0x19, 0x23, 0xBE, 0x10, 0xB9, 0xB9, 0x0B, 0xD1, 0xE1, 0x9D, 0x54, 0x09, 0x7B, 0x3C, 0x42, 0xF3, 0x5B, 0x5B, 0xE3, 0xC0, 0x13, 0x05, 0x8D, 0x21, 0xBF, 0x2D, 0xFF, 0x9C, 0x56, 0x61, 0x36, 0x11, 0xBD, 0xB7, 0x3D, 0x9A, 0x22, 0x1B, 0x96, 0x1B, 0xBC, 0xB8, 0xD8, 0xDE, 0x84, 0xA3, 0x48, 0x29, 0xBC, 0x47, 0x65, 0xA4, 0x2C, 0x5F, 0xFF, 0x81, 0xBB, 0x29, 0xDF, 0xC9, 0x7E, 
wMBus-lib:  Error during decoding 'unknown'

[SzczepanLeon]

It is strange for me. For sure CRC calculation in my code is OK (both CRC, for frame and for payload). There is something strange in Rx from CC1101. T1 A mode is working, C1 A mode also should be OK (I don't have that meter but I have feedback).

Only that C1 B mode is not OK - but logic is the same as for C1 A (almost). Maybe that almost is key to my riddle :-(

btw You run my soft and that other on the same hardware?

[evilmumi]

It is strange for me. For sure CRC calculation in my code is OK (both CRC, for frame and for payload). There is something strange in Rx from CC1101. T1 A mode is working, C1 A mode also should be OK (I don't have that meter but I have feedback).

Only that C1 B mode is not OK - but logic is the same as for C1 A (almost). Maybe that almost is key to my riddle :-(

btw You run my soft and that other on the same hardware?

atm yours on an 8266 d1 mini and the other on an esp32dev ;az-delivery-devkit-v4

do you think - i should test yours on esp32 also?

[SzczepanLeon]

One week ago I would say it is does not matters, but today - yes please test it on the same HW.

[evilmumi]

so i took also esp32 and same antenna:

[D][rxLoop:159]: Have 53 bytes from CC1101 Rx
[D][mbus:022]: Processing C1 B frame
[V][mbus:026]: Frame: 3444372C347971233A168D209D03843F21A6C0F65FA962803F1FF7D3F89A54E701D33740F84D5C09DB2B6D486D49C4C626CAFBFBF1 (53) [with CRC]
[V][mbus:159]: Validating CRC for Block1 + Block2
[E][crc:035]:   calculated: 0x31A6, read: 0xFBF1  !!!
[D][mbus:056]: Frame: 3244372C347971233A168D209D03843F21A6C0F65FA962803F1FF7D3F89A54E701D33740F84D5C09DB2B6D486D49C4C626CAFB (51) [without CRC]
[I][wmbus:097]: Using driver 'evo868' for ID [0x23717934] RSSI: -65 dBm LQI: 132 Frame: C1 B T: 3244372C347971233A168D209D03843F21A6C0F65FA962803F1FF7D3F89A54E701D33740F84D5C09DB2B6D486D49C4C626CAFB (51)
[V][utils:109]: (ELL)  CI: 8D  offset: 17
[V][utils:112]: (ELL)  IV: 372C347971233A162003843F21000000
[V][utils:115]: (ELL) KEY: keykeykey(16)
[D][utils:124]: (ELL) AES_CTR decrypting: A6C0F65FA962803F1FF7D3F89A54E701D33740F84D5C09DB2B6D486D49C4C626CAFB (34)
[D][utils:152]: (ELL) AES_CTR  decrypted: FDC37905099CE6000000007CE203007C0506600006D00001320B11000079E703000F (34)
[V][wmbus:303]: Validating CRC for ELL payload
[I][crc:047]:   calculated: 0xC3FD, read: 0xC3FD
[E][wmbus:119]: Something was not OK during decrypting telegram for ID [0x23717934] 'evo868' key: 'kexkkeykey'
[E][wmbus:120]: T : 3244372C347971233A168D209D03843F21A6C0F65FA962803F1FF7D3F89A54E701D33740F84D5C09DB2B6D486D49C4C626CAFB (51)
[E][wmbus:121]: T': 3244372C347971233A168D209D03843F21FDC37905099CE6000000007CE203007C0506600006D00001320B11000079E703000F (51)

[D][rxLoop:159]: Have 53 bytes from CC1101 Rx
[D][mbus:022]: Processing C1 B frame
[V][mbus:026]: Frame: 3444372C347971233A168D209F11843F211F09E5F8CAA5DE0B9879D41726086FA1BA4597D4419A403816E22668B9124A32942F2FF1 (53) [with CRC]
[V][mbus:159]: Validating CRC for Block1 + Block2
[E][crc:035]:   calculated: 0xFF8E, read: 0x2FF1  !!!
[D][mbus:056]: Frame: 3244372C347971233A168D209F11843F211F09E5F8CAA5DE0B9879D41726086FA1BA4597D4419A403816E22668B9124A32942F (51) [without CRC]
[I][wmbus:097]: Using driver 'evo868' for ID [0x23717934] RSSI: -66 dBm LQI: 129 Frame: C1 B T: 3244372C347971233A168D209F11843F211F09E5F8CAA5DE0B9879D41726086FA1BA4597D4419A403816E22668B9124A32942F (51)
[V][utils:109]: (ELL)  CI: 8D  offset: 17
[V][utils:112]: (ELL)  IV: 372C347971233A162011843F21000000
[V][utils:115]: (ELL) KEY: keykeky(16)
[D][utils:124]: (ELL) AES_CTR decrypting: 1F09E5F8CAA5DE0B9879D41726086FA1BA4597D4419A403816E22668B9124A32942F (34)
[D][utils:152]: (ELL) AES_CTR  decrypted: FDC37905099CE6000000007CE203007C0506600006D00001320B11000079E703000F (34)
[V][wmbus:303]: Validating CRC for ELL payload
[I][crc:047]:   calculated: 0xC3FD, read: 0xC3FD
[E][wmbus:119]: Something was not OK during decrypting telegram for ID [0x23717934] 'evo868' key: 'keykey'
[E][wmbus:120]: T : 3244372C347971233A168D209F11843F211F09E5F8CAA5DE0B9879D41726086FA1BA4597D4419A403816E22668B9124A32942F (51)
[E][wmbus:121]: T': 3244372C347971233A168D209F11843F21FDC37905099CE6000000007CE203007C0506600006D00001320B11000079E703000F (51)

[evilmumi]

with this yaml:

## ------------------------------------------------------------------
## WMBUS METER D1 MINI + CC1101 for Diehl IZAR RC 868 I R4 PL
## HARDWARE: D1 MINI ESP8266 80MHz, 80KB RAM, 4MB Flash
##
## CC1101 TESTCASE FOR ALL WATERMETERS
## DO NOT USE THIS CONFIGURATION FOR PRODUCTION
##
##   1. uses esphome-components latest version from github
##   2. uses syslog component  (optional)
##      tail -f /var/log/syslog | grep "water-meter"
##
## This version shows data from the all watermeters.
## Use this for frist test to find your watermeterID.
##
## ------------------------------------------------------------------
substitutions:

  ## device settings
  device_name_short: "water-meter-esp32"
  device_description: "TEST: SzczepanLeon - find watermeters"
  projectname: "Diehl IZAR RC 868.Watermeter"
  appversion: "2.0.8"

  ## all watermeters wmid: "0", your watermeter: wmid: !secret watermeterId
  ## wmid: "0"
  wmid: "0x23717934"

  ## logger settings, use DEBUG or VERBOSE to see the telegram data
  log_level: "VERBOSE"    # In production mode use "WARN"
  log_wmbus: "VERBOSE"    # Loglevel for wmbus meters component
  log_baudrate: "115200"     # Disable uart logger messages log baudrate=0

## ----------------------------------------------------------------
## HARDWARE: WEMOS D1 MINI ESP8266 80MHz, 80KB RAM, 4MB Flash
## ----------------------------------------------------------------

# wemmos D1 Mini  = d1_mini
# D1 mit externer Antenne = d1_mini_pro
# esp01 mit 1MB Speicher = esp01_1m

esp32:
  board: az-delivery-devkit-v4
  framework:
    type: arduino  

preferences:
  flash_write_interval: 1min

## ---------------------------------------------------
## ESPHOME Configuration
## ---------------------------------------------------
esphome:
  name: ${device_name_short}
  comment: ${device_description}
  # Automatically add the mac address to the name
  # so you can use a single firmware for all devices
  name_add_mac_suffix: false
  project:
    name: ${projectname}
    version: ${appversion}
  build_path: ./build/${device_name_short}
  on_boot:
    - priority: -100.00
      then:
        - globals.set:
            id: boot_counter
            value: !lambda "return id(boot_counter)+=1;"
        - logger.log:
            level: WARN
            tag: "system"
            format: "BOOTMESSAGE:${device_name_short} API is connected, Device ready!"
        - component.update: bootcounter
    - priority: 800
      then:
        - logger.log:
            level: WARN
            tag: "system"
            format: "BOOTMESSAGE:${device_name_short} hardware initialization of vital components is executed "

  on_shutdown:
    priority: 700
    then:
      - logger.log:
          level: ERROR
          tag: "system"
          format: "BOOTMESSAGE:${device_name_short} is down!"

## ---------------------------------------------------
## External components
## ---------------------------------------------------
external_components:

  # uses the latest version from SzczepanLeon
  # https://github.com/SzczepanLeon/esphome-components
  # You can make ESPHome check the repository every time by setting this option to 0s

  - source: github://SzczepanLeon/esphome-components@pre_v3.0_noCrc
    refresh: 0d
    components: [ wmbus ]

  # uses the latest local version from SzczepanLeon
  # - source:
  #    type: local
  #    path: custom_components
  #  components: [wmbus]

  # use local component from
  # https://github.com/zdzichu6969/esphome-components
  - source:
      type: local
      path: custom_components
    components: [backup]

  # use local component from
  # enable this if you have a syslog server
  # https://github.com/TheStaticTurtle/esphome_syslog
  # - source:
  #     type: local
  #     path: custom_components
  #   components: [syslog]

## ---------------------------------------------------
## syslog service
## ---------------------------------------------------
# syslog:
#   ip_address: !secret syslog_server
#   port: !secret syslog_port
#   min_level: DEBUG
#   enable_logger: true

# ----------------------------------------------------------------
# Save your ESPHome device configuration in firmware and and
# recover it if you lost source files.
# ----------------------------------------------------------------
backup:
  auth:
    username: !secret web_username
    password: !secret web_password
  force_update: false

## ---------------------------------------------------
## Global variables
## ---------------------------------------------------
globals:
  - id: boot_counter
    type: int
    restore_value: yes
    initial_value: "0"
  - id: last_value
    type: float
    restore_value: yes
    initial_value: "0.00"

## ---------------------------------------------------
## WIFI Settings 3 wifis
## ---------------------------------------------------
wifi:
  networks:
    - ssid: ssid
      password: "pw"
      priority: 0
    - ssid: !secret ssid1_name
      password: !secret ssid1_pswd
      priority: 1
    - ssid: !secret ssid2_name
      password: !secret ssid2_pswd
      priority: 2
  domain: !secret domain

## ---------------------------------------------------
## mDNS Component
## ---------------------------------------------------
mdns:
  # if mDNS is disabled, they will no longer be able to automatically find your devices.
  disabled: false

# The captive portal component in ESPHome is a fallback mechanism for
# when connecting to the configured WiFi fails.
captive_portal:

## ---------------------------------------------------
## LOGGER COMPONENT
## ---------------------------------------------------
logger:
  id: appslogger
  level: ${log_level}
  baud_rate: ${log_baudrate}
  logs:
    wmbus: ${log_wmbus}
    wMBus-lib: ${log_wmbus}

## ---------------------------------------------------
## DEBUG COMPONENT
## ---------------------------------------------------
debug:
  update_interval: 5s

## ---------------------------------------------------
## OTA COMPONENT
## ---------------------------------------------------
ota:
  password: !secret ota_pswd
  safe_mode: false
  on_begin:
    then:
      - logger.log:
          format: "OTA Start"
          tag: "OTA"
          level: WARN
  on_progress:
    then:
      - logger.log:
          level: WARN
          tag: "OTA"
          format: "OTA progress %0.1f%%"
          args: ["x"]
  on_end:
    then:
      - logger.log:
          format: "OTA End"
          tag: "OTA"
          level: WARN
  on_error:
    then:
      - logger.log:
          format: "OTA update error %d"
          tag: "OTA"
          level: ERROR
          args: ["x"]

## ---------------------------------------------------
## COMPONENT WEBSERVER
## ---------------------------------------------------
web_server:
  port: 80
  version: 2
  js_url: !secret webserver_jsurl

## ---------------------------------------------------
## Home Assistant API COMPONENT
## ---------------------------------------------------
api:
  id: espapiwm2_d1
  port: 6053
  reboot_timeout: 0s

## ---------------------------------------------------
## SNTP Time server
## ---------------------------------------------------
time:
  - platform: sntp
    id: time_sntp
    timezone: Europe/Berlin
    servers:
      - 0.at.pool.ntp.org
      - 0.pool.ntp.org
      - 1.pool.ntp.org
    on_time_sync:
      # Components should trigger on_time_sync when they update the system clock.
      then:
        - if:
            condition:
              lambda: 'return id(device_lastBoot_time).state == "";'
            then:
              - text_sensor.template.publish:
                  id: device_lastBoot_time
                  state: !lambda return id(time_sntp).now().strftime("%Y-%m-%dT%H:%M:%S %Z");
        - logger.log:
            level: WARN
            tag: "system"
            format: "Synchronized sntp clock"

 ## ------------------------------------------------------------------
 ##           WMBUS CC1101 --> ESP32 az-delivery-devkit-v4
 ## ------------------------------------------------------------------
 ##
 ##
 ##                                                               o 1 (3.3V)
 ##                                                               |
 ##   ╭――x――x――x――x――x――x――x――x――x――x――x――x――x――x――x――x――x――x――x――o―╮
 ##   |                                                             |
 ## - | 5v               az-delivery-devkit-v4                      | -- ANT
 ##   |                                                             |
 ##   |                          16 17 5  18 19               23    |
 ##   ╰――x――x――x――x――x――x――x――x――o――x――o――o――o――o――o――o――o――o――o――o―╯
 ##                              |  |  |  |  |                 |   |
 ##                              o  |  |  o  |                 |   ╰-o - 2 (GND)
 ##                              7  o  |  4  o                 o
 ##                            GDO0 6  | CLK 5                 3
 ##                               GD02 o    MISO              M0SI
 ##                                    8
 ##                                   CSN
 ##
 ## ------------------------------------------------------------------
wmbus:
  mosi_pin: GPIO23  ## SI:   braun   3: MOSI Attached to Hardware SPI controller MOSI SPI Interface
  miso_pin: GPIO19  ## SO:   grün    5: MISO Attached to Hardware SPI controller MISO SPI Interface
  clk_pin: GPIO18   ## SCLK: violett 4: SCK  Attached to Hardware SPI controller CLK
  cs_pin: GPIO05    ## CSN:  orange  8: CSN  Attached to Hardware SPI controller
  gdo0_pin: GPIO16  ## GD00: gelb    7: RX Clock output. High Impedance !
  gdo2_pin: GPIO17  ## GD02: weiss   6: TX FIFO status signals. High Impedance !

 # https://github.com/LSatan/SmartRC-CC1101-Driver-Lib/blob/master/img/Esp32_CC1101.png
  # log_unknown (Optional): Show telegrams from not configured meters in log. Defaults to False
  log_unknown: True

## ---------------------------------------------------
## SENSORS
## ---------------------------------------------------
sensor:
  - platform: wmbus
    meter_id: $wmid
    mode: T1C1
    type: evo868
    key: "keykeykey"
    total_water_m3:
      name: "test meter"

  # The debug component can be used to debug problems with ESPHome.
  # At startup, it prints a bunch of useful information like reset reason,
  # free heap size, ESPHome version and so on.
  - platform: debug

    #  Reports the free heap size in bytes.
    free:
      name: "Heap Free"
      entity_category: "diagnostic"

    # Reports the fragmentation metric of the heap (0% is clean, more than ~50% is not harmless).

    # Reports the largest contiguous free RAM block on the heap in bytes.
    block:
      name: "Heap Max Block"
      entity_category: "diagnostic"

    # Reports the longest time between successive iterations of the main loop.
    loop_time:
      name: "Application Loop Time"
      entity_category: "diagnostic"

  # device boot counter
  - platform: template
    name: Boot counter
    id: bootcounter
    accuracy_decimals: 0
    state_class: "measurement"
    entity_category: "diagnostic"
    lambda: |-
      return (id(boot_counter));

## ---------------------------------------------------
## SWITCHES
## ---------------------------------------------------
switch:
  # reset boot counter value
  - platform: template
    name: Boot Counter reset
    turn_on_action:
      then:
        - lambda: |-
            id(boot_counter) = 0;
            id(bootcounter).publish_state(id(boot_counter));
        - logger.log:
            level: WARN
            tag: "system"
            format: "${device_name_short} reset boot counter o.k!"
        - component.update: bootcounter

  # restart device
  - platform: restart
    name: "Restart device"
    id: restart_switch

  # save device boot (develop only)
  - platform: safe_mode
    name: "Restart (Safe Mode)"

  # reset the device to factory reset (develop only)
  - platform: factory_reset
    icon: mdi:lock-reset
    name: Restart factory default

## ---------------------------------------------------
## TEXT SENSORS
## ---------------------------------------------------
text_sensor:
  - platform: debug
    # Reports the device information:
    device:
      name: "Device Info"
      entity_category: "diagnostic"
    # Reports the last reboot reason in a human-readable form.
    reset_reason:
      name: "Reset Reason"
      entity_category: "diagnostic"

  # Last boot timestamp
  - platform: template
    name: "Last Boot timestamp"
    disabled_by_default: true
    id: device_lastBoot_time
    icon: mdi:clock-start`

from here https://github.com/zibous/ha-watermeter/tree/master

[SzczepanLeon]

Strange ;-)

[D][rxLoop:159]: Have 53 bytes from CC1101 Rx
[D][mbus:022]: Processing C1 B frame
[V][mbus:026]: Frame: 3444372C347971233A168D209D03843F21A6C0F65FA962803F1FF7D3F89A54E701D33740F84D5C09DB2B6D486D49C4C626CAFBFBF1 (53) [with CRC]
[V][mbus:159]: Validating CRC for Block1 + Block2
[E][crc:035]:   calculated: 0x31A6, read: 0xFBF1  !!!
[D][mbus:056]: Frame: 3244372C347971233A168D209D03843F21A6C0F65FA962803F1FF7D3F89A54E701D33740F84D5C09DB2B6D486D49C4C626CAFB (51) [without CRC]
[I][wmbus:097]: Using driver 'evo868' for ID [0x23717934] RSSI: -65 dBm LQI: 132 Frame: C1 B T: 3244372C347971233A168D209D03843F21A6C0F65FA962803F1FF7D3F89A54E701D33740F84D5C09DB2B6D486D49C4C626CAFB (51)
[V][utils:109]: (ELL)  CI: 8D  offset: 17
[V][utils:112]: (ELL)  IV: 372C347971233A162003843F21000000
[V][utils:115]: (ELL) KEY: keykeykey(16)
[D][utils:124]: (ELL) AES_CTR decrypting: A6C0F65FA962803F1FF7D3F89A54E701D33740F84D5C09DB2B6D486D49C4C626CAFB (34)
[D][utils:152]: (ELL) AES_CTR  decrypted: FDC37905099CE6000000007CE203007C0506600006D00001320B11000079E703000F (34)
[V][wmbus:303]: Validating CRC for ELL payload
[I][crc:047]:   calculated: 0xC3FD, read: 0xC3FD
[E][wmbus:119]: Something was not OK during decrypting telegram for ID [0x23717934] 'evo868' key: 'kexkkeykey'
[E][wmbus:120]: T : 3244372C347971233A168D209D03843F21A6C0F65FA962803F1FF7D3F89A54E701D33740F84D5C09DB2B6D486D49C4C626CAFB (51)
[E][wmbus:121]: T': 3244372C347971233A168D209D03843F21FDC37905099CE6000000007CE203007C0506600006D00001320B11000079E703000F (51)`

Frames from "other sw" have frame CRC OK, and for frames from my sw frame CRC is not OK:

[E][crc:035]:   calculated: 0x31A6, read: 0xFBF1  !!!

But CRC for decoded payload is OK:

[V][wmbus:303]: Validating CRC for ELL payload
[I][crc:047]:   calculated: 0xC3FD, read: 0xC3FD

also for that frame/payload total value should be 255.865 -- right?

btw Is it normal that I can't get value from frame via wmbusmeters page. it seems that frames are in different format that implemented driver there.

[evilmumi]

last value I ve got was 255.773 so it could be the right value you ve read out.

guy from https://github.com/pthalin/esp32-multical21 wrote me:

So perhaps there is mystery :/

[evilmumi]

now i got:

[D][mbus:022]: Processing C1 B frame
[V][mbus:026]: Frame: 4944372C347971233A168D206CC28B3F21A687CAA1488C8F6694BE3E87377D3A09C57F21DA53E9886A9CC48CD32314A510E43E0688EC3DC27FD095512EBC6114EE2D4C2125B11C22223A (74) [with CRC]
[V][mbus:159]: Validating CRC for Block1 + Block2
[E][crc:035]:   calculated: 0xDFFF, read: 0x223A  !!!
[D][mbus:056]: Frame: 4744372C347971233A168D206CC28B3F21A687CAA1488C8F6694BE3E87377D3A09C57F21DA53E9886A9CC48CD32314A510E43E0688EC3DC27FD095512EBC6114EE2D4C2125B11C22 (72) [without CRC]
[I][wmbus:097]: Using driver 'evo868' for ID [0x23717934] RSSI: -86 dBm LQI: 130 Frame: C1 B T: 4744372C347971233A168D206CC28B3F21A687CAA1488C8F6694BE3E87377D3A09C57F21DA53E9886A9CC48CD32314A510E43E0688EC3DC27FD095512EBC6114EE2D4C2125B11C22 (72)

https://wmbusmeters.org/analyze/4744372C347971233A168D206CC28B3F21A687CAA1488C8F6694BE3E87377D3A09C57F21DA53E9886A9CC48CD32314A510E43E0688EC3DC27FD095512EBC6114EE2D4C2125B11C22

Auto driver  : flowiq2200
Best driver  : flowiq2200 20/27
Using driver : flowiq2200 00/00
000   : 47 length (71 bytes)
001   : 44 dll-c (from meter SND_NR)
002   : 372c dll-mfct (KAW)
004   : 34797123 dll-id (23717934)
008   : 3a dll-version
009   : 16 dll-type (Cold water meter)
010   : 8d ell-ci-field (ELL: Extended Link Layer II (8 Byte))
011   : 20 ell-cc (slow_resp sync)
012   : 6c ell-acc
013   : c28b3f21 sn (AES_CTR)
017   : 86e2 payload crc (calculated 86e2 OK)
019   : 78 tpl-ci-field (EN 13757-3 Application Layer (no tplh))
020   : 04 dif (32 Bit Integer/Binary Instantaneous value)
021   : FF vif (Manufacturer specific)
022   : 23 vife (?)
023 C!: 00000000 ("status":"OK")
027   : 44 dif (32 Bit Integer/Binary Instantaneous value storagenr=1)
028   : 13 vif (Volume l)
029 C!: 7CE20300 ("target_m3":254.588)
033   : 52 dif (16 Bit Integer/Binary Maximum value storagenr=1)
034   : 3B vif (Volume flow l/h)
035 C!: 7C05 ("max_flow_m3h":1.404)
037   : 06 dif (48 Bit Integer/Binary Instantaneous value)
038   : FF vif (Manufacturer specific)
039   : 1B vife (?)
040 C?: 06600006D000
046   : 42 dif (16 Bit Integer/Binary Instantaneous value storagenr=1)
047   : 6C vif (Date type G)
048 C!: 0132 ("target_date":"2024-02-01")
050   : 61 dif (8 Bit Integer/Binary Minimum value storagenr=1)
051   : 67 vif (External temperature °C)
052 C!: 0B ("min_external_temperature_c":11)
053   : 51 dif (8 Bit Integer/Binary Maximum value storagenr=1)
054   : 67 vif (External temperature °C)
055 C!: 11 ("max_external_temperature_c":17)
056   : 02 dif (16 Bit Integer/Binary Instantaneous value)
057   : 3B vif (Volume flow l/h)
058 C!: 0000 ("flow_m3h":0)
060   : 04 dif (32 Bit Integer/Binary Instantaneous value)
061   : 13 vif (Volume l)
062 C!: B6E70300 ("total_m3":255.926)
066   : 81 dif (8 Bit Integer/Binary Instantaneous value)
067   : 01 dife (subunit=0 tariff=0 storagenr=2)
068   : E7 vif (External temperature °C)
069   : FF combinable vif (MfctSpecific)
070   : 0F combinable extension vife
071 C?: 0F

{
    "media":"cold water",
    "meter":"flowiq2200",
    "name":"",
    "id":"23717934",
    "flow_m3h":0,
    "max_external_temperature_c":17,
    "max_flow_m3h":1.404,
    "min_external_temperature_c":11,
    "target_m3":254.588,
    "total_m3":255.926,
    "status":"OK",
    "target_date":"2024-02-01",
    "timestamp":"2024-02-05T20:04:57Z"
}

[evilmumi]

so long(74) are "sometimes" working - short (53) not my conclusion but only without CRC

[D][rxLoop:159]: Have 74 bytes from CC1101 Rx
[D][mbus:022]: Processing C1 B frame
[V][mbus:026]: Frame: 4944372C347971233A168D207C038C3F2144DA6679CD7F37A3528D4B6E82A1081D130A8B36CF6C17BFFC72AFE93287C46E7D34077534024AD808E8FE1F115E3557A9B1F2F2B4A369693A (74) [with CRC]
[V][mbus:159]: Validating CRC for Block1 + Block2
[E][crc:035]:   calculated: 0x2EB2, read: 0x693A  !!!
[D][mbus:056]: Frame: 4744372C347971233A168D207C038C3F2144DA6679CD7F37A3528D4B6E82A1081D130A8B36CF6C17BFFC72AFE93287C46E7D34077534024AD808E8FE1F115E3557A9B1F2F2B4A369 (72) [without CRC]
[I][wmbus:097]: Using driver 'evo868' for ID [0x23717934] RSSI: -85 dBm LQI: 129 Frame: C1 B T: 4744372C347971233A168D207C038C3F2144DA6679CD7F37A3528D4B6E82A1081D130A8B36CF6C17BFFC72AFE93287C46E7D34077534024AD808E8FE1F115E3557A9B1F2F2B4A369 (72)

this was not working in analyzer:

[D][rxLoop:159]: Have 74 bytes from CC1101 Rx
[D][mbus:022]: Processing C1 B frame
[V][mbus:026]: Frame: 4944372C377971233A168D2097E18C3F219F69C102F2BE6688F01BDE6F3E73C1BAF853D50DAB986E2C2273C1E5821C955EE8CFCC6B6CE707F775F08416D4B480877778FB8A79BFA6A63A (74) [with CRC]
[V][mbus:159]: Validating CRC for Block1 + Block2
[E][crc:035]:   calculated: 0x187F, read: 0xA63A  !!!
[D][mbus:056]: Frame: 4744372C377971233A168D2097E18C3F219F69C102F2BE6688F01BDE6F3E73C1BAF853D50DAB986E2C2273C1E5821C955EE8CFCC6B6CE707F775F08416D4B480877778FB8A79BFA6 (72) [without CRC]
[D][wmbus:202]: Meter ID [0x23717937] RSSI: -91 dBm LQI: 135 Frame: C1 B not found in configuration T: 4744372C377971233A168D2097E18C3F219F69C102F2BE6688F01BDE6F3E73C1BAF853D50DAB986E2C2273C1E5821C955EE8CFCC6B6CE707F775F08416D4B480877778FB8A79BFA6 (72)

[SzczepanLeon]

Short frame:

000   : 32 length (50 bytes)
001   : 44 dll-c (from meter SND_NR)
002   : 372c dll-mfct (KAW)
004   : 34797123 dll-id (23717934)
008   : 3a dll-version
009   : 16 dll-type (Cold water meter)
010   : 8d ell-ci-field (ELL: Extended Link Layer II (8 Byte))
011   : 20 ell-cc (slow_resp sync)
012   : 9d ell-acc
013   : 03843f21 sn (AES_CTR)
017   : fdc3 payload crc (calculated fdc3 OK)
019   : 79 tpl-ci-field (EN 13757-3 Application Layer with Compact frame (no tplh))

Long frame:

000   : 47 length (71 bytes)
001   : 44 dll-c (from meter SND_NR)
002   : 372c dll-mfct (KAW)
004   : 34797123 dll-id (23717934)
008   : 3a dll-version
009   : 16 dll-type (Cold water meter)
010   : 8d ell-ci-field (ELL: Extended Link Layer II (8 Byte))
011   : 20 ell-cc (slow_resp sync)
012   : 6c ell-acc
013   : c28b3f21 sn (AES_CTR)
017   : 86e2 payload crc (calculated 86e2 OK)
019   : 78 tpl-ci-field (EN 13757-3 Application Layer (no tplh))

What you mean by sometimes? Sometimes second CRC (from ELL) is correct?

[V][wmbus:303]: Validating CRC for ELL payload
[I][crc:047]:   calculated: 0xC3FD, read: 0xC3FD

So long frame can be decoded as evo868 and short one is in proprietary (maybe) format.

[evilmumi]

sometimes even long is not decryptable: 4744372c347971233a168d2094708c3f01316cBB1860B223a35ae42eB5c8289f67a665BB3508c79fBce99ddc4a9c7da3698d18328254d994e5c6B15c6486d7dc854de934Ba5e618d

AND value is not getting into homeassisant perhaps - why?

[D][rxLoop:159]: Have 74 bytes from CC1101 Rx
[D][mbus:022]: Processing C1 B frame
[V][mbus:026]: Frame: 4944372C347971233A168D20D4808D3F21EB3F13F7A008346D102F4DE1CD3165BBF90D3BCCFBD96DF5D542F3FA22A2748786C3EFB9C15D3674B1A2CB70473364D84519C301E4591E1E3A (74) [with CRC]
[V][mbus:159]: Validating CRC for Block1 + Block2
[E][crc:035]:   calculated: 0x57B4, read: 0x1E3A  !!!
[D][mbus:056]: Frame: 4744372C347971233A168D20D4808D3F21EB3F13F7A008346D102F4DE1CD3165BBF90D3BCCFBD96DF5D542F3FA22A2748786C3EFB9C15D3674B1A2CB70473364D84519C301E4591E (72) [without CRC]
[I][wmbus:097]: Using driver 'evo868' for ID [0x23717934] RSSI: -87 dBm LQI: 131 Frame: C1 B T: 4744372C347971233A168D20D4808D3F21EB3F13F7A008346D102F4DE1CD3165BBF90D3BCCFBD96DF5D542F3FA22A2748786C3EFB9C15D3674B1A2CB70473364D84519C301E4591E (72)
[V][utils:109]: (ELL)  CI: 8D  offset: 17
[V][utils:112]: (ELL)  IV: 372C347971233A1620808D3F21000000

Auto driver : flowiq2200 Best driver : flowiq2200 20/27 Using driver : flowiq2200 00/00 000 : 47 length (71 bytes) 001 : 44 dll-c (from meter SND_NR) 002 : 372c dll-mfct (KAW) 004 : 34797123 dll-id (23717934) 008 : 3a dll-version 009 : 16 dll-type (Cold water meter) 010 : 8d ell-ci-field (ELL: Extended Link Layer II (8 Byte)) 011 : 20 ell-cc (slow_resp sync) 012 : d4 ell-acc 013 : 808d3f21 sn (AES_CTR) 017 : 86e2 payload crc (calculated 86e2 OK) 019 : 78 tpl-ci-field (EN 13757-3 Application Layer (no tplh)) 020 : 04 dif (32 Bit Integer/Binary Instantaneous value) 021 : FF vif (Manufacturer specific) 022 : 23 vife (?) 023 C!: 00000000 ("status":"OK") 027 : 44 dif (32 Bit Integer/Binary Instantaneous value storagenr=1) 028 : 13 vif (Volume l) 029 C!: 7CE20300 ("target_m3":254.588) 033 : 52 dif (16 Bit Integer/Binary Maximum value storagenr=1) 034 : 3B vif (Volume flow l/h) 035 C!: 7C05 ("max_flow_m3h":1.404) 037 : 06 dif (48 Bit Integer/Binary Instantaneous value) 038 : FF vif (Manufacturer specific) 039 : 1B vife (?) 040 C?: 06600006D000 046 : 42 dif (16 Bit Integer/Binary Instantaneous value storagenr=1) 047 : 6C vif (Date type G) 048 C!: 0132 ("target_date":"2024-02-01") 050 : 61 dif (8 Bit Integer/Binary Minimum value storagenr=1) 051 : 67 vif (External temperature °C) 052 C!: 0B ("min_external_temperature_c":11) 053 : 51 dif (8 Bit Integer/Binary Maximum value storagenr=1) 054 : 67 vif (External temperature °C) 055 C!: 11 ("max_external_temperature_c":17) 056 : 02 dif (16 Bit Integer/Binary Instantaneous value) 057 : 3B vif (Volume flow l/h) 058 C!: 0000 ("flow_m3h":0) 060 : 04 dif (32 Bit Integer/Binary Instantaneous value) 061 : 13 vif (Volume l) 062 C!: B6E70300 ("total_m3":255.926) 066 : 81 dif (8 Bit Integer/Binary Instantaneous value) 067 : 01 dife (subunit=0 tariff=0 storagenr=2) 068 : E7 vif (External temperature °C) 069 : FF combinable vif (MfctSpecific) 070 : 0F combinable extension vife 071 C?: 0F

{ "media":"cold water", "meter":"flowiq2200", "name":"", "id":"23717934", "flow_m3h":0, "max_external_temperature_c":17, "max_flow_m3h":1.404, "min_external_temperature_c":11, "target_m3":254.588, "total_m3":255.926, "status":"OK", "target_date":"2024-02-01", "timestamp":"2024-02-05T20:32:16Z" }

can you explain your question with CRC and ELL :)

[SzczepanLeon]

can you explain your question with CRC and ELL :)

You mentioned that sometimes it is OK. So I'm curious it is related to correct/wrong CRC in ELL calculation.

Anyway, please try next version. It is with small changes how I count bytes to receive in CC1101.

[evilmumi]

looks like a good thing, or?

[07:20:18][E][rxLoop:157]: Length problem: req(76) != rx(78)
[07:20:18][D][rxLoop:159]: Have 78 bytes from CC1101 Rx
[07:20:18][D][mbus:024]: Processing C1 B frame
[07:20:18][V][mbus:028]: Frame: 4944372C347971233A168D207450B23F215977E7024D5C84E3F522DAC84830F762589A46414BAA83F6C0C82A334FF4C9EC07A1D4AAFD6ADF88316D460C92903FD8221DEDFE70D55F7D1C1C8D (76) [with CRC]
[07:20:18][V][mbus:161]: Validating CRC for Block1 + Block2
[07:20:18][I][crc:031]:   calculated: 0x7D1C, read: 0x7D1C
[07:20:18][D][mbus:058]: Frame: 4744372C347971233A168D207450B23F215977E7024D5C84E3F522DAC84830F762589A46414BAA83F6C0C82A334FF4C9EC07A1D4AAFD6ADF88316D460C92903FD8221DEDFE70D55F (72) [without CRC]
[07:20:18][I][wmbus:097]: Using driver 'evo868' for ID [0x23717934] RSSI: -69 dBm LQI: 130 Frame: C1 B T: 4744372C347971233A168D207450B23F215977E7024D5C84E3F522DAC84830F762589A46414BAA83F6C0C82A334FF4C9EC07A1D4AAFD6ADF88316D460C92903FD8221DEDFE70D55F (72)
[07:20:18][V][utils:109]: (ELL)  CI: 8D  offset: 17
[07:20:18][V][utils:112]: (ELL)  IV: 372C347971233A162050B23F21000000
[07:20:18][V][utils:115]: (ELL) KEY: keykeykkey(16)
[07:20:18][D][utils:124]: (ELL) AES_CTR decrypting: 5977E7024D5C84E3F522DAC84830F762589A46414BAA83F6C0C82A334FF4C9EC07A1D4AAFD6ADF88316D460C92903FD8221DEDFE70D55F (55)
[07:20:18][D][utils:152]: (ELL) AES_CTR  decrypted: 23907804FF230000000044137CE20300523B7C0506FF1B06700006D000426C013261670B516711023B00000413DFE703008101E7FF0F0E (55)
[07:20:18][V][wmbus:303]: Validating CRC for ELL payload
[07:20:18][I][crc:047]:   calculated: 0x9023, read: 0x9023
[07:20:19][D][wmbus:104]: Decrypted T : 4744372C347971233A168D207450B23F2123907804FF230000000044137CE20300523B7C0506FF1B06700006D000426C013261670B516711023B00000413DFE703008101E7FF0F0E (72)
[07:20:19][I][wmbus:743]: Reset current value to: 0.000, Waterdisplay value: 255.967, last value: 0.000
[07:20:19][D][wmbus:757]: Diff millisecond is: 29824
[07:20:19][D][wmbus:535]: cc1101 state message: Warte auf Daten, error code: 1
[07:20:30][D][wmbus:535]: cc1101 state message: Warte auf Daten, error code: 1

but not everytime good:

[07:23:27][E][rxLoop:157]: Length problem: req(76) != rx(78)
[07:23:27][D][rxLoop:159]: Have 78 bytes from CC1101 Rx
[07:23:27][D][mbus:024]: Processing C1 B frame
[07:23:27][V][mbus:028]: Frame: 4944372C427971233A168D20E263B23F21EA2966F70B2F338C3A3EEBC25D68A79FF422BBF44DC5DF7F9F51C5BA60C6F18FE2466FA130AFBECF9779647776172F0FC7CD56392F4DC108EFEF8D (76) [with CRC]
[07:23:27][V][mbus:161]: Validating CRC for Block1 + Block2
[07:23:27][E][crc:035]:   calculated: 0xBF99, read: 0x08EF  !!!
[07:23:27][D][mbus:058]: Frame: 4744372C427971233A168D20E263B23F21EA2966F70B2F338C3A3EEBC25D68A79FF422BBF44DC5DF7F9F51C5BA60C6F18FE2466FA130AFBECF9779647776172F0FC7CD56392F4DC1 (72) [without CRC]
[07:23:30][D][wmbus:535]: cc1101 state message: Warte auf Daten, error code: 1

this is also not analyzable via webpage

but more and more good are coming:

telegram=|4744372C347971233A168D208491B23F21239078_04FF230000000044137CE20300523B7C0506FF1B06700006D000426C013261670B516711023B00000413DFE703008101E7FF0F0E|

Auto driver : flowiq2200 Best driver : flowiq2200 20/27 Using driver : flowiq2200 00/00 000 : 47 length (71 bytes) 001 : 44 dll-c (from meter SND_NR) 002 : 372c dll-mfct (KAW) 004 : 34797123 dll-id (23717934) 008 : 3a dll-version 009 : 16 dll-type (Cold water meter) 010 : 8d ell-ci-field (ELL: Extended Link Layer II (8 Byte)) 011 : 20 ell-cc (slow_resp sync) 012 : 84 ell-acc 013 : 91b23f21 sn (AES_CTR) 017 : 2390 payload crc (calculated 2390 OK) 019 : 78 tpl-ci-field (EN 13757-3 Application Layer (no tplh)) 020 : 04 dif (32 Bit Integer/Binary Instantaneous value) 021 : FF vif (Manufacturer specific) 022 : 23 vife (?) 023 C!: 00000000 ("status":"OK") 027 : 44 dif (32 Bit Integer/Binary Instantaneous value storagenr=1) 028 : 13 vif (Volume l) 029 C!: 7CE20300 ("target_m3":254.588) 033 : 52 dif (16 Bit Integer/Binary Maximum value storagenr=1) 034 : 3B vif (Volume flow l/h) 035 C!: 7C05 ("max_flow_m3h":1.404) 037 : 06 dif (48 Bit Integer/Binary Instantaneous value) 038 : FF vif (Manufacturer specific) 039 : 1B vife (?) 040 C?: 06700006D000 046 : 42 dif (16 Bit Integer/Binary Instantaneous value storagenr=1) 047 : 6C vif (Date type G) 048 C!: 0132 ("target_date":"2024-02-01") 050 : 61 dif (8 Bit Integer/Binary Minimum value storagenr=1) 051 : 67 vif (External temperature °C) 052 C!: 0B ("min_external_temperature_c":11) 053 : 51 dif (8 Bit Integer/Binary Maximum value storagenr=1) 054 : 67 vif (External temperature °C) 055 C!: 11 ("max_external_temperature_c":17) 056 : 02 dif (16 Bit Integer/Binary Instantaneous value) 057 : 3B vif (Volume flow l/h) 058 C!: 0000 ("flow_m3h":0) 060 : 04 dif (32 Bit Integer/Binary Instantaneous value) 061 : 13 vif (Volume l) 062 C!: DFE70300 ("total_m3":255.967) 066 : 81 dif (8 Bit Integer/Binary Instantaneous value) 067 : 01 dife (subunit=0 tariff=0 storagenr=2) 068 : E7 vif (External temperature °C) 069 : FF combinable vif (MfctSpecific) 070 : 0F combinable extension vife 071 C?: 0E

{ "media":"cold water", "meter":"flowiq2200", "name":"", "id":"23717934", "flow_m3h":0, "max_external_temperature_c":17, "max_flow_m3h":1.404, "min_external_temperature_c":11, "target_m3":254.588, "total_m3":255.967, "status":"OK", "target_date":"2024-02-01", "timestamp":"2024-02-06T06:25:33Z" }

[SzczepanLeon]

Yes, I see progres.

btw What fields from telegram do you need to have?

For sure total water m3.

[evilmumi]

Great. Thanks for your doing!

fields. i am not sure whats possible. possible fields are these listed below? i think this is last value of last minute in last month? target_m3 total_m3 -> yes status is the leckage? would be good i dont think this is needed for me: "flow_m3h":0, "max_external_temperature_c":17, "max_flow_m3h":1.404, "min_external_temperature_c":11,

i am not sure whats possible

https://documentation.kamstrup.com/docs/flowIQ_2200_EU/en-GB/Data_sheet/CONT07BEC5F79AF846B2AD153D44DEEBA501/

[SzczepanLeon]

Next version, please try:

external_components:
  - source: github://SzczepanLeon/esphome-components@flowiq
    refresh: 0d
    components: [ wmbus ]

and in sensor section (added flowiq2200 driver with total and target water -- status will be added soon):

sensor:
  - platform: wmbus
    meter_id: $wmid
    mode: T1C1
    type: flowiq2200
    key: "keykeykey"
    total_water_m3:
      name: "total water"
    target_water_m3:
      name: "target water"

Both long and short frames should be decoded. Both CRCs should be OK.

Please collect couple logs for me.

[evilmumi]

i will let it run some time. first impression: 2.080.375,750 m³ is more than before 255.967 and WRONG :) And cant find long like >70 frame values....

[SzczepanLeon]

Please add logs.

For every data you should see at least something like:

[07:20:18][D][rxLoop:159]: Have 76 bytes from CC1101 Rx
[07:20:18][D][mbus:024]: Processing C1 B frame
[07:20:18][V][mbus:028]: Frame: 4944_some_sample_frameFF4C9EC07A1D4AAFD6ADF88316D460C92903FD8221DEDFE70D55F7D1C1C8D (74) [with CRC]
[07:20:18][V][mbus:161]: Validating CRC for Block1 + Block2

Maybe meter transmits different frames in different time frame?

[evilmumi]

here you are logs_testtestesp32_run.txt

[SzczepanLeon]

Thanks for logs. As you can see CRC check works. Next version is available - as usual, please test it, collect logs.

Please also add that target_water_m3, status, volume_flow_lh and max_flow_lh to YAML. All of them should be available both in short and long frames:

sensor:
  - platform: wmbus
    meter_id: $wmid
    mode: T1C1
    type: flowiq2200
    key: "keykeykey"
    total_water_m3:
      name: "total water"
    target_water_m3:
      name: "target water"
    status:
      name: "status"
    volume_flow_lh:
      name: "flow l"
    max_flow_lh:
      name: "max flow l"

[evilmumi]

Fast answer before logs. looks nice. status is 0 not ok as analyzer says:

{
    "media":"cold water",
    "meter":"flowiq2200",
    "name":"",
    "id":"23717934",
    "flow_m3h":0,
    "max_external_temperature_c":17,
    "max_flow_m3h":1.404,
    "min_external_temperature_c":11,
    "target_m3":254.588,
    "total_m3":256.008,
    "status":"OK",
    "target_date":"2024-02-01",
    "timestamp":"2024-02-06T14:16:04Z"
}

[SzczepanLeon]

Status will be as number. Just like for izar.

[evilmumi]

I was only wondering why different as Webpage - ok for me! Don't know izar^^ logs_testtestesp32_run (1).txt

[SzczepanLeon]

So you can see all:

    total_water_m3:
      name: "total water"
    target_water_m3:
      name: "target water"
    status:
      name: "status"
    volume_flow_lh:
      name: "flow l"
    max_flow_lh:
      name: "max flow l"

in HomeAssistant and values are correct ??

Lets also wait for long frames ... but meantime next version available (added more detailed logs and small fix).

[evilmumi]

as total

still some stuff were calculated != read some long should be and one in here logs_testtestesp32_logs.txt

[SzczepanLeon]

Great. Next version is available (i think it is last one before merge to master). This time fixed long frame. Again please collect at least one short and one long frame.

[evilmumi]

again again

logs_testtestesp32_run (2).txt HA looks good

[SzczepanLeon]

Thanks for cooperation. Everything looks OK.

[16:02:48][D][rxLoop:153]: Have 55 bytes from CC1101 Rx
[16:02:48][D][mbus:024]: Processing C1 B frame
[16:02:48][V][mbus:028]: Frame: 3444372C347971233A168D201BF2D23F218EE9E95336AEC6AD7920E5E1AEED64E39CD43367E84124E47754CC634889CC9B7558538F (53) [with CRC]
[16:02:48][V][mbus:161]: Validating CRC for Block1 + Block2
[16:02:48][I][crc:031]:   calculated: 0x538F, read: 0x538F
[16:02:48][D][mbus:058]: Frame: 3244372C347971233A168D201BF2D23F218EE9E95336AEC6AD7920E5E1AEED64E39CD43367E84124E47754CC634889CC9B7558 (51) [without CRC]
[16:02:48][I][wmbus:097]: Using driver 'flowiq2200' for ID [0x23717934] RSSI: -89 dBm LQI: 132 Frame: C1 B T: 3244372C347971233A168D201BF2D23F218EE9E95336AEC6AD7920E5E1AEED64E39CD43367E84124E47754CC634889CC9B7558 (51)
[16:02:48][V][utils:109]: (ELL)  CI: 8D  offset: 17
[16:02:48][V][utils:112]: (ELL)  IV: 372C347971233A1620F2D23F21000000
[16:02:48][V][utils:115]: (ELL) KEY: KEYKEYKEY (16)
[16:02:48][D][utils:124]: (ELL) AES_CTR decrypting: 8EE9E95336AEC6AD7920E5E1AEED64E39CD43367E84124E47754CC634889CC9B7558 (34)
[16:02:48][D][utils:152]: (ELL) AES_CTR  decrypted: 573379050929EF000000007CE203007C0506700006D00001320B1100000FE803000E (34)
[16:02:48][V][wmbus:303]: Validating CRC for ELL payload
[16:02:48][I][crc:046]:   calculated: 0x3357, read: 0x3357
[16:02:48][D][wmbus:104]: Decrypted T : 3244372C347971233A168D201BF2D23F21573379050929EF000000007CE203007C0506700006D00001320B1100000FE803000E (51)
[16:02:48][V][wmbus:135]: Publishing 'max_flow_lh' = 1404.0000
[16:02:48][V][wmbus:135]: Publishing 'status' = 0.0000
[16:02:48][V][wmbus:135]: Publishing 'target_water_m3' = 254.5880
[16:02:48][V][wmbus:135]: Publishing 'total_water_m3' = 256.0150
[16:02:48][V][wmbus:135]: Publishing 'volume_flow_lh' = 0.0000

[16:03:04][D][rxLoop:153]: Have 76 bytes from CC1101 Rx
[16:03:04][D][mbus:024]: Processing C1 B frame
[16:03:04][V][mbus:028]: Frame: 4944372C347971233A168D201CF3D23F2174F9E8313947B90958E70AF878FCDC52483E86755EE90DC757FE0376F9FF34FFE8259A8DAB9CCC3A49158DB2C9D57D17BBD81EC3B06212EC99 (74) [with CRC]
[16:03:04][V][mbus:161]: Validating CRC for Block1 + Block2
[16:03:04][I][crc:031]:   calculated: 0xEC99, read: 0xEC99
[16:03:04][D][mbus:058]: Frame: 4744372C347971233A168D201CF3D23F2174F9E8313947B90958E70AF878FCDC52483E86755EE90DC757FE0376F9FF34FFE8259A8DAB9CCC3A49158DB2C9D57D17BBD81EC3B06212 (72) [without CRC]
[16:03:04][I][wmbus:097]: Using driver 'flowiq2200' for ID [0x23717934] RSSI: -89 dBm LQI: 130 Frame: C1 B T: 4744372C347971233A168D201CF3D23F2174F9E8313947B90958E70AF878FCDC52483E86755EE90DC757FE0376F9FF34FFE8259A8DAB9CCC3A49158DB2C9D57D17BBD81EC3B06212 (72)
[16:03:04][V][utils:109]: (ELL)  CI: 8D  offset: 17
[16:03:04][V][utils:112]: (ELL)  IV: 372C347971233A1620F3D23F21000000
[16:03:04][V][utils:115]: (ELL) KEY: KEYKEYKEY (16)
[16:03:04][D][utils:124]: (ELL) AES_CTR decrypting: 74F9E8313947B90958E70AF878FCDC52483E86755EE90DC757FE0376F9FF34FFE8259A8DAB9CCC3A49158DB2C9D57D17BBD81EC3B06212 (55)
[16:03:04][D][utils:152]: (ELL) AES_CTR  decrypted: 27537804FF230000000044137CE20300523B7C0506FF1B06700006D000426C013261670B516711023B000004130FE803008101E7FF0F0E (55)
[16:03:04][V][wmbus:303]: Validating CRC for ELL payload
[16:03:04][I][crc:046]:   calculated: 0x5327, read: 0x5327
[16:03:04][D][wmbus:104]: Decrypted T : 4744372C347971233A168D201CF3D23F2127537804FF230000000044137CE20300523B7C0506FF1B06700006D000426C013261670B516711023B000004130FE803008101E7FF0F0E (72)
[16:03:04][V][wmbus-drivers:172]: Found register '0413' with '256015'->'256.015000'
[16:03:04][V][wmbus-drivers:192]: Found register '4413' with '254588'->'254.588000'
[16:03:04][V][wmbus-drivers:493]: Found register '04FF23' with '0000'
[16:03:04][V][wmbus-drivers:070]: Found register '023B' with '0'->'0.000000'
[16:03:04][V][wmbus-drivers:090]: Found register '523B' with '1404'->'1404.000000'
[16:03:04][V][wmbus:135]: Publishing 'max_flow_lh' = 1404.0000
[16:03:04][V][wmbus:135]: Publishing 'status' = 0.0000
[16:03:04][V][wmbus:135]: Publishing 'target_water_m3' = 254.5880
[16:03:05][V][wmbus:135]: Publishing 'total_water_m3' = 256.0150
[16:03:05][V][wmbus:135]: Publishing 'volume_flow_lh' = 0.0000

[evilmumi]

Thank YOU. What are next steps?

[SzczepanLeon]

Coffee ;)

You can use this version and when all changes will be available on master I just close this ticket.

[evilmumi]

I hope you found my coffee ?!

[SzczepanLeon]

Driver available in version 3.0.0