logo elektroda
logo elektroda
X
logo elektroda

[BK7231N] [CBU] Tuya Light + PIR Motion Sensor (FH_PIR_400A)

auntlydia 7629 50

TL;DR

  • Teardown and flashing notes for the Tuya Light + PIR Motion Sensor FH_PIR_400A with a BK7231N CBU module and an extra ambient light sensor.
  • It is not a TuyaMCU device, so it flashes directly with bk7231flasher without cutting traces or desoldering the CBU module.
  • The light sensor is supposed to measure about 0~6500 lux, and the board can run from 2xAAA batteries or 5V via MicroUSB.
  • OpenBK deep sleep brings the device online and reports status in about ~5 seconds, while always-on Wi‑Fi gives instant motion response.
  • Home Assistant discovery works immediately, but the ambient light sensor could not be made to work with GPIO Doctor on any tested pin.
Generated by the language model.
ADVERTISEMENT
📢 Listen (AI):
  • Hello,

    I would like to present teardown and my user experience of this module:

    Tuya Light + PIR Motion Sensor (FH_PIR_400A) --> AliExpress-Link

    First, some photos of package and content:

    White, round PIR motion sensor with USB port, placed on a wooden surface. Tuya product box with a barcode and Tuya logo. Technical parameters from Tuya motion sensor packaging Packaging and contents of the Tuya PIR motion sensor kit

    Pry to open carefully under reset button, then insert some flat tool to separate the two halves of housing by stretching the gap:
    Close-up of a hand holding a small white device with a reset button on the casing.

    Now have a look at parts and module:

    Disassembled housing of a motion and light sensor. PIR sensor module in an open casing, showing electronic components. Tuya module PCB with microphone and MicroUSB port Electronic module on a purple PCB with a CBU component. Close-up of a circuit board with a CBU module and BK7231 chip.

    We have a very similar module in this post: https://www.elektroda.com/rtvforum/topic3982613.html

    But here we have a CBU module and an additional light sensor which can measure light intensity by Lux at a range between 0 ~ 6500, give or take:

    Interior of the module with a labeled light sensor on the circuit board.

    A few things about device and flashing:

    - it is not a TuyaMCU device
    - there is no need to cut connections or desolder CBU module
    - flashing works flawlessly with bk7231flasher Windows tool
    - the device can be powered with 2xAAA batteries, which makes sense with deep sleep driver (Door Sensor function)
    - it can also be powered with 5V via MicroUSB
    - the reaction time until Wifi is connected and status reported with OpenBK deep sleep is about ~5 seconds
    - without deep sleep the Wifi connection is kept stable and it reacts instantly on motion
    - After detecting motion, it changes to "Clear" within ~5 seconds when no further motion is detected
    --> edit: I have bought several of those devices, and actually only the first one I bought has this fast clearing of motion interval, all the others take 30 seconds to change the status to "Clear" when no further motion is detected.

    I was able to assign following functions to pins:

    P8: motion detector --> dInput(_n) / DoorSnsrWSleep (whichever suits better)
    P16: LED --> LED(_n) / WifiLED
    P23: Battery --> BAT_ADC (choose different channel here)
    P24: Reset Button --> btn

    bkflasher was unable to extract information from original firmware read.

    Here is the file: Tuya_Motio...Sensor.bin (2 MB)You must be logged in to download this attachment.

    Home Assistant discovery works on the spot:

    Sensor widget displaying battery status, voltage, and motion sensor status.

    Unfortunately, I was unable to get the light sensor working. I tried GPIO doctor with all the pins dInput with and without pullup, no success. Any contribution to make the light sensor work would be appreciated.

    Cheers!

    Cool? Ranking DIY
    About Author
    auntlydia
    Level 10  
    Offline 
    auntlydia wrote 70 posts with rating 14, helped 2 times. Been with us since 2023 year.
  • ADVERTISEMENT
  • #2 20722881
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14580
    Help: 654
    Rate: 12604
    So U4 is a light sensor? Are you able to check with multimeter to which GPIO it connects to? It looks like it might have two data lines, is it possible it's something like a I2C sensor?
    Helpful post? Buy me a coffee.
  • #3 20723965
    auntlydia
    Level 10  
    Posts: 70
    Help: 2
    Rate: 14

    Hi, thanks for your reply!

    I was able to trace back the connections, there are 3 connections directly to CBU pins! That is very interesting!!

    Let's have a look:

    Image of a PCB with marked pins P6, P7, P26, and GND. Electronic module with marked pins P6, P7, and P26. Close-up of a PCB with pins labeled with various symbols and colored wires.

    The connections arrive at P6, P7, and P26 of CBU, which are all PWM pins. The other side of the light sensor is connected to GND.

    I am not sure about I2C... until today I had no knowledge about it but read a bit and understand that there are two data lines (SDA and SCL), between the host (main device) and slave (sensor). We seem to have three lines here, all of which are data lines.

    Can you make something of this information? Thank you.
  • #4 20724029
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14580
    Help: 654
    Rate: 12604
    Maybe we can search for I2C light sensors online and see if there are any similar to the one you have on the board.
    Helpful post? Buy me a coffee.
  • #5 20724523
    dgel27
    Level 8  
    Posts: 19
    Hi,
    i have ordered this PiR Sensor:

    [BK7231N] [CBU] Tuya Light + PIR Motion Sensor (FH_PIR_400A)

    Inside it contain LED, BUTTON, PiR sensor, Battery monitor and Light sensor (U4 on the board):
    Electronic module with PiR sensor and various components on a purple PCB CBU module on red printed circuit board with visible test points.

    The device build on TUYA CBU module and contain testpoints TP6 and TP7 (Tx and Rx) from the module. I cannot re-flash it with tuyacloud, only with BK7321 Flash tool. Also, non Flash tool, not tuya cloudcutter cannot extract tyua template (the Tyua firmware attached)

    From my investigation i found connection for this device:
    P8 - PiR sensor
    P16 - LED /WiFi LED
    P24 - Button
    P23 - Batt ADC (coefficient 1.97 work fine for me)
    P22 - Batt Relay

    Light sensor (U4 on the board):
    P6 - I2C clock
    P7 - I2C data
    P26 - programmable interrupt from light sensor, when the light strong(over the range), the signal fall down

    I dont know what is a light sensor, but i attach 2 PulseView files:
    - one is Tuya FW sensor capture
    - OBK power on sensor capture

    I tried to execute scanI2C command, i have see OK result, but i cannot see anything on the bus (the signals is not changes, and was always high). Maybe i dont execute the command right way, but threre no info about this command.

    I will glad if this driver will be implement in OBK firmware.

    Thanks
    Attachments:
    • data_analyzer.zip (6.38 KB) You must be logged in to download this attachment.
    • BK7231N_QIO_pir_light.zip (995.34 KB) You must be logged in to download this attachment.
  • #6 20724577
    ferbulous
    Level 18  
    Posts: 419
    Help: 8
    Rate: 56
    Hi, on the stock firmware
    Do you only get light sensor updates when there's motion detected?
  • ADVERTISEMENT
  • #7 20724587
    auntlydia
    Level 10  
    Posts: 70
    Help: 2
    Rate: 14
    Hi, I had a look at mouser to see if I can find any. It seems not a very easy task, there are many different kinds which look similar, and it is hard do tell what is the difference as a non-professional.

    Here is mouser search result for "ambient light sensor": https://www.mouser.com/c/optoelectronics/optical-detectors-sensors/ambient-light-sensors/

    Those are few ones which I found most similar, but I think they are not the same:
    https://www.mouser.de/datasheet/2/239/Lite-On_LTR-303ALS-01_DS_ver%201.1-1175269.pdf
    https://www.mouser.de/datasheet/2/588/TSL2521_Short_Datasheet_DS001010_1_00-2584593.pdf
    https://docs.broadcom.com/doc/APDS-9251-001-DS

    So, how is the process with unknown I²C components? Do we need to do reverse engineering and read/encrypt data that is sent through I²C bus? I suppose special equipment and some electric knowledge is required here? Or if we are lucky we can find the required data of components in docs and data sheets?
  • #8 20724589
    dgel27
    Level 8  
    Posts: 19

    Hi,
    On the stock firmware, the module stays in deep sleep mode.
    The motion or interrupt from a huge light source (flashlight from a mobile), and it updates 3 things:
    - motion
    - light (lumens)
    - battery percentage

    Thanks!
  • #9 20724626
    auntlydia
    Level 10  
    Posts: 70
    Help: 2
    Rate: 14

    Oh, awesome! As I see, you have done the job of analyzing this light sensor? Yes, combining this topic would be the best. So, with your data, maybe the developers can try to make it work in OpenBK!
  • #10 20724631
    dgel27
    Level 8  
    Posts: 19

    Per footprint, it seems LTR-303-ALS-01.
    Others don't fit the footprint/pinout.
  • #11 20724710
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14580
    Help: 654
    Rate: 12604
    It seems that I2C address is 38:
    Screenshot from a logic analyzer showing I2C signals with addressing and data writing.
    I've read on the other thread that it may be LTR303, but it doesn't seem to match:
    https://github.com/automote/LTR303/blob/master/LTR303.h
    Also the addresses they write to seem different, but maybe I am wrong?

    Do you still have logic analyzer hooked up? I could write some basic code with LTR303_PART_ID request so we can tell whether it's LTR303
    Helpful post? Buy me a coffee.
  • #12 20724750
    dgel27
    Level 8  
    Posts: 19

    Yes, the slave address doesn't match. But pinout exactly fits. I also looked for all LiteOn sensors and cannot find 0x38.
    Maybe something is wrong with my analyzer, it's a simple $5 board. I have a Keysight at work, but it will be next week.
    Is it possible to scan addresses in OBK?
  • ADVERTISEMENT
  • #13 20725244
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14580
    Help: 654
    Rate: 12604
    The scan function you've found was for the hardware I2C bus. Apparently the hardware bus is not used often and our drivers are implemented now as bit-bang in software. Still, if you think that could helpful, hmm... I can think about something and add some kind of generic I2C scanner for software I2C.
    Helpful post? Buy me a coffee.
  • #14 20725830
    dgel27
    Level 8  
    Posts: 19

    I think it will be great.
    Take pins marked as SoftSDA and SoftSCL (or some other type, just for scanning) and scan full addresses.

    It will be great for someone (like me) who wants to add some sensors to current devices.
    I want to use this device and add an I2C weather sensor to the I2C bus and an IR Tx LED to an unused pin. In one nice package, I will have all necessary sensors for the room.

    And many thanks to you for excellent work!
    I'm ready to help with the project to the best of my abilities.
  • ADVERTISEMENT
  • #15 20725894
    auntlydia
    Level 10  
    Posts: 70
    Help: 2
    Rate: 14
    Wow! This is a really cool idea, to add weather sensors and extend the function of this sensor board. Could you share your project here in this thread and explain how you do it? I would be interested to follow the progress...


    @p.kaczmarek2 , thanks for combining our topics! :)

    Added after 3 [hours] 5 [minutes]:

    I was trying to find the sensor again with google search, found some similar ones but that one seems hard do get. I will try to ask a Chinese friend if they can find it in Chinese internet.
    I want to share another photo I took under the microsope. We have 5 internal pins inside the sensor, and it looks like the SMD package has 6 pins, 3 on each side, similar to the LITEON one.. in my photo it looks slightly rectangular, but actually it is square shaped! (display problem)
    Close-up of a sensor on a PCB under a microscope.

    maybe wil fill find it still!
  • #16 20739000
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14580
    Help: 654
    Rate: 12604
    I2C scanner works:
    Screenshot of a system log showing information about I2C scanning with device identification.
    Usage:
    1. set SoftSDA and SoftSCL pins
    2. use:
    
    startDriver I2C
    scanI2C Soft
    
    Helpful post? Buy me a coffee.
  • #17 20739223
    auntlydia
    Level 10  
    Posts: 70
    Help: 2
    Rate: 14
    Hi, thanks!

    I tried with setting P6 to SoftSCL and P7 to SoftSDA, as @dgel27 suggested thad I2C communication is handled through those. Then I set the driver via autoexec.bat and restarted. Now I use a strong flashlight to trigger the sensor, but I don't get any result in log about I2C. Am I using the correct approach here?

    As P26 seems to be the pin where the lux value arrives, which function should we assign to that pin?

    Thanks for help!
  • #18 20739260
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14580
    Help: 654
    Rate: 12604
    No, it doesn't work that way. It's just I2C scanner, it will print addresses of I2C devices detected on the bus. It's not a complete device driver.

    Execute:
    
    scanI2C Soft
    

    from the Web App console and it should print the address of the sensor. Make sure to start I2C driver first.
    Helpful post? Buy me a coffee.
  • #19 20739275
    auntlydia
    Level 10  
    Posts: 70
    Help: 2
    Rate: 14
    OK, I understand. I get

    Info:CMD:[WebApp Cmd 'scanI2C Soft' Result] OK

    but I don't get I2C result! Do I need to specify different channels for the data/clock buses? I tried both with channel 0 and other unused channel, but no difference.
  • #20 20739310
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14580
    Help: 654
    Rate: 12604
    Channels will not affect behaviour of the scan.

    Maybe you've swapped SDA with SCL?

    It should detect a single device address, hm...

    Or maybe you haven't updated OBK?
    Helpful post? Buy me a coffee.
  • #21 20739322
    auntlydia
    Level 10  
    Posts: 70
    Help: 2
    Rate: 14
    I updated to newest OpenBK (246) just before I tried it. The driver is activated and loaded. I have tried SDA and SCL on both P6 and P7, and also P26. There is no message on I2C in logs.
  • #22 20739354
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14580
    Help: 654
    Rate: 12604
    You can't have two SDAs, nor also two SCLs.

    You must have only a single SDA and single SCL.

    Please fix and try again.
    Helpful post? Buy me a coffee.
  • #23 20739406
    auntlydia
    Level 10  
    Posts: 70
    Help: 2
    Rate: 14
    I'm sorry, I was not clear... I tried both:

    P6 - SDA
    P7 - SCL

    and

    P6 - SCL
    P7 - SDA

    and to be sure, I have tried possible combinations of SDA and SCL between P26 and P6 / P26 and P7, to be sure. But I haven't put SDA or SCL double at the same time.

    Is a restart required if pin settings are changed?

    I also double checked to enable "I2C" in log level.
  • #24 20739484
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14580
    Help: 654
    Rate: 12604
    I just realized something...

    Can you update OBK now and try again?

    I am sure you had incomplete version of the scanner:
    Screenshot of a GitHub repository page showing the OpenBK7231T_App branch.
    I committed it 6 hours ago but the push didn't go trough.
    Helpful post? Buy me a coffee.
  • #25 20739506
    auntlydia
    Level 10  
    Posts: 70
    Help: 2
    Rate: 14
    nice!

    this is what I get now:

    Info:I2C:Address 0x38 (dec 56)
    Info:CMD:[WebApp Cmd 'scanI2C Soft' Result] OK

    is that helping in order to make the sensor working?
  • #26 20739889
    dgel27
    Level 8  
    Posts: 19
    I'm also get 0x38.

    I have tried find device by datasheets with this address, and cannot.
    We need wait, or do some reverse engineering with logic analyzer, to find some commands, we can operate.

    @p.kaczmarek2 : I have add another I2C device on the bus (BMP280), and i cannot get results. Is scan support only one device?
    In electronics are no miracles, just bad contacts :)

    I can see 2 devices on the bus:

    Info:I2C:Address 0x38 (dec 56)
    Info:I2C:Address 0x76 (dec 118)
    Info:CMD:[WebApp Cmd 'scanI2C Soft' Result] OK

    Thanks,
  • #27 20739934
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14580
    Help: 654
    Rate: 12604
    This tells us it that it's really an I2C device.

    The next question is - which I2C device is it?

    Which I2C sensor looks like it and has 0x38 address?

    Added after 7 [minutes]:

    Maybe I should implement basic read for LTR303 and we will see how it goes?

    Added after 5 [minutes]:

    This could be useful:
    https://i2cdevices.org/addresses/0x38
    Helpful post? Buy me a coffee.
  • #28 20740507
    dgel27
    Level 8  
    Posts: 19
    It possibly to try, but registers addresses not fit.
    More closer registers adresses in LTR-390, LTR-381RGB, LTR-308, LTR-216, but also not fit that i see in logic analyzer.

    VISHAY have different pinout and different command sysytem - it uses 2 different addresses for read and write (0x38 and 0x39)

    But anyway, i think we have progress, if not in this device, but in full firmware.
    If we can detect device, it possible add many different drivers, and automatically add detected devices to the bus.
    This concept brings OBK to all development possibilities, not just devices present on the market currently.

    OK, we cannot find currently what is device with 0x38 address, ok, it possible order breakout board with known sensor, solder 4 wires... and WOW... we have additional light sensor, that works, and non-works wait for future use....

    Thanks!
  • #29 20741207
    auntlydia
    Level 10  
    Posts: 70
    Help: 2
    Rate: 14
    @dgel27 great idea!
    would you mind do share your steps on how to add known devices to I2C bus and configure them to add their function of the module? maybe a little guide with commented photos would help some other people like myself.

    I have a spare CBU module from a broken device, which still works and could be used for some experimental project like this! I also have a spare motion sensor with 3 pins and could try to connect it, or some buttons or LEDs, or little siren. But I don't have enough knowledge yet which pin to connect where and then to configure it.

    I have flashed more than 20 devices now with OpenBK, it is super cool and makes me addicted somehow 😅I want to get to that point where I can erase all different smarthome apps from my phone and run everything independently and locally with Home Assistant or simple web interface.
  • #30 20741233
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14580
    Help: 654
    Rate: 12604
    How many steps are needed to get the measurement results with that device? Maybe we just could rewrite the steps observed into the logic analyzer into the code... of course assuming we know how we get the data and the data is in some simple format with not much postprocessing needed
    Helpful post? Buy me a coffee.
📢 Listen (AI):

Topic summary

✨ The discussion revolves around the teardown and user experience of the Tuya Light + PIR Motion Sensor (FH_PIR_400A). Participants analyze the internal components, particularly focusing on the light sensor (U4) and its connections to the CBU module. They explore the possibility of the light sensor being an I2C device, with discussions on pin configurations and data lines. Various users share their findings on the sensor's connections, including PWM pins and I2C data lines, and express interest in developing a driver for the sensor to enable its functionality with OpenBK firmware. The conversation also touches on the challenges of identifying the specific I2C device and the need for reverse engineering to understand its communication protocol. Additionally, there are suggestions for alternative Zigbee devices that offer similar functionalities without the need for complex setups.
Generated by the language model.

FAQ

TL;DR: The FH_PIR_400A is a BK7231N/CBU Wi-Fi PIR sensor that flashes without desoldering, reconnects in about 5 seconds from deep sleep, and exposes an I2C light sensor at 0x38. As one maintainer put it, "it's really an I2C device." This FAQ helps OpenBK and Home Assistant users map GPIOs, enable sleep, and troubleshoot the onboard lux sensor. [#20739934]

Why it matters: This device is unusually hackable for a Tuya battery sensor because motion, battery, button, and even the unknown light sensor are directly reachable from the CBU module.

Option Power Setup effort Home Assistant path Main trade-off
FH_PIR_400A with OpenBK 2×AAA or 5V MicroUSB Flashing and pin setup required Native OpenBK discovery works Better flexibility, more work
Similar Zigbee PIR with Zigbee2MQTT Lower battery use Usually out-of-box USB Zigbee coordinator + Z2M Easier setup, less hacking

Key insight: The hard part is not flashing the FH_PIR_400A. The real blocker is identifying and driving the onboard I2C light sensor, which scans reliably at address 0x38 but still lacked a finished OpenBK driver in the thread. [#20739506]

Quick Facts

  • The board can run from 2×AAA batteries or 5V via MicroUSB, which makes it usable both as a battery PIR and as a permanently powered Wi-Fi sensor. [#20722830]
  • Deep sleep gives roughly 5 seconds from wake to Wi-Fi report, while keeping Wi-Fi active makes motion reporting effectively instant. [#20722830]
  • Reported lux range was described as about 0–6500 lux in testing, while the paper manual mentioned 0–10000. [#20741282]
  • The onboard light sensor bus was traced to P6, P7, and P26, and OpenBK later detected the device at I2C address 0x38. [#20739506]

How do I flash the Tuya FH_PIR_400A PIR motion sensor with a BK7231N CBU module using bk7231flasher without desoldering the module?

You can flash it in place, because the CBU module does not need desoldering or trace cuts. 1. Open the case carefully under the reset button and separate the housing halves. 2. Access the CBU test points, then connect bk7231flasher on Windows. 3. Flash OpenBK directly; this model was reported to flash flawlessly with bk7231flasher. The original firmware read did not yield useful extracted template data, so manual pin mapping was still required after flashing. [#20722830]

What GPIO pin mapping works for the FH_PIR_400A in OpenBK, including PIR, LED, battery ADC, and reset button?

A working OpenBK map is P8 for the PIR, P16 for the LED, P23 for battery ADC, and P24 for the reset button. The PIR was used as dInput(_n) or DoorSnsrWSleep, the LED as LED(_n) or WifiLED, the battery input as BAT_ADC, and the button as btn. One tester also reported P22 as a battery relay and used a battery coefficient of 1.97 on P23. [#20724523]

Why does the FH_PIR_400A motion status clear after about 5 seconds on some units but take around 30 seconds on others?

The clear interval varies by hardware unit or stock behavior, not by a single universal OpenBK setting shown in the thread. One tested unit changed from motion to clear in about 5 seconds, but several other units needed about 30 seconds with no further motion. That means the fast clear time is an edge case, not the default you should expect when buying multiple FH_PIR_400A sensors. [#20722830]

How can I configure deep sleep on the FH_PIR_400A in OpenBK, and what effect does it have on Wi-Fi reconnect time and motion response?

Use the PIR input as DoorSnsrWSleep when you want a battery-first configuration. Deep sleep keeps power usage sensible on 2×AAA cells, but wake-up, Wi-Fi join, and status reporting take about 5 seconds. If you disable deep sleep and keep Wi‑Fi connected, the sensor responds to motion immediately instead. That makes sleep mode better for battery life, and always-on Wi‑Fi better for low-latency automations. [#20722830]

What is a TuyaMCU device, and why does it matter that the FH_PIR_400A is not based on TuyaMCU?

"TuyaMCU" is a device architecture that uses a separate Tuya microcontroller to handle functions and exchange state with the Wi‑Fi chip over a serial protocol, instead of wiring sensors directly to the Wi‑Fi module. It matters here because the FH_PIR_400A was explicitly identified as not being a TuyaMCU device. That made direct GPIO mapping possible on the CBU module and avoided extra reverse engineering of a TuyaMCU protocol layer. [#20722830]

What is I2C, and how do SDA, SCL, and interrupt pins relate to the light sensor connections on the CBU module?

"I2C" is a two-wire serial bus that lets one host talk to multiple addressed peripherals over a shared data line and a shared clock line, while some sensors also expose an interrupt pin for threshold events. On this board, the light sensor used two bus lines plus one extra signal. The traced pins were interpreted as SCL on P6, SDA on P7, and an interrupt on P26, with the other sensor side tied to ground. [#20724523]

Which pins on the FH_PIR_400A are used by the onboard light sensor U4, and how were P6, P7, and P26 identified?

The onboard light sensor U4 uses P6, P7, and P26 on the CBU module. Those pins were identified by physically tracing three direct PCB connections from U4 back to the module pads. Later testing refined the roles: P6 as I2C clock, P7 as I2C data, and P26 as a programmable interrupt that drops when strong light triggers the threshold. [#20724523]

How do I use the OpenBK software I2C scanner with SoftSDA and SoftSCL to detect devices on pins P6 and P7?

Set P6 and P7 as the software I2C lines, start the driver, then run the scan command. 1. Assign one pin to SoftSCL and the other to SoftSDA. 2. Start the driver with startDriver I2C. 3. Run scanI2C Soft from the Web App console. A working scan on this device printed Address 0x38 (dec 56). [#20739000]

Why does scanI2C Soft return OK but show no detected I2C address in OpenBK, and what troubleshooting steps should I try?

This usually means the scan command ran, but the pin assignment or firmware build was wrong. Try three checks in order: use exactly one SDA and one SCL, swap P6 and P7 if needed, and update OpenBK to a newer build because one reported scanner version was incomplete until a later push. After updating, the same hardware began returning 0x38 correctly. Channel numbers do not affect scan behavior. [#20739484]

What does it mean when the FH_PIR_400A light sensor shows up at I2C address 0x38, and which ambient light sensors use that address?

It means the onboard lux chip is a real I2C peripheral and answers on 7-bit address 0x38, not just a passive analog sensor. That address ruled out several early guesses and focused the search on sensors that actually use 0x38. The thread later found a strong match in an Everlight ambient light sensor family with the same address and matching SDA, SCL, and INT pin positions. [#20741282]

How was the unknown light sensor in the FH_PIR_400A narrowed down from LTR-303 candidates to the Everlight EAALSDIC2020A2 family?

It was narrowed down by combining address, pinout, and register behavior. Early guesses pointed to Lite-On LTR-303 because the footprint looked similar, but the observed 0x38 slave address and logic analyzer traffic did not fit well. A later datasheet match for Everlight EAALSDIC2020A2 showed the same 0x38 address and a matching pinout, including an INT pin corresponding to P26. [#20741282]

What is the best way to reverse engineer an unknown I2C light sensor from Tuya stock firmware using a logic analyzer and datasheets?

The best method is to capture the stock firmware’s I2C transactions, then compare those register reads and writes against candidate datasheets. In this thread, that meant tracing the bus to P6/P7, confirming the sensor at 0x38, and checking whether observed commands matched likely ambient-light chips. A maintainer suggested a practical shortcut: rewrite the steps seen in the logic analyzer into code if the returned data format looks simple enough. [#20741233]

How can I add another I2C sensor like a BMP280 to the same OpenBK device and scan multiple devices on one software I2C bus?

You can wire another I2C sensor in parallel on the same SDA and SCL lines and scan the full bus. One tester added a BMP280 and later saw both devices in OpenBK: 0x38 for the onboard light sensor and 0x76 for the BMP280. That confirms the software I2C scanner supports multiple devices on one bus when the wiring and contacts are correct. [#20739889]

OpenBK Wi-Fi PIR sensor vs Zigbee PIR sensor with Zigbee2MQTT: which is better for battery life, setup effort, and Home Assistant use?

Zigbee was the better choice in the thread for battery life and easiest Home Assistant setup, while OpenBK Wi‑Fi was better for flexibility. The Zigbee option worked out of the box with a cheap USB coordinator and Zigbee2MQTT, needed no flashing, and was said to consume less power. The FH_PIR_400A offered more hardware freedom because it has both 2×AAA power and MicroUSB 5V, but setup required flashing and manual configuration. [#21092654]

How do I decrease the update time on a Zigbee PIR sensor like the HW-510A-A001 when it currently reports after about 5 seconds?

The thread did not provide a fix for reducing that Zigbee sensor’s update time. The only concrete report was a user seeing about 5 seconds on the HW-510A-A001, with no follow-up settings, firmware tweak, or hardware mod posted afterward. So the safest answer from this thread alone is that no validated method was documented there. [#21104166]
Generated by the language model.
ADVERTISEMENT