I removed the enclosure and the RSSI signal improved (the one with 88 works every time and it’s also the most distant from esp)
There is something I noticed this morning, when I triggered the button, the esp sent the signal and on the switchbot I just saw the internal light turning on but no “arm” movement. I guess it’s a problem with my switchbot after all, I’ll try a reset later this afternoon.
Has anyone tested this with something like wESP32? Where the Power is provided over ethernet.
I have not used an ethernet device. This uses the Wifi libraries specifically. It also uses the ESPMqttClient library which I’d have to research if that can work over ethernet
My guess is it could work with a few changes, but I’d need to look.
If you are willing test I can take a look
If you watch the mqtt message if the error value return = 6 then that means low battery
in v6.4 I changed the error message to say low battery when value = 6. in v5.2 it only says the value = 6
could be low battery issue
From quick research it sounds like the ESPMQTTClient library might have issues with ethernet and it might need to be converted to the PubSubClient library (which it is based off of and supports ethernet)
So it is probably possible but would take a few code changes.
I went with ESPMQTTClient because it manages the wifi reconnections
The wESP32 also support WiFi, but I am not sure if it the compiled code can just run on the device. POE is more convenient for me because I don’t have to provide a USB cable to the device but instead just have a ethernet cable running from the POE switch. I’m happy to help you test, but I first need to order the device 
If you are just using POE for power but using Wifi for data then I think it will just work without code changes
Just ordered one, will try to flash your code onto it when it arrives and let you know!
devWaves, congrats about this project!
I just tried to integrate a curtain but I only receive a sensor called Linkquality. Do you have any idea about this?
LE: fixed, I had to restart HA host.
upvote from me. I’ve implemented it to control a dual curtain and works fantastic. sometimes the response from HA control to switchbot responding might be a few seconds slow to start but from my understanding this is most likely due to the time to rewake up the bots and reconnect to them.
thanks @champ26. How far is the esp32 from your curtains? what is the linkquality value?
I’ve honestly never seen the curtains work in person since I don’t own them, but the bot works basically instantly. The further away the esp32 is from the device the longer it will take
Does the switchbot app have the same behaviour with curtain? if yes then ya I guess thats just a curtain thing
I have 13 curtains connected with 2 esp32.
I introduced the second esp32 because of the distance / signal strenght and steer all curtains as singles. Signal strength is now very good.
Closing or opening a single curtain takes approx. 10 seconds.
The automation / script I use (reacting on lumen outside and time of day) closes all curtains.
The first times i used the script the following happened some times:
After I introduced a 10 seconds pause between curtain commands solved this problem.
Now it’s running like a charme for a few months.
——
Manual commands quickly after each other to one or even more curtains show long delays.
Goodevening all,
DevWaves, thanks for this great project, it is all I need to get my curtains moving through HA. However…
I browsed the entire topic, to scan for any flaws in my setup. Can’t get it to work. Maybe some readers can point me at the obvious thing I missed.
Here we go:
my ESP32 is fine: it runs the sample sketches on WiFiscan and BLE scan perfect. My switchbot curtains show up on the BLEscan.
Loading V6.4 - ESP32 shows up on my router - Debug output set to true, and the output stops at “Starting NimBLE client”. Actually, that is the only output I see. No other debug data printed. Should it not report on wifi connection etc prior to this ?
My curtain definitions:
static std::map<std::string, std::string> allCurtains = {
{ "kamerlinks", "fb:1c:8b:a9:fb:eb" },
{ "Kamer-Midden", "d0:b5:b2:67:2e:53" },
{ "Kamer-Rechts", "eb:09:f0:be:9d:c4" }
};
Anything you guys/ladies seen before and I overlooked ?
Tnx
John
Only difference with my definitions is they are in all upper case. But that should not have any effect in my opinion.
So I guess that the issue is either in the libraries or somewhere in the source code.
I just tried with the exact same names you used and it works for me. So the issue is that it is either not connecting to your WIFI or not connecting to MQTT
a) not connecting to your WIFI
If you can access the OTA webpage, then you know WIFI is for sure working (or if you see it from your router)
b) not connecting to your MQTT broker
You should see a message on the MQTT topic with payload "{"status":"boot"}" as soon as the ESP32 connects to your MQTT, then you will see the HA MQTT discovery messages
I am also assuming you are using a 2.4ghz wifi, because the ESP32 does not support 5ghz
(ignore the crappy linkquality in my screenshots. I am testing from my PC that is too far to get good signal)
I have a feeling the curtains send out some kind of broadcast to other curtains when activated, which causes other curtains in the area to not accept commands for a few seconds. I would guess this broadcast is sent to find the linked curtains if they are in pairs. Just a guess though. Adding the delay like you did would fix that though so good job, glad that works for you. The bots don’t do this, but it sounds like the curtains do. Not sure if you meant you added a delay from HA side or by changing defaultCurtainWaitTime
If you changed the defaultCurtainWaitTime: defaultBotWaitTime/defaultCurtainWaitTime delay is actually intended to delay commands for one specific device if I remember correctly how I coded it. So if you wanted to control a bot and go ON, OFF, ON, OFF it will add a delay in between each command for that one bot. But if you had 2 bots, a command of Bot1 ON, then Bot2 ON should have no delay in between (other than the time to send the command). My guess of what is occurring is that the first commands are all sent out to the curtains but only the first one succeeds. The first curtain controlled will work, but then the others will fail on first command. Then the second attempt will work and so on
If that is what is occurring I can look into putting a delay for all curtain devices which would technically be better. I have defaultCurtainWaitTime set to 0 by default so that you can call PAUSE/STOP immediately after a position or OPEN command. With the way you have it setup with the delay you wouldn’t be able to do that
Can you please tell me if you see a bunch of failed or busy responses on the MQTT topic… <ESPMQTTTopic>/curtain/<name>/status
Messages would look something like this…
{"status":"busy", "value":3, "command":"OPEN"}
{"status":"failed", "value":9, "command":"OPEN"}
If you can confirm that for me, I will make the appropriate changes in a v6.5. Thanks
Thanks for the hints. I have to go back to basics first, as I am not even getting on the OTA page. 2.4Ghz indeed it is. Starting to troublesheet connectivity first. One hurdle already taken, my main SSID is //SPARKS\\… The backslashes you know…
Keep U posted, encouraging to see all the working configurations here, sure mine will make it as well.
EDIT: Escaped the backslashes with backslashes in the code and disabled MESH function for the node on my network. Fully up and running with 3 curtains !!
tnx
John
I’m traveling al lot at the moment and it will take some time before I’m able to look into your questions.
@JoepW No problem. You seem to have the most curtains I have seen so far so you are a good test subject. The code does retry on busy and failed responses for curtains, so it must just be reaching the limit of retries set. cheers
link quality is normally -64
the esp is maybe 6-7 feet from the curtain bots (on a lower shelf of a wood table next to the window)
the app response on button press seems to be near instant, as long as i am within range of it.
I’ll try placing the module a little closer to the curtains over the next couple weeks to see if it makes a difference.
