Add Local API Support

[niemyjski]

Is your feature request related to a problem? Please describe.

It's extremely important to control this hub and products locally (preferably via mqtt or http). Having cloud dependencies doesn't work when networks go down or companies go under or kill a product line.

Describe the solution you'd like

I'd like to control my devices locally and get metadata about them (firmware version info, current state, etc).

Describe alternatives you've considered

Additional context

From reading I thought you were working on a local api for the hub but it's only a cloud api.

References #12, #13 where I asked a question if this for the cloud api or local control.

[nigels0]

If you won’t develop this, then please publish the calls to the hub so that the community can do it.

[mvevitsis]

Give us local control! No cloud!

[Nardol]

A local API would be essential. Moreover, with no rate limit as 1000 per day is really poor, especially for meters. Having the temperature updated without the ability to do it even one time per minute is not enough precise. A local API doesn't need to take in account servers charge so it is another argument to make it or to communicate users how to communicate with a Switch-Bot hub (every models).

[AdyRock]

I have written an app for the Athom Homey to integrated SwitchBot devices into users home automation systems. Currently the app has nearly 300 users but I get many that are disappointed by the slow response of devices due to the rate limit. Most users have at least 2 or 3 SwitchBot devices that need to be kept up to date and as the limit is on the total number of calls and each device needs one call to update it, it means each one only gets updated about every 5 minutes. If a user wants to turn on lights when the curtains close via a remote, 5 minutes is a long to to wait in the dark. I am trying to educate users to dump the SwitchBot remotes and use Homey to control everything. My app also communicates directly via BLE if the devices are close enough to Homey which does solve some of the issues. If Homey is not in range, then I encourage users to buy a £7 ESP32 module and load my Arduino code. That can interface to the devices via BLE and reports back to Homey via an HTTP callback over WiFi. However, if the SwitchBot hub supported a good local API then I could recommend that instead of the other inconveniences that put users off.

[Nardol]

Can we hop an official answer from Switch-Bot on this subject? To know if it is planned, excluded or something else...

[Minsheng]

Hello keen developers, this is Davidson from the dev team. We are aware of the needs for having a local API and the merits of it Unfortunately we currently cannot promise anything about it because tbh with you our dev resources are fully occupied with the R&D of new products and the maintenance of the app. We encourage you guys to find alternative solutions at this point but we will continue to keep a close eye at the community. Thanks! Davidson, SwitchBot Team

[AdyRock]

We encourage you guys to find alternative solutions at this point

And what would you suggest as an alternative solution?

The rate limit on the current alternative solution (the official API) is crippling. It wouldn't be so bad if the rate limit was per device or there was an API to retrieve the status of all devices in one call. Maybe the dev team could add in a callback method where an address could be registered in the API to post events to. E.g. when a curtain position changes or the temperature measurement changes, send a message to the callback address. Then at least the rate limit would just be for sending commands to control devices, which would be usable. If you don't have time to implement a full local API at least spend a little bit of time making the cloud API useful.

[mvevitsis]

The alternative solution is to throw your switchbot devices in the trash and buy something that uses Zigbee or Zwave

[Damianeq90]

Sorry for my English. I have a problem with curtains and hombridge, when I manually close the curtain, the status in HomeBridge does not update - it helps to enter the SwitchBot iPhone application, scroll down (refresh) and after two minutes Homebridge updates - has anyone dealt with this problem? I bought a hub on purpose, hoping that the update would be trouble-free

[devWaves]

if anyone is looking for a local solution for bots/curtains/meters and you have an esp32 (about $5). no switchbot hub needed.

uses MQTT and now supports HA MQTT discovery

https://community.home-assistant.io/t/switchbot-bot-curtain-meter-mqtt-esp32-bridge-local-control

[DutchmanNL]

And what would you suggest as an alternative solution?

The rate limit on the current alternative solution (the official API) is crippling. It wouldn't be so bad if the rate limit was per device or there was an API to retrieve the status of all devices in one call.

fully aggree, so we have enough developers to maintain a useless cloud with rate limit of 1000 calls a day but not to ensure a device I bought in my house can be controlled locally without limitations.

I am currently. developing integration to smartphone systems for SwitchBot and will finalize it for cloud api but will not support any consumers as this limit is, sorry to say that, absolutely ridiculous and absolutely moving the device from a 9-10 start rating down to 0 @Minsheng

The device here will been returned right away due to this limitation

In addition to topic startet, please (if local api come available) make it smart and support WS (web services) not only mqtt for integrations in other solution a stable protocol is needed with proper communication and that's not MQTT or a polling API

[Zwordi]

@Minsheng

Thanks for your message about your current load :).

Will wait the news then about a local api support through the hubmini who knows...

Regards,

[rafa-esco]

Just to let you know that in May 21 I got the following response from the switchbot twitter account: "... our API limitation has been increased to 10000 per day..."

I'm indeed sending at least 5000 request every day from my domoticz installation to all my sensors and curtains.

[funkymonkeymonk]

Hey folks. I wanted to bump this as 10000 requests per day is a great step forward for the cloud offering but I'd still like to be able to work with local control as right now the latency for closing my curtains is very long.

[nodecentral]

Just wanted to add my support to us all having a completely local (no cloud) API for Switchbot

[slimninja]

+1 for local api support. Would reduce demand on switchbot servers as well

[JGKarlin]

Hello keen developers, this is Davidson from the dev team. We are aware of the needs for having a local API and the merits of it Unfortunately we currently cannot promise anything about it because tbh with you our dev resources are fully occupied with the R&D of new products and the maintenance of the app. We encourage you guys to find alternative solutions at this point but we will continue to keep a close eye at the community. Thanks! Davidson, SwitchBot Team

SwitchBot products are scorned by the home assistant and home automation communities because of these limitations. Do you not realize how much your sales would grow by working to allow your products to have greater user control through a local API? Is it really practical for you to run Cloud servers with users needing to ping the Cloud API nearly 10,000/day?

[andhya]

would definitely be more keen to buy the new blind bots if there was a local api, but i've got the hub and meter and a couple of curtain bots currently sat doing nothing because they're just not reliable enough via cloud

[asknoone]

@Minsheng given that this thread is nearly 2 years old now, do you have an update on this?

It looks like the Home Assistant community has managed to implement local control for some devices, however some such as the smart lock and keypad have not been implemented. Smart locks in particular is kind of device that people don't like exposing to the Internet via 3rd party servers if it's not necessary.

There is not much effort required from Switchbot, just to provide the relevant tech specs. It would be very helpful to provide HA developers with the information they need to build these integrations. There are over half a million users of Home Assistant now so it's something worth taking note of.

[Minsheng]

@Minsheng given that this thread is nearly 2 years old now, do you have an update on this?

It looks like the Home Assistant community has managed to implement local control for some devices, however some such as the smart lock and keypad have not been implemented. Smart locks in particular is kind of device that people don't like exposing to the Internet via 3rd party servers if it's not necessary.

There is not much effort required from Switchbot, just to provide the relevant tech specs. It would be very helpful to provide HA developers with the information they need to build these integrations. There are over half a million users of Home Assistant now so it's something worth taking note of.

I have been keeping an eye on this thread as well as the need to build local API. Some of our developers had internal discussions about this. Our marketing teams, who have closely collaborated with the community and KOLs, have also approached me regarding better integrations with Home Assistant.

Many of your opinions are valid and I myself agree with you as a developer and consumer. We haven't come to a conclusion to when and how we will support local API control just yet, but we will definitely keep coming up with more updates.

[AdyRock]

Local control would be great so automation can continue when the Internet connection is down.

[dcousens]

@Minsheng that's great to hear it's still on your radar, thanks for the update! I know that at least I am holding out from buying SwitchBot products until I have local control :yellow_heart:

[nodecentral]

@Minsheng - great to hear, and please don't just think about Home Assistant - the use goes way beyond that.

A local rest api can be integrated into so many things. I for one build my own plugins for ezlo/Vera and openLuup, and I'm a big user of NodeRed too.

A number of use cases around home automation I see are at holiday homes where internet can be patchy, but they need to know somethings are actively being monitored and responded to.

For a company that provides door locks, temperature sensors, curtain openers etc. - your missing out on a load of off-grid places (by choice or circumstances) who can't use SwitchBot..

[austwhite]

Just adding my voice to the local API. If they can start with Home Assistant, then at least there is room to build out from there as Home Assistant does use pretty standard API's, including REST APi's. Anything in the direction of local control is a good step.
The Home Automation industry has come full circle on this, with more platforms, such as Smartthings, going to more local control and Matter is also local control. To have that local control would be to be keeping up with the game now. Two years ago it would have been leading the field, but now it is essential for you to keep up with the other guys.

[jpconfessor]

Finally Home assistant implemented BLE control for switchbot locks! it is available in the 2023.1 release.. I wasn't expecting that.. after the upgrade.. boom! the lock shows up!

[austwhite]

@jpconfessor
Yes, that was really good to see. The HA Bluetooth Integration is now really world class. Even the ESPHome Proxies work with the Switchbot Locks. They are still via Bluetooth rather than a local API to the Switchbot Hub and some features are still missing, but it's a great start. They also have initial support for the Switchbot Humidifier, though that only seems to support on and off at this time. Still waiting for the Switchbot Blind Tilt motor to be supported in both API and HA integration

@Minsheng I know Switchbot is a small team, but do you think maybe someone at Switchbot could reach out to Home Assistant / Nabu Casa to make a world class integration for Switchbot? Given Home Assistant is one of the most popular Smart Home "hubs" in the world and the most popular Opensource project it could be really beneficial to Switchbot to do the whole "Works with Home Assistant" program and make it official.
I know Switchbot doesn't have a lot of development time available, but there are the resources at Nabu Casa and in the Home Assistant community if you give them all the right information. They could develop the underlying API's and integrations, and maybe even help you guys get your existing API's more efficient.

[DutchmanNL]

@jpconfessor

Yes, that was really good to see. The HA Bluetooth Integration is now really world class. Even the ESPHome Proxies work with the Switchbot Locks.

They are still via Bluetooth rather than a local API to the Switchbot Hub and some features are still missing, but it's a great start.

They also have initial support for the Switchbot Humidifier, though that only seems to support on and off at this time.

Still waiting for the Switchbot Blind Tilt motor to be supported in both API and HA integration

@Minsheng I know Switchbot is a small team, but do you think maybe someone at Switchbot could reach out to Home Assistant / Nabu Casa to make a world class integration for Switchbot? Given Home Assistant is one of the most popular Smart Home "hubs" in the world and the most popular Opensource project it could be really beneficial to Switchbot to do the whole "Works with Home Assistant" program and make it official.

I know Switchbot doesn't have a lot of development time available, but there are the resources at Nabu Casa and in the Home Assistant community if you give them all the right information. They could develop the underlying API's and integrations, and maybe even help you guys get your existing API's more efficient.

I already asked that for 2 years an no response, ble Option as example was already integrated 2 years ago in ioBroker and i wanten to extend that Integration with the hub by api and did that based on cloud api.

Still waiting that the vendor provides us local api, happy to work together to an standarized api interface for all smarthome systems, not only iobroker and home Assistent but as long there is no response .... to bad... good product but very poor in making integrations possible and by that almost useless in home automation

Ble = missing features Cloud = over my dead body I will make myself depending on internet connection to control local devices

[unclehack]

The local API support is probably never going to be implemented. They want to collect the customer's data. They want to have the keys of all devices on their cloud platform. Where does this data go? Do they meet the criteria of GDPR? Do they keep the data for European users in Europe? Do they transfer it outside of the EU?

You probably want to stay away from all Switchbot products if you use Home Assistant or any other platform which doesn't require an Internet connection to work. It'll be impossible to configure their products when their infrastructure goes down temporarily or permanently.

They've announced a new hub with Matter support over wifi. All of the existing hardware they've sold to customers doesn't seem to receive the same kind of attention.

It's quite obvious that Switchbot just wants to make as much money as possible by selling hardware with buggy firmware. They don't care about local API, not relying on their cloud platform and proprietary application. Everything is closed source.

Perhaps it's the right time for everyone to consider open alternatives to Switchbot's products and even maybe start building such products. I'm not going to give these people even a single dime again.

[austwhite]

@unclehack A Github issue is not really the correct place for a rant. Take this to a forum But to addres a couple of things. You obviously have never used a Switchbot product or Home Assistant, otherwise you'd know that you do not even need the hub (which is the only way to connect to the cloud with Switchbot) as all devices use local Bluetooth to communicate with your app on your phone and majority of products communicate LOCALLY via Bluetooth on Home Assistant without the need to ever use an API. The Home Assistant integration only uses Bluetooth and not the Switchbot API / Hub. A local API is just something that would make integrating those few things that Home Assistant does not support via Bluetooth, or to integrate with other systems, easier. This is NOTHING to do with data gathering in this case. It is a hell of a lot easier and efficient to have a cloud based server process the commands and serve the API than to do it through a hub which is limited in processing power.
I don't know where you get the idea of buggy firmware from. All of my products work 100% fine, as do several thousand, likely a lot more, users around the world. Anyway, not the place for a rant. This should be taken to a forum. I just wanted to clarify a couple of obvious things that were just fake news in your post.

The one thing I do agree with you on is that Local API likely wont happen as the existing hubs are not really powerful enough and it would be a fairly time consuming project for a very small team like Siwtchbot have currently

[unclehack]

@unclehack A Github issue is not really the correct place for a rant. Take this to a forum But to addres a couple of things. You obviously have never used a Switchbot product or Home Assistant, otherwise you'd know that you do not even need the hub (which is the only way to connect to the cloud with Switchbot) as all devices use local Bluetooth to communicate with your app on your phone and majority of products communicate LOCALLY via Bluetooth on Home Assistant without the need to ever use an API. The Home Assistant integration only uses Bluetooth and not the Switchbot API / Hub. A local API is just something that would make integrating those few things that Home Assistant does not support via Bluetooth, or to integrate with other systems, easier. This is NOTHING to do with data gathering in this case. It is a hell of a lot easier and efficient to have a cloud based server process the commands and serve the API than to do it through a hub which is limited in processing power. I don't know where you get the idea of buggy firmware from. All of my products work 100% fine, as do several thousand, likely a lot more, users around the world. Anyway, not the place for a rant. This should be taken to a forum. I just wanted to clarify a couple of obvious things that were just fake news in your post.

The one thing I do agree with you on is that Local API likely wont happen as the existing hubs are not really powerful enough and it would be a fairly time consuming project for a very small team like Siwtchbot have currently

The part where you state that I haven't used any of their products and Home Assistant comes off as condescending. That's as far as I'll go.

The BLE side doesn't work properly in HA for some of their products, including the blind tilt. The locks have some bugs which sometimes leave the user with a stuck lock.

The application is required to update the firmware of the devices. Updating the devices means that the device must be added to the mobile app. The devices can only be added to the app if the user is signed in with an account. Would you be willing to explain what part regarding data collection doesn't apply in this case? Have you read the EULA? They require the user to have an account to be able to update the firmware on their BLE devices made by Switchbot. They want the user to be signed it. They transfer data about the devices to their servers and they can collect other data as well. It doesn't really matter if you use Home Assistant or not in this case.

There's nothing efficient about reaching out to a server somewhere on the Internet with hundreds of milliseconds of latency. Home Assistant will always be better. All of that efficiency of the cloud server goes out the window when the Internet is down or when their APIs are down.

The Switchbot team size isn't exactly relevant. Do you think the team size allows them to find the time to develop new products with all of these features, yet they don't have time to provide support and updates for the existing ones they're still selling?

I hope people see how the Switchbot team didn't implement these features and didn't listen to the customers for some time. People who care about not relying on cloud services should think twice when buying a product from them.

[austwhite]

@unclehack This is an issue / feature request. Most of your complaints really do belong on a forum/discussion board. I have 5 blind tilts, 3 locks and 10 bots. All work 100% reliably in Home Assistant and the Swithcbot app. Maybe raise an issue on the HA github so your issue with the integration can be resolved :) The guys over there are very responsive, even if switchbot is a little cold on the local API issue.
:)

[unclehack]

The hub mini has an ESP8266 chip and a Nordic bluetooth chip. This means that it'd be more than enough to serve a local API which doesn't rely on the cloud.

Before someone jumps in to defend WonderLabs to say that the ESP8266 has very limited resources, you may want to keep in mind the fact that Tasmota also runs on ESP8266 devices with configurations which support a number of sensors and devices. There's absolutely no issue with having a local only API there. There are other vendors which provide ESP8266 based products with local APIs. I didn't mention any non-open software and products on purpose.

It is certainly possible to build a version of the software which doesn't need the cloud. If it can reach out to an API on the Internet, it can certainly expose a local only REST API or something similar for local control.

The same goes for all the devices it'd pair with and for firmware upgrades. There's absolutely no need to have an account.

I'm not buying anything else from these people if they don't implement the local API. There are alternatives which don't require any cloud account.

[Nardol]

I think implementing MQTT would be good enough, because it would not be polling as the Switch Bot hub would push information when publishing to different topics and all clients subscribing to these topics would receive information in real time.

A rest API would be polling so not really reliable, except if web hooks could be implemented. So I really don't see the problem caused by MQTT.

[unclehack]

MQTT is indeed a good option. Tasmota also supports MQTT.

They just need to get rid of the cloud dependency. The hub speaks to the bluetooth devices.

It boils down to them being honest, sitting down and implementing this to remove all dependencies on their servers. It's not as if it's not possible to buy similar devices elsewhere or building them ourselves.

[austwhite]

Not sure why anyone is comparing a local API / Rest API to Tasmota which uses highly optimised libraries connecting devices via the GPIO Pins of the ESP8266.
IF you want a more realistic comparison, look at the sluggish behaviour of the WLED API when on an ESP8266 chip. It's okay on an ESP32, but on the older chip it is quite slow. Given the Cipher and Encryption needed for locks, the old ESP chips would struggle. Unfortunately MQTT would also struggle with the security issues with locks.

All that said, playing devils advocate, you can control these all with local control just using BLE. If you use the app, without any hubs, you are doing it full local. BLE also integrates to third party hubs, such as Home Assistant.

[austwhite]

@unclehack Let's forget Tasmota, as that is a completely different thing and completely unrelated to Switchbot. I get you like Tasmota and are subtly advertising it, but it is a completely different thing, unless you want to flash your Switchbot hub with Tasmota.

Regarding MQTT. How do you guys propose to get arround the security issue with locks? I would not want to trust my front door to MQTT.

[Nardol]

Regarding MQTT. How do you guys propose to get arround the secruity issue with locks? I would not want to trust my front door to MQTT.

Nuki have implemented a MQTT API for the smart lock 3.0 pro and for people who prefer limiting the security risks, there is a parameter to only view information and not control the lock. I don't really see the problem with a MQTT broker on the local network.

The comparison with Tasmota is it use MQTT on an ESP8266, nothing related about other functions it provide. It also provide a REST API. And if you don't trust MQTT, it is also not possible to trust a REST API except if it is behind TLS which is a chalange with an ESP8266.

[unclehack]

Not sure why anyone is comparing a local API / Rest API to Tasmota which uses highly optimised libraries connecting devices via the GPIO Pins of the ESP8266. IF you want a more realistic comparison, look at the sluggish behaviour of the WLED API when on an ESP8266 chip. It's okay on an ESP32, but on the older chip it is quite slow. Given the Cipher and Encryption needed for locks, the old ESP chips would struggle. Unfortunately MQTT would also struggle with the security issues with locks.

All that said, playing devils advocate, you can control these all with local control just using BLE. If you use the app, without any hubs, you are doing it full local. BLE also integrates to third party hubs, such as Home Assistant.

Tasmota is running just fine with MQTT. The switchbot hub is already communicating with the cloud APIs right now. Can you explain how the requirement to use TLS for the cloud communication is any worse, provided they use any security mechanisms for communication with their hosted API?

I'd agree with you that this chip is slow if I didn't see it perform just fine on my network. Sensors and other devices aren't WLED controllers updating many times every second or very dependent on latency.

@unclehack Let's forget Tasmota, as that is a completely different thing and completely unrelated to Switchbot. I get you like Tasmota and are subtly advertising it, but it is a completely different thing, unless you want to flash your Switchbot hub with Tasmota.

Regarding MQTT. How do you guys propose to get arround the security issue with locks? I would not want to trust my front door to MQTT.

"Subtly advertising it" - what? That's wrong on so many levels. This is a tracker for issues and requests concerning closed source products I've paid for. I'd much rather use all of them without any account and without any cloud API at all. Tasmota is an example of open source software which runs on one of the chips this company ships in their cloud dependent hubs. I've seen people make up excuses that it's not possible to implement the local API because the hardware is too weak. Does that make sense to you?

The fact that MQTT is or isn't secure isn't relevant. It's possible to use TLS certificates for a more secure MQTT setup. You could ask the same security related question about the bluetooth code and the firmware they use on the BLE enabled devices they sell. There are also other options (such as a local TLS enabled API). The cloud API is always going to be slower to respond than anything local, regardless of how slow it is because of some slow software based cryptography.

Solutions can be found IF someone at this company actually wants to implement local API support.

[dcousens]

@austwhite are you saying you can locally control the Switchbot Hub Mini with BLE?

[AdyRock]

No, he is saying you can control Switchbot devices with BLE directly, therefore cutting out the hub altogether.

[dcousens]

@AdyRock the Hub Mini is an IR controller too - if that functionality is controllable with BLE, that would be awesome :yellow_heart:

[gollkn]

Hello guys, I've read so much about Switchbot doesn't support local API, also I've read and found about homebridge and similar tools, but I'm a little confused about integration, I plan to build a custom mobile app on top of Switch bot, I only need to use Lock which needs to open with Bluetooth and also cloud API, I can't understand which lib/tool do I need to use to support BLE? as I understand Homebridge supports a local server where you can add Switchbot lock itself but I'm not sure if it's something "local server" and then I need to call homebridge local server to open the switch bot lock with BLE. Thank you, any suggestions will be helpful

[johnuopini]

I am an OpenHAB user, would like to start working on an OpenHAB binding, i have a new Hub2 device which supports Matter and i guess Thread, means it has a network device able to expose a network service in the local LAN. Any chance we can get Local API at least for the HUB2 model? Polling public API for sensors is not good.

[alexbk66]

I'm developing integration plugins for HomeSeer https://homeseer.com/compatible-products/ and one of my plugins is for SwitchBot.

The first question my users ask - is it local or cloud? And when I reply that the official SwitchBot API is cloud - they reply "no, thank you".

[johnuopini]

I'm developing integration plugins for HomeSeer https://homeseer.com/compatible-products/ and one of my plugins is for SwitchBot.

The first question my users ask - is it local or cloud? And when I reply that the official SwitchBot API is cloud - they reply "no, thank you".

Believe it or not yesterday evening all infrared controls were down also in the app due to an AWS outage, i mean even mqtt would be fine as long as it's local

[danmcmyler]

Wow! So glad I stumbled across this. I was just about to buy a dozen. No local API is a deal breaker, it's nuts to think such a device would be reliant on having an internet connection. Pity as other than this limitation it looks like a great product.

[donavanbecker]

@danmcmyler https://github.com/OpenWonderLabs/SwitchBotAPI-BLE

[switzer60]

Appreciative of the informative (and entertaining) thread. I've also been burned by home automation providers having cloud API issues, solvency issues, etc. I have about $1000 worth of bricks at home. Lesson learned.

What is prohibiting the open source community from (functionally) creating their own "hub" that would convert the BLE support into a local API? In other words "SwitchBot device" <-> BLE <-> homebrew hardware/software> <-> REST API <-> whatever your heart delights. I'm not saying it wouldn't be work-intensive but what would be the limitations to that approach? This isn't my area of expertise, I'm just someone interested in the product as well, but hesitant because of the lack of support except for Home Assistant, which isn't my platform of choice.

Appreciate y'all's thoughts.

[alexbk66]

creating their own "hub" that would convert the BLE support into a local API

It already exists, i.e. https://pypi.org/project/switchbot-mqtt/ https://pypi.org/project/switchbotpy/

[austwhite]

The good thing with Switchbot is you don't need the cloud API because it also has BLE so Home Assistant can grab it all via BLE as does the Switchbot app. You only need the API if you plan using one of switchbot hubs as your primary remote access device.

I think the hubs can work locally via BLE, but that really makes little difference given the app connects BLE also