Cool, nice to see it works for you 
The repeated calls are a status update call, to see what the current status of the device is. It is controlled by the refreshInterval parameter. Normal behaviour thus.
1 Like
How do I get this for my Switchbot, I don’t see it in the bindings? sorry pretty new at this…
I’m working on replicating this and I get an error when I try to run the last line: (sudo pip install bluepy)
sudo apt-get update
sudo apt-get install python-pexpect
sudo apt-get install libusb-dev libdbus-1-dev libglib2.0-dev
sudo apt-get install libudev-dev libical-dev libreadline-dev
sudo pip install bluepy
openhabian@openhabian:~ $ sudo pip install bluepy
sudo: pip: command not found
If I try to run the script, I’m getting “No module named bluepy.btle”
I have an RPi 3 that has Bluetooth, so I do not have a dongle.
I found the issue, used
sudo pip3 install bluepy
I spoke too soon, I still have an issue when I try to run the script from the Pi where is the Mac Address of my device:
openhabian@openhabian:~/python-host $ python switchbot.py <mac add> Press
Traceback (most recent call last):
File "switchbot.py", line 17, in <module>
from bluepy.btle import Scanner, DefaultDelegate
Hi all,
just FYI, OpenMQTTGateway has almost all (save for the Plug Mini) SwitchBot devices integrated into its BLE gateway, with the Bot control already directly implemented, and the Curtain control working by direct MQTT commands so far. The remaining SwitchBot devices are status read only, e.g. Motion Sensor, Contact Sensor …
So with a small ESP32 and OpenMQTTGateway installed on it this is fully compatible with the OpenHAB MQTT implementation, including auto-discovery.
1 Like
The challenge is that the documentation is written for those who already understand it. It is not a tutorial on ‘how’ to do it. The original post was somewhat a step-by-step tutorial, but the issue is that it is now outdated, doesn’t work and no one seems to know how to fix it.
I use this gateway implementation which is pretty easy to use and also offers auto detection:
However I agree that a solution like this, even if easily configurable, is not something for everyone.
Apologies, I just assumed that with a web installation on an ESP32 would be quite easy, and then receiving MQTT states (stateTopic) for all the implemented SwitchBot devices, and being able to control them with MQTT commands (commandTopic) would be manageable with so many other MQTT tutorials already in the forum. But as DrRSatzteil stated above, it’s not for everyone, especially if there is no previous experience with MQTT.
Unfortunately, since I’m using all textual configurations, I’m not the best one to give an easy tutorial either, but a search for OpenMQTTGateway or the above mentioned gateway should come up with many results for other device’s implementations, adhering to the same paradigm. And once familiar with the general OpenHAB MQTT functionality it opens up a a wide range of future device possibilities, without the need for specific bindings or scripts.
EDIT - a tutorial has just been posted
No doubt if you have an ESP32, all the required pieces, and know how to use it, then it would be simple.
I have the same question. I’m using OH 3.2.0
I can’t find the Switchbot binding
Hi,
thanks dietah for your post 
. Unfortunately I have problems with the deployment.
I’m using a Raspi 4B with Raspberry Pi OS (64-bit). On the Raspi, there are running OH and MQTT containers. I’m using Portainer for container administration. I have connected a z-Wave USB-stick and the EnOncean Pi module on GPIO of the Raspi. My plan is to use the internal Bluetooth interface on the Raspi to control Switchbot switches.
I tried the following according to your readme. I am listing everything in detail as I am still quite a beginner:
- Installing of the necessary Bluetooth libraries => worked well
sudo apt-get install bluetooth bluez libbluetooth-dev libudev-dev
- Read out Bluetooth interface (i have changed Bluetooth to mini-UART because of the EnOcean Pi on the GPIO):
root@*******:~# ls -l /sys/class/bluetooth
insgesamt 0
lrwxrwxrwx 1 root root 0 10. Aug 01:19 hci0 -> ../../devices/platform/soc/fe215040.serial/tty/ttyS0/hci0
As far as I understand, Bluetooth is now on device /ttyS0/hci0
- Own directory created for the switchbot container
mkdir /opt/switchbot
- The docker-compose.yml is created in it (mode privileged: true and network_mode: host added):
version: '3.6'
services:
mqtt-switchbot:
container_name: switchbot
image: deetoreu/mqtt-switchbot
restart: always
privileged: true
environment:
MQTT_HOST: "192.xxx.xxx.xxx"
MQTT_PORT: 1883
MQTT_USERNAME: xxxxx
MQTT_PASSWORD: xxxxx
MQTT_TOPIC: switchbot
LOG_LEVEL: "DEBUG"
SCAN_DURATION: 5*1000
DEVICE_LIST: "xx:xx:xx:xx:xx:xx,xx:xx:xx:xx:xx:xx"
devices:
- "/dev/ttyS0"
- "/dev/hci0"
- "/dev/ttyS0/hci0"
network_mode: host
volumes:
- ./volumes/switchbot/logs:/usr/src/app/logs
- Apply the container with:
docker-compose -f docker-compose.yml up -d
The switchbot container is running well according to Portainer. Unfortunately, I still don’t see any incoming topics from the Switchbot switch in the MQTT Explorer 
I have also checked Bluetooth connections with
sudo bluetoothctl
agent on
default-agent
scan on
The switchbot switches are listed and have good RSSI values. So I think that the Bluetooth connection generally works.
- In OH I created a generic MQTT thing, created an on-off switch as a channel and adapted the code for the value to be transferred:
UID: mqtt:topic:2e5f0240eb:Switchbottest
label: Switchbottest
thingTypeUID: mqtt:topic
configuration: {}
bridgeUID: mqtt:broker:2e5f0240eb
channels:
- id: Switchbottest
channelTypeUID: mqtt:switch
label: Switchbottest
description: ""
configuration:
commandTopic: /switchbottest
stateTopic: /switchbottest
off: switchbottest/switch/xx:xx:xx:xx:xx:xx/set off
on: switchbottest/switch/xx:xx:xx:xx:xx:xx/set on
The topic with the values arrives correctly at the MQTT broker.
Unfortunately, the Switchbot switch is not responding. Anyone have any ideas what could be wrongly configured? Are the topic settings in the .yml correct? Should the Switch also send it’s status (battery, linkquality) after operate with the Switchbot app?
Hello, is it possible to recover theaddon-binding.jar file somewhere because I don’t have the skills to compile it myself. thanks in advance.
am under openHAB 3.4.4 on an openhabian RPI4
Hi
Can you help me to do this because I am totally beginner. THANKS
Just adding my attempts to make this work, low code mostly just configuration through UI so far. My goal would be to turn this into the start of a binding if it ends up working out.
I’m running OH4 on RP4.
The target device is the SwitchBot Curtain 3.
I followed this tutorial from oh3 which seemed to work out, adding mosquito service to the same raspberry pi running openhabian (hostname is just localhost), adding the MQTT binding and broker bridge through the UI, and then I ran TheengsGateway on demand to test it out.
I then ran MQTT-Explorer’s UI on my windows laptop and connected to it using the local network IP for my raspberry pi.
And this almost worked. I saw the events in MQTT-Explorer with "mfr": "Woan Technology (Shenzhen) Co., Ltd." in the json body. Which seems to be the actual device manufacturing company for SwitchBot devices. I later confirmed with the vendor distributed python-host scripts (linked in the thread’s original post) that the MAC addresses were the same ones which it detected.
However, it seems that Theengs might not be supporting the Curtain 3? Or else there’s something wrong with my board’s bluetooth service, as no events from the devices were properly decoded, and when I tried pasting the raw events to their webparser (click on “Web Parser” in the top right on their docs website), I got Error: Cannot read properties of undefined (reading 'properties'), so clearly not fully implemented or something.
The python-host script kept running into failures for me when running it on my raspberry pi, and using bluetoothctl to attempt manual connections kept failing as well:
I'd often see errors like this from the script
$ sudo python3 switchbot_py3.py --scan
Scanning for bluetooth low-energy devices
Discovering Switchbot services
PyGattLib ERROR: connect error: Function not implemented (38)
free(): double free detected in tcache 2
Aborted
or it would get futher and then error out
$ sudo python3 switchbot_py3.py --scan
Scanning for bluetooth low-energy devices
Discovering Switchbot services
* Found Switchbot service on device <MACADDR> handle 16
PyGattLib ERROR: connect error: Function not implemented (38)
free(): double free detected in tcache 2
Aborted
when I tried specifying the device and giving a command with the script, I'd get similarly abysmal results
$ sudo python3 switchbot_py3.py --device <MACADDR> -c close
Connected!
Traceback (most recent call last):
File "/home/openhabian/python-host/switchbot_py3.py", line 210, in <module>
main()
File "/home/openhabian/python-host/switchbot_py3.py", line 205, in main
driver.run_command(opts.command)
File "/home/openhabian/python-host/switchbot_py3.py", line 154, in run_command
return req.write_by_handle(self.handles[command], self.commands[command])
gattlib.GATTException: Characteristic value/descriptor operation failed: Attribute can't be written
using `bluetoothctl` while `TheensGateway` was not running, connecting would work, but pairing wouldn't
$ bluetoothctl
Agent registered
[CH G] Controller <Ctlr MACADDR> Pairable: yes
[bluetooth]# connect <SwitchBot MACADDR>
Device <SwitchBot MACADDR> not available
[bluetooth]# agent on
Agent is already registered
[bluetooth]# default-agent
Default agent request successful
[bluetooth]# pairable on
Changing pairable on succeeded
[bluetooth]# discoverable on
Changing discoverable on succeeded
[CHG] Controller <Ctlr MACADDR> Discoverable: yes
[bluetooth]# scan on
Discovery started
[CHG] Controller <Ctlr MACADDR> Discovering: yes
[NEW] Device <SwitchBot MACADDR> <SwitchBot MACADDR>
[bluetooth]# connect <SwitchBot MACADDR>
Attempting to connect to <SwitchBot MACADDR>
[CHG] Device <SwitchBot MACADDR> Connected: yes
Connection successful
[NEW] Primary Service (Handle 0xb584)
/org/bluez/hci0/dev_<SwitchBot MACADDR>/service0001
00001801-0000-1000-8000-00805f9b34fb
Generic Attribute Profile
[NEW] Characteristic (Handle 0x006c)
/org/bluez/hci0/dev_<SwitchBot MACADDR>/service0001/char0002
00002a05-0000-1000-8000-00805f9b34fb
Service Changed
[NEW] Descriptor (Handle 0x84fc)
/org/bluez/hci0/dev_<SwitchBot MACADDR>/service0001/char0002/desc0004
00002902-0000-1000-8000-00805f9b34fb
Client Characteristic Configuration
[NEW] Primary Service (Handle 0xc6e4)
/org/bluez/hci0/dev_<SwitchBot MACADDR>/service000e
cba20d00-224d-11e6-9fb8-0002a5d5c51b
Vendor specific
[NEW] Characteristic (Handle 0x006c)
/org/bluez/hci0/dev_<SwitchBot MACADDR>/service000e/char000f
cba20002-224d-11e6-9fb8-0002a5d5c51b
Vendor specific
[NEW] Characteristic (Handle 0x006c)
/org/bluez/hci0/dev_<SwitchBot MACADDR>/service000e/char0011
cba20003-224d-11e6-9fb8-0002a5d5c51b
Vendor specific
[NEW] Descriptor (Handle 0x84fc)
/org/bluez/hci0/dev_<SwitchBot MACADDR>/service000e/char0011/desc0013
00002902-0000-1000-8000-00805f9b34fb
Client Characteristic Configuration
[CHG] Device <SwitchBot MACADDR> UUIDs: 00001800-0000-1000-8000-00805f9b34fb
[CHG] Device <SwitchBot MACADDR> UUIDs: 00001801-0000-1000-8000-00805f9b34fb
[CHG] Device <SwitchBot MACADDR> UUIDs: cba20d00-224d-11e6-9fb8-0002a5d5c51b
[CHG] Device <SwitchBot MACADDR> ServicesResolved: yes
[CHG] Device <SwitchBot MACADDR> Name: WoCtn3
[CHG] Device <SwitchBot MACADDR> Alias: WoCtn3
[CHG] Device <SwitchBot MACADDR> RSSI: -77
[CHG] Device <SwitchBot MACADDR> ServicesResolved: no
[CHG] Device <SwitchBot MACADDR> Connected: no
[bluetooth]# pair <SwitchBot MACADDR>
Attempting to pair with <SwitchBot MACADDR>
[CHG] Device <SwitchBot MACADDR> Connected: yes
Failed to pair: org.bluez.Error.AuthenticationFailed
[CHG] Device <SwitchBot MACADDR> Connected: no
So, I’ll likely try again with another RP or some other bluetooth device so I can confirm that the SwitchBot is not the problem.
If the problem is Theens decoding just not having an implementation for Curtain 3, then my options become quite limited, as C/C++ is not my strong suit at all, but I’ll probably give it a go if that turns out to be my only option. I’d have to make some sort of sense of the github documentation for the curtain’s BLE interface first though. I did confirm that the UUIDs match with that document, and they are still the same. Just need to figure out what the authentication failure might be for 
Otherwise, maybe I’ll figure out an arduino/esp32-based solution.
That could well be, as we haven’t had any feedback or sample raw advertising data for Curtain 3 yet. And with the change from Curtain to Curtain 2 having had changes that were easily added I suspect the same with Curtain 3.
If you set
-padv PUBLISH_ADVDATA, --publish_advdata PUBLISH_ADVDATA
Publish advertising and advanced data (1) or not (0)
(default: 0)
to 1 and give some sample Curtain 3 undecoded advertising servicedata messages I’m sure we can add them easily to Theengs Decoder.
OpenMQTTGateway uses the same Theengs Decoder library, but also has the advantage of being able to directly send commands to the SwitchBot devices with its WRITE command.
Oh wow, thanks a ton for your quick reply! Was honestly not expecting anyone to be monitoring this thread.
What! This is the best news, alright let me grab some.
Okay, I opened a issue on the github project with some sample data: Include decoding support for SwitchBot Curtain 3 · Issue #469 · theengs/decoder · GitHub
Not sure if you’re a contributor to the github or not, but let me know if I can pitch in for the change. As I said, I’m somewhat of a novice with C/C++ but I wouldn’t mind the chance to learn about it and the project!
I’m mainly contributing to the Theengs Decoder BLE library, and we set it up that all device decoders are defined in a (fairly 
) simple JSON format, so that no C/C++, Python etc. knowledge is necessary.
How these JSON definitions work is described at
for anyone who wants to add or collaborate on any new devices which broadcast useful data in their BLE advertising data.
1 Like
Once @Hans_Lree updated TheengsDecoder, I was able to upgrade it (after having to upgrade pip 20=>23) and run the gateway as a service, as described here:
just add User and Group as openhab or whatever user on the device you installed the python modules with, and add ExecStart as /usr/bin/python -m TheengsGateway. If your python installation is not at /usr/bin/python or you’re not sure where it is, run which python or which python3 and use that instead of /usr/bin/python
Once the gateway is running on the bluetooth enabled raspberry pi, you’ll see events coming in.
I think it’s only reading the data, however, not sure if there’s any writing capabilities, so you might not be able to tell the curtains to open or close, for instance, which is what I was hoping for
I’ll need to experiment more with the github linked in the original post to see if I can get that part working or not, but monitoring is working perfectly.
Correct, currently Theengs Gateway does not have READ/WRITE capabilities, but as I commented on GitHub, OpenMQTTGateway on an ESP32, which uses the same Theengs Decoder library for decoding can issue READ/WRITE commands to Bluetooth devices, making it possible to also control your curtains.