Core panic on switchbot press

Compatible devices
1

First of all, OpenMQTTGateway is an amazing project. It’s massive overkill for what I’m trying to do today, but now that I’ve seen what it can do, I’ll be looking for ideas to use it with.

What I’m trying to do today is to use cron on my linux machine to issue a press command to the one switchbot I own, because my phone is usually too far away from my dehumidifier when I want to turn it on and off. I’ve tried linux-only options and several esp32 options. This is my first exposure to BLE.

My SwitchBot is a “SWITCHBOT-S1” (according to Amazon) with mac D5:35:33:34:3C:5F, running firmware 6.6 (I’m pretty sure it’s 6.6 – my phone app isn’t showing the version right now). I’m running OpenMQTTGateway on a Lolin D32 Pro. I’ve also tried it on an ESP32 Thing and a non-Pro Lolin D32 with the same core panic issue.

I’m probably doing something wrong, but here’s what I hope are all the relevant details. I appreciate any help or advice!

My MQTT command:
$ mosquitto_pub -h 192.168.1.12 -t home/OMG_ESP32_BLE/commands/MQTTtoBT -m ‘{“ble_write_address”:“D5:35:33:34:3C:5F”, “mac_type”:1, “ble_write_service”:“cba20d00-224d-11e6-9fb8-0002a5d5c51b”, “ble_write_char”:“cba20002-224d-11e6-9fb8-0002a5d5c51b”, “ble_write_value”:“5701”, “value_type”:“HEX”, “ttl”:4, “immediate”:true }’

Relevant ESP32 console output:
…
N: Device detected: D5:35:33:34:3C:5F
…
N: Send on /BTtoMQTT/D53533343C5F msg {“id”:“D5:35:33:34:3C:5F”,“rssi”:-64,“brand”:“SwitchBot”,“model”:“Bot”,“model_id”:“X1”,“type”:“ACTR”,“mode”:“onestate”,“state”:“on”,“batt”:100}
…
N: Send on /SYStoMQTT msg {“uptime”:964,“version”:“version_tag”,“disc”:true,“ohdisc”:false,“env”:“esp32dev-ble”,“freemem”:97660,“mqttp”:“1883”,“mqtts”:false,“mqttv”:false,“msgprc”:69,“msgblck”:0,“maxq”:3,“cnt_index”:0,“minmem”:42508,“tempc”:57.78,“freestck”:2236,“eth”:false,“rssi”:-42,“SSID”:“xxxxxxxxx”,“BSSID”:“C8:A7:0A:C9:AA:8E”,“ip”:“192.168.1.15”,“mac”:“C8:2B:96:8C:1F:78”,“lowpowermode”:-1,“modules”:[“WebUI”,“BT”]}
N: Send on /BTtoMQTT msg {“bleconnect”:true,“interval”:55555,“adaptivescan”:true,“intervalacts”:55555,“intervalcnct”:3600000,“scanduration”:10000,“onlysensors”:false,“randommacs”:false,“hasspresence”:false,“prestopic”:“presence/”,“presuseuuid”:false,“minrssi”:-100,“extDecoderEnable”:false,“extDecoderTopic”:“undecoded”,“filterConnectable”:false,“pubadvdata”:false,“pubuuid4topic”:false,“ignoreWBlist”:false,“presenceawaytimer”:120000,“movingtimer”:60000,“forcepscn”:false,“tskstck”:2360,“crstck”:3084,“enabled”:true,“scnct”:15}
N: Send on /WebUItoMQTT msg

(I think here is the point where I did that mosquitto_pub command above)

{“displayMetric”:true,“webUISecure”:true,“displayQueue”:0}
N: BLE Connect begin
Guru Meditation Error: Core 1 panic’ed (Unhandled debug exception).
Debug exception reason: Stack canary watchpoint triggered (imActTask)
Core 1 register dump:
PC : 0x400929d8 PS : 0x00060d36 A0 : 0x80092a76 A1 : 0x3fff6d20
A2 : 0x3ffeba80 A3 : 0x3fff6d70 A4 : 0x00000000 A5 : 0x00000010
A6 : 0x0000000f A7 : 0x0000002b A8 : 0x3fff6d71 A9 : 0x00000044
A10 : 0x00000008 A11 : 0x00000000 A12 : 0x00000000 A13 : 0x3ffba538
A14 : 0xffffffff A15 : 0x353a4333 SAR : 0x00000020 EXCCAUSE: 0x00000001
EXCVADDR: 0x00000000 LBEG : 0x40091d05 LEND : 0x40091d15 LCOUNT : 0xfffffffb

Backtrace: 0x400929d5:0x3fff6d20 0x40092a73:0x3fff6d50 0x401ba701:0x3fff6d70 0x401b43f9:0x3fff7100 0x400f6b3a:0x3fff71c0 0x400e5d0e:0x3fff7210 0x400e616d:0x3fff7950 0x400e677f:0x3fff79b0

ELF file SHA256: 73da1f82e6fd0d79

Rebooting…
ets Jun 8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x17 (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:13192
load:0x40080400,len:3028
entry 0x400805e4
N:
************* WELCOME TO OpenMQTTGateway **************
[ 171][E][Preferences.cpp:50] begin(): nvs_open failed: NOT_FOUND
N: SYS config not found
N: OpenMQTTGateway Version: version_tag
N: WiFi ok with manual config credentials
[ 2096][E][Preferences.cpp:50] begin(): nvs_open failed: NOT_FOUND
N: No WebUI config to load
N: OpenMQTTGateway URL: http://192.168.1.15/
N: ZwebUI setup done
[ 3602][E][Preferences.cpp:50] begin(): nvs_open failed: NOT_FOUND
N: BT config not found
N: BLE scans interval: 55555
N: BLE connects interval: 3600000
N: BLE scan duration: 10000
N: Publishing only BLE sensors: false
N: Publishing random MAC devices: false
N: Adaptive BLE scan: true
N: Active BLE scan interval: 55555
N: minrssi: -100
N: Low Power Mode: -1
N: Presence Away Timer: 120000
N: Moving Timer: 60000
N: Force passive scan: false
N: Enabled BLE: true
N: ZgatewayBT multicore ESP32 setup done
N: OpenMQTTGateway modules: [“WebUI”,“BT”]
N: ************** Setup OpenMQTTGateway end **************
W: MQTT connection…
N: Connected to broker
N: Update check, free heap: 98564[ 5790][E][ssl_client.cpp:37] _handle_error(): [start_ssl_client():273]: (-9984) X509 - Certificate verification failed, e.g. CRL, CA or signature check failed
[ 5794][E][WiFiClientSecure.cpp:144] connect(): start_ssl_client: -9984
E: Error on HTTP requestN: Update check done, free heap: 95240N: Send on /SYStoMQTT msg {“uptime”:4,“version”:“version_tag”,“disc”:true,“ohdisc”:false,“env”:“esp32dev-ble”,“freemem”:97692,“mqttp”:“1883”,“mqtts”:false,“mqttv”:false,“msgprc”:0,“msgblck”:0,“maxq”:0,“cnt_index”:0,“minmem”:94116,“tempc”:58.33,“freestck”:5804,“eth”:false,“rssi”:-41,“SSID”:“xxxxxxxx”,“BSSID”:“C8:A7:0A:C9:AA:8E”,“ip”:“192.168.1.15”,“mac”:“C8:2B:96:8C:1F:78”,“lowpowermode”:-1,“modules”:[“WebUI”,“BT”]}
N: Send on /BTtoMQTT msg {“bleconnect”:true,“interval”:55555,“adaptivescan”:true,“intervalacts”:55555,“intervalcnct”:3600000,“scanduration”:10000,“onlysensors”:false,“randommacs”:false,“hasspresence”:false,“prestopic”:“presence/”,“presuseuuid”:false,“minrssi”:-100,“extDecoderEnable”:false,“extDecoderTopic”:“undecoded”,“filterConnectable”:false,“pubadvdata”:false,“pubuuid4topic”:false,“ignoreWBlist”:false,“presenceawaytimer”:120000,“movingtimer”:60000,“forcepscn”:false,“tskstck”:5280,“crstck”:4580,“enabled”:true,“scnct”:0}
N: Send on /WebUItoMQTT msg {“displayMetric”:true,“webUISecure”:true,“displayQueue”:0}
N: Scan begin

2

Welcome @aaroncouts

Unfortunately this is a known current regression issue, also mentioned at

which seems to have crept in with one of the last releases.

You could install the older version 1.2.0 or wait until this has been addressed in the current development version ready for a new release.

3

I should have searched harder. Thank you! I’ll try 1.2.0 for now.

4

I installed 1.2.0. I’m not getting a reboot, but I’m also not seeing anything indicating that OMG is attempting to control the Switchbot. Currently my Switchbot is in on/off mode.

Attempt 1:
$ mosquitto_pub -h 192.168.1.12 -t home/OpenMQTTGateway_ESP32_BLE/commands/MQTTtoBT -m ‘{“SBS1”:“on”, “mac”:“D5:35:33:34:3C:5F”}’

Attempt 1 console response:
…
N: Device detected: D5:35:33:34:3C:5F
…
N: Send on /BTtoMQTT/D53533343C5F msg {“id”:“D5:35:33:34:3C:5F”,“mac_type”:1,“rssi”:-67,“brand”:“SwitchBot”,“model”:“Meter (Plus)”,“model_id”:“THX1/W230150X”}
…
N: [ MQTT->OMG ]: {“SBS1”:“on”,“mac”:“D5:35:33:34:3C:5F”}

(nothing further from console, just normal BLE device scanning)

Attempt 2:
$ mosquitto_pub -h 192.168.1.12 -t home/OpenMQTTGateway_ESP32_BLE/commands/MQTTtoBT -m ‘{“ble_write_address”:“D5:35:33:34:3C:5F”, “mac_type”:1, “ble_write_service”:“cba20d00-224d-11e6-9fb8-0002a5d5c51b”, “ble_write_char”:“cba20002-224d-11e6-9fb8-0002a5d5c51b”, “ble_write_value”:“570101”, “value_type”:“HEX”, “ttl”:4, “immediate”:true }’

Attempt 2 console response:
…
N: Device detected: D5:35:33:34:3C:5F
…
N: Send on /BTtoMQTT/D53533343C5F msg {“id”:“D5:35:33:34:3C:5F”,“mac_type”:1,“rssi”:-67,“brand”:“SwitchBot”,“model”:“Meter (Plus)”,“model_id”:“THX1/W230150X”}
…
N: [ MQTT->OMG ]: {“ble_write_address”:“D5:35:33:34:3C:5F”,“mac_type”:1,“ble_write_service”:“cba20d00-224d-11e6-9fb8-0002a5d5c51b”,“ble_write_char”:“cba20002-224d-11e6-9fb8-0002a5d5c51b”,“ble_write_value”:“570101”,“value_type”:“HEX”,“ttl”:4,“immediate”:true}

(nothing further from console, just normal BLE device scanning)

5

What confuses me here a bit is that the MAC address you ar sending the commands to seems to be for a decoded SwitchBot Meter (Plus), as seen in the decoded state messages you are receiving. Could this be a different SwitchBot thermometer, possibly of your neighbours? And your actual SwitchBot Bot you are trying to control does have a completely different MAC address? Unless this is a completely wrong decoding with the older OMG version.

Can you confirm that D5:35:33:34:3C:5F is your actual Bot?

6

Confirmed, this is what is shown under Device Info in the SwitchBot app on my phone, and I can operate the bot with the phone app. This is the only Switchbot I own, and the only Switchbot product appearing in both the OMG scan and my phone app, so I don’t think there’s a neighbor’s device present. I noticed the difference in the decoder output between 1.2.0 and 1.7.0, which might be an issue with the v6.6 Switchbot firmware. There might also be an issue with my Switchbot – I’ve only had it for a couple weeks, but I just did a hard reset on it and it’s still not responding to the “Firmware and Battery” option in the Switchbot app.

7

Could you set Advertisement and advanced data to true and post a new received decoded message again for your bot, then with its included servicedata?

This will allow us to see why it might be recognised as a thermometer instead of a Bot.

And as you are able to create your own builds with PlatformIO, can you adjust the Decoder version link in platformio.ini to
decoder = https://github.com/theengs/decoder.git#development
from its older version?

8

Done.

I couldn’t get the current dev release to complile with 1.2.0:
.pio/libdeps/esp32dev-ble/TheengsDecoder/src/decoder.cpp: In member function 'int TheengsDecoder::decodeBLEJson(ArduinoJson::JsonObject&)': .pio/libdeps/esp32dev-ble/TheengsDecoder/src/decoder.cpp:915:48: error: 'stoul' was not declared in this scope char ch = stoul(part, nullptr, 16); ^

I tried v1.7.5 of the decoder, which does compile with 1.2.0, not sure if that has what you’re looking for. The decoder output definitely looks better than under decoder v1.0.0, but issuing {"pubadvdata":true} does not seem to change the decoder output.

N: Send on /BTtoMQTT/D53533343C5F msg {“id”:“D5:35:33:34:3C:5F”,“mac_type”:1,“rssi”:-61,“brand”:“SwitchBot”,“model”:“Bot”,“model_id”:“X1”,“type”:“ACTR”,“acts”:true,“mode”:“on/off”,“state”:“off”,“batt”:100}
…
N: [ MQTT->OMG ]: {“pubadvdata”:true}
…
N: Send on /BTtoMQTT/D53533343C5F msg {“id”:“D5:35:33:34:3C:5F”,“mac_type”:1,“rssi”:-65,“brand”:“SwitchBot”,“model”:“Bot”,“model_id”:“X1”,“type”:“ACTR”,“acts”:true,“mode”:“on/off”,“state”:“off”,“batt”:100}

9

I should have included the config message that was published right after I sent {“pubadvdata”:true}:

: [ MQTT->OMG ]: {“pubadvdata”:true}
N: Send on /BTtoMQTT msg {“bleconnect”:true,“interval”:55555,“activescan”:true,“scanbcnct”:10,“onlysensors”:false,“hasspresence”:false,“presenceTopic”:“presence/”,“presenceUseBeaconUuid”:false,“minrssi”:-100,“extDecoderEnable”:false,“extDecoderTopic”:“undecoded”,“filterConnectable”:false,“pubKnownServiceData”:false,“pubUnknownServiceData”:true,“pubKnownManufData”:false,“pubUnknownManufData”:true,“pubServiceDataUUID”:false,“pubBeaconUuidForTopic”:false,“ignoreWBlist”:false}

10

This is actually an issue with the older 1.2.0 OMG version :wink: to get the advertising data you would need to add

'-DpubBLEManufacturerData=true'
'-DpubKnownBLEServiceData=true'

to the build flags of the environment you are using, or alternatively use the esp32dev-ble-datatest environment.
The actual turning on and off of this was only introduced in a later release.

At least now with Theengs Decoder 1.7.5 the SwitchBot Bot is being recognised and decoded correctly, so no real need to view the advertising data any longer/

Now for sending the WRITE command, does it still not work for you with OMG 1.2.0?

11

:slight_smile: Done, and confirmed:

N: Send on /BTtoMQTT/D53533343C5F msg {“id”:“D5:35:33:34:3C:5F”,“mac_type”:1,“manufacturerdata”:“6909d53533343c5f09ac”,“rssi”:-72,“servicedata”:“48c0e400”,“servicedatauuid”:“0xfd3d”,“brand”:“SwitchBot”,“model”:“Bot”,“model_id”:“X1”,“type”:“ACTR”,“acts”:true,“mode”:“on/off”,“state”:“off”,“batt”:100}

Unfortunately it is still not working with OMG 1.2.0. I also tried OMG 1.1.1, 1.4.0, and 1.5.1. Same thing, I see the acknowledgement of the command in the console, but no further action occurs.

12

Also tried OMG 1.2.0 on an ESP32 Thing, same issue. I’m happy to send you guys my Switchbot if you want. I bet it’s the 6.6 firmware.

13

I also tried OMG 1.2.0 and development versions on an M5stick-C. Same thing as the D32 Pro – no Switchbot action for OMG 1.2.0 and core panic for the dev version.

14

Thanks for the offer, but le us get our heads around the regression first here, then we can go on to see what new issues remain with the 6.6 firmware.

We’ll get back to you once there is a new development version for testing with the Bot commands :slight_smile:

15

Sounds good, thanks!

16

Not on the list of compatible devices as it’s new, but will it be usable?

IMG_2206
Switchbot Water Leak Detector

Really like running these Switchbot sensors on your great system!

17

It could well be - all depends on the advertising data it sends and if it contains decodable status data.

Best to open a discussion thread at

and post some undecoded raw advertising data messages along with screenshots of the settings in the SwitchBot app the water leak sensor might have.

1 Like
18

Thank you for the rapid reply! As soon as it’s available in my zone I will get one, and if not yet done, will publish the raw data here.:+1:

1 Like
19

Fixed below: