Switch-Bot API integration

I’m still working… but maybe this can be help you:

rest_command:
  switchbot_device_command:
    url: 'https://api.switch-bot.com/v1.0/devices/{{ deviceId }}/commands'
    method: post
    content_type: 'application/json'
    headers:
      Authorization: !secret switchbot_api
    payload: '{"command": "{{ command }}","parameter": "{{ parameter }}"}'

#<Curtains Position and other sensors here>
  - platform: rest
    name: 'Motionsensor JSON'
    resource: !secret switchbot_motioningresso_status_url
    method: GET
    scan_interval: 600
    headers:
      Authorization: !secret switchbot_api
      Content-Type: 'application/json'
    value_template: '{{ value_json.body }}'
    json_attributes_path: "$.body"
    json_attributes:
      - deviceId 
      - deviceType
      - hubDeviceId
      - moveDetected
      - brightness
  - platform: template
    sensors:
      switchbot_motioningresso_motiondetected:
        friendly_name: "Motion Detected"
        value_template: '{{ states.sensor.motionsensor_json.attributes["moveDetected"] }}'
        
in secrets file you must enter:

switchbot_motioningresso_status_url: "https://api.switch-bot.com/v1.0/devices/YOURDEVICEID/status"

I am using the v1.0 API interface for my switchbot curtains. Ever since I updated my firmware on the Switchbot Mini Hub and the Switchbot curtains to v6, the API does not return the correct position of the curtains. It appears to be fixed values that it was last updated.

Does anyone have the same experience or is there a fix to this?

I looked that the v1.1 API interface, but as pointed out above, this new authorization method is time limited - so I guess the current methods used here can no longer be used.

Same problem, after update the firmware the position value is zero.

Did you ever figure out the lock via v1.1? Possible using jinja or python script? I am interested in this is well.

1 Like

I am also crossing my fingers for an API-based integration. I could adventure into the manual code but I have been working 7 days a week and spend most of my free time sleeping where I can. So not a lot of trouble-shooting time as of late :frowning: thus an easier solution would be great so that I can start controlling my SB locks.

1 Like

If you want to use it I created this repo, with my script, to use API 1.1.

:warning: It is not a simple home assistant script, you need pyscrypt from hacs, but mostly this script at the moment is Work In Progress :warning:

The procedure is well explained (I think) but I’m Italian so, there might be something lost in translation.

For any problems open an issue.

2 Likes

Hi Guys,

I am new to HA, reading threads like crazy… i was reading gdeboos’s instructions on how to integrate the curtains to my enviroment, i have succesfully configured but when the curtains are “closed” - they show as “open” and vice versa - under the cover state.

Is there a quick fix for this? many thanks for your support!

Can anyone provide additional instructions on how the use the IR blaster on the Switchbot hub. I looked at some of the instructions above but was not able to get it to work. I’m trying to control a fan, so I need On/Off, speed control (just a single button that cycles through 3 different speeds), and a toggle for oscillation. Any help would be greatly appreciated!

For anyone with a similar issue to what I previously asked, I have found a solution.

As previously stated, you will need the rest command. I’ve included mine here, but it’s the same as all the other ones posted here.

rest_command:
  switchbot_irdevice_command:
    url: 'https://api.switch-bot.com/v1.0/devices/{{ deviceId }}/commands'
    method: post
    content_type: 'application/json'
    headers:
      Authorization: !secret switchbot_api
    payload: '{"command": "{{ command }}","parameter": "default", "commandType": "customize"}'

Assuming you are adding more than one IR command, you will need to add multiple “switches” for each command. In my example below, I have a total of three “switches” (commands), power, speed control, and oscillation. They all need to go under the single “Switch” line.

switch:
  - platform: template
    switches:
      fan_power:
        friendly_name: Fan_Power
        turn_on:
          service: rest_command.switchbot_irdevice_command
          data:
            deviceId: !secret switchbot_fan_deviceId
            command: "Power"
        turn_off:
          service: rest_command.switchbot_irdevice_command
          data:
            deviceId: !secret switchbot_fan_deviceId
            command: "Power"
            
      fan_speed:
        friendly_name: Fan_Speed
        turn_on:
          service: rest_command.switchbot_irdevice_command
          data:
            deviceId: !secret switchbot_fan_deviceId
            command: "Speed_Toggle"
        turn_off:
          service: rest_command.switchbot_irdevice_command
          data:
            deviceId: !secret switchbot_fan_deviceId
            command: "Speed_Toggle"
            
      fan_oscillate:
        friendly_name: Fan_Oscillate
        turn_on:
          service: rest_command.switchbot_irdevice_command
          data:
            deviceId: !secret switchbot_fan_deviceId
            command: "Oscillate"
        turn_off:
          service: rest_command.switchbot_irdevice_command
          data:
            deviceId: !secret switchbot_fan_deviceId
            command: "Oscillate"

Finally, on the Switchbot app, make a custom button for each one of these, ensuring that the name of the button matches the command name. I.E. the command “Power” only works because I have a custom button programmed in the Switchbot app named “Power”.

3 Likes

Hi, I’m tried to use your method above to integrate the Switchbot virtual remote to switch on my aircon by modyfing the code as below.

However I’m getting an error: ‘Failed to call service switch/turn_on. Unable to find service rest_command.switchbot_irdevice_command’

Grateful for any pointers

Edit: I’m an idiot - HA needed a full restart of the server to get the Service to be recognised, not just reloading of YAML configuration. All good now

rest_command:
  switchbot_device_command:
    url: 'https://api.switch-bot.com/v1.0/devices/{{ deviceId }}/commands'
    method: post
    content_type: 'application/json'
    headers:
      Authorization: !secret switchbot_api
    payload: '{"command": "{{ command }}","parameter": "{{ parameter }}"}'
  switchbot_irdevice_command:
    url: 'https://api.switch-bot.com/v1.0/devices/{{ deviceId }}/commands'
    method: post
    content_type: 'application/json'
    headers:
      Authorization: !secret switchbot_api
    payload: '{"command": "{{ command }}","parameter": "{{ parameter }}", "commandType": "{{ commandType }}"}'

switch:
  - platform: template
    switches:
      bedroom_aircon:
        friendly_name: "Bedroom Air Con Virtual Remote"
        turn_on:
          service: rest_command.switchbot_irdevice_command
          data:
            deviceId: !secret bedroom_aircon_deviceId
            command: "turnOn"
            commandType: ""
        turn_off:
          service: rest_command.switchbot_irdevice_command
          data:
            deviceId: !secret bedroom_aircon_deviceId
            command: "turnOff"
            commandType: "command"

With the completion of Add Battery and Firmware Info to Device status · Issue #11 · OpenWonderLabs/SwitchBotAPI · GitHub to expose battery of switchbot devices, what’s the most updated way to use API v1.1?

Using device/status for a regular bot I can only see: {‘deviceId’: ‘xxx’, ‘deviceType’: ‘Bot’, ‘hubDeviceId’: ‘xxx’, ‘power’: ‘on’}

Created a way to use API v1.1 with a standalone python script.

This example below works for just a switchbot bot device, but can be easily expanded for other devices. Feel free to submit any pull requests for additional commands/improvements.

Hi all :slight_smile:

I used “Smart Matching” when i added my portable ac, switchbot found many buttons and the display with current temp. When i curl to get device id i get this on the AC:
Why is the id long like that??
“,{“deviceId”:“01-202304211748-55496909”,“deviceName”:“AC”,“remoteType”:“Air Conditioner”,“hubDeviceId”:“ED*******3F4”}]}”

Is it not possible to use this one with HA using rest_command? :frowning:

Hi! How do your device id look like on the ac?

mine is like this “01-202304241929-74326444”
It doesent work for me :frowning:

https://api.switch-bot.com/v1.0/devices/01-202304241929-74326444/status
gives me this: {“statusCode”:190,“body”:{},“message”:“wrong deviceId”}
01-202201281415-69304742

Bumb :confused: Anyone ?

Hi there - First off thank you so much for this great discussion on this topic. I have been able to get one set of my SwitchBot Curtain 2 working with the API integration. However, when I am working to add my second curtain 2 for another room, I am getting the following error.

Template variable warning: 'parameter' is undefined when rendering '{"command": "{{ command }}","parameter": "{{ parameter }}"}'

What is interesting to me is when I open the switchbot app and look at the log for the device, i do see a Failed to connect warning where it calls out API. So it seems like it is connecting and authenticating okay, but having problems getting to the curtain 2 from the hub. I double checked the deviceID and can use curl to query the url status, and it reports as expected.

What is interesting to me is that the API request to fetch the location (closed/open) is working, it is just when I try to do a close/open/stop on the cover. So to me it seems like the POST command and call is failing. But it shouldn’t be a problem with the POST command since the same code works for the other curtain set…

Any thoughts on where to look, or others have problems with just a single device? Almost seems like a permission issue or something.

Just responding that I figured out the issue.

For anyone else going down this rabbit hole, have a look at this: GitHub - OpenWonderLabs/homebridge-switchbot: The Homebridge SwitchBot plugin allows you to access your SwitchBot Device(s) from HomeKit. Homebridge.

Between spinning up the container, adding the switchbot plugin, and setting it up, I probably only lost 15 minutes. Muuuuuch less than the amount of time I was sinking into getting Bluetooth working through Docker or setting up these python scripts.

Once Homebridge was done, it was automatically detected by Home Assistant and waiting for me in the integrations page. Couple clicks later, I’m able to control my “Bot” (the button-pushing one) with the switch.toggle service

1 Like

Ugh, well that’s sad… I’m not sure what is going on with the integration team, but this sounds like an easy method of using the API rather than Bluetooth. (Which I have never liked as a point of communication. Using BT for initial install is fine, but unfortunately right now the official integration gets a B- for competition and a D+ for effort) any time I try to setup a Bluetooth dongle, it works great for a day then I get severe hardware hci issues. Ends up bricking supervisor. The proxy will work but it’s another item you gotta plug in and well at the end of it all you can only passively connect to 3 devices maximum.

@Nardol is there anyway to convert this integration to have 2 methods of connection. 1 current system, 2 cloud/API?

I have created a new add-on using the SwitchBotAPI and have released it.
Please refer to the following topic for more details.

Additionally, I will share what I discovered during development.
While not documented in the API specifications,
I have found commands to operate default buttons of automatically detected or list-selected virtual infrared remote devices.
The command type is “tag”.

  • Example payload for preset commands
    {"commandType":"command","command": "turnOn","parameter": "default"}
    {"commandType":"command","command":"setPosition","parameter":"0,ff,70"}

  • Example payload for custom commands:
    {"commandType":"customize","command": "MyButtonName","parameter": "default"}

  • Example payload for tag commands
    {"commandType":"tag","command": "1","parameter": "default"}

Based on a limited range of testing, it seems that the buttons are assigned sequentially from the top left of the screen, with smaller numbers assigned first.

1 Like