search

zibous / ha-watermeter

Data provider for smartmeter watermeter.
GNU General Public License v3.0
157 stars 27 forks source link

CC1101-E07-900MBL-01 #23

Closed zibous closed 6 months ago

zibous commented 8 months ago 
          Hi @zibous,

Tell me if you want me to open a new issue. I've received and tested a new E07-900MBL-01 rev v.1.1 to replace the CC1101 cards, tested 2 ESP32, and I still got the corruptions.

After some investigations, they only appear when calling 

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 !
  log_unknown: False

I've built the testing code with Web ESP Home and from Docker container, then it can't be related to the compiler. The pins are good, are I've tested providing power to the network card by the integrated USB or from 3.3V of ESP32. Cables are all brand new too.

Here is the wired setup 20231020_213411

By any chance, may you have another idea?

Originally posted by @Flow76320 in https://github.com/zibous/ha-watermeter/issues/21#issuecomment-1773297937

zibous commented 8 months ago

@Flow76320

I really like E07-900MBL-01, but I can do it only buy in China and the import is very expensive and has a long delivery time.

Where did you buy it?

Are you sure the wiring is correct? What do the log messages look like when starting? https://www.cdebyte.com/products/E07-900MBL-01/4#Downloads

Flow76320 commented 8 months ago

I bought it from ali, 1 month delivery. It looks qualitative but as 3 quite different revisions. I read this file to find out how to wire: E07-900MBL-01_UserManual_EN_v1.1.pdf

Thus, it gives the following wiring from E07-900MBL-01 to az-delivery-devkit-v4:

I also tried a 3rd az-delivery-devkit-v4; and changing wmbus component from main to 2.1.20 and 2.2.6 which correspond to the latest patches at my initial installation date time...

The full log message is 

ets Jul 29 2019 12:21:46

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:1184
load:0x40078000,len:13132
load:0x40080400,len:3036
entry 0x400805e4
E (24207) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (24207) task_wdt:  - loopTask (CPU 1)
E (24207) task_wdt: Tasks currently running:
E (24207) task_wdt: CPU 0: IDLE
E (24207) task_wdt: CPU 1: loopTask
E (24207) task_wdt: Aborting.

abort() was called at PC 0x40106310 on core 0

Backtrace:0x40083915:0x3ffbe9cc |<-CORRUPTED

ELF file SHA256: 0000000000000000

Rebooting...
ets Jul 29 2019 12:21:46

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:1184
load:0x40078000,len:13132
load:0x40080400,len:3036
entry 0x400805e4
E (24239) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (24239) task_wdt:  - loopTask (CPU 1)
E (24239) task_wdt: Tasks currently running:
E (24239) task_wdt: CPU 0: IDLE
E (24239) task_wdt: CPU 1: loopTask
E (24239) task_wdt: Aborting.

abort() was called at PC 0x40106310 on core 0

Backtrace:0x40083915:0x3ffbe9cc |<-CORRUPTED

ELF file SHA256: 0000000000000000

Rebooting...
ets Jul 29 2019 12:21:46

And the flashing log (firmware already built once):

# esphome run compteur.yaml
INFO ESPHome 2023.8.3
INFO Reading configuration compteur.yaml...
INFO Updating https://github.com/SzczepanLeon/esphome-components.git@2.2.6
INFO Updating https://github.com/zdzichu6969/esphome-components.git@main
INFO Generating C++ source...
INFO Compiling app...
Processing compteur-eau (board: az-delivery-devkit-v4; framework: arduino; platform: platformio/espressif32@5.4.0)
-------------------------------------------------------------------------
Library Manager: Installing SPI @ *
INFO Installing SPI @ *
HARDWARE: ESP32 240MHz, 520KB RAM, 4MB Flash
 - toolchain-xtensa-esp32 @ 8.4.0+2021r2-patch5
Dependency Graph
|-- AsyncTCP-esphome @ 1.2.2
|-- WiFi @ 2.0.0
|-- FS @ 2.0.0
|-- Update @ 2.0.0
|-- ESPAsyncWebServer-esphome @ 2.1.0
|-- DNSServer @ 2.0.0
|-- ESPmDNS @ 2.0.0
|-- ArduinoJson @ 6.18.5
|-- WiFiClientSecure @ 2.0.0
|-- HTTPClient @ 2.0.0
|-- wMbus-lib @ 1.2.12+sha.dde0d9b
|-- wmbus-drivers @ 0.0.0+20231023213312.sha.0665603
|-- noise-c @ 0.1.4
Compiling .pioenvs/compteur-eau/src/main.cpp.o
Linking .pioenvs/compteur-eau/firmware.elf
RAM:   [=         ]   8.2% (used 43916 bytes from 532480 bytes)
Flash: [======    ]  63.7% (used 1168137 bytes from 1835008 bytes)
Building .pioenvs/compteur-eau/firmware.bin
Creating esp32 image...
Successfully created esp32 image.
esp32_create_combined_bin([".pioenvs/compteur-eau/firmware.bin"], [".pioenvs/compteur-eau/firmware.elf"])
Wrote 0x12e990 bytes to file /config/build/compteur-eau/.pioenvs/compteur-eau/firmware-factory.bin, ready to flash to offset 0x0
===================== [SUCCESS] Took 13.40 seconds =====================
INFO Successfully compiled program.
INFO Connecting to 192.168.1.157
INFO Uploading ./build/compteur-eau/.pioenvs/compteur-eau/firmware.bin (1173904 bytes)
Uploading: [============================================================] 100% Done...

INFO Waiting for result...
INFO OTA successful
INFO Successfully uploaded program.
INFO Starting log output from 192.168.1.157 using esphome API

I think it's related to wmbus crash, but the NTP does not seem to enforce the time before crashing

zibous commented 8 months ago

I bought it from ali, 1 month delivery. It looks qualitative but as 3 quite different revisions.

Thus, it gives the following wiring from E07-900MBL-01 to az-delivery-devkit-v4:

* pin 8 to 3V3
* pin 5 to any GND
* pin 10 MISO to GPIO19
* pin 11 MOSI to GPIO 23
* pin 12 CLK to GPIO18
* pin 13 NSS to GPIO05
* pin 15 RX to GPIO16
* pin 14 TX to GPIO17

I also tried a 3rd az-delivery-devkit-v4; and changing wmbus component from main to 2.1.20 and 2.2.6 which correspond to the latest patches at my initial installation date time...

Backtrace:0x40083915:0x3ffbe9cc |<-CORRUPTED comes when something went wrong during flashing. Which tool do you use? If it is Homeassistant / ESPHOME, there are problems and incorrect behavior occurs.

Try ESP WEB Flash Tool (chrome browser) and the test firmware. https://github.com/zibous/ha-watermeter/tree/master/esphome/testcases water-meter-esp32-izar-test.bin

Backtrace error see:

https://github.com/zibous/ha-watermeter/issues/21

Flow76320 commented 8 months ago

I used esphome latest Docker container and web EspHome. I just tried again with your test case https://github.com/zibous/ha-watermeter/blob/master/esphome/testcases/water-meter-esp32-izar-test.bin, some bactrace corruption. Changed USB cable another time too to prevent any hardware isssue.

It think it's more related to:

E (24239) task_wdt: CPU 1: loopTask
E (24239) task_wdt: Aborting.

A task is looping and killed by WDT

zibous commented 8 months ago

@Flow76320

Use ESP WEB Flash Tool (chrome browser) and the test firmware. https://esphome.github.io/esp-web-tools/

1st test w/o connected E07-900MBL-01 2nd test with connected E07-900MBL-01

if 1st is working the installed firmware is o.k if 2nd is not working you have problems with E07-900MBL-01.

I use also the EBYTE TI CC1101 with a ESP32 and the latest wbmusmeters lib w/o any problems.

https://github.com/zibous/ha-watermeter/blob/master/esphome/docs/E07-900MBL-01.jpg https://amzn.eu/d/bA0fmJE https://www.cdebyte.com/products/E07-900MM10S/2#Pin

Check the wire for the E07-900MBL-01:

* pin 8 to 3V3                   <--- ??? MCU's SWIM pin not 3VC maybe pin 2 or 3 
* √ pin 5 to any GND
* √ pin 10 MISO to GPIO19
* √ pin 11 MOSI to GPIO 23
* √ pin 12 CLK to GPIO18
* ? pin 13 NSS to GPIO05
* √ pin 15 RX to GPIO16
* √ pin 14 TX to GPIO17

The log shows you that CC1101 SPI bus is o.k:

[17:16:18][C][wmbus:394]: wM-Bus v2.2.29:
[17:16:18][C][wmbus:411]:   CC1101 SPI bus:
[17:16:18][C][wmbus:412]:     MOSI Pin: GPIO13
[17:16:18][C][wmbus:413]:     MISO Pin: GPIO12
[17:16:18][C][wmbus:414]:     CLK Pin:  GPIO14
[17:16:18][C][wmbus:415]:     CS Pin:   GPIO15
[17:16:18][C][wmbus:416]:     GDO0 Pin: GPIO4
[17:16:18][C][wmbus:417]:     GDO2 Pin: GPIO5
[17:16:18][E][wmbus:430]:   Check connection to CC1101!
Flow76320 commented 8 months ago

@zibous I did again the firmware installation w/ et w/o the E07-900MBL-01. As expected, it works without the card and fails with it plugged in.

I bought 2 EBYTE TI CC1101 but it was a real pain to weld, this is the reason why I bought a ready-to-go E07-900MBL-01.

I tried pin 3 with 3.3V, the ESP32 does not crash. On pin 2, it does crash.

I think that I have another clue regarding E07-900MBL-01. Regarding its specs, I did not pay attention that it embeds a MCU (stm8l151g4u6). Moreover, regarding this document, 【SCH】_M+Series+Test+Baseplate.pdf I feel that RXD and TXD are not directly plugged to E07-900M10S, but they are USART ports. Maybe the MCU needs some programing to must the ESP32 communicate with the E07-900M10S

Flow76320 commented 6 months ago

Hi @zibous ,

I gave up for this one. I also gave up with the E07-900M10S, I could not managed to make it recognize the CC1101. Back to the old C1101 directly and I kind of work!

I only face this one with the same code as before image

This is flashed with Docker container. Do you have any clue?

zibous commented 6 months ago

Do you have any clue?

It would have been good if it had worked with the E07-900M10S, because it looks very good. I wanted to order one but couldn't get it to Austria.

It looks like the telegram from the watermeter is not correct or wmbus cannot encode it.

Which water meter do you have?

Try setting the watermeterid to 0 and the log_level to debug.

## logger settings
  log_level: "DEBUG"  
  log_wmbus: "DEBUG"

## all watermeters
wmid: "0"

or try: https://github.com/zibous/ha-watermeter/blob/master/esphome/testcases/wm-d1mini32-izar-test.yaml https://github.com/zibous/ha-watermeter/blob/master/esphome/testcases/water-meter-esp32-izar-test.bin

Then you should see the telegrams from all water meters, which you can then check here: https://wmbusmeters.org/

Flow76320 commented 6 months ago

Yes... I triple checked the weldings and can't find where I made a mistake. For the E07-900MBL-01 I never had feedback from ebyte team unfortunately.

I've upgraded my firmware and set "Key" to "". It worked again. We can close this issue, thanks for your help!