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

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

:+1:
If I get a moment at the weekend, Ill have a play!
Happy to help out. :slight_smile:

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. :slightly_smiling_face:

You can do this already with ESPHome :slight_smile:

Oh yeh, of course Thank you. Fully HA integrated too.
Another thing to add to the list :joy:.

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)

probably just the arduino IDE being weird. I usually do usb update since I watch the serial output

wow. Big changes. Need to figure out what I need to do now and hopefully the naming of the mqtt bots didn’t interfere with my other swithbot node.js setup since the switch and cover entities are automatically created :open_mouth:

probably just the arduino IDE being weird. I usually do usb update since I watch the serial output

Hmm. I’ve unplugged from pc and retry to upload via usb, but still get same error message. OTA still works. Does the log suggests anything about the code being out of place?

I am testing the curtain with the position service.

2021-06-12_13-15-42

cover.set_cover_position

and noticed the status get stuck at commandsent at times and the physical curtain does not move. It would stay like this even after sliding the position slider to another number. After a few tries it works, but would get stuck at commansent again.

2021-06-12_12-53-14

These 2 sevices seem to work fairly well though.

cover.open_cover
cover.close_cover

do you ever see a {"status"= "success", "value"=1} when you call position on curtain?

if you never see that for position, then on the new method notifyCB at the bottom of the code I am checking that the length of the response is 3 for curtain. It is possible the position response length is different from 3 and I would need to account for that

if the length is 3 for a position response it should work the same as open/close

if it sent the commandSent status though, the command was sent…

commandSent status means the swichtbot got the command, what it decides to do with that command is answered by the response it sends back

do you ever see a {“status”= “success”, “value”=1} when you call position on curtain?

I do see it and the curtain would move, but when I continue to move the curtain via the position slider, it would stop at commandSent. It would take a few tries to get success.

You grew up watching He-Man?

ya he-man cartoon and the horrible movie that I loved as a kid lol. Borrowed it from the library a bunch lol…

happy cake day btw

hmm…
When you call position the second time I would need to somehow see if the notifyCB method gets called. If that method gets called then there must be some other kind of response from curtain I am not accounting for. I am only accounting for length =3 for curtain response in notifyCB

definitely odd that the commandSent happens and the curtain doesnt move. I can only handle that if I know how the curtain is responding

I’m not seeing any pauses or obvious issues my end. This is my output using open/close and slider triggers.

switchbotMQTT/Lounge_esp32/curtain/lounge_curtain_rhs_esp32/status,{"status":"connected"}
switchbotMQTT/Lounge_esp32/curtain/lounge_curtain_rhs_esp32/status,{"status":"commandSent"}
switchbotMQTT/Lounge_esp32/curtain/lounge_curtain_rhs_esp32/status,{"status":"success","value":1}
switchbotMQTT/Lounge_esp32/curtain/lounge_curtain_rhs_esp32/status,{"status":"connected"}
switchbotMQTT/Lounge_esp32/curtain/lounge_curtain_rhs_esp32/status,{"status":"commandSent"}
switchbotMQTT/Lounge_esp32/curtain/lounge_curtain_rhs_esp32/status,{"status":"connected"}
switchbotMQTT/Lounge_esp32/curtain/lounge_curtain_rhs_esp32/status,{"status":"commandSent"}
switchbotMQTT/Lounge_esp32/curtain/lounge_curtain_rhs_esp32/status,{"status":"success","value":5}
switchbotMQTT/Lounge_esp32/curtain/lounge_curtain_rhs_esp32/status,{"status":"connected"}
switchbotMQTT/Lounge_esp32/curtain/lounge_curtain_rhs_esp32/status,{"status":"commandSent"}
switchbotMQTT/Lounge_esp32/curtain/lounge_curtain_rhs_esp32/status,{"status":"success","value":1}
switchbotMQTT/Lounge_esp32/curtain/lounge_curtain_rhs_esp32/status,{"status":"connected"}
switchbotMQTT/Lounge_esp32/curtain/lounge_curtain_rhs_esp32/status,{"status":"commandSent"}
switchbotMQTT/Lounge_esp32/curtain/lounge_curtain_rhs_esp32/status,{"status":"success","value":1}
switchbotMQTT/Lounge_esp32/curtain/lounge_curtain_rhs_esp32/status,{"status":"connected"}
switchbotMQTT/Lounge_esp32/curtain/lounge_curtain_rhs_esp32/status,{"status":"commandSent"}
switchbotMQTT/Lounge_esp32/curtain/lounge_curtain_rhs_esp32/status,{"status":"success","value":1}

thanks, do you remember what you did when you got value 5?

for bots value = 1= successful on/off, value = 5 = sucessful press action

I put success for curtain as value 1 and value 5 also, and it seems like curtain actually does return value 5, I was only really expecting value 1 to work, but I left 5 there also.

I noticed the 5 is returned after what looks like 2 commandSent calls. With no success in between

switchbotMQTT/Lounge_esp32/curtain/lounge_curtain_rhs_esp32/status,{"status":"connected"}
switchbotMQTT/Lounge_esp32/curtain/lounge_curtain_rhs_esp32/status,{"status":"commandSent"}
switchbotMQTT/Lounge_esp32/curtain/lounge_curtain_rhs_esp32/status,{"status":"connected"}
switchbotMQTT/Lounge_esp32/curtain/lounge_curtain_rhs_esp32/status,{"status":"commandSent"}
switchbotMQTT/Lounge_esp32/curtain/lounge_curtain_rhs_esp32/status,{"status":"success","value":5}

That was me Stopping a closed command then issuing at open command after. (Pressing pause/stop).

Ill see if I can emulate the commandSent calls with no success commands again prior to value 5…

It’s a new day. The esp32 has not been disconnected or move from it’s last location. Tested the position slider 10 times consecutively. It moved for all. Just when I thought everything is cool. It hanged at commandSent.

Where is TeaMan getting those logs from. I am just looking at mqtt explorer which doesn’t save log like that.

log from mqtt explorer. Top most is the last call.

 
{"status":"commandSent"}
06/13/2021 6:29:02 AM(-1.37 seconds) 
{"status":"connected"}
06/13/2021 6:28:03 AM(-58.61 seconds) 
{"status":"success","value":1}
06/13/2021 6:28:03 AM(-0.06 seconds) 
{"status":"commandSent"}
06/13/2021 6:27:50 AM(-13.74 seconds) 
{"status":"connected"}
06/13/2021 6:27:42 AM(-7.21 seconds) 
{"status":"success","value":1}
06/13/2021 6:27:42 AM(-0.07 seconds) 
{"status":"commandSent"}
06/13/2021 6:27:39 AM(-3.33 seconds) 
{"status":"connected"}
06/13/2021 6:27:05 AM(-33.69 seconds) 
{"status":"success","value":1}
06/13/2021 6:27:05 AM(-0.05 seconds) 
{"status":"commandSent"}
06/13/2021 6:27:05 AM(-0.46 seconds) 
{"status":"connected"}
06/13/2021 6:26:17 AM(-47.78 seconds) 
{"status":"success","value":1}
06/13/2021 6:26:17 AM(-0.06 seconds) 
{"status":"commandSent"}
06/13/2021 6:26:16 AM(-0.62 seconds) 
{"status":"connected"}
06/13/2021 6:25:46 AM(-30.46 seconds) 
{"status":"success","value":1}
06/13/2021 6:25:46 AM(-0.06 seconds) 
{"status":"commandSent"}
06/13/2021 6:25:43 AM(-2.42 seconds) 
{"status":"connected"}
06/13/2021 6:25:24 AM(-19.13 seconds) 
{"status":"success","value":1}
06/13/2021 6:25:24 AM(-0.05 seconds) 
{"status":"commandSent"}
06/13/2021 6:25:02 AM(-21.82 seconds) 
{"status":"connected"}
06/13/2021 6:24:52 AM(-10.03 seconds) 
{"status":"success","value":1}
06/13/2021 6:24:52 AM(-0.06 seconds) 
{"status":"commandSent"}
06/13/2021 6:24:50 AM(-2.33 seconds) 
{"status":"connected"}
06/13/2021 6:24:43 AM(-6.66 seconds) 
{"status":"success","value":1}
06/13/2021 6:24:43 AM(-0.05 seconds) 
{"status":"commandSent"}
06/13/2021 6:24:40 AM(-3.31 seconds) 
{"status":"connected"}
06/13/2021 6:24:26 AM(-13.68 seconds) 
{"status":"success","value":1}
06/13/2021 6:24:26 AM(-0.05 seconds) 
{"status":"commandSent"}
06/13/2021 6:24:22 AM(-4.09 seconds) 
{"status":"connected"}
06/13/2021 6:22:19 AM(-2.05 minutes) 
{"status":"success","value":1}
06/13/2021 6:22:19 AM(-0.05 seconds) 
{"status":"commandSent"}
06/13/2021 6:22:10 AM(-9.3 seconds) 
{"status":"connected"}
06/13/2021 6:22:01 AM(-9.21 seconds) 
{"status":"success","value":1}
06/13/2021 6:22:01 AM(-0.05 seconds) 
{"status":"commandSent"}
06/13/2021 6:22:00 AM(-0.45 seconds) 
{"status":"connected"}

When you call position the second time I would need to somehow see if the notifyCB method gets called. If that method gets called then there must be some other kind of response from curtain I am not accounting for. I am only accounting for length =3 for curtain response in notifyCB

Where would I find out? Using the Arduino monitor log?