SwitchBot bot/curtain/meter/contact/motion MQTT ESP32 bridge - Local control

Wow, congratulations on the new born.

1 Like

Hi Everyone,

v7.0 is ready for testing and can be located here https://github.com/devWaves/SwitchBot-MQTT-BLE-ESP32/tree/v7alpha

there are a TON of updates and improvements. The main ones beingā€¦

  • ESP32 Meshing (use multiple ESP32s for contact/motion/meter for better performance)
  • Active vs Passive scanning. Passive scanning uses less battery on switchbot devices and can be used with contact/motion/meter/plug
  • Support for plug mini
  • Scan and update curtain position while curtain is moving

I will go through all the updates later, but the code is up and ready for use.

My contact and motion sensors seem to work just as fast as Zigbee/Zwave contact/motion sensors when using multiple meshed ESP32s (I am using 2 ESP32s meshed atm)

Cheers

2 Likes

Thanks for the update, will give it a try. At the moment I have 4 curtains and the ESP is downstairs. That sometimes result in a 15sec delay (other times it works instantly).

What is your personal thought on the new bluetooth integration?
Will v7 also improve my delay or do you advise to place another one upstairs?

hey @Thommy86. The delay is simply caused by the distance from the ESP32 to the curtain. Another ESP32 will definitely improve things or place the ESP32 in the middle

The HA integration will result in the same delay, if your bluetooth adapter etc is far from the curtains.

v7 wonā€™t reduce the delay in creating a connection. Nothing I can do there. Thatā€™s just the nature of bluetooth and creating a connection to the curtains

I will personally always be using ESP32s instead of the HA bluetooth. It is for sure cool that it is native, but ESP32s offer many more benefits. Thatā€™s just my opinion though

I use ESP32s with external antennas as my primary units. They offer the best signal reception

V7.0 has been released to the main github branch. The readme has been updated with a Mesh setup instructions and an Examples folder of how to configure multiple ESP32s in a mesh for contact/motion/meter maximum performance

I am using 2 ESP32s in a mesh setup and the motion/contact sensors work basically instantly similar to zigbee/zwave speeds

1 Like

Is the V7 alpha the same as the v7 official release or we should update with the v7 official?

@duceduc v7.0 release is the exact same as v7.0-preRelease2. just did some final testing

Iā€™m getting a few lockups using v7.1, very similar to when I originally installed NimBLE 1.3.8 when I first installed the version that only supported 1.3.7, v6.ā€œsomethingā€, possibly v6.9 i.e. the blue light comes on and the esp32 becomes unresponsive. Is there anything I can do to diagnose?
Current NimBLE I have installed is 1.4.0 - Have I jumped too far ahead?

@evanshaw are u using platform io or arduino?

if arduino are u using the esp32 core library v1.0.6? Issues have been discovered with v2+. Documentation has been updated to reflect this

if you are using platform io, the code has been updated to pull version 3.5.0 of the esp32 core library (v4+ uses the v2+ arduino which has issues)

Nimble 1.4.0 is correct and v6.11 onward is fixed for nimble issues

Hi devWaves, thanks for the reply.

Iā€™m using Arduino on Linux. Iā€™ve checked for esp32 in libraries and canā€™t see anything entitled ā€œcore libraryā€ under Tools/Manage Libraries/Installed What is the easiest way to check?

Thank You

its under ā€œboards managerā€. Search esp32

Thanks for that, Itā€™s using esp32 2.0.4 so I shall downgrade.

Hi @devWaves, Iā€™ve noticed my SwitchBot meter updates every 3 hours since the last update rather than every couple of secs before. Is there any way to revert to more frequent updates? I tried the Active / Passive but it didnā€™t help. Iā€™m only using 1 instance.

@notownblues are you using v7.1?

the meters should auto update any time there is a change in temp or humidity, no matter what the settings are. But to get more frequent MQTT updates you can set these values

defaultMeterMQTTUpdateSecs = Any time the ESP32 is scanning and the device is found it will update every X seconds

static const int defaultMeterMQTTUpdateSecs = 600;

defaultMeterActiveScanSecs = The ESP32 will active scan for the meter. Meters support passive scanning though and active scannning uses more battery, so this is why the value is higher

static const int defaultMeterActiveScanSecs = 3600;

Thanks for your reply @devWaves!

Good to know that it should update when the temp or humidity changes, I must have missed that in the doc.

Yes Iā€™m on the 7.1 version. I looked at last nightā€™s history and it didnā€™t update for 8 hours despite the temp changing, I think the ESP might be a bit too far as the link quality Iā€™m getting now is -95 rssi.

Iā€™ll try to add a closer one to the Meter and see how it goes.

Thanks for your help!

Hi devWaves,

Iā€™m still getting the odd freeze using v7.1.
Iā€™ve checked all the library versions installed and compared to the documentation, they are ok. The ESP32 version is also correct. Itā€™s not happening as often as it did previously when I was using the wrong ESP32 version, but it is happening at least once a day.

hey @evanshaw sorry I am not having the same issues so I am not sure. Mine has been running v7.1 since the last update. No lock ups at all

What are all the device types you have? I have like 2-4 of each type

are you using a dedicated MQTT user/pass for the esp32? if no try creating one just for the esp32

also make sure you are using a good power supply

just as a note, what esp32 dev board do u have again?

if you leave the esp32 plugged into your pc you can turn on debugging to try and figure put why. You will want to use the arduino IDE 2 or platform io. The original arduino IDE can crash with too much serial monitor output

these are debug settings

static const bool printSerialOutputForDebugging = false;     // Only set to true when you want to debug an issue from Arduino IDE. Lots of Serial output from scanning can crash the ESP32
static bool manualDebugStartESP32WithMQTT = false;           // Only set to true when you want to debug an issue. ESP32 will boot in an OFF state when set to true. To start the ESP32 processing send any MQTT message to the topic ESPMQTTTopic/manualstart. This will make it easier to catch the last serial output of the ESP32 before crashing

Hi devWaves,

Thanks for the reply.
I only have switchbot curtain rods v2 with firmware 4.6
Yes already have a dedicated mqtt user and password.

Power supply is good: https://www.amazon.co.uk/dp/B01MXXOQTE/?coliid=I1B69LI6LQ97CD&colid=17RBMQPSFGGK9&psc=1&ref_=lv_ov_lig_dp_it

And the ESP32 Iā€™m using is this one: https://www.amazon.co.uk/gp/product/B071JR9WS9/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1

Not sure about the debugging thing as all this is pretty new to me. v6.11 worked superbly for me with NimBLE 1.3.7, Iā€™m suspecting that itā€™s still a NimBLE 1.4.0 problem in my case, Will 7.1 still work ok if I revert to NmBLE 1.3.7?

@evanshaw yes 1.3.7 will still work. the change I made was to not unsubscribe from BLE notification inside the notification method. I dont think 1.4.0 is the issue though as it works fine for me

Do u happen to have a diff brand esp32 to try with? someone else mentioned the ā€œesp32sā€ giving them issues and they moved to a diff brand and it solved all the problems

these are the main ones I use
ESP-WROOM-32-U (with external antenna)

Wemos D1 Mini (CP2104)

Hi devWaves,

Hope you are well.
So I tried dropping to NimBLE 1.3.7, no change.
Then I tried experimenting with a different board type in the IDE, I went to what I think is quite generic ā€œESP32 Dev Moduleā€ again, no change, I was using ā€œDOIT ESP32 DEVKIT V1ā€ previously.
Not really sure which board type I should be using TBH as there is nothing in the list with WROOM in the description.
Anyway, I decided to upgrade back to NimBLE 1.4.0 and again no change. (Iā€™ve kept it as ESP32 Dev Module for now)

Now for the weird part, after the failures I thought Iā€™d switch on the debugging via the Arduino IDE, by setting the line you mentioned :-

static const bool printSerialOutputForDebugging = false;

to true.

And blimey, after setting up the Arduino Serial Monitor with that set, I think Iā€™m seeing the Quantum Wave Affect, where when you monitor something, it does as expected. Itā€™s not crashed since the serial monitor has been on. :crazy_face:

P.S. The chip on the board itself says ā€œESP-WROOM-32 211-161007ā€