[APP][Cloud & Pro] SwitchBot (Release 2.0.30, Test 2.0.34)

This is my experience when using the ESP32 with data taken from the Log tab and reduce for clarity:

* 2025-07-04T07:00:10.438Z
* COMMAND: Setting curtain to:21
 …

* 2025-07-04T07:00:13.702Z
* [
  {
    "rssi": -63,
    "serviceData": {
      "model": "c",
      "modelName": "WoCurtain",
      "position": 44,
    }
  }
]

So, from the time that Homey picks up the UI request to the point at which the curtains send the first response because they are moving is about 3 seconds and they had already moved from 50% to 44% in that time. It’s very unlikely that the response can get much quicker than that.
But, to be honest, the main aim of the ESP32 is to improve the reporting time of changes. During that move, the position in Homey was updated via push notifications 3 times. Without the ESP32, Homey would have to poll the BLE to get updates, which adds a significant load on Homey and is only done every 10 to 30 seconds.

Using the hub I get:

* 2025-07-04T07:30:32.702Z
* Sending {
  "command": "setPosition",
  "parameter": "0,0,31",
  "commandType": "command"
} to EEDFC1EB307B using OAuth

* 2025-07-04T07:30:35.304Z
* [
  {
    "hubMAC": "ec:6d:38:b2:67:ac",
    "address": "EE:DF:C1:EB:30:7B",
    "rssi": -62,
    "serviceData": {
      "model": "c",
      "modelName": "WoCurtain",
      "calibration": true,
      "battery": 30,
      "position": 39,
      "lightLevel": 2
    }
  }
]

* 2025-07-04T07:30:39.333Z
* Got a webhook message! {
  "eventType": "changeReport",
  "eventVersion": "1",
  "context": {
    "battery": 40,
    "calibrate": true,
    "deviceMac": "EEDFC1EB307B",
    "deviceType": "WoCurtain",
    "group": true,
    "slidePosition": 30,
    "timeOfSample": 1751614239211
  }
}

So, about 3 seconds from sending the command until the ESP32 reports the movement, but about 5 seconds before the webhook reports it.

Therefore, the ESP32 is marginally quicker at sending commands than the HUB method, faster at reporting the changes and supports more capabilities on most devices without polling. Also, it is a totally local interface, so no internet required.
I originally produced the ESP32 solution to improve the response of the door opening device and report information that’s not supported via the API

Hmmm when I look into the log i get this:

* 2025-07-03T02:23:00.689Z
!!!!!! Error EHOSTUNREACH: connect EHOSTUNREACH 192.168.1.23:80

* 2025-07-03T02:23:00.726Z
!!!!!! HTTP Catch: connect EHOSTUNREACH 192.168.1.23:80

* 2025-07-03T02:23:00.742Z
!!!!!! connect EHOSTUNREACH 192.168.1.23:80

* 2025-07-03T02:23:00.750Z
!!!!!! HTTP Catch: Error: connect EHOSTUNREACH 192.168.1.23:80

* 2025-07-03T04:03:02.275Z
!!!!!! HTTP Catch: Timeout

* 2025-07-03T04:03:02.286Z
!!!!!! socket hang up

* 2025-07-03T11:10:06.271Z
!!!!!! HTTP Catch: Timeout

* 2025-07-03T11:10:06.281Z
!!!!!! socket hang up

* 2025-07-04T00:04:12.492Z
!!!!!! HTTP Catch: Timeout

* 2025-07-04T00:04:12.500Z
!!!!!! socket hang up

* 2025-07-04T05:12:10.125Z
!!!!!! Error ECONNREFUSED: connect ECONNREFUSED 192.168.1.38:80

* 2025-07-04T05:12:10.128Z
!!!!!! HTTP Catch: connect ECONNREFUSED 192.168.1.38:80

The 2 IP’s are my ESP32…

How is this possible and how to fix this?

I cannot find any ‘evidence’ that the switchbot app in Homey is using the ESP32 at all, execp the error i pasted here.

I set log to BASIC and moved 1 curtain via BLE in Homey, but it does not show any logs what referred to any ESP32 module.

What is going wrong here?!

Both Homey and the ESP modules should work on the same LAN, within the same subnet.
The wifi coverage should be ok.

If your Homey Pro is connected by Wifi as well this should be ok.

If Homey is connected by an ethernet cable, check if there is no switch in between router and Homey which filters data for any reason.

So Homey made an announcement that the Hub3 is now fully (?) supported. However, when I look at the app and click on the hub3, I only see sharing of values (temperature etc) and not a combination with the dials and screen. Or am I mistaken and is support expanded (i.e. two way communication)?

Hi, is it possible to start a scene, from the switchbot remote, to … well… turn on lights or the tv via homey.

I have the remote and a mini hub matter from switchbot, and want to control some lights and turn on some sockets to turn on the tv.

I have the lights and tv working via homey, but would be nice to also be able to start them via the switchbot remote.

I cant find the answer/solution and i think (am afraid) that its not even possible unfortunately.

Anybody ? (the forum is veeeery long so cant check all 1704 messages..)

The remote is not available to Homey, so certainly can’t use it directly.
The only possibility is if the remote activates some other SwitchBot device that can make a trigger.

SwitchBot don’t publish notifications for any of the controls or make the display available, so it’s not possible to support those.

1 Like

Thanks (again) for your reply. I thought that maybe with this official announcement things had expanded :slight_smile: Let’s hope that happens in the future!

They are in same network and subnet, wifi coverage is also oke.
Homey itself is wired connected (and in same subnet etc) and connect all devices within the network.

1 Like

Thanks Adrian. So when i :

  1. buy a random Switchbot product lets say a Switchbot Bot
  2. install it (on the remote)
  3. push button on remote that switches the Switchbot Bot on, and also starts scene X.
  4. in homey adv flow: when scene X starts, turn on lights and tv

Correct?

If so… any idea when this remote and homey will/can be integrated more?
Homey even pushed a story in the last email about Switchbot update and integrated better, but this is still missing then..

1 Like

Close, but Homey isn’t notified of scenes starting so you would need to trigger from the bot turning on.

If you point your browser at the ESP32 ip address do you see the web interface?

I’m not sure what mailing you received, but I got this one

(it just doesn’t say anything in my eyes)

I think he means this email that brings you to this website.

https://mailchi.mp/switchbot/unboxtherapy-13837180?e=dc76249b9c

Thanks all for replying.

Indeed referring to that email. “more switchbot devices, fully supported”. Well, not all devices for sure.

I’m not using a esp32, only q mini hub matter supported version.

Guess I’ll have to wait and hope for better integration..

Somehow if i want to sent the error log i get “error: aborted”. I will sent you a screen shot. When i go to “onderhoud-probeer te repareren” and i fill in the account details the error disappears most of the time.