Switchbot Curtain

Thanks for this.

Any idea how to run swtichbots.js on boot? i’ve google and tried a couple of solutions without success. im running the official Raspberry Pi OS as user pi

Also, im getting this reply error intermittently - almost every other time - from the node js server.

Error: Failed to discover services and characteristics: DISCONNECTED

i can solve it for the curtain, but running the URL shell_command multiple times. but can’t use that workaround for switchbot switches that toggle devices… any clues?

To have the script start on boot:
Create a file call switchbot.service at /etc/systemd/system

add these text to the switchbot.service file. Make sure you change the path to the switchbot.js file base on your setup.

# Switchbot
[Unit]
Description=switchbot.js - Switchbots
After=network.target

[Service]
Type=simple
User=root
ExecStart=/usr/local/bin/node /home/pi/bin/mqtt/switchbot/switchbot.js
Restart=on-failure

[Install]
WantedBy=multi-user.target

Run this cmd to have the script start on every boot.

sudo systemctl enable switchbot.service

i can solve it for the curtain, but running the URL shell_command multiple times.

I am getting this as well. The author has mentioned this and am aware of it. Though there is no fix. I think it is a limitation of the BT on the PI?. A suggestion was to create a longer scan time, but I don’t think this will solve it.

Interference may be another possibility. I run Monitor on a different pi and I notice that pi picks up quite a few BT devices at different intervals. These BT devices are not mine.

How far is the bot to the pi?

thank you for that. occasional linux user here. sometimes i run myself in circles. node js service running fine on boot now

i’ve got 1x curtain and 2x switches. one switch is pretty close and seems to suffer about the same, i cant see a pattern. when it fails, it fails very quickly.
it seems pretty reliable on second go… in the HA script, i might try running a “dummy” command first to wake it up…something like
http://10.0.50.145:5004/?id=c398d5769d42&cmd=battery
then
http://10.0.50.145:5004/?id=c398d5769d42&cmd=press

i’ve got 1x curtain and 2x switches. one switch is pretty close and seems to suffer about the same, i cant see a pattern. when it fails, it fails very quickly.

I have one switch that is literally right next to the pi with a wooden panel between them. It triggers always on cmd. I have another switch that is in the same room as the pi, but separated by a wall. This one does not trigger all them time on cmd, however.

Overall, this method is better for me then using the switchbot integration as the HA server is quite far. Moreover, this method can track battery life.

i might try running a “dummy” command first to wake it up…something like

This sounds like a good workaround. For my curtain bots, I have 2 sets of the curtain bots ( 4 bots total)to run 2 curtains in the Livingroom. I have an automation to open and close the curtains at sunrise and sunset. To prevent both sets of bots to trigger at the same time, I’ve added a one second delay so both cmds do not fire at the same time.

similar experience.

NOTE; the additional dummy commands don’t help. if anything it make the problem worse.

i think it’s a combination of things. i think pi bluetooth signal is weak which contributes to the problem - particularly in a noisy 2.4Ghz environment. the Curtain seems a lot stronger signal than the switches.

the Home Assistant integration is more reliable than this relay. i have seen it fail, but i think it fails gracefully and retries and gets the job done most times. i see retrys in the HA logs.

This relay implementation - if it fails first time it seems to hang for longer and contribute to future failures.
I’ve repositioned my relay Pi. im still getting maybe 10% failures to curtain and 30% failures to switches. but it’s almost 100% success on 2nd try after failure. so the whole thing is currently bearable. i hope the devs update node-switchbot relay to a more reliable retry? maybe there is a &retryonfailure swtich. i dont have to skills to contribute, but i’ll head over to github and contribute what i can.

as a workaround - i might try and make my HA shell_commands read the successful "OK!"and try again on failure or at least show an error to the user.
duceduc - does your HA implementation do that? im using a CURL command to fire the URL. ill have a play.

cheers

as a workaround - i might try and make my HA shell_commands read the successful "OK!"and try again on failure or at least show an error to the user.

I have updated the script.js to have a ok/error check via mqtt. Every time you call the bot, it will either have ok or error message output to mqtt.

From there you can create a sensor and use it to re run the bot if it outputs error. You will need to think how you can implement this check for all your bots. I was testing it on the bot device using script. Seems to work. The below script template will run 10 times or until until sensor.switchbot_status state is ok.

script.yaml

  switchbot_bot_enable:
    sequence:
    - repeat:
        until:
        - condition: or
          conditions:
          - condition: template
            value_template: "{{ is_state('sensor.switchbot_status', 'ok') }}"
          - condition: template
            value_template: "{{ repeat.index % 10 == 0 }}"
        sequence:
        - service: switch.turn_{{ mode }}
          data:
            entity_id: '{{ bot }}'

automation.yaml

- alias: 'turn on 24hr fan'
  trigger:
    platform: time
    at: '05:30:00'
  condition:
  - condition: template # Not on Vacation
    value_template: "{{ not is_state('input_select.home_mode', 'Vacation') }}"
  - condition: template # Someone is home
    value_template: "{{ not is_state('input_select.home_mode', 'Away') }}"
  action:
    - service: script.switchbot_bot_enable
      data:
        mode: 'on'
        bot: switch.24hr_fan_bot

- alias: 'turn off 24hr fan'
  trigger:
    platform: time
    at: '23:00:00'
  condition:
  - condition: template # Not on Vacation
    value_template: "{{ not is_state('input_select.home_mode', 'Vacation') }}"
  - condition: template # Someone is home
    value_template: "{{ not is_state('input_select.home_mode', 'Away') }}"
  action:
    - service: script.switchbot_bot_enable
      data:
        mode: 'off'
        bot: switch.24hr_fan_bot

sensor.yaml

  - platform: mqtt
    name: 'Switchbot Status'
    state_topic: 'switchbot/status/msg'
    value_template: '{{ value }}'

Guys, I’m planning to buy Switchbot Curtain but I have some doubts.
I have NAS with Docker HA installed 2nd floor and curtains which I wish to control on 1st floor. Im pretty sure of that Bluetooth range will not cover that place.

Is it possible to extend a range of bluetooth or mage Rpi Zero as some kind of extender or bridge?
Upper you wrote about switchbots.js as I understand I have to install it on Rpi0? This connect via MQTT with my Mosquito Broker on NAS?

So the communication looks like:
SwitchBot -- (BT) --> Raspberry Pi -- (MQTT - WiFi) --> NAS with MQTT

Did I understand correctly?

Hi.
That looks right. Though mqtt is optional if you don’t care about knowing the data of the bot. My pi 3 is connected via wire, but I am sure wifi will work as well. Just make sure the pi zero has good wifi coverage.

You have the pi zero W? Let us know how it goes if you are going to go forward with it. I am thinking about switching over to a rpi zero w myself.

Is it possible to extend a range of bluetooth or mage Rpi Zero as some kind of extender or bridge?

I am not sure if that is possible or if it is, it maybe not worth the trouble not knowing how far it can be extended.

Is anyone integrate Switchbot Curtain via BT-MQTT-GATEWAY (https://github.com/zewelor/bt-mqtt-gateway)?
Yesterday with success I installed this on my old RPi0 and connected to Xiaomi Thermostat.
In documentation it support Switchbot but I didn’t found information if it support Curtain.

Hi Everyone,

My set up is HA installed via docker on a NAS in the basement and the curtains are in the bedroom two floors up. I do have the Hub in the bedroom.

I recently purchased the switchbot curtain and it works very well. I’m also starting out with HA for the 4th time. I integrated the curtain via mac and it does show up in HA. However, none of the buttons do anything. I’m assuming that is because it’s trying to communicate via BT and it can’t reach it.

I’ve read through this entire thread and I’m not more confused than I started. I’ve tried using the mac of the curtain, hub and BLE but only the mac for the curtains show up as pressable buttons (which again don’t do anythign when clicked).

Is there a way to integrate the HUB to control the curtains in HA?

TIA

The curtain integration provided by the user above works by communicating with HA via BT and not the Switchbot Hub. Since your HA is install 3 floors down, it is out of range. Does your NAS have BT?

As far as I know, there is no HA Integration to talk to the hub. However, there is a switchbot api method you can try which needs the hub to communicate. Request a token via the mobile app feedback. I don’t have a hub to test. But an example of a way to trigger via HA is by curl.

curl "https://api.switch-bot.com/v1.0/devices" -H "authorization: YOUR_TOKEN_KEY"

The downfall to the api method is that, if you lose internet connection, you will not be able to trigger your devices. An alternative is to move your HA closer to the curtain device or install another server (ex. rpi) and try my method.

There is another method I have found recently that uses ESP32 to connect to the device. It is setup for 2 bot devices and the author claims it should work for the curtain devices as well, but not tested.

ya it should work with curtains, but I would have to make a couple code changes. It currently only does push. Shouldn’t be difficult to make the changes for open/close calls. I can look at that this weekend if someone wants to test

I have updated my esp32 code

  • it is now setup to work with “unlimited” devices
  • it works with press/on/off (buttons)
  • it works with open/close/pause (curtains)

I’ve read your guide again and it seems the switchbot hub is needed with this setup? I don’t have the hub to test.

no switchbot hub needed for my esp32 setup. Any smarthub that can do MQTT works.

HA <–(MQTT)–> ESP32 <–(Bluetooth BLE) --> switchbot

thanks for this. Reading your guide, i’m not sure if this will work in my situation as all i have is the switchbot hub. I’m also still having issues getting Mosquitto MQTT to work properly on my Qnap Nas. I took a look at the switchbot api solution as well and that was a bit over my head.

I do however have an old smartthings hub laying around somewhere thats not being used. not sure if that would help.

I was hoping there was a solution for HA (in docker on a QNAP NAS) > Switchbot Hub > Switchbot Curatin.

If you don’t mind using the api, which means you’ll need an active internet connection for this to work, it’s quite easy to get it working. I’ve posted instructions here: Switch-Bot API integration - Feature Requests - Home Assistant Community (home-assistant.io)

there are a couple solutions. you just need to decide which one suite your needs. using the switchbot hub is a solution but will always require internet access as mentioned

If you want full local control you need to do it with bluetooth BLE. You can either have your smarthub make the bluetooth calls or have your smarthub call something else, and that something else makes the bluetooth calls.

for me, my main switchbot is too far from my smarthub to be reliable. This is why I wrote the esp32 option. an esp32 cost $5.

my esp32 option avoids the hassle of ensuring the linux box bluetooth is configured correctly. you don’t use the bluetooth on the linux box.

1 Like

Thank you for your code. I tested it and it is working impressively good.
I noticed a bug with the position of the curtains, which is reported after using requestInfo.
Independently from the state of the curtain it always reports the same position.

yes there is an issue with the curtain and meter values I am hoping to get to that this weekend

the control part should be pretty solid though. I put in a couple fixes recently