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

Share your Projects!
369

The 1st screenshot above entities were created by mqtt discovery. You should have the same count of entities as mine.

370

Oh.

nope, I just get the basic entities required. Yours shows as a bot not a meter?!

Screenshot_20210921-233500
Screenshot_20210921-233500995Ɨ2048 137 KB

371

Yours shows as a bot not a meter?!

That is strange. I checked the code and I have added the meter mac in the correct area. Not sure why mine is showing a bot.

/* Switchbot Meter Settings */
static std::map<std::string, std::string> allMeters = {
  { "meter", "c2:76:p5:98:68:ad" }
};
372

if you compile once with meter mac in the bot list then itll do that. just delete the device and reboot. not a big deal

but ya there is a metervbug for sure in v6.0. ill release in a bit, just testing to be sure

373

if you compile once with meter mac in the bot list then itll do that. just delete the device and reboot. not a big deal

Oh. I didnā€™t realized I had placed it in the bot at one point. I will do that on my next reboot of HA.

374

v6.1 is released. should fix the meter not auto scanning issue

375

ya I double checked and nothing changed with meter discovery since v5.2 and it works for me. the method is publishHomeAssistantDiscoveryMeterConfig in the code

Try v6.1. not sure what went wrong, but I assume itā€™ll start working again with v6.1

1 Like
376

by default it will use defaultMeterScanSecs = 60 to scan for ALL meters every 60 secs

if you had one meter that you wanted to scan more often (like every 30 sec), you could add it to the botScanTime list

static std::map<std::string, int> botScanTime = {
  { "meterone", 30 }
};

you can scan as often as you want, technically it just means the esp32 uses a bit more power

1 Like
377

Hey everyone, sorry a small bug was found in v6.1. v6.2 released

The curtain cover entity was not being created by auto discovery. I didnā€™t leave enough buffer space for the cover entity mqtt message. in v6.1 it is 512, it is set back to 1024 in v6.2

@TeaMan this couldā€™ve also affected meter and maybe why you had discovering meter devices

cheers

378

Good stuff Thanks for letting me/us know. And nice one for finding!

Ill upgrade at some point. :slight_smile:

379

Ah, I was about to comment about not having any cover entities show up in autodiscovery. Iā€™ve upgraded to 6.2 and unfortunately Iā€™m still not seeing themā€¦

Iā€™m seeing the other 5 entities that get created with autodiscovery.

380

I just retried to confirm and all good from my side. deleted the device, rebooted esp32, then they show up after 30 secs or so

maybe your 6.2 update didnā€™t go through? does the OTA webpage show 6.2?

you should see 6 entities on a curtain device:

  1. battery
  2. calibrated
  3. curtain (cover)
  4. illuminance
  5. linkquality
  6. position

(Ignore the values, they are incorrect because I donā€™t own curtain and I am faking one)

image

381

Hi devWaves,
Looks good on v6.2 for Bots and METER, Well-done!

My Curtain bots arenā€™t attached to this ESP32 so canā€™t test for that.
At some point Iā€™ll update the Curtain ESP32ā€¦

382

Ah, that was it. Pretty embarassing on my end. I was using the arduino-cli to try to upgrade, didnā€™t think of checking the OTA webpage to check. Used it to flash the new image and now Iā€™m on 6.2 with cover entities.

They seem to be working, the device is doing a lot of scanning at the moment for some reason (the blue led is on a lot) so actions are a bit slow, but Iā€™ll look into that myself.

Thanks a lot (again)!

383

cool. ya no problem. if you are using motion and/or contact sensor the LED will be on all the time by default because it scans all the time

if you only have bot/meter/curtain then you should see the scanning stop. based on the number of devices.

the scanning should not affect the speed of control ( it did in previous older versions). whenever scanning and a control/set is received, it should immediately stop scanning, then perform the actionā€¦ no noticeable delay

make sure you have good linkquality RSSI values for each devices. Scanning can be done with a bad signal, control is best to be at least -75 ish
if you can get an rssi around 40-50-60 then that is a good connection. The worse the signal, the longer it takes to control

384

I just noticed that SwitchBot released BLE documentation for their new upcoming color bulb (not even sure if it is released yet)

If anyone ends up getting one and wants me to add support for it, just give me a shout. Seems like it would be pretty straight forward to implement. I would need a tester

385

Cool. Not for me, Iā€™m well and truly in the Hue eco system.
Wish Switchbot would design some sort of blind controller though, just tilt adjustment would be nice and all running off esp32ā€™s! :slight_smile:

386

It was brought to my attention that the curtain cover MQTT discovery message did not associate the state PAUSE to the closed state. The call would work, but would generate a warning like this in HA logs
Payload is not supported (e.g. open, closed, opening, closing, stopped): PAUSE

a very minor change was added and released as v6.3 to fix this

387

For those that prefer using PlatformIO instead of the Arduino IDE, I have released a v6.4

There are no functional differences between v6.4 and v6.3, so if you are already running v6.3 there is no need to update to v6.4

Cheers

1 Like
388

A request to support the remote button was made in github hereā€¦
devWaves Github - Remote Support Link

Edit: it looks like the switchbot remote up/down actions cannot be supported because of how it works. The remote links directly with a bot or curtain and does not advertise this data. The remote only seems to advertise battery level. I may still add it as a possible device to monitor battery through MQTT, but the up/down actions cannot be captured