SwitchBot Blind Tilt BLE integration

DigiH · April 18, 2024, 9:51pm

Thanks for the confirmation, I will merge the changes into Theengs Decoder so it will also be included in the OpenMQTTGateway nightly development builds from tonight on.

Have you got both of these set to true?
"disc":true,"ohdisc":true

Make sure they are both set to true, then issue a restart command to the gateway.

After the restart the Blind Tilts should show up in your inbox.

Unfortunately please be aware that while OpenHAB states Home Assistant MQTT Components discovery, this only seems to be implemented half-baked, so you will likely need to manually adjust some of the discovered devices’ properties.

Daniel615be · April 19, 2024, 6:34am

Yep, both are true.

If I’m not wrong, something should be published in homeassistant topic whith the informations needed to create the things.
But there are only the topics of the OpenMQTTGateway.

Daniel615be · April 19, 2024, 12:59pm

Finally, I’ve created the things with channels manually.

I found this implementation of the Blind Tilt on Github, perhaps it will help to update this implementation.

DigiH · April 19, 2024, 2:05pm

And you issued a restart with both true?
Which is important to do with new devices, which all your Blinds Tilts were as they were only recognised and decoded after the newly amended decoder was included.

But I’m glad to hear you got it working with creating the things and channels manually - as I also do myself for everything.
Nevertheless the discovery should work correctly with the steps above, and does for me with other sensors when testing. Not having the Blind Tilt here, but the property definitions are very much the same as for other decoders.

Daniel615be · April 19, 2024, 8:13pm

Yes

Can you give me a small example on how to operate the Blind Tilt from OMG ? (If it’s possible)

DigiH · April 19, 2024, 9:01pm

Then I’m wondering if "disc":true needs to be sent with "save":true as toggling of discovery does in the HA UI?!? And then issuing a restart?!? Something to look into …

I usually create one single command string thing per gateway, along the lines of

Type string : mqtt_config_string_command        "string Command"    [ commandTopic="home/OMG_BLE/commands/MQTTtoBT/config" ]

with a related String item for this. Then set up your UI elements as you want them, likely with buttons, segmented controls, a slider for the openb percentage etc. as desired. Then in the rule(s) triggered by these UI elements send a OMG WRITE command like

MQTT_BT_Config_Command.sendCommand('{\"ble_write_address\":\"AA:BB:CC:DD:EE:FF\",\"mac_type\":1,\"ble_write_service\":\"aaaa\",\"ble_write_char\":\"bbbb",\"ble_write_value\":\"XXXXXXXX\",\"value_type\":\"HEX\",\"ttl\":4,\"immediate\":true}')

with the ble_write_value XXXXXXXX being the actual HEX command with the ending octet likely being the variable open percentage, and aaaa/bbbb the appropriate service and characteristic for writing the command to the SwitchBot Blind Tilt. All of which I don’t know by heart, and somehow can’t currently seem to find the repo where I saw it previously on GitHub

Similar to what I wrote here for the SwitchBot Curtain

github.com/1technophile/OpenMQTTGateway

Switchbot Curtain Data is not decoded

opened 02:19PM - 22 Jan 23 UTC

closed 04:56PM - 22 Jan 23 UTC

sebbo2002

- [x] Before submitting a problem please check the troubleshooting section http…s://docs.openmqttgateway.com/upload/troubleshoot.html **Describe the bug** OpenMQTTGateway caught my eye because, [according to its website](https://docs.openmqttgateway.com/prerequisites/devices.html#for-ble-devices), it supports SwitchBot Curtains and thus could replace the hub I currently use. On compatible.openmqttgateway.com SwitchBot Curtains is not listed, so I don't know which data source is correct and if the product is really supported. [Here](https://community.openmqttgateway.com/t/openmqttgateway-v1-0-0/2073) it's listed again as a new and supported product, so I assume it's a bug. In any case, it can be stated that SwitchBot curtain advertisements are currently not parsed correctly for me and only the raw data ends up in MQTT / Serial Log. Is this correct? Which of the two websites represents the correct implementation status? **To Reproduce** Steps to reproduce the behavior: 1. Install v1.2.0 on EPS32 (used a precompiled build from GitHub Releases) 2. Ensure that Switchbot Curtain is nearby the ESP 3. Check Serial Log / MQTT Broker **Expected behavior** I would expect the values contained in the advertisement (motion state/position/light level/battery/calibration state) to be included in the JSON. Instead, only the raw data is included. Other bluetooth devices like the `LYWSDCGQ` I have here are correctly parsed. ``` 14:58:43.609 -> N: Device detected: DD:A2:6E:62:B8:2F 14:58:43.784 -> N: Send on /BTtoMQTT/DDA26E62B82F msg {"id":"DD:A2:6E:62:B8:2F","mac_type":1,"manufacturerdata":"6909dda26e62b82fe307641104","rssi":-74,"servicedata":"63c011641104","servicedatauuid":"0xfd3d"} ``` **Screenshots** ~~If applicable, add screenshots to help explain your problem.~~ **Environment (please complete the following information):** * OpenMQTTGateway version used (V0.9.3, 0.8, development) * v1.2.0 (tested with ttgo-t-beam-firmware.bin and esp32dev-ble-firmware.bin) * Library version related to the problem you have (if you have troubles with RF provide the version of RCSwitch library) * No idea how to get this 🙈 * For IR and RF clarify if you tested with the basic examples given with these libraries **Additional context** Add any other context about the problem here. * You should not have a compilation error if you use the versions of the libraries linked into the libraries folder, this badges show you the state of the compilation [![Build Status](https://github.com/1technophile/OpenMQTTGateway/workflows/Build/badge.svg?branch=master)](https://github.com/1technophile/OpenMQTTGateway/actions) * If you are not sure this is a bug or an enhancement post your question to the forum below [![Community forum](https://img.shields.io/badge/community-forum-brightgreen.svg)](https://community.openmqttgateway.com)

Anyone else got a Blind Tilt and these values at hand? Or best to have a fresh look again tomorrow

DigiH · April 20, 2024, 12:44pm

Well, the SwitchBot command structure for the Blind Tilt seems to be very similar/the same as the Curtain, so not sure if you have already tried it out with these.

Best to have some test runs in the Publish section of MQTT Explorer, with

Open : 570F4501010132 (Quiet Slow??)
Open : 570F450105FF32

Close UP: 570F4501010164 (Quiet Slow??)
Close UP: 570F450105FF64

Close DOWN: 570F4501010100 (Quiet Slow??)
Close DOWN: 570F450105FF00

And I would assume the service to be 0d00 (or fd3d in case of this Blind Tilt version?!?) as well, with the characteristic being 0002.

Be aware that there is an issue when sending concurrent connection commands in OpenMQTTGateway, so best to wait a few seconds between commands.

Let us know how you get on.

Daniel615be · April 21, 2024, 10:33am

Unfortunately I don’t have so much time this weekend.
But will have a try in the next few days.

If I look in the Python code from my link (in device.py), write and service seem’s to be common to all SwitchBot devices.

DigiH · April 21, 2024, 1:27pm

Yes, I was suspecting that, but always good when users with actual SwitchBot devices get proactive in device implementations and with so many recent undocumented firmware and advertising data changes from SwitchBot one can never be sure

Any remaining uncertainties or verifications can also easily be done by anyone with a particular device and a mobile phone with nRF Connect installed.

So it is 0d00 and 0002, and making the last octet in the ble_write_value a variable to be concatenated into the WRITE command, you should be all set.

I’m just wondering if the raw open value should also be included in the decoder. Then it could be defined as a separate channel, directly linkable to a 0-100 slider item, with both the stateTopic and commandTopic in a single channel definition.

Let me know, when you get the time to implement this, if a raw_open property would be helpful, and with which kind of UI elements you are setting up the Blind Tilt control.

Daniel615be · April 24, 2024, 4:35pm

Something doesn’t work…

I send this 2 payloads on home/OpenMQTTGateway/commands/MQTTtoBT/config :

{"ble_write_address":"D6:48:35:AF:72:BA","mac_type":1,"ble_write_service":"cba20d00-224d-11e6-9fb8-0002a5d5c51b","ble_write_char":"cba20002-224d-11e6-9fb8-0002a5d5c51b","ble_write_value":"570F4501010100","value_type":"HEX","ttl":4,"immediate":true}
{"ble_write_address":"D6:48:35:AF:72:BA","mac_type":1,"ble_write_service":"cba20d00-224d-11e6-9fb8-0002a5d5c51b","ble_write_char":"cba20002-224d-11e6-9fb8-0002a5d5c51b","ble_write_value":"570F450105FF00","value_type":"HEX","ttl":4,"immediate":true}

And nothing is moving

DigiH · April 24, 2024, 4:45pm

You didn’t include the

,\"mac_type\":1

form my example above, which all SwitchBots, and any other "mac_type":1 devices, require, and is documented in the READ/WRITE section

Exactly the same issue with the linked Curtain thread on Github, when my suggested commands initially didn’t work

And you could also very possibly just use the 16-bit ble_write_service and ble_write_char instead of the long 128-bit ones.

And just to be on the completely safe side. Is your gateway name actually OpenMQTTGateway? This is only a place holder in all the command examples, but (hopefully obviously) needs to be replaced with the actual name of each individual gateway.

Let us know how it works with the mac_type included and the correct gateway name.

Daniel615be · April 24, 2024, 4:57pm

"mac_type":1 is the second parameter of my JSON string…

Yep the name of my gateway is OpenMQTTGateway.

A screenshot of MQTT Explorer :

DigiH · April 24, 2024, 5:03pm

And how about with the 16-bit ble_write_service and ble_write_char?
e. g.

{
“ble_write_address”:“D6:48:35:AF:72:BA”,
“mac_type”:1,
“ble_write_service”:“0d00”,
“ble_write_char”:“0002”,
“ble_write_value”: “570f450105ff00”,
“value_type”: “HEX”,
“ttl”: 4,
“immediate”: true
}

Daniel615be · April 24, 2024, 5:08pm

Nop…

{"ble_write_address":"D6:48:35:AF:72:BA","mac_type":1,"ble_write_service":"0d00","ble_write_char":"0002","ble_write_value":"570F4501010132","value_type":"HEX","ttl":4,"immediate":true}
{"ble_write_address":"D6:48:35:AF:72:BA","mac_type":1,"ble_write_service":"0d00","ble_write_char":"0002","ble_write_value":"570F450105FF32","value_type":"HEX","ttl":4,"immediate":true}

I let 200 ms between the 2 commands.

DigiH · April 24, 2024, 5:12pm

Might actually still be too close causing the gateway crash and restart, until the issue is fixed.

Should be visible through the gateway uptime in SYStoMQTT.

While I know that your linked Python implementation seems to indicate that both commands are required, I am not really too sure about that, as the Curtain implementation looks much the same, but only really needs a single command - that’s why I also commented these commands with (Quiet Slow??)

Could you just try the single command I just now gave above? I. e. your second command, or also try it with the single first command.

DigiH · April 24, 2024, 5:20pm

DANG!!! my bad, your bad, we just really don’t read the docs properly

The READ/WRITE commands must not have the /config at the end, somehow makes sense, as we do not want to set any config setting of the gateway, but READ or WRITE a command.

So, send the Blind Tilt commands to
home/OpenMQTTGateway/commands/MQTTtoBT

How does it work then?

Daniel615be · April 24, 2024, 5:22pm

Uptime is OK.

Here is the info in the console of the OMG :

N: [ MQTT->OMG ]: {"ble_write_address":"D6:48:35:AF:72:BA","mac_type":1,"ble_write_service":"cba20d00-224d-11e6-9fb8-0002a5d5c51b","ble_write_char":"cba20002-224d-11e6-9fb8-0002a5d5c51b","ble_write_value":"570f4501010132","value_type":"HEX","ttl":4,"immediate":true}
N: Send on /BTtoMQTT msg {"bleconnect":true,"interval":55555,"adaptivescan":true,"intervalacts":55555,"intervalcnct":3600000,"scanduration":10000,"onlysensors":false,"randommacs":false,"hasspresence":false,"prestopic":"presence/","presuseuuid":false,"minrssi":-100,"extDecoderEnable":false,"extDecoderTopic":"undecoded","filterConnectable":false,"pubadvdata":false,"pubuuid4topic":false,"ignoreWBlist":false,"presenceawaytimer":120000,"movingtimer":60000,"forcepscn":false,"tskstck":2280,"crstck":3004,"enabled":true,"scnct":7173}
N: [ MQTT->OMG ]: {"ble_write_address":"D6:48:35:AF:72:BA","mac_type":1,"ble_write_service":"cba20d00-224d-11e6-9fb8-0002a5d5c51b","ble_write_char":"cba20002-224d-11e6-9fb8-0002a5d5c51b","ble_write_value":"570f450105ff32","value_type":"HEX","ttl":4,"immediate":true}
N: Send on /BTtoMQTT msg {"bleconnect":true,"interval":55555,"adaptivescan":true,"intervalacts":55555,"intervalcnct":3600000,"scanduration":10000,"onlysensors":false,"randommacs":false,"hasspresence":false,"prestopic":"presence/","presuseuuid":false,"minrssi":-100,"extDecoderEnable":false,"extDecoderTopic":"undecoded","filterConnectable":false,"pubadvdata":false,"pubuuid4topic":false,"ignoreWBlist":false,"presenceawaytimer":120000,"movingtimer":60000,"forcepscn":false,"tskstck":2280,"crstck":3004,"enabled":true,"scnct":7173}

Daniel615be · April 24, 2024, 5:45pm

OK now if I send the command to home/OpenMQTTGateway/commands/MQTTtoBT, each time I send a command, the OMG crash

I’ve changed the delay between the 2 commands to 2000 ms, but it still crash.
If I only send the first command, it crash too.

DigiH · April 24, 2024, 5:47pm

Sorry about that, but I am just experiencing the very same here myself, when issuing a READ command which previously always worked.

Give us some time to look into this with the current development version.

Will let you know here when things are sorted and fixed, so that we all can properly send READ and WRITE commands again

Daniel615be · April 24, 2024, 5:55pm

OK no problems, thanks for your help !

Oh and I finaly get the Blind Tilt in the inbox in openHAB…
To avoid problems, I’ve removed the topic home/OpenMQTTGateway/commands/MQTTtoBT from my MQTT server and after the 1st OMG crash, the things were in the inbox.
I had set a whitelist with a retain flag, probably the cause of the non creation of the values in the homeassistant topic.