just to be sure, I purchased a 2nd XIAO.
Same result. So it’s not a product defect.
I read that the bluefruit library was built on the nordic stuff, and at least used to be the better choise.
Is this correct?
Do you have any other “embedded” device you can test code with?
1 Like
Plenty. What do you want. Raspberry pi 3,4,5, zeroW. Arduino uno, mega? Boxes full.
On another note, i was digging around in the code to see what filters it uses. As i’m pretty sure it does receive the sensor, but it gets filtered for some reason.
This led me to set #define BLE_TRACE; However I get no trace. What am I missing?
Well I was right. Issue itself is not fixed yet, but I now know where it’s going wrong.
That A8 address was the one eluding me. And now it’s getting reported.
So the XIAO DOES see the device. The offending code is here:
in the GAP.cpp file in /Arduino\libraries\ArduinoBLE\src\utility.
The issue is that my device/address doesnt make device->discovered() evaluate to true.
… will update when more info avail.
1 Like
It appears to me Tuya is not following the bluetooth standards on this one. The advertised data frame is decoded incorrectly, resulting in the flags set to 1, whereas the code expects either 0x03 or 0x04 to be set. For now I solved this by changing the flag mask from 0x18 to 0x19.
I am pondering to just make new firmware for the sensor. As stated, it uses a PHY6222, which is a BLE SOC. So it should work. I feel like they added some tuya specific ‘security’ to force you to stay in the tuya ecosystem, which clearly I’m not.
http://www.k-sol.com.hk/assets/phy6222_ble_soc_datasheet_v1.0-20201204.pdf
Its starting to look more and more like I’m right in this:
This is the scan example from the BLE package. After having changed beforementioned mask, it reports this.
Looking for UUID FD50 yields:
" ya’s pairing protocol also includes the Tuya-specific service (UUID: 0xFD50 ). This service defines properties (read, write, and notify) for characteristic values and specifies Bluetooth LE parameters such as advertising period/interval, connection interval/mode, and data exchange method to maximize Bluetooth performance."
In other words… i’m fighting tuya specific crap.
1 Like
I think that’s why the alternate solution I mentioned re-flashes the firmware. I asked Tuya Development for a solution but have not heard back.
It seems it is possible without a firmware change - see the Tuya BLE HACS integration. But I haven’t tried (yet 
).
1 Like
Your message made me look back, as I didn’t see any alt firmware. Missed your link. That might be the best answer so far, as it looks like they did exactly what I propose; replace the proprietary tuya crap with general firmware.
It looks like 'm going to flash their firmware and have it work.
Well, having some time to dick around with this, and the issue is solved, thanks to Grobasoz. Who linked GitHub - pvvx/THB2: Custom firmware for Tuya devices on the PHY622x2 chipset this page, which contains firmwares for the sensor. It requires you to own a serial<>com device FRDI, which I do. I tinker with this stuff a lot 
Thy have specific firmware for this sensor. The OTA stuff didn’t work for me, but you can write the firmware bin to the device directly using the usb/com adapter.
This worked flawlessly and now it’s no longer a tuya device. Withouth any changes to BLE, it connects fine and I can read it’s values.
1 Like
@zikken - Thanks for the update 