SwitchBot gets an open API!

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.

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

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

1 Like

Hi TOMW,

Thank you for the updated Curtain Driver.

  • Vitaliy
1 Like

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

Hey @kraegd, I saw your post here: SwitchBotAPI Driver for SwitchBot Bot

I'm not sure what may be wrong, but I'll bet we can figure it out. I still don't have a curtain device, but some other users here have gotten it to work.

To start, can you tell me what version of the driver is quoted under this line in the driver source for the curtain driver? Change history:

Some of the earliest versions tried to check if the curtain was properly calibrated, which the API didn't actually reliably report. It made my driver non-functional in a lot of cases. I removed that check and also made a number of other corrections on the attribute handling for windowShade and position.

So, since all of that is not working, I'm wondering if you have an older version that had those bugs.

1 Like

Hi Tom,

I was running the latest version from your GitHub.

I decided to delete all my child devices and recreate them, after that things started to work...no clue what had gone on!

Thanks for the response, if you need anything testing add my to the volunteers. I'm hoping to order a few more of these as they seem to be an ok solution ... Although not perfect.

Kraeg

1 Like

use HPM to ensure you stay up to date on everything

1 Like

I've just installed a SwitchBot Curtain and am seeing something odd. In the device page all of the buttons work. The curtain will open and close with those buttons, as well as the on/off buttons. The curtain will even go to the correct position if I use that to open the part way, see image.

What the device is not doing is updating the Current States when the curtain is fully closed. On the device page, if I hit the Close or Off button the curtain will move, but the state will not update. If I set the position to 100 the curtain will fully close, but not update the states and still show on/open.

25% Position:
image
100% Position still shows on/open:
image
I installed using HPM. Oh, and this is a grouped curtain device.

I think my logic is flipped.

Is 100% closed? I figured 100% was opened, like a dimmer being set to 100% brightness.

@dadarkgtprince, @rudyscoggins, does the behavior that @jason described match what you saw with your curtains?

This is the logic right now:

else if(respData.body?.slidePosition)
        {
            switch(respData.body.slidePosition.toInteger())
            {
                case 95..100:
                    windowShade = "open"
                    switchState = "on"
                    break
                case 0..5:
                    windowShade = "closed"
                    switchState = "off"
                    break
                default:
                    windowShade = "partially open"
                    switchState = "off"
            }
        }

Here is what I'm showing in the SwitchBot app. I think the logic is opposite of what you have. With the sliders in the app at 25% you get 25% of coverage. At 100% you get full coverage and the app shows fully closed.

1 Like

OK, should be an easy fix. Please try updating to 0.9.8 via HPM and see if you get better results.

The logic for percentage and open/close, on/off is good. It does look like the API is slow to update itself. I'll use Hubitat to issue a Open/On command and the curtain will move, but the debug logs show that the slidePosition isn't changed.

Here is what I'm seeing in the logs:

dev:25682021-03-05 05:05:58.946 pm debugresp.data = [statusCode:100, body:[deviceId:redacted, deviceType:Curtain, hubDeviceId:redacted, slidePosition:100], message:success]
dev:25682021-03-05 05:05:58.329 pm debughttpGetExec([uri:https://api.switch-bot.com/v1.0/devices/redacted/status, headers:[Authorization:redacted, Content-Type:application/json; charset=utf8]])
dev:25682021-03-05 05:05:56.255 pm debugresp.data = [statusCode:100, body:[:], message:success]
dev:25682021-03-05 05:05:55.145 pm debughttpPostExec([uri:https://api.switch-bot.com/v1.0/devices/redacted/commands, headers:[Authorization:redacted, Content-Type:application/json; charset=utf8], body:{"command": "turnOn", "parameter": "default","commandType": "command"}])

Then the SwitchBot system device did a refresh and the slidePosition is now 0:

dev:25682021-03-05 05:07:08.265 pm debugresp.data = [statusCode:100, body:[deviceId:redacted, deviceType:Curtain, hubDeviceId:redacted, calibrate:true, group:false, moving:false, slidePosition:0], message:success]
dev:25682021-03-05 05:07:07.691 pm debughttpGetExec([uri:https://api.switch-bot.com/v1.0/devices/redacted/status, headers:[Authorization:redacted, Content-Type:application/json; charset=utf8]])

However, the Curtain device page still shows the Current States as 100/off/closed
image

1 Like

You're right- the logic for attribute updates still seems kind of wrong. Your debug prints help. I'll take another pass through the logic and hit you up for further testing.

2 Likes

I think I found the error in my code. I just made a fix but did not change the version, so just use the Repair option in HPM to get the change.

I did the Repair to grab the new code. When I use Hubitat to open or close the signal gets sent and the curtains move, but the API fails to update the status for a beat. I can hit Refresh of the child and/or the parent device and it will not have the new status for at least 30 seconds if not a minute. That is not anything you can do I'm sure. When I hit refresh with the logging open the response from switchbot will be wrong for a beat or two.

That's unfortunate, but it does seem like their API is pretty laggy. If it eventually catches up then that may be the best we can do.

One tweak I could add is to lengthen the time that the driver waits before refreshing after a command to move the device is sent. Right now it's really short- 2 seconds. If it was consistently 30 seconds (or whatever) I could adjust to make it as responsive as possible.

How consistent is the delay if you manually refresh it until it updates

I'll mess around with the curtains tomorrow and make some notes on how long it takes the API to respond.

1 Like

Attempt Number One; Curtain started in the open position, status in Hubitat was 0/On/Open. I hit the Close button at 08:23:30.724 am. I then hit refresh repeatedly starting when the curtain was fully closed and not moving. The first response with slidePosition:99 (not 100 for some reason) was at 08:25:17.104 am. This was 1m 47s.

Attempt Number Two; Curtain starting the closed position, status in Hubitat was 99/Off/Closed. I hit the open button at 08:42:42.897 am. The state change to 0/On/Open was refreshed at 08:43:20.411 am. This run was much better at 38 Seconds.

I ran another cycle and got these times: Open to Close: 2m 4s. Closed to Open: 41s.
It takes a much shorter time for the API to update with an open command than a close command. My curtain takes about 15 seconds to move from full stop to full stop.

I have also noticed that if the curtain is in the 100/Off/Closed state and you press the Close button the state will change immediately to 0/On/Open. It will stay in that state until the API is updated and refreshed in Hubitat.

1 Like

unfortunately when i was testing, i wasn't too concerned with the attributes as much as i was about the functionality. i always figured i could just look at my blinds (open floor plan) and see if they're open/closed. i wasn't too interested in the partial open/close, so i didn't go too much into that.