Test CC1101 wbmus - Simulate telegram data

[zibous]

Hi Leon,

Are there more ways to test wmbus and CC1101?

• CC1101 connection ok, but no telegram because the water meter is too far away.

• CC1101 connection fails, There is only an error message if the CC1101 is not recognized. Is there a way to evaluate this via a sensor?

• Is there a way to simulate the telegram w/o a connected CC1101?

   wmbus:
         telegram:  1944A511780743434418A241150013CE0766324C94EE48EEF6C8

• is platform: sntp required ?

     time:
         - platform: sntp
           id: time_sntp

  see: https://github.com/SzczepanLeon/esphome-components#211-example-for-version-2x

Testcase:

---
## ------------------------------------------------------------------
## TESTCASE FOR WMBUS METER + CC1101 for WATERMETES
##
## This version has no sensors and shows only
## the logs for checking wM-Bus and CC1101.
##
## No sensors - only logging to see the wmbus messages
## and watermeter telegrams.
##
## ------------------------------------------------------------------
substitutions:
  device_name_short: "water-meter-test"
  device_description: "Watermeter CC1101 wmbus Test"
  projectname: "Watermeter.CC1101 wmbus Test"
  appversion: "2.0.7"

  # logger settings
  log_level: "VERBOSE"
  log_bautrate: "0"

## ---------------------------------------------------
##
##               GDO0
##                 o
##                 7
##                 | GD02         ╭-------o 2 (GND)
##                 |  6
##                 |  o           |
##                 |  |           |
##        ╭――x――x――o――o――x――x――x――o――╮
##        │       D1  D2          -  │
##        │                          │
##        │       D1MINI WEMOS       │
##   ANT  │                          │ USB
##        │                          │
##        │           D5 D6 D7 D8 +  │
##        ╰――x――x――x――o――o――o――o――o――╯
##                    |  |  |  |  |
##                    |  |  |  |  ╰-----o  1 (+3.3V)
##                    |  o  |  o
##                    |  5  |  8
##                    | MISO| CSN
##                    o     o
##                    4     3
##                   CLK   MOSI
##
## --------------------------------------------------  
  BOARD: d1_mini
  CC1101_3: D7 # MOSI 
  CC1101_4: D5 # CLK
  CC1101_5: D6 # MISO
  CC1101_6: D2 # GD02
  CC1101_7: D1 # GDO0
  CC1101_8: D8 # CSN

## ------------------------------------------------------------------
##
##                                                               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
##
## ------------------------------------------------------------------
# BOARD: az-delivery-devkit-v4
# CC1101_3: GPIO23  # M0SI
# CC1101_4: GPIO18  # CLK
# CC1101_5: GPIO19  # MISO
# CC1101_6: GPIO17  # GD02
# CC1101_7: GPIO16  # GDO0
# CC1101_8: GPIO05  # CSN

## ------------------------------------------------------------------
##
##
##       GDO0                 MOSI
##         7              MISO  3
##         o GD02       CLK  5  o  CSN
##         |  6           4  o  |  8           ╭-------o 2 (GND)
##         |  o           o  |  |  o           |  ╭----o 1 (3.3V)
##         |  |           |  |  |  |           |  |
##   ╭――x――o――o――x――x――x――o――o――o――o――x――x――x――o――o―╮
##   |     D1 D2          D5 D6 D7 D8               |
##   |                                              |
## - | ANT              NODEMCU V3                  | -- USB
##   |                                              |
##   |                                              |
##   ╰――x――x――x――x――x――x――x――x――x――x――x――x――x――x――x―╯
##
##
##
## ------------------------------------------------------------------
# BOARD: nodemcuv2
# CC1101_3: D7  # MOSI
# CC1101_4: D5  # CLK
# CC1101_5: D6  # MISO
# CC1101_6: D2  # GD02
# CC1101_7: D1  # GDO0
# CC1101_8: D8  # CSN

## ----------------------------------------------------------------
## HARDWARE: D1 MINI ESP8266 80MHz, 80KB RAM, 4MB Flash
## ----------------------------------------------------------------
esp8266:
  board: ${BOARD}
  restore_from_flash: true

# ----------------------------------------------------------------
# HARDWARE:  NODEMCU V3 ESP8266 80MHz, 80KB RAM, 4MB Flash
# ----------------------------------------------------------------
# esp8266:
#   board: ${BOARD}
#   restore_from_flash: true

## ----------------------------------------------------------------
## HARDWARE az-delivery-devkit-v4
##          ESP32 240MHz, 520KB RAM, 4MB Flash
## ----------------------------------------------------------------
# esp32:
#   board: ${BOARD}
#   framework:
#     type: arduino

## ----------------------------------------------------------------
## ESPHOME APPLICATION
## ----------------------------------------------------------------
esphome:
  name: ${device_name_short}
  comment: ${device_description}
  project:
    name: ${projectname}
    version: ${appversion}
  build_path: ./build/${device_name_short}

## ----------------------------------------------------------------
## External components
## ----------------------------------------------------------------
external_components:
  # uses the latest version from SzczepanLeon
  - source: github://SzczepanLeon/esphome-components@main
    refresh: 0s
    components: [wmbus]

## ---------------------------------------------------
## WIFI Settings 3 wifis
## ---------------------------------------------------
wifi:
  id: wifi_d1mini
  networks:
    - ssid: !secret ssid3_name
      password: !secret ssid3_pswd
      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

## ---------------------------------------------------
## Captive portal component 
## ---------------------------------------------------
captive_portal:

## ---------------------------------------------------
## LOGGER component 
## ---------------------------------------------------
logger:
  id: appslogger
  level: ${log_level}
  baud_rate: ${log_bautrate}

## ---------------------------------------------------
## OTA Updates
## ---------------------------------------------------
ota:
  password: !secret ota_pswd
  on_error:
    then:
      - logger.log:
          format: "OTA update error %d"
          args: ["x"]

## ---------------------------------------------------
## LOCAL WEBSERVER, local settings - no internet
## ---------------------------------------------------
web_server:
  port: 80
  version: 2
  local: true

## ---------------------------------------------------
## 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

## ---------------------------------------------------
## CC11001 WMBUS TO DEVICE (selected board)
## ---------------------------------------------------
wmbus:
  mosi_pin: ${CC1101_3}  # MOSI Attached to Hardware SPI controller MOSI SPI Interface
  miso_pin: ${CC1101_5}  # MISO Attached to Hardware SPI controller MISO SPI Interface
  clk_pin: ${CC1101_4}   # SCK  Attached to Hardware SPI controller CLK
  cs_pin: ${CC1101_8}    # CSN  Attached to Hardware SPI controller
  gdo0_pin: ${CC1101_7}  # GDO0 Clock output. High Impedance !
  gdo2_pin: ${CC1101_6}  # GDO2 status signals. High Impedance !

  # Shows telegrams from all watermeters in log.
  log_unknown: True

## Nothing follow here, output only on log console

[SzczepanLeon]

• CC1101 connection ok, but no telegram because the water meter is too far away.

In that case what should reported? I don't have any idea.

• CC1101 connection fails, There is only an error message if the CC1101 is not recognized. Is there a way to evaluate this via a sensor?

It could be possible. I can create another sensor called status.

• Is there a way to simulate the telegram w/o a connected CC1101?

   wmbus:
         telegram:  1944A511780743434418A241150013CE0766324C94EE48EEF6C8

With current implementation - no. But maybe in future. But why you need this feature? It will send the same data again and again. Do you want to create dummy sensor with specific telegram or just dummy sensor with (pseudo)random data?

• is platform: sntp required ?

Yes, it is used by client. Time is required but you can use sntp or homeassistant. But I want to change it. When client is present in config then time is required otherwise time is not needed. I don't know (yet) is it feasible to do this.

[zibous]

Hi Leon,

Thanks for your time and replay.

In that case what should reported? I don't have any idea.

Would it not be possible to check in the void WMBusComponent::loop() whether a telegram has arrived after a certain time has elapsed. If no telegram is evaluated in the specified time, a warning message appears.

This would show that everything was configured correctly, but no telegram was recorded (water meter too far away, source of interference or broken antenna)

  wmbus:
      telgram_present: 30s (default)

---

• I can create another sensor called status.

It's a good idea, so you could also find out if everything is ok. Would be great if there would be the status.

---

• Is there a way to simulate the telegram w/o a connected CC1101?

wmbusmeters offers the possibility to check the telegram. If this is known, then it would be easier to check the frontend and the configuration if everything was configured correctly.

---

Do you want to create dummy sensor with specific telegram or just dummy sensor with (pseudo)random data?

With Esphome or Homeassistant use an input text to insert the telegram and check it if there is a change or to simulate the telegram that comes from the CC1101.

---

platform: sntp: Yes, it is used by client. Time is required but you can use sntp or homeassistant.

Does the id have to be exact time_sntp or does it only have to be - platform: sntp ?

[zibous]

Hi Leon,

Found and ordered a new CC1101 see: https://amzn.eu/d/fxQ0Ot2

[SzczepanLeon]

In that case what should reported? I don't have any idea.

Would it not be possible to check in the void WMBusComponent::loop() whether a telegram has arrived after a certain time has elapsed. If no telegram is evaluated in the specified time, a warning message appears. This would show that everything was configured correctly, but no telegram was recorded (water meter too far away, source of interference or broken antenna)

  wmbus:
      telgram_present: 30s (default)

;-) You lived in perfect Izar world where watermeters are crazy and send data every 8 seconds. In normal world watermeter can be programed in different way and send data every 3-5 minutes and only in working days, etc So that telegram_present option is tricky.

• I can create another sensor called status.

It's a good idea, so you could also find out if everything is ok. Would be great if there would be the status.

So I have to read and think more about text_sensor and how to organize it in .py files

• Is there a way to simulate the telegram w/o a connected CC1101?

wmbusmeters offers the possibility to check the telegram. If this is known, then it would be easier to check the frontend and the configuration if everything was configured correctly.

Do you want to create dummy sensor with specific telegram or just dummy sensor with (pseudo)random data?

With Esphome or Homeassistant use an input text to insert the telegram and check it if there is a change or to simulate the telegram that comes from the CC1101.

I will think about this ...

platform: sntp: Yes, it is used by client. Time is required but you can use sntp or homeassistant.

Does the id have to be exact time_sntp or does it only have to be - platform: sntp ?

No. Only time component is required. Time source can be any type.

For example:

time:
  - platform: sntp

or

time:
  - platform: homeassistant

or

time:
  - platform: gps

etc.

[zibous]

Hi Leon

Sounds good, I'm looking forward to the new version...

[zibous]

Hi Leon,

1. ;-) You lived in perfect Izar world where watermeters are crazy and send data every 8 seconds. Yes agree, i can do this with ESPHOME with on_time and set the cc1101_stateon sensors:

   
   globals:
   - id: cc1101_state
   type: int
   restore_value: no
   initial_value: '0'

   • id: cc1101_state_message type: std::vector restore_value: no
     initial_value: '{"Warte auf Daten", "Ready"}'
     .... on_time:

     check cc1101 telegram state message

     • seconds: 30 then:
       • lambda: |- int msgcode = int(id(cc1101_state)); std::string message = id(cc1101_state_message)[msgcode]; ESP_LOGD("wmbus", "watermeter_status_message: %s, error code: %d", message.c_str(), msgcode); id(watermeter_status_message).publish_state(message);

2. can create another sensor called status. So I have to read and think more about text_sensor and how to organize it in .py files

   I would make a status code (like the alarm code) so that it can be translated into the desired language. I t's a pity that no text sensor is needed for this one. I would like to have the one for the last_measure_date.

3. No. Only time component is required. Time source can be any type.

   Perfect. Good news.

4. simulate the telegram w/o a connected CC1101?

   Pending