Closed aderusha closed 1 year ago
I've installed the BTVS sniffer from Microsoft and fired it up with Wireshark to grab the service discovery messages from the device.
I'm seeing the following two BLE advertisement messages being repeated from this device:
Frame 197: 35 bytes on wire (280 bits), 35 bytes captured (280 bits) on interface TCP@127.0.0.1:24352, id 0
Interface id: 0 (TCP@127.0.0.1:24352)
Interface name: TCP@127.0.0.1:24352
Encapsulation type: Bluetooth H4 with linux header (99)
Arrival Time: Jun 30, 2022 08:20:59.240706000 Eastern Daylight Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1656591659.240706000 seconds
[Time delta from previous captured frame: 0.051024000 seconds]
[Time delta from previous displayed frame: 4.981993000 seconds]
[Time since reference or first frame: 6.374984000 seconds]
Frame Number: 197
Frame Length: 35 bytes (280 bits)
Capture Length: 35 bytes (280 bits)
[Frame is marked: False]
[Frame is ignored: False]
Point-to-Point Direction: Received (1)
[Protocols in frame: bluetooth:hci_h4:bthci_evt:btcommon]
Bluetooth
[Source: controller]
[Destination: host]
Bluetooth HCI H4
[Direction: Rcvd (0x01)]
HCI Packet Type: HCI Event (0x04)
Bluetooth HCI Event - LE Meta
Event Code: LE Meta (0x3e)
Parameter Total Length: 32
Sub Event: LE Advertising Report (0x02)
Num Reports: 1
Event Type: Connectable Undirected Advertising (0x00)
Peer Address Type: Random Device Address (0x01)
BD_ADDR: dc:23:4d:e4:4d:f1 (dc:23:4d:e4:4d:f1)
Data Length: 20
Advertising Data
Flags
Length: 2
Type: Flags (0x01)
000. .... = Reserved: 0x0
...0 .... = Simultaneous LE and BR/EDR to Same Device Capable (Host): false (0x0)
.... 0... = Simultaneous LE and BR/EDR to Same Device Capable (Controller): false (0x0)
.... .1.. = BR/EDR Not Supported: true (0x1)
.... ..1. = LE General Discoverable Mode: true (0x1)
.... ...0 = LE Limited Discoverable Mode: false (0x0)
16-bit Service Class UUIDs (incomplete)
Length: 3
Type: 16-bit Service Class UUIDs (incomplete) (0x02)
UUID 16: Unknown (0xfd50)
Service Data - 16 bit UUID
Length: 12
Type: Service Data - 16 bit UUID (0x16)
UUID 16: Unknown (0xfd50)
Service Data: 000000000000000000
RSSI: -78 dBm
Frame 198: 45 bytes on wire (360 bits), 45 bytes captured (360 bits) on interface TCP@127.0.0.1:24352, id 0
Interface id: 0 (TCP@127.0.0.1:24352)
Interface name: TCP@127.0.0.1:24352
Encapsulation type: Bluetooth H4 with linux header (99)
Arrival Time: Jun 30, 2022 08:20:59.243694000 Eastern Daylight Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1656591659.243694000 seconds
[Time delta from previous captured frame: 0.002988000 seconds]
[Time delta from previous displayed frame: 0.002988000 seconds]
[Time since reference or first frame: 6.377972000 seconds]
Frame Number: 198
Frame Length: 45 bytes (360 bits)
Capture Length: 45 bytes (360 bits)
[Frame is marked: False]
[Frame is ignored: False]
Point-to-Point Direction: Received (1)
[Protocols in frame: bluetooth:hci_h4:bthci_evt:btcommon]
Bluetooth
[Source: controller]
[Destination: host]
Bluetooth HCI H4
[Direction: Rcvd (0x01)]
HCI Packet Type: HCI Event (0x04)
Bluetooth HCI Event - LE Meta
Event Code: LE Meta (0x3e)
Parameter Total Length: 42
Sub Event: LE Advertising Report (0x02)
Num Reports: 1
Event Type: Scan Response (0x04)
Peer Address Type: Random Device Address (0x01)
BD_ADDR: dc:23:4d:e4:4d:f1 (dc:23:4d:e4:4d:f1)
Data Length: 30
Advertising Data
Manufacturer Specific
Length: 23
Type: Manufacturer Specific (0xff)
Company ID: Hangzhou Tuya Information Technology Co., Ltd (0x07d0)
Data: 00000100a63cb801d748bf7fa40693a37522419c
[Expert Info (Note/Undecoded): Undecoded]
[Undecoded]
[Severity level: Note]
[Group: Undecoded]
Device Name: TY\000\000
Length: 5
Type: Device Name (0x09)
Device Name: TY
RSSI: -78 dBm
Is it the pink variant? This is the first time I heard of that version. That would also be the first time a FlowerCare variant is not compatible with the original... I'm buying one right now but it will take a bit of time to be delivered.
I'm seeing the following two BLE advertisement messages being repeated from this device:
Can you give me the values from the official app, corresponding to these data packets? So I can try to understand what is the content.
Thanks for all the infos that's already a lot. Can I ask you to take some screenshots of the with the "nRF connect" app on Android? The service list would be great, and the details of the 0x1204 service if it exists (and let's hope it does) and maybe FE95.
This is indeed the pink variant, purchased here: https://www.amazon.com/dp/B09JWJL9RR?psc=1&ref=ppx_yo2ov_dt_b_product_details
Another user has dumped some data for the home assistant BLE custom component here: https://github.com/custom-components/ble_monitor/issues/809
Let me see what I can do about collecting some more info for you, and thanks for the fast response (and the rest of this cool project!)
Another user has dumped some data for the home assistant BLE custom component here: https://github.com/custom-components/ble_monitor/issues/809
Yes I saw this thread, but it's always the same problem with the HA plugins, they only do advertisement, which is only useful because they have a computer monitoring that 24/7. To get Flower Care sensor values in a timely manner, as well as history support, you need to connect to the sensor. Hence the info about BLE services. The good news is that the "new" Flower Care seems to broadcast all data at once, unlike regular Flower Care that only advertise one value at a time, and only when it changed, so even advertisement only implementation would probably work with this one.
Unfortunately, the size and format of the packets from the other github issue and yours aren't the same at all, so I cannot blindly implement advertisement decoding. You can also screenshot advertisement data from the main menu of nRF connect, just by clicking on the name of a device. Details will be shown.
You can try a patched Windows build from here: https://github.com/emericg/WatchFlower/actions/runs/2590210727 It's just adding the name of your device and hoping that unlike advertising, the connection process is the same than the regular flower care. Who knows :p
I enabled BT debug logging on my Android device, ran through the connection process in Smart Life, and dumped the results here
The patched Windows build now shows the device and seems stuck on Syncing. Feels like progress!
Thanks for the support! In the meantime, there is a new build with maybe advertisement support for this device.
I've received my unit, and the advertisement route that seemed promising is actually... not. I'll take some time soon to do a proper RE of the 'regular' Bluetooth communication.
By the way the latest versions are actually working with the Tuya Flower Care, as long as you connected it to the Tuya app once. There is no support for history sync, but that's already something!
Closing, this issue is solved in v5.0
Describe the bug I've purchased the new Flower Care HHCCJCY10 device (update from the previous device HHCCJCY01) which is listed as compatible device. The device is not found by WatchFlower under Windows 11 nor on Android 12.
Details:
DC:23:4D
DC:23:4D
doesn't appear as a valid vendor in any of the lookup tools I'm using.Expected behavior I expect to be able to discover and pair the device as demonstrated in the "Smart Life" application
To Reproduce Steps to reproduce the behavior:
Screenshots N/A
Your environment Please describe the environment you are using: