when you change the mqtt topic they are now considered new devices in HA. you would need to delete the old devices in HA, then reboot the esp32 to get the latest HA discovery messages. The devices would then create with the latest topic name
Oh ok, understood.
Cheers devWaves! 
1 Like
Nevermind, I flashed a different ESP32 and it works now! Thanks a lot for helping!
1 Like
I’ve released a couple new features in a v3.0
- get responses from bot/curtain (success, failed, busy)
- automatically retry on “busy” response bot/curtain
- put a delay between commands to the same device
- get settings from bots (firmware, hold seconds, numbers of timers, inverted)
- Automatically get hold time from bots and add that to delay between commands
- get/set hold second on bots
- get/set mode on bots
I haven’t tested v3.0 with curtains, so if someone can let me know that would be cool
I am assuming the success, busy, failed responses from the curtains are the same values as the bots
getting settings is different then getting attribute values. getting settings requires writing a value to the bot/curtain and listening for the response. Similar to a set/control command
setting the hold seconds on bots is useful for people that need to use the same bot for different hold times.
Example: turning something on requires holding for 10 seconds, turning that same thing off requires holding for 0 seconds.
In v3.0 you can now look for the "status"="success" message if you have getBotResponse = true
the bots will now respond when it successfully completed the action
Hey there, I tried version 3.0.
I have a small issue… for some reason I do received the CommandSent and Success… but sometimes it stays in the CommandSent status even if I can see that it successfully performed the action. Not everytime, sometimes it changes to Success.
And I am waiting a good 30 seconds before sending command… Could this be due to the fact that my signal is -90? Like it’s not receiving the response from the BOT? Or this is signal proof and will retry to read the success value after a couple of seconds?
Also what is the value “5” after the Sucess Status ?
Thanks!
ya -90 is probably the cause. -100 means no signal.
to get the “success”, “failed”, or “busy” the new changes I added were to subscribe to switchbot ble responses. The value 5 is associated to a successful press action, value 1 is a successful on/off. 3 = busy, 9 = wrong password. I am only returning that value for diagnosis issues because I made the same changes for curtain and I am just assuming the response values are same as bots
the esp32 won’t retry on no response. responses are sent immediately
I set responses required, so if your not getting it… makes sense with bad signal
Hey devWaves,
I’m trying v3.0 with my curtain bots, it could be just me but only one bot out of two is being picked up by mqtt discovery.
Checking for typos and all appears good my side after copy/paste. 
Also tried removing devices in HA, reboot of HA and esp32.
Any ideas?
Its ok, think I’ve fixed it.
Adding values for the curtain bots for this string didn’t like things. [5] was set.
static std::map<std::string, int> botWaitBetweenControlTimes = {
Left values to default and seem fine now. Might be something you may need to look at?!?
do u have curtains? sorry can’t remember. I am not seeing where the issue could be. I just tried with the values inside botWaitBetweenControlTimes commented and uncommented… worked for me. I only have 2 bots though
also that variable shouldnt affect mqtt discovery
Bizarre then…
Yes this esp32 has just 2 curtain bots attached (1 controlling LHS, other RHS).
Actually the second curtain bot that was recognised had missing entities to.
After a esp32 reboot the other bot disappeared and the other re appeared, LoL.
ok, let me know if you have issues with curtains getCurtainResponse in combination with retryCurtainOnBusy
I am just assuming the curtain response values are the same as bots where 1 or 5 = success, 3 = busy, everything else means failed
my hope is the retry on busy fixes an issue that seems to exist if you are calling 2 different sets of 2 linked curtains at the same time. The master curtain MAC of one set may be sending out a signal that causes all other curtains around it to become busy when it sends the signal to the slave curtain (even if the other curtains aren’t linked to the master). If the curtain is sending a busy response in that case, the esp32 will now retry
Thanks for the info.
Just to confirm, do I use this listening topic to get feed back (getCurtainResponse in combination with retryCurtainOnBusy).
Sorry not something I’m 100% familiar with.
<ESPMQTTTopic>/curtain/<name>/status
yes that’s the correct mqtt topic to look
for curtain, if you are able to ever get a busy message of {"status":"busy", "value":3} then the retry should work. The retry code is expecting the response to be = 3 on busy , just like bots
I don’t know exactly how fast curtains react when multiple control commands are sent one after the other, but my assumption is if you send 2 commands at the same time to the same curtain, the 2nd one that the esp32 tries to call might get a busy response
a test I am thinking if you can try is to manually publish an open and a close set/control command at the same time and see if you can get a busy response. the 2nd command that tries to call may return a busy response
…or just click open and close a bunch of times quickly and see if you can see a busy response
for bots its super simple to get the busy response, especially if you have a long hold time
make sure the delay is 0 between curtain commands, otherwise you wont be able to get the busy signal
If I get a moment at the weekend, Ill have a play!
Happy to help out.
At the moment they seem to operate perfectly and super responsive, to be fair these curtains only automate to open in the morning and close when it gets dark… that’s it.
Unless a voice command to force them… rare though.
Take care!
@devWaves.
Slightly off topic but using the same principle of the esp32.
I have moisture sensors like this dotted round the house to monitor plants and wanting to put them at a distance away from the Raspi they’re connecting to.
Do you know of any project that is using a ESP32 to help improve signal like you are doing with Switchbot?
Maybe your using them and/or able to write a program for them?
There are so many variants of this sensor, as long as its originated from China and a mac address can be extracted from them, the sensor can connect to HA etc.
Hope you can help on this, I’d like your thoughts. 
You can do this already with ESPHome
Oh yeh, of course Thank you. Fully HA integrated too.
Another thing to add to the list 
.
Are you using this sensor within EspHome? if so, is it reliable?
Getting this error when upgrading from v2.1 to v3
Sketch uses 1124713 bytes (85%) of program storage space. Maximum is 1310720 bytes.
Global variables use 51168 bytes (15%) of dynamic memory, leaving 276512 bytes for local variables. Maximum is 327680 bytes.
java.lang.NullPointerException
at cc.arduino.packages.uploaders.SerialUploader.uploadUsingProgrammer(SerialUploader.java:295)
at cc.arduino.packages.uploaders.SerialUploader.uploadUsingPreferences(SerialUploader.java:90)
at cc.arduino.UploaderUtils.upload(UploaderUtils.java:77)
at processing.app.SketchController.upload(SketchController.java:732)
at processing.app.SketchController.exportApplet(SketchController.java:703)
at processing.app.Editor$UploadHandler.run(Editor.java:2055)
at java.lang.Thread.run(Thread.java:748)
Update: v3 update successful via OTA
Without changing any settings, I tried it with OTA and was successful. Not sure why I could not done it using usb. The ota admin page says
SwitchBot ESP32 MQTT version: v3.0 (Unofficial)