SwitchBot Blind Tilt BLE integration


Any chance to have the SwitchBot Blind Tilt venetian blind motor support to OMG. For what I understand it seems very much like the SwitchBot Curtain already there (https://github.com/theengs/decoder/blob/development/src/devices/SBCU_json.h).

The details I can find right now:


MQTT Explorer in HomeAssistant reports only this:

E95B41152AD4 = {“id”:“E9:5B:41:15:2A:D4”,“rssi”:-75}

Anything else I can do to help?


Hi @likis

Could you turn set Advertisement and Advanced Data to true. Then you should see the undecoded raw advertising data in MQTT Explorer, one of which you gave above in the nRF Connect Advertising screenshot.

If you then gives some samples of the different Blind Tilt settings states (all the way up, allk the way down, tilt one way, tilt the other way …) along with the corresponding data received we can see how it can be implemented into Theengs Decoder, i.e. OpenMQTTGAteway.

There seems to be some issue with incomplete advertising data though for the Blind Tilt, from what i can gather in the GitHub threads, and unfortunately there hasn’t been any release of the official Blind Tilt BLE API on the GitHub repo either yet.

It’s been a while but now I had time to debug things. Below the same commands from two Blind Tilts.

Closed up



Fully open



Closed down



Opened up 46%


Opened up 54%


Hi @likis

Thanks for the further information of your Blind Tilts, and it seems to be working fine with the test decoder I still have stashed away here, but I’m only able to verify the tilting of the blinds with your above data - that is if I understood your open and closed correctly, you do mean the tilting by that, don’t you?

How about having the blinds pulled all the way up or down, regardless of the actual tilting of the blades? Or is the Blind Tilt not actually not capable of that, and only able to tilt the blind blades? I really have to read up about this device again, it’s been a while :slight_smile:

Are you using a pre-built binary with OpenMQTTGateway or do you create your own build with PlatformIO, so we can see what the best option is for you to test this decoder?

The “tilt” is defined by the percentage in the Switchbot app. Fully open = 100% (flaps in the middle). Fully closed down 0% (the flaps are fully down). Fully closed up 0% (the flaps fully up). And open up/down anywhere between 0-100% tilt.

There is no that kind of operation.

I have used the pre-build binary. No experience of PlatformIO.

The app is also able to display battery level, if it is charging, if the solar panel is present and panels light level… but I have not seen any messages like that.

The decoder also has

motion true/false
calibrated true/false
battery percentage

The tilt however is actually bbeing broadcast as follows by the data
0 = closed down, 50 = open and 100 = closed up

So I’m just looking at transforming this to
-100 = closed down, 0 = open and 100 = closed up
to be more in sync with what the app shows. Looks like the app also never shows any odd numbers for the tilts because of this transform :wink:

I will then start of a test build for you to be able to download as a pre-built binary. This will take about 90 minutes and will be overwritten again just after midnight UTC, so you can hopefully install it before then.

Will let you know here once the test build is ready.


I’m not quite sure if the test builds have completed fine, but could you try to install from

with SHA:6ba9c2

I have since found some issues
• The battery level was wrong in the decoder for the test build, which I have since fixed, so should be fine in the next version
• The light level always comes back as 1, as I’m currently unsure where it is being encoded. Could you provide some more data samples as above, one with the solar panel covered up and then one with light shining on it?
• The solar panel also seems to be optional, so could you also give some data samples with the solar panel connected and with it being disconnected?
• Can you also try the motion property, by switching from fully closed up to fully closed down and catch an MQTT message during the changing motion?

Once the light level and motion has been sorted out we should have a full status decoder for the Blind Tilt.

I downloaded the image and successfully installed it but I have problems to get ha mqtt-connection working (error in omg log). As far as I understand the omg_esp32_ble chip is constantly rebooting itself…

I’ll be back tomorrow, I dont have time to do more debugging right now… Cheers!

Did you erase the flash when uploading the test binary?

I have just restarted the test build again, and this time it does look fine, so could you try a fresh download again from the above linked development test upload page, making sure to select the binary suitable for your ESP32?

I got the latest build installed and working. What I can see it Works perfectly.

  • the tilt is from 100 (close up) 0 (open) -100 (close down). The reading is not the same as in app but you have to subtract from 100. For example reports -24 the app says 76% opened down. Reports 62 app 38% opened up. But when you know that you can make sensor to do the math.
  • motion I think reports right
  • calibrated is correct but i cannot test the uncalibrated setting
  • lighlevel is correct
  • batt is correct

Just great, thank you very much. Now I can start building integrations…!

It seems to report lightlevel=2 when the panel is not recognized.

Are you going to control it with OMG thanks to the write characteristic command?

Hi @likis

Thanks for the feedback, but please ho,d on with your integration as we should try and sort out the reaming issues. Otherwise the next Blind Tilt user comes along in a while, stating what needs to be changed with the decoder, and then you’ll have to rearrange your integration.

I’d rather the the decoder does the math, so that every user getsthe same ready to use values without having to apply any extra calculations on their controller side. The decoder already does the calculation to convert the original broadcast data
0 = closed down, 50 = open, 100 = closed up
to your observed
-100 = closed down, 0 = open, 100 =closed up
which looked logical to me for the tilt values. You now stating that the reported tilt value still needs to be subtracted from 100 to get the percentage value of the openness does make sense. So for confirmation, both current -100 and 100 should report as 0%, whereas a small tilt of, let’s say 20 either way, should report back as -80% and 80%.
Wich also makes me wonder if the property name tilt might not be the most appropriate here. How does the app name these property of how open the blinds are?

So when the solar panel is disconnected the decoder reports lightlevel=2?
THis could very well mean that bit[2] pf the light level byte is an indicator of the solar panle being connected/disconnected.
What are the highest light levels you have observed in the app so far?

Hi @likis

I’ve made the changes to the decoder, and now it reports the already above integrated tilt from
-100 = closed down, 0 = open, 100 =closed up
but also the newly calculated open % state with
0 = closed down, 100 = open, 0 =closed up
which should match the app value.

Could you verify this with the same test build SHA:6ba9c2

I suppose for the final merge into the Theengs Decoder project we might only keep the open property and remove tilt!?!
The only problem then being that the two fully closed 0 = closed down and 0 =closed up both have 0%, so the additional signed tilts -100 = closed down and 100 =closed up might still be useful for these cases.

It is quite dark here at this time of year… but I see the level 10. But level 2 is also reported during the night. The level 2 is also coming from one blind that reports at app that the panel can not be found.

That sounds good. But the blinds can also have other “tilts” than 0/100… that is between the full close and full open.

I’ll try the new build.

Of course, and all other values between -2 to -98 are reported correctly as negatives for any DOWN position, it’s just with the DOWN 0%, as -0 is not a valid mathematical calculation result

So in keeping the tilt property it give the indication for any negative tilt value being the DOWN position, and any positive tile value indicating UP.

If and how we might change this to only positive percentage values with an additional Down/UP property is best left for the future, as we’re planning other new features for Theengs Decoder which will also required transformations like this, so already pondering on what the best implementation will be to cover all/most eventualities.

I have made some more changes so that the results should now be on a par with the app - the open percentage values are now always positive, tilt has been replaced by direction with “up”, "down and “–”.

Let us know how it is working for you.

Also keep in mind that when you want to write commands to your Blind Tilt you will also have to apply sucj transformations to end up with the native
0 = closed down, 50 = open and 100 = closed up


I’m attempting to use the Blind Tilt integration, but I don’t know what I’m doing wrong…

I’m using openHAB 4.
I’ve compiled the last dev version and uploaded it on a ESP32.
I’ve added the OpenMQTTGateway as a thing in openHAB and configured the OpenHAB discovery to true.
I’ve added a whitelist with the mac addresses of the SwitchBot Blind Tilt modules with MQTT Eplorer.
I can see the 6 SwitchBot Blind Tilt mac addresses in MQTT Explorer under the topic home/OpenMQTTGateway/BTtoMQTT.

But the 6 Blind Tilt (firmware version v2.2) doesn’t appear in the openHAB inbox.

Here are the adv data from the log :

Thanks in advance,


Welcome @Daniel615be

It seems that SwitchBot changed the advertising data for the Blind Tilt with firmware version v2.2 - is that the newest firmware? - to include one extra octet in the manufacturerdata.

Do you know if there has been any new feature(s) added with this firmware, which might be encoded in the extra octet?

Either way, I have submitted a test branch with the amendment for this new advertising format.

I’ve compiled the last dev version and uploaded it on a ESP32.

which you can easily test out by building from the development source and changing the line
decoder = https://github.com/theengs/decoder.git#development
in platformio.ini to
decoder = https://github.com/DigiH/decoder.git#blindtilt

Let us know how you get on and if the properties are confirmed for your Blind Tilts.

Thanks for the quick response !

To be honest, I already had the problem with v2.1 of the firmware. I updated my Blind Tilts 2 days ago from 2.1 to 2.2.
I never found the release notes for v2.1 and v2.2.

OK now I’ve readable data (in the OpenMQTTGateway logs and MQTT Explorer) and it’s accurate.
State of the Blind Tilt when I started the ESP32 with last dev version:
{“id”:“E5:A6:7F:BB:AB:B5”,“rssi”:-85,“brand”:“SwitchBot”,“model”:“Blind Tilt”,“model_id”:“W270160X”,“type”:“WCVR”,“open”:40,“direction”:“up”,“motion”:false,“calibrated”:true,“lightlevel”:2,“batt”:100,“mac”:“E5:A6:7F:BB:AB:B5”}
{“id”:“D6:68:58:39:56:5F”,“rssi”:-77,“brand”:“SwitchBot”,“model”:“Blind Tilt”,“model_id”:“W270160X”,“type”:“WCVR”,“open”:40,“direction”:“up”,“motion”:false,“calibrated”:true,“lightlevel”:2,“batt”:100,“mac”:“D6:68:58:39:56:5F”}
{“id”:“D6:48:35:AF:72:BA”,“rssi”:-92,“brand”:“SwitchBot”,“model”:“Blind Tilt”,“model_id”:“W270160X”,“type”:“WCVR”,“open”:40,“direction”:“up”,“motion”:false,“calibrated”:true,“lightlevel”:2,“batt”:100,“mac”:“D6:48:35:AF:72:BA”}
{“id”:“D8:9D:4A:40:F9:A4”,“rssi”:-71,“brand”:“SwitchBot”,“model”:“Blind Tilt”,“model_id”:“W270160X”,“type”:“WCVR”,“open”:70,“direction”:“up”,“motion”:false,“calibrated”:true,“lightlevel”:2,“batt”:100,“mac”:“D8:9D:4A:40:F9:A4”}
{“id”:“CA:AA:3E:8F:C7:F4”,“rssi”:-86,“brand”:“SwitchBot”,“model”:“Blind Tilt”,“model_id”:“W270160X”,“type”:“WCVR”,“open”:50,“direction”:“up”,“motion”:false,“calibrated”:true,“lightlevel”:2,“batt”:100,“mac”:“CA:AA:3E:8F:C7:F4”}

State of the Blind Tilt after a close down command (from SwitchBot app) of all Blind Tilt :
{“id”:“E5:A6:7F:BB:AB:B5”,“rssi”:-88,“brand”:“SwitchBot”,“model”:“Blind Tilt”,“model_id”:“W270160X”,“type”:“WCVR”,“open”:0,“direction”:“down”,“motion”:false,“calibrated”:true,“lightlevel”:2,“batt”:100,“mac”:“E5:A6:7F:BB:AB:B5”}
{“id”:“D6:68:58:39:56:5F”,“rssi”:-81,“brand”:“SwitchBot”,“model”:“Blind Tilt”,“model_id”:“W270160X”,“type”:“WCVR”,“open”:0,“direction”:“down”,“motion”:false,“calibrated”:true,“lightlevel”:2,“batt”:100,“mac”:“D6:68:58:39:56:5F”}
{“id”:“D6:48:35:AF:72:BA”,“rssi”:-98,“brand”:“SwitchBot”,“model”:“Blind Tilt”,“model_id”:“W270160X”,“type”:“WCVR”,“open”:0,“direction”:“down”,“motion”:false,“calibrated”:true,“lightlevel”:2,“batt”:100,“mac”:“D6:48:35:AF:72:BA”}
{“id”:“D8:9D:4A:40:F9:A4”,“rssi”:-64,“brand”:“SwitchBot”,“model”:“Blind Tilt”,“model_id”:“W270160X”,“type”:“WCVR”,“open”:0,“direction”:“down”,“motion”:false,“calibrated”:true,“lightlevel”:2,“batt”:99,“mac”:“D8:9D:4A:40:F9:A4”}
{“id”:“FE:54:2F:9E:8C:FE”,“rssi”:-81,“brand”:“SwitchBot”,“model”:“Blind Tilt”,“model_id”:“W270160X”,“type”:“WCVR”,“open”:0,“direction”:“down”,“motion”:false,“calibrated”:true,“lightlevel”:2,“batt”:98,“mac”:“FE:54:2F:9E:8C:FE”}
{“id”:“CA:AA:3E:8F:C7:F4”,“rssi”:-81,“brand”:“SwitchBot”,“model”:“Blind Tilt”,“model_id”:“W270160X”,“type”:“WCVR”,“open”:0,“direction”:“down”,“motion”:false,“calibrated”:true,“lightlevel”:2,“batt”:100,“mac”:“CA:AA:3E:8F:C7:F4”}

I’ve added the home/OpenMQTTGateway/commands/MQTTtoBT/config {“filterConnectable”:true}, but still nothing in the openHAB inbox.