Qingping CGH1 panic

Seeing repeated panic when the battery is in a new Qingping CGH1. I’ve connected it to Qingping+ which I thought was necessary to get it to send data unencrypted.

Using esp32dev-ble-cont and connect to devices is turned off in omg. I’ve tried flashing the latest version and erasing flash. Neither seemed to help any. It runs fine if I take the battery out of the CGH1.

20:12:55.738 -> N: Device detected: 58:2D:34:60:2C:3B
20:12:55.738 -> Guru Meditation Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled.
20:12:55.785 -> Core 1 register dump:
20:12:55.785 -> PC      : 0x400d8099  PS      : 0x00060530  A0      : 0x800d996c  A1      : 0x3ffcd350  
20:12:55.785 -> A2      : 0x00000000  A3      : 0x00000038  A4      : 0x3ffcdbbc  A5      : 0x3ffe3df4  
20:12:55.785 -> A6      : 0x00000000  A7      : 0x3ffcdd5d  A8      : 0x800d80b5  A9      : 0x00000038  
20:12:55.785 -> A10     : 0x00000012  A11     : 0x3ffcdd5d  A12     : 0x3ffcd478  A13     : 0x0000ff00  
20:12:55.785 -> A14     : 0x00ff0000  A15     : 0xff000000  SAR     : 0x00000010  EXCCAUSE: 0x0000001c  
20:12:55.833 -> EXCVADDR: 0x00000000  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0x00000000  
20:12:55.833 -> 
20:12:55.833 -> ELF file SHA256: 0000000000000000
20:12:55.833 -> 
20:12:55.833 -> Backtrace: 0x400d8099:0x3ffcd350 0x400d9969:0x3ffcdaf0 0x400dac32:0x3ffce070 0x401068a4:0x3ffce090 0x40090d52:0x3ffce0b0
20:12:55.833 -> 
20:12:55.833 -> Rebooting...

Hi @Grant,

just as a quick test, could you try rebuilding and uploading OMG with defining den Decoder URL in platformio.ini with the latest development build of Decoder

; decoder = https://github.com/theengs/decoder.git#v0.4.0
decoder = https://github.com/theengs/decoder

and commenting out the current v0.4.0?

Just see see if recent changes of the CGH1 decoder make any difference or if it is a different underlying issue?

I updated the line and its still rebooting if the CGH1 is advertising.
I also uncommented this line to provide more console output - ‘-DLOG_LEVEL=LOG_LEVEL_TRACE’

12:07:46.011 → T: Device mac 58:2D:34:60:2C:3B
12:07:46.011 → T: Looking for Model_id: 8
12:07:46.011 → T: properties: {“properties”:{“open”:{“name”:“door”}}}
12:07:46.058 → T: Key: openT: Unit: T: Name: doorGuru Meditation Error: Core 1 panic’ed (LoadProhibited). Exception was unhandled.
12:07:46.058 → Core 1 register dump:
12:07:46.058 → PC : 0x400d80d1 PS : 0x00060530 A0 : 0x800d99a4 A1 : 0x3ffcd480
12:07:46.058 → A2 : 0x00000000 A3 : 0x00000038 A4 : 0x3ffcdcec A5 : 0x3ffdcdd8
12:07:46.058 → A6 : 0x00000000 A7 : 0x3ffcde8d A8 : 0x800d80ed A9 : 0x00000038
12:07:46.058 → A10 : 0x00000012 A11 : 0x3ffcde8d A12 : 0x3ffcd5a8 A13 : 0x0000ff00
12:07:46.058 → A14 : 0x00ff0000 A15 : 0xff000000 SAR : 0x00000010 EXCCAUSE: 0x0000001c
12:07:46.104 → EXCVADDR: 0x00000000 LBEG : 0x4000c2e0 LEND : 0x4000c2f6 LCOUNT : 0x00000000
12:07:46.104 →
12:07:46.104 → ELF file SHA256: 0000000000000000
12:07:46.104 →
12:07:46.104 → Backtrace: 0x400d80d1:0x3ffcd480 0x400d99a1:0x3ffcdc20 0x400dac6a:0x3ffce1a0 0x40106a98:0x3ffce1c0 0x40090d52:0x3ffce1e0

I was afraid of that, but was worth a shot.

The fact that it’s causing a panic is puzzling.

If you want to give it another try with the following two changes:

This time change the Decoder URL to

decoder = https://github.com/DigiH/decoder#CGH1-test

and I don’t know if you already monitor the servicedata, if any, in the log or with MQTT Explorer, but it would be good to know what raw servicedata message is actually being tried to decode.

Other than the above suggestion I’m afraid this is out of my area of knowledge, and someone else will need to have a look.

BTW - Did you make any changes/additions to the esp32dev-ble-cont environment, or are you just building with its default definition in platformio.ini?

Using #CGH1-test prevents any reboots. Topics are being published as expected.

I havent modified anything other than what you’ve suggested, and uncommenting default_envs = esp32dev-ble-cont, and the trace line

One side note - I expected the config topic to have dev_cla set to cover so homeassistant would recognize it as a cover, not general sensor. Maybe my understanding of how things work is wrong. Here’s the config topic contents for reference

“stat_t”: “+/+/BTtoMQTT/582D34602C3B”,
“name”: “CGH1-open”,
“uniq_id”: “582D34602C3B-open”,
“val_tpl”: “{{ value_json.open | is_defined }}”,
“state_class”: “measurement”,
“device”: {
“identifiers”: [
“connections”: [
“manufacturer”: “Qingping”,
“model”: “CGH1”,
“name”: “Door sensor”,
“via_device”: “OpenMQTTGateway_ESP32_BLE_C”

Hopefully this info proves helpful.
Thanks for the fast responses. Loving openmqttgateway btw!

Good to hear :slight_smile: This was merged into the Theengs Decoder 0.5.0 release, so if you want or need to rebuild again please use

decoder = https://github.com/theengs/decoder.git#v0.5.0

As I don’t use HA nor auto discovery myself I’m not one to comment on this :wink: but I’m sure your detailed information will be read by others well versed with the HA discovery subject.

Hope you can enjoy OpenMQTTGateway to its fullest now :slight_smile: