Add Local API Support
niemyjski opened this issue · 102 comments
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.
If you won’t develop this, then please publish the calls to the hub so that the community can do it.
Give us local control! No cloud!
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).
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.
Can we hop an official answer from Switch-Bot on this subject?
To know if it is planned, excluded or something else...
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
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.
The alternative solution is to throw your switchbot devices in the trash and buy something that uses Zigbee or Zwave
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
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
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
Thanks for your message about your current load :).
Will wait the news then about a local api support through the hubmini who knows...
Regards,
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.
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.
Just wanted to add my support to us all having a completely local (no cloud) API for Switchbot
+1 for local api support. Would reduce demand on switchbot servers as well
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?
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
@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 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.
Local control would be great so automation can continue when the Internet connection is down.
@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 💛
@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..
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.
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!
@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.
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
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.
@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 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.
@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.
:)
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.
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.
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.
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.
@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.
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.
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.
@austwhite are you saying you can locally control the Switchbot Hub Mini with BLE?
No, he is saying you can control Switchbot devices with BLE directly, therefore cutting out the hub altogether.
@AdyRock the Hub Mini is an IR controller too - if that functionality is controllable with BLE, that would be awesome 💛
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
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.
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".
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
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.
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.
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/
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
I think the hubs can work locally via BLE
@austwhite do you have any references for this? My understanding is the Hub Mini cannot be used locally for it's IR functionality.
I don't use the IR blaster function, so can't comment on that. But I know I have to enable cloud for the individual switchbot devices I have for the hub to connect to them, otherwise the app just connects directly
For BLE devices, yes the BLE devices use BLE to connect to the hub, but the app seems to use the API to connect to the hub, at least with the hub mini that I have. Can't comment on the newer hubs as I have no experience with them as yet.
Sorry for my confusion on the last comment. I didn't quite finish my sentence properly. Brain fart.
I use ESP32 modules running my own code
(which is in my GitHub repository) to do just that. They send receive BLE and REST commands as a broker between Homey and the Switchbot devices. They work very well and provide a fast response to state changes and commands. I know several Homey users have implemented them but they are technically out of reach for the majority of users. I could produce them for users, as once programmed they are completely plug-and-play, so very simple to use, but the cost of shipping from the UK puts users off as it's two to three times the price of the hardware.
I use ESP32 modules running my own code
(which is in my GitHub repository) to do just that. They send receive BLE and REST commands as a broker between Homey and the Switchbot devices. They work very well and provide a fast response to state changes and commands. I know several Homey users have implemented them but they are technically out of reach for the majority of users. I could produce them for users, as once programmed they are completely plug-and-play, so very simple to use, but the cost of shipping from the UK puts users off as it's two to three times the price of the hardware.
Hi Andy, would the esp code be available? I just started with a homey pro 2023 and also have some SwitchBot products, so very interested. Able to compile the esp32 code myself if available.
Yep, it's in my GitHub repo https://github.com/AdyRock/SwitchBotBLEHub.
I have provide instructions in the readme.
I use https://github.com/1technophile/OpenMQTTGateway/ to control my SwitchBot Curtains without the offical hub. Works fine for me. Reading is supported out of the box and you can send also send commands (see 1technophile/OpenMQTTGateway#1412). The biggest advantage is that many other devices are also supported. Maybe someone will find this useful.
Either the api limit needs to scale with number of devices purchased or pay for be api limit if local api is never gonna happen.
having 30 devices I can only poll like once every 5 minutes is pretty stale…
having 30 devices I can only poll like once every 5 minutes is pretty stale…
Maybe a web hook can be a solution?
Even if I still totally agree a local API would be really welcome because web hook requires opening a port remotely accessed.
I do an annual checkin on this issue to see if SwitchBot stuff is ready to buy yet, guess not yet. Cobbled together and reverse engineered Bluetooth command support that can disappear at any time is not adequate. Maybe next year
I do an annual checkin on this issue to see if SwitchBot stuff is ready to buy yet, guess not yet. Cobbled together and reverse engineered Bluetooth command support that can disappear at any time is not adequate. Maybe next year
The BLE API is official: https://github.com/OpenWonderLabs/SwitchBotAPI-BLE
Maybe a web hook can be a solution?
There are other technologies, i.e. YoLink use MQTT, ESPHome use EventSource, etc.
There are other technologies, i.e. YoLink use MQTT, ESPHome use EventSource, etc.
You forgot to quote the part of my comment where I told a real local API would be better 😄
My intent was only to suggest something which could help within using existing features while the really best solution is not implemented 🙂
You forgot to quote the part of my comment where I told a real local API would be better
I totally agree. Just from my experience with these companies, if they against Local API for any reason (hopefully temporarily) - some kind of Server real time event is better than polling.
I.e. YoLink MQTT status updates work fine (assuming internet connection works).
BTW, YoLink polling rate limiting is much better - it only limits within 5 minutes, unlike SwitchBot - where once you hit the limit - you have to wait for a new day, which sucks.
FYI, I'm the author of HomeSeer integrations
Webhooks are available for a lot of things, but there are still key events that are still missing from the specification.
But I agree, a local API would be the best solution. I can see that Matter is slowly being rolled out, but so far I haven't got that to work either.
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
Three years later. Hi @Minsheng Davidson - any update?
FYU - I'm the author of HomeSeer SwitchBot integration https://forums.homeseer.com/forum/hs4-products/hs4-plugins/lighting-primary-technology-plug-ins-aa/ak-switchbot/1620351-new-switchbot-plugin-using-latest-switchbot-api-v1-1
And I'm telling you - without the local integration you are just loosing sales big time. First question HomeSeer users ask - is it Local or Server? And then - "No, thank you".
At least, without Local integration you should implement some real time status notifications which doesn't require port forwarding - i.e. YoLink using MQTT.
Polling just doesn't work given the rate limiting.
[EDIT]
our dev resources are fully occupied with the R&D of new products
You should set priorities right. You have good enough range of products. By adding Local API you will increase your sales 100 times. Then you can afford R&D of new products.
Any update on this would be great. Even a non standard local API through wireless LAN would be enough and greatly appreciated.
I urge you to add a local API!
still no local API? wow ...
In case somebody finds this helpful:
I can control my switchbot lock pro locally using using Home assistant + Matter + switch bot hub mini.I think switchbot are adding matter support to their other products via firmware updates.
1)Install Matter add on in HA and Matter integration in HA
2)Enable Matter on hub mini using the switchbot app and add the lock pro or other switchbot devices as secondary devices to hub mini's matter interface in the switchbot app
3)Pair hub mini Matter with HA using the HA android or iOS app.
4) head to HA and in the devices your matter enabled devices should appear. It is very responsive too and status seems to be updated too.
In case somebody finds this helpful:
I can control my switchbot lock pro locally using using Home assistant + Matter + switch bot hub mini.I think switchbot are adding matter support to their other products via firmware updates.
1)Install Matter add on in HA and Matter integration in HA 2)Enable Matter on hub mini using the switchbot app and add the lock pro or other switchbot devices as secondary devices to hub mini's matter interface in the switchbot app 3)Pair hub mini Matter with HA using the HA android or iOS app. 4) head to HA and in the devices your matter enabled devices should appear. It is very responsive too and status seems to be updated too.
How do you enable Matter on hub mini? Hub mini does not support Matter. Only Hub 2 can support Matter.
In case somebody finds this helpful:
I can control my switchbot lock pro locally using using Home assistant + Matter + switch bot hub mini.I think switchbot are adding matter support to their other products via firmware updates.
1)Install Matter add on in HA and Matter integration in HA 2)Enable Matter on hub mini using the switchbot app and add the lock pro or other switchbot devices as secondary devices to hub mini's matter interface in the switchbot app 3)Pair hub mini Matter with HA using the HA android or iOS app. 4) head to HA and in the devices your matter enabled devices sh
How do you enable Matter on hub mini? Hub mini does not support Matter. Only Hub 2 can support Matter.
You will have to enable Matter for the Hub Mini from the switchbot app. Under hub mini settings.
You will have to enable Matter for the Hub Mini from the switchbot app. Under hub mini settings.
Unfortunately, this feature seems to be available only for the newest version of the hub mini that is "Matter enabled".
I can't find that Matter option in the hub mini settings in the SwitchBot app, for the hub mini that I currently own.
That is a shame with older hub mini's. Nevertheless I think Matter is the route switchbot seems to be going instead of a proprietary local API. They other way I can think of local control of switchbot devices is by using ESPhome Bluetooth proxy + HA.
That is a shame with older hub mini's. Nevertheless I think Matter is the route switchbot seems to be going instead of a proprietary local API. They other way I can think of local control of switchbot devices is by using ESPhome Bluetooth proxy + HA.
@am2pgs @MrXANA91 Well, this almost guarantee they're not going to upgrade the firmware for the old hub mini because that will impact the sale of their new one. The hardware of the old and new ones are probably the same, only the firmware is upgraded.
BT proxy + HA only work for bluetooth devices, not the IR. For the infrared, it's still cloude based without Matter.
The hardware of the old and new ones are probably the same
I think Matter requires "Thread" chip?
@am2pgs can you utilize the IR functionality of the Hub mini using matter?
I don't use the IR function of hub mini. But I just tried adding a random TV remote to hub mini, and it shows up on matter as a single on/off switch on Matter/HA. Not sure if I M doing something wrong.
The hardware of the old and new ones are probably the same
I think Matter requires "Thread" chip?
No. Matter support multiple PHY standards. Thread is just one of them. WiFi and Bluetooth are all supported by Matter.
funny that after 4 year we still try to solve this and no reaction from the vendor at all....
honestly, I did throw all switchbot devices to the trash. Support and customer wishes sucks and I didn't even won't to try selling it to others
I was even more satisfied doing that than using it
There are news?
Cause if there is this option and we can't use it ourselves directly the situation becomes really comical
A product called Nature Remo, which functions similarly to Switchbot, is available in Japan.
This product is experiencing a failure as of this writing, apparently due to problems with AWS.
In the extremely hot Japanese summer, the inability to control the air conditioner is directly related to death.
However, this product supports local APIs, so those who are familiar with the product can use those APIs.
Since Switchbot also uses the cloud API, it is quite possible that it may become unusable due to a failure on the cloud side.
For such cases, the local API is considered indispensable.
I'm actually OK with not getting this as long as I can control everything via Matter and Home Assistant, that's basically all I need. If they just make everything accessible via Matter I'm all set
I'm the author of AKSwitchBot plugin for HomeSeer
and my users are constantly complaining ;(
I'm actually OK with not getting this as long as I can control everything via Matter and Home Assistant, that's basically all I need. If they just make everything accessible via Matter I'm all set
True, Another very important thing is to correctly associate the devices with the corresponding Matter (Not currently manageable by the user), for example an IR air conditioner cannot be served as a thermostat when matter from 1.2 offers the room air conditioner type. Also for the sake of being able to use all the necessary (compatible) commands
And still nothing :(
What is the current status?
What is the current status?
At present, locally we have only bluetooth api (limited support) and matter (some functions missing, in some devices)
What is the current status?
At present, locally we have only bluetooth api (limited support) and matter (some functions missing, in some devices)
Some devices (like the first version of the SwitchBot Hub Mini which I possess) are still cloud only.
What is the current status?
At present, locally we have only bluetooth api (limited support) and matter (some functions missing, in some devices)
Some devices (like the first version of the SwitchBot Hub Mini which I possess) are still cloud only.
Well yes, true, matter is only for who have a matter hub (like Hub 2), and Bluetooth API is for a very restricted range of device
Worth bearing in mind too that having matter support doesn’t mean local control.
Support have confirmed unfortunately with the S1 even though it will support matter via the hub, it will still need an internet connection to work as their servers are still involved.
Worth bearing in mind too that having matter support doesn’t mean local control.
Support have confirmed unfortunately with the S1 even though it will support matter via the hub, it will still need an internet connection to work as their servers are still involved.
It would be nice to get a roadmap for the implementation of the local API.
Worth bearing in mind too that having matter support doesn’t mean local control.
Support have confirmed unfortunately with the S1 even though it will support matter via the hub, it will still need an internet connection to work as their servers are still involved.
Omg 😱 it's true! do they have the courage to call this stuff matter compliant? I'm not saying it's a scam but it's very close to it.
We still REALLY need this... tbh I wouldn't have bought it if I knew it needs the cloud to work. Local control is fundamental for high security environments, and to ensure things still work when internet is down.
Please, please PLEASE release APIs for local control, or the tools we need to implement them ourselves. It doesn't even make sense that we need the cloud involved to unlock our doors, and it feels unsafe... why??
I suspect SwitchBot won't make any changes, for them you can use BLE for "Local" control, and "Matter" is the future, however it's moving too slow...
I suspect SwitchBot won't make any changes, for them you can use BLE for "Local" control, and "Matter" is the future, however it's moving too slow...
Yeah I'm afraid so too. I'd be fine using Matter, but seems it doesn't support all functions, and that also requires connecting to their cloud? (from some comments)
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
Hi Davidson (and to all the dev team). Since it has been very long and still no good solution in sight, could you maybe release a way for us to run a SwitchBot Cloud instance locally? (a docker file, a project we can run, a virtual machine, a raspberry ISO with the server already up and running... anything would do). In this way we could just change the server URL (from https://api.switch-bot.com to our local instance) and have our local environment very little effort from your side....
With a local environment we'd be able to use your system in many more cases, since we don't have hard performance limitations, more control, and most importantly many security conscious companies and privates would be able to use your products, while know they cannot since it's impossible to completely trust a could service which can control our doors and environment...
Pretty PLEEEEASE? ;)
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
Hi Davidson (and to all the dev team). Since it has been very long and still no good solution in sight, could you maybe release a way for us to run a SwitchBot Cloud instance locally? (a docker file, a project we can run, a virtual machine, a raspberry ISO with the server already up and running... anything would do). In this way we could just change the server URL (from https://api.switch-bot.com to our local instance) and have our local environment very little effort from your side....
With a local environment we'd be able to use your system in many more cases, since we don't have hard performance limitations, more control, and most importantly many security conscious companies and privates would be able to use your products, while know they cannot since it's impossible to completely trust a could service which can control our doors and environment...
Pretty PLEEEEASE? ;)
I suspect it's a bit too much to ask ;)
I suspect it's a bit too much to ask ;)
Maybe, but a man can dream lol. Also it seem like a really smart move to me which makes lots of business sense:
- Currently they have costs to keep their cloud running, but cannot charge customers a periodic fee or it'd be a riot, and no one would buy anymore their products. If they offer a reasonable option to host your own cloud for free, you can then reasonably charge a small free for providing a more convenient service to those who'd rather have them handle that
- They sell hardware, software is specific to their hardware, so no risk losing business by releasing the software
- If they open source it (not even required, but nice to have) with the right EULA, they'll get improvements, fixes and cool features for free
- They'd get access to a much larger base of potential customers, for example I like the hardware, but cannot install it professionally the way it is since I could not formally guarantee security.
- they could get all of this with very little effort (assuming their software design is decent, if not, it's a good chance to clean up tech debt, before it collapses the system and the company)
Keeping my fingers crossed!
I suspect it's a bit too much to ask ;)
Maybe, but a man can dream lol. Also it seem like a really smart move to me which makes lots of business sense:
- Currently they have costs to keep their cloud running, but cannot charge customers a periodic fee or it'd be a riot, and no one would buy anymore their products. If they offer a reasonable option to host your own cloud for free, you can then reasonably charge a small free for providing a more convenient service to those who'd rather have them handle that
- They sell hardware, software is specific to their hardware, so no risk losing business by releasing the software
- If they open source it (not even required, but nice to have) with the right EULA, they'll get improvements, fixes and cool features for free
- They'd get access to a much larger base of potential customers, for example I like the hardware, but cannot install it professionally the way it is since I could not formally guarantee security.
- they could get all of this with very little effort (assuming their software design is decent, if not, it's a good chance to clean up tech debt, before it collapses the system and the company)
Keeping my fingers crossed!
Understand. But most Chinese companies have different view. They want to force users use their servers to collect customer data and have access to your devices and network.