SwitchBot gets an open API!

⚙️ Custom Apps and Drivers
21

@dadarkgtprince did a fair amount of testing and debug with me. Thanks for that!

I updated with some improvements to the code on GitHub and bumped the version so that HPM updates will pick them up. Please let me know if anyone has additional feedback for the Curtain driver.

1 Like
22

Can't wait to try this out .... no shipment date yet :slightly_frowning_face:

1 Like
23

Does anyone know what the switchbot uses to communicate other than Bluetooth? If it uses RF at 433MHz, I wonder if you could get one of these flashed with tasmota to get local control. Not sure if these can control multiple devices though.

24

Hi all!

I just got this working with my curtains. Thanks for making the driver! Your readme guide was well written.

I run my curtain device in switch mode and can expose it to Google home. I then make a routine to use the voice commands "Open the curtain" and "Close the curtain" to turn on and turn off the switch respectively.

My only points of feedback for curtain use of the driver:

  1. I don't know if this is possible since making it a 'switch' makes it an easy installation, but using a "Open" and "Close" command for the device would be more intuitive than "Turn on" and "Turn off".
  2. I would suggest modelling this after a "dimmer" device instead of a switch to allow for percentage setting, so the curtain can be opened halfway. I see that there is a 'setPosition' option in the API, so perhaps that can be used?
2 Likes
25

I do support the WindowShade capability, which exposes open(), close(), and setPosition() commands in Hubitat. I'm not sure if these can be mapped to device types in things like Google Home and Alexa, though. They're there for use where they're relevant, though.

Dimmer is a great suggestion, and it should be trivial to add. I'll make the change and send you something in PM to try before I push it live.

1 Like
26

At least for Alexa, it is simple enough to create routines that use open/close as trigger words.

1 Like
27

Thanks for your idea and testing help @rudyscoggins.

The SwitchLevel functionality as well as a critical bugfix with setPosition from WindowShade are in version 0.9.4 on GitHub and updated in HPM.

2 Likes
28

Sorry, we had a family thing come up... let me get this installed now...

1 Like
29

Hi,

I have two SwitchBot Curtain Rod devices
I am trying to use TOMW SwitchBot Curtain Driver v 0.9.4
Everything is working but after few minutes status of
"switch" and "windowShade" changes to "unknown".
This way it is impossible to create a reliable rule.
I can introduce a Local Variable fo the reliable status
tracking but why this is happening and how to fix this?

Thank you,

  • Vitaliy
30

Hi,

I will be very interested in any local control solution.
Being Home Automation enthusiast for about 25 years
I have very strong opinion all Home Automation must
be LOCAL. All these CLOUDS must not be a part of
Home Automation.

Thank you,

  • Vitaliy
1 Like
31

Does the Switchbot curtain motor unit have to sit in plain view, or can it be mounted/connected so it's on the back-side of the curtains. Wife took a look and was not happy about the "huge white thing" (her words) on the curtain rod. :slight_smile:

32

Backside is easily done . :+1::+1::+1:

1 Like
33

Yes! Thanks, that's good news...

1 Like
34

This must be due to missing data in the response from SwitchBot. I have seem some instances where the replies from the API have incomplete info if it is more of a idle state status check than requests to update status shortly after an actual command or other operation to the device. I suspect that this is unintentional and/or a bug from the SwitchBot API.

I'll tweak the driver to only update the states if there is an actual status reported (instead of toggling to "unknown" if it is not reported).

1 Like
35

Hi TOMW,

Thank you very much.
I will wait for the driver update.
Is it any way to bypass Cloud all together?

I am trying to find small enough Zigbee or ZWave
motor controller and replace with it Bluetooht one
inside the SwitchBot Curtain device.
I am desperately trying to remove all cloudiness
on a horizon. Sky must be clean and Sunny.

Thank you,

  • Vitaliy
1 Like
36

Maybe. And I agree that it would be strongly preferable. The problem is that Hubitat does not have BLE/Bluetooth connectivity, so you have to use an external piece of hardware.

I have been using this with a Raspberry Pi Zero W: GitHub - OpenWonderLabs/node-switchbot: The node-switchbot is a Node.js module which allows you communicate with SwitchBot Devices over BLE

I have had great results with getting updates working locally where data came from a SwitchBot device (HT sensor, Bot) about its status. I have a version running locally which is relaying the temp/humidity measurements without cloud interaction, for example. I may release this as a configurable option on my Hubitat driver along with a small application which I wrote that is required on the node.js side.

However, devices that require commands (Bot, Curtain) are not as reliable. Sometimes they do not respond, and I suspect that there are arbitration issues for access to the device between the SwitchBot hub and the local access. And, this is an unsupported API so it is unsurprising that it has some reliability issues. And I don't have a Curtain module, so I can't adequately develop and debug the local integration.

37

Hi TOMW,

This is very interesting info.
Let me think about using Raspberry PI.
I am very experienced EE with somewhat good
C/C++ programming skills. Unfortunately I never dealt
with OSes. I guess, it is time to learn something new.

Thank you,

  • Vitaliy
38

This is posted in version 0.9.5 and is also updated in my HPM repo.

1 Like
39

Hi TOMW,

Thank you for the updated Curtain Driver.

  • Vitaliy
1 Like
40

I just updated to a new version (0.9.6) on GitHub and in my HPM listing, which adds support for humidifier devices. Thanks for the suggestion and testing help, @beetleBaum