Reed switch not working with BTHome v2.

[SeanCline]

I'm trying to use the reed switch feature with BTHome v2 advertises on a Xiaomi LYWSD03MMC. All the typical sensors are picked up by the HomeAssistant BTHome integration, but the integration never creates an entity representing the reed switch.

Based on the BTHome format, I was expecting to see a 0x11 byte representing an "Opening" sensor. I see no such byte in the advertising payload for the device.

I captured the advertises from an ESP32, and here's what I do see:

[19:02:43][D][ble_adv:022]:   Address: A4:C1:38:3E:98:09
[19:02:43][D][ble_adv:027]:   AdFlags: 6
[19:02:43][D][ble_adv:037]:   Service Data: UUID: 0x181A, data: 09.98.3E.38.C1.A4.E7.0B.CE.10.93.0E.64.27.05 (15)
[19:02:45][D][ble_adv:021]: BLE Advertise:
[19:02:45][D][ble_adv:022]:   Address: A4:C1:38:3E:98:09
[19:02:45][D][ble_adv:027]:   AdFlags: 6
[19:02:45][D][ble_adv:037]:   Service Data: UUID: 0x181A, data: 09.98.3E.38.C1.A4.E7.0B.CE.10.93.0E.64.29.04 (15)
[19:02:45][D][ble_adv:021]: BLE Advertise:
[19:02:45][D][ble_adv:022]:   Address: A4:C1:38:3E:98:09
[19:02:45][D][ble_adv:027]:   AdFlags: 6
[19:02:45][D][ble_adv:037]:   Service Data: UUID: 0x181A, data: 09.98.3E.38.C1.A4.E7.0B.CE.10.93.0E.64.2B.04 (15)
[19:02:46][D][ble_adv:021]: BLE Advertise:
[19:02:46][D][ble_adv:022]:   Address: A4:C1:38:3E:98:09
[19:02:46][D][ble_adv:027]:   AdFlags: 6
[19:02:46][D][ble_adv:037]:   Service Data: UUID: 0x181A, data: 09.98.3E.38.C1.A4.E7.0B.CE.10.93.0E.64.2B.04 (15)
[19:02:48][D][ble_adv:021]: BLE Advertise:
[19:02:48][D][ble_adv:022]:   Address: A4:C1:38:3E:98:09
[19:02:48][D][ble_adv:027]:   AdFlags: 6
[19:02:48][D][ble_adv:037]:   Service Data: UUID: 0xFCD2, data: 40.00.31.01.64.02.E9.0B.03.C9.10 (11)
[19:02:49][D][ble_adv:021]: BLE Advertise:
[19:02:49][D][ble_adv:022]:   Address: A4:C1:38:3E:98:09
[19:02:49][D][ble_adv:027]:   AdFlags: 6
[19:02:49][D][ble_adv:037]:   Service Data: UUID: 0x181A, data: 09.98.3E.38.C1.A4.E9.0B.C9.10.93.0E.64.32.05 (15)
[19:02:49][D][ble_adv:021]: BLE Advertise:
[19:02:49][D][ble_adv:022]:   Address: A4:C1:38:3E:98:09
[19:02:49][D][ble_adv:027]:   AdFlags: 6
[19:02:49][D][ble_adv:037]:   Service Data: UUID: 0xFCD2, data: 40.00.33.01.64.02.E9.0B.03.C9.10 (11)
[19:02:54][D][ble_adv:021]: BLE Advertise:
[19:02:54][D][ble_adv:022]:   Address: A4:C1:38:3E:98:09
[19:02:54][D][ble_adv:027]:   AdFlags: 6
[19:02:54][D][ble_adv:037]:   Service Data: UUID: 0x181A, data: 09.98.3E.38.C1.A4.E9.0B.C9.10.93.0E.64.37.05 (15)
[19:02:55][D][ble_adv:021]: BLE Advertise:
[19:02:55][D][ble_adv:022]:   Address: A4:C1:38:3E:98:09
[19:02:55][D][ble_adv:027]:   AdFlags: 6
[19:02:55][D][ble_adv:037]:   Service Data: UUID: 0x181A, data: 09.98.3E.38.C1.A4.E9.0B.C9.10.93.0E.64.37.05 (15)

Decoding the BTHome v2 packets yields the following:

40 (BTHome v2, unencrypted, interval-based advertises)
00.31 (packet id)
01.64 (battery)
02.E9.0B (temperature)
03.C9.10 (humidity)

So, BTHome is lacking the reed switch data but decoding the pvvx packets, I see the following:

09.98.3E.38.C1.A4 (mac address)
E9.0B (temperature)
C9.10 (humidity)
93.0E (battery mv)
64 (battery level)
37 (counter)
05 (flags indicating reed switch is closed!)

The last bit of the payload seems to represent the reed switch.

This leaves me with a few questions:

1) Am I doing something wrong? I have the AdFlags box checked. Packet capture confirms AdFlags is 06. In fact, here's the whole config. 2) If not, then have I stumbled upon a bug? 3) Why is the pvvx packet being sent at all when I have the advertising type set to BTHome v2?

[pvvx]

Why is the pvvx packet being sent at all when I have the advertising type set to BTHome v2?

You did not save the configuration:

06:51:28: Hardware Revision String: B1.4
06:51:28: Software Revision String: V4.7
06:51:28: Firmware Revision String: github.com/pvvx
06:51:28: Detected custom Firmware
06:51:28: Hardware Version: LYWSD03MMC B1.4, Software Version: 4.7, Sensor: SHTC3 (SHTV3)
06:51:28: Custom config HEX string: 55031000003004ae31318096
06:51:36: Settings 44 was sent successfully
06:51:36: Threshold Temp/Humi: 21.00°C/50.00%, Hysteresis T/H: -0.55°/0.00%, Reed switch mode: 17, Rs rep.interval: 30 sec, flg: 0x0E, RS input inversion

TelinkMiFlasher:

If not, then have I stumbled upon a bug?

The reed switch is transmitted immediately when changed. The transmission of state changes occurs in a batch of 5 transmissions with an interval of 50 ms. The duplication time for the reed switch state when there is no change is set in seconds.

• ESP32 cannot receive constantly when working with WiFi. This results in many missed BLE packets on reception.

BTHome:

Passive BLE monitor:

[SeanCline]

Hi pvvx,

Thanks for looking into this so quickly!

You did not save the configuration

I did save, but it was in a previous browser session. I just connected to the device using Telink to capture the screenshot, so it should be an accurate representation of the device's configuration.

If the configuration weren't properly saved for some reason, does it still make sense for the device to be sending both pvvx and bthome advertises?

ESP32 cannot receive constantly when working with WiFi. This results in many missed BLE packets on reception.

I did consider this as the setup is not ideal for signal integrity. I have an ESPHome BT Proxy sitting between the router and the bluetooth thermometer, which is outside.

Still, I find it very strange that over the 2 weeks the reed switch has been configured, the BTHome integration has never seen a packet with reed switch data in it. I'll see about capturing from a laptop just to have a more complete packet capture.

P.S. Even though I'm having trouble with the reed switch functionality, I have 10 thermometers which have been rock-solid for years now. Thanks for maintaining this awesome firmware!

[pvvx]

With the "pvvx" option, data from sensors is output in the "pvvx" format, and events in the "BTHomeV2" format. Same with "ATC". Old formats do not contain "events".

If the configuration weren't properly saved for some reason, does it still make sense for the device to be sending both pvvx and bthome advertises?

Most likely these are errors in third-party software. In the latest versions of the thermometer program, the ability to broadcast all types of advertising one by one has long been disabled.

If there are many devices, many BLE advertising packages arrive in a short period of time. If the device does not have time to process and does not protect the receive buffer during processing, then the data and MAC are confused. ESP32 is known for its low productivity when processing data into text form (MQTT). The performance of both ESP32 cores with a large amount of code does not exceed the Cortex M0 counterpart operating at 16 MHz due to the low performance of SPI-Flash and the small cache size...

[SeanCline]

In the latest versions of the thermometer program, the ability to broadcast all types of advertising one by one has long been disabled.

This is why it's very puzzling to me that my thermometer is broadcasting both pvvx and BTHomev2 advertises.

I think I've found why that's happening.

If I'm reading this line correctly, it sets up the send buffer up to include reed switch data in the next BTHomev2 advertise. But then it falls through to the next line, calling pvvx_event_beacon(rds.type); which overwrites what bthome_event_beacon(rds.type); just did.

I suspect there is a missing else. There is an else when encryption is enabled, so I set a bindkey on my device and now HomeAssistant picks up the Opening and Count entities I was expecting to see.

The data is quite delayed, but I suspect that's a result of my poor signal integrity discussed earlier.

[pvvx]

Thanks for pointing out the error! All files have been rebuilt with corrections.

[SeanCline]

Just reporting back that I've been running the new build for a couple days with encryption turned off.

All good so far!

Thanks for making the correction so quickly, and thanks again for the awesome firmware!