Switchbot Curtain Data is not decoded

[sebbo2002]

• Before submitting a problem please check the troubleshooting section
  https://docs.openmqttgateway.com/upload/troubleshoot.html

Describe the bug
OpenMQTTGateway caught my eye because, according to its website, 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 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
  
• If you are not sure this is a bug or an enhancement post your question to the forum below
  

[DigiH]

Hi @sebbo2002,

SwitchBot Curtains should be supported, but we could not verify it with all models/versions of the the Curtains releases.

Could you let us know which version/model you have, and also if you use prebuilt binaries/web upload or make you own builds with Platformio, so we can supply an updated test version for you.

For your above undecoded message would this be correct for the then Curtains state?

{"brand":"SwitchBot","model":"Curtain","model_id":"W070160X","motion":false,"position":100,"calibrated":true,"lightlevel":1,"batt":17}

[sebbo2002]

SwitchBot Curtains should be supported

Fantastic news 🥳

Could you let us know which version/model you have, and also if you use prebuilt binaries/web upload or make you own builds with Platformio, so we can supply an updated test version for you.

My SwitchBot Curtains are on Firmware Version 6.0. I only used prebuild binaries (tried both ttgo-t-beam-firmware.bin and esp32dev-ble-firmware.bin) and uploaded them via web and espool (I wanted to try both to rule out an error here). I use an Heltec WiFi/Lora Board with Display, but I only need BLE for my needs. I was a bit unsure about the build selection, so I tried a bit. LoRa / display sure would be a plus, but I assume that's not possible in parallel, right?

For your above undecoded message would this be correct for the then Curtains state?

Unsure about the model id, but at least for position, calibrated, lightlevel and battery I can say that's correct.

[DigiH]

Thanks for the info and confirmation about the decoded details.

A test build is currently running, will give you the link to download binaries for final testing on your side.

An actual display for decoded BLE device status on your Heltec board is also in the works by @NorthernMan54, similar to the already implemented rtl_433 information, so with a future update you will be able to see your SB Curtains and other devices info on it.

[sebbo2002]

A test build is currently running, will give you the link to download binaries for final testing on your side.

Thank you for the quick reply and solution. I'll wait for the link then.

An actual display for decoded BLE device status on your Heltec board is also in the works by @NorthernMan54, similar to the already implemented rtl_433 information, so with a future update you will be able to see your SB Curtains and other devices info on it.

Oh wow, very cool. I'm definitely looking forward to it, thanks for the info.

[DigiH]

While the status decoding test build is still running you might also want to try the control of the SwitchBot Curtains with the OpenMQTTGateway WRITE command, as we don't actually have any confirmation about its correct working yet, but the commands should be as follows:

Open : 570F450105FF00
Close : 570F450105FF64
Certain position: 570F450105FF00-64 (0-100%)
Stop : 570F450100FF

With
serviceUUID = "cba20d00-224d-11e6-9fb8-0002a5d5c51b"
charUUID = "cba20002-224d-11e6-9fb8-0002a5d5c51b"

For example for closing

  {"ble_write_address":"AA:BB:CC:DD:EE:FF",
  "mac_type":1,
  "ble_write_service":"cba20d00-224d-11e6-9fb8-0002a5d5c51b",
  "ble_write_char":"cba20002-224d-11e6-9fb8-0002a5d5c51b",
  "ble_write_value":"570F450105FF64",
  "value_type":"HEX",
  "ttl":4,
  "immediate":true }'

[sebbo2002]

To be honest, I don't know if I'm doing it correctly right now, so I'll go into a little more detail:

I sent this payload via MQTT (topic home/OpenMQTTGateway/commands/MQTTtoBT/config):

{
  "ble_write_address":"EC:B9:3A:06:BF:96",
  "ble_write_service":"cba20d00-224d-11e6-9fb8-0002a5d5c51b",
  "ble_write_char":"cba20002-224d-11e6-9fb8-0002a5d5c51b",
  "ble_write_value":"570F450105FF64",
  "value_type":"HEX",
  "ttl":4,
  "immediate":true }

Is this correct? If so, it unfortunately fails. Extract from the Serial Log:

17:09:27.161 -> N: [ MQTT->OMG ]: {"ble_write_address":"EC:B9:3A:06:BF:96","ble_write_service":"cba20d00-224d-11e6-9fb8-0002a5d5c51b","ble_write_char":"cba20002-224d-11e6-9fb8-0002a5d5c51b","ble_write_value":"570F450105FF64","value_type":"HEX","ttl":4,"immediate":true}
17:09:27.161 -> N: Send on /BTtoMQTT msg {"bleconnect":true,"interval":55555,"activescan":true,"scanbcnct":10,"onlysensors":false,"hasspresence":false,"presenceTopic":"presence/","presenceUseBeaconUuid":false,"minrssi":-100,"extDecoderEnable":false,"extDecoderTopic":"undecoded","filterConnectable":false,"pubKnownServiceData":false,"pubUnknownServiceData":true,"pubKnownManufData":false,"pubUnknownManufData":true,"pubServiceDataUUID":false,"pubBeaconUuidForTopic":false,"ignoreWBlist":false}
17:09:27.194 -> N: BLE Connect begin
17:09:32.219 -> E: Connect to: ec:b9:3a:06:bf:96 failed
17:09:37.205 -> E: Connect to: ec:b9:3a:06:bf:96 failed
17:09:42.225 -> E: Connect to: ec:b9:3a:06:bf:96 failed
17:09:47.218 -> E: Connect to: ec:b9:3a:06:bf:96 failed
17:09:47.218 -> N: BLE Connect end
17:09:47.218 -> N: BLE Connect begin
17:09:47.218 -> N: BLE Connect end
17:09:47.218 -> N: Scan begin
17:09:47.218 -> N: Send on /BTtoMQTT/ECB93A06BF96 msg {"id":"EC:B9:3A:06:BF:96","service":"cba20d00-224d-11e6-9fb8-0002a5d5c51b","characteristic":"cba20002-224d-11e6-9fb8-0002a5d5c51b","write":"570F450105FF64","success":false}
17:09:47.255 -> N: Device detected: 35:0F:CF:A3:E3:13

[DigiH]

Looks fine, but with "mac_type":1 this also needs to be added to the WRITE command, as the default is "mac_type":0

[sebbo2002]

Closing works like a charm (😍), give me a minute to check open/position/stop as well…

Update: Works perfectly great, I am thrilled.
Is also faster and more reliable than the official SwitchBot Hub 🥳

• open
• close
• position (90% → 570F450105FF5a)
• stop

[DigiH]

Thanks a lot for the actual confirmation, what so far has only been theoretical :)

[DigiH]

Could you tell us which controller you are using with the OpenMQTTGateway output- Home Assistant, OpenHAB … some other?

[sebbo2002]

I use FHEM. I have too much stuff in there and don't dare migrate to something else 😂

[DigiH]

No worries, that wasn't the intention, but with your above confirmation of the control commands we are now planning on including these in OpenMQTTGateway with auto-discovery of them and direct inclusion in the UI of compatible controllers.

With FHEM you will still be able to send the commands as above :)

[DigiH]

The test build has finished and you can download your relevant binary at

https://github.com/1technophile/OpenMQTTGateway/tree/gh-pages/dev/firmware_build

or through the test web upload

https://docs.openmqttgateway.com/dev/upload/web-install.html

[sebbo2002]

Oh, no, unfortunately I don't have anything from that. But I can manage very well with the Write command. 👍🏼

[sebbo2002]

It just works like a dream. Thank you very much, that really helped me a lot. The ticket ca be closed, if there's not anything still open so that the changes end up in the next release.

[DigiH]

Thanks a lot for you collaboration and confirmation!

I'll merge the fix into Decoder and it will be included in a future update of OpenMQTTGateway.

[DigiH]

@sebbo2002

If you don't mind and if you get a few minutes, would you mind confirming if the SwitchBot Curtains require active scanning, which is the current default, or if their advertising data would still be received and decoded with passive scanning.

https://docs.openmqttgateway.com/use/ble.html#setting-if-the-gateway-use-active-or-passive-scanning

Many thanks

[sebbo2002]

Good morning, without having tested it: the SwitchBot curtains always send out their Bluetooth advertisements, even without active scanning. I know this because my previous solution doesn't support active scanning at all. But I can also try it again tonight with OpenMQTTGateway, just to be 100% sure.

[sebbo2002]

Okay, so I still get events without active scanning, but the payload doesn’t seem to be parsed correctly anymore. Then I only get messages like this: {„id“:“FA:83:ED:1F:81:8D“,“rssi“:-75}

[DigiH]

This means that with passive scanning there is no servicedata being broadcast/received, so nothing which can be used for decoding.

Could you just try the following command to make sure all data publishing is ON
mosquitto_pub -t home/OpenMQTTGateway/commands/MQTTtoBT/config -m '{"pubadvdata":true}'
and see if the messages change?

But it's very likely that the SwitchBot Curtains needs active scanning, as all the other SwitchBot devices seem to behave that way.

[sebbo2002]

Before:

{"id":"FA:83:ED:1F:81:8D","rssi":-74,"brand":"SwitchBot","model":"Curtain","model_id":"W070160X","motion":false,"position":0,"calibrated":true,"lightlevel":1,"batt":95}

After {"activescan":false} and {"pubadvdata":true}:

{"id":"FA:83:ED:1F:81:8D","mac_type":1,"adv_type":0,"manufacturerdata":"6909fa83ed1f818d110f001104","rssi":-72}

[DigiH]

Thank you for the confirmation.
As expected, with passive scanning only the freely broadcast manufacturerdata is available. While this also includes some of the relevant data it is insufficient for a full status decoding, and more importantly it doesn't contain the relevant information to uniquely identify the SwitchBot device model as Curtain.

So the SB Curtains do require active scanning, like the other SwitchBot devices.

If you leave {"pubadvdata":true} but restore {"activescan":true} you will see that only then both manufacturerdata and servicedata are being received, with the servicedata and servicedatauuid required for correct decoding.