logo elektroda
logo elektroda
X
logo elektroda
Dostępna jest polska wersja

Czy wolisz polską wersję strony elektroda?

Nie, dziękuję Przekieruj mnie tam

BK7231T - WB3S UME Outdoor Security Floodlight: Motion-Activated LED, PIR Sensor, CW Lights

mbetter 4746 43
Best answers

How can I make this BK7231T floodlight turn both white LED channels on from the PIR sensor with a delay, and how can I control the PIR sensitivity autonomously?

Use a motion-triggered script or automation that turns on both LED channels together, then delays and turns them off, instead of binding the PIR to only one channel [#20768158] A working pattern shared for the same style of WB3S floodlight uses a PIR input on P6, a cwww light on P8/P9, and scripts such as `waitThenDIM` / `waitThenOff` to keep the light on for a configurable time before dimming or shutting off [#20803268] The Tuya dump shows the PIR-related settings separately: `pirin_pin` is the motion output, while `pirsense_pin: 26` is the sensitivity control pin [#20790634][#20790668] That sensitivity pin appears to be PWM-controlled; the original app exposes it as Near/Medium/Far, which corresponded to about 100% / 50% / 0% duty cycle in testing [#20862391][#20862428] So, in practice, set the two LED PWM channels together in a script, use a delayed off timer, and drive `pirsense_pin` with PWM to match the Tuya sensitivity setting [#20768158][#20803268][#20862428]
ADVERTISEMENT
  • #31 20953486
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14654
    Help: 655
    Rate: 12661
    airdrummingfool wrote:
    I'm working on the PIR sensor input (P6), which does trigger when I walk in front of it, but it also triggers randomly, sometimes repeatedly for many minutes at a time. I tried using a pullup configuration ("6": "dInput_n;57") and also the configuration from this thread ("6": "dInput_NoPullUp;3") but neither fixed the phantom triggering problem. I also tried setting the PIR sensitivity to low (P26 PWM 1000hz 100% duty cycle), but it didn't seem to work (though I'm not positive I configured the sensitivity pin correctly).

    Have you tried all 3 options for dinput - pullup, pulldown and no pull up?

    Have you tried 600Hz PWM? We have a flag for that:
    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/flags.md
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #32 20953551
    Sunnysky
    Level 8  
    Posts: 57
    Help: 1
    Rate: 2

    TLDR; I did not fully understand your network specs, but I know that PIR sensors are analog differential gain and internally very high impedance IR detectors. They are very sensitive to stray noise (conducted and radiated).

    It seems this may be the source of the problem. If you can rule out this cause, that would be good. A 10:1 probe used as a loop antenna for radiated near-field sniffing and then on Vdc. gnd near the chip might reveal some issues < 20 MHz.
  • ADVERTISEMENT
  • #33 20953713
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14654
    Help: 655
    Rate: 12661
    Maybe we need a better filtering on dInput pin? Better algorithm to ignore random noise spikes?
    Helpful post? Buy me a coffee.
  • #34 20953824
    Sunnysky
    Level 8  
    Posts: 57
    Help: 1
    Rate: 2

    If the PIR is malfunctioning due to interference, the only remedy is to remove the real noise.
  • ADVERTISEMENT
  • #35 20953903
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14654
    Help: 655
    Rate: 12661
    I think we can safely assume that the device was working correctly with Tuya. Then it means there is a difference on our side, how we handle the control. if PWM is correct (have you checked both 600Hz and 1000Hz modes?), and the digital input mode is correct (pull-up or pull-down config), then the only last piece of muzzle is the sampling algorithm. Maybe tuya samples the output of PIR, let's say, 100 times per second, and then checks if samples digital values are mostly 0 or mostly 1. Maybe it's possible that it gets randomly sampled as 1 from time to time and it throws the OBK algorithm but works with Tuya.
    Helpful post? Buy me a coffee.
  • #36 20953907
    Sunnysky
    Level 8  
    Posts: 57
    Help: 1
    Rate: 2

    PWM rate may be irrelevant.
    More relevant is ground shift noise or Vcc noise coupled by the PWM due to trace ESL or other parasitics.
  • ADVERTISEMENT
  • #37 20954000
    airdrummingfool
    Level 3  
    Posts: 4

    Thank you all for your responses.

    p.kaczmarek2 wrote:
    Have you tried all 3 options for dinput - pullup, pulldown and no pull up?


    I've tried pullup and no pull up. I can't find anything in the OBK Pin Settings that references pulldown, but I might be looking in the wrong place?

    It's worth noting that I also tried ESPHome on this device, and that firmware had the same issue with the motion sensor. I did try the "pulldown" option in ESPHome, though there's a GitHub issue that says ESPHome's pullup/pulldown options may not work on WB3S.

    p.kaczmarek2 wrote:
    Have you tried 600Hz PWM? We have a flag for that:
    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/flags.md


    I have not, but my understanding from the dumped JSON config is that 1000hz PWM is correct. That is based on these keys:
    Code: JSON
    Log in, to see the code


    p.kaczmarek2 wrote:
    I think we can safely assume that the device was working correctly with Tuya. Then it means there is a difference on our side


    Unfortunately I did not really test Tuya functionality on the device before flashing it. I have received a second Amico Floodlight from the manufacturer, and I am testing Tuya on it now. If it doesn't have the same problem, I will flash it and test and we will know for sure.

    Sunnysky wrote:
    If the PIR is malfunctioning due to interference, the only remedy is to remove the real noise.


    Unfortunately I am not very familiar with identifying and mitigating interference - do you have any practical suggestions on things I might want to check or things that could be causing interference? The device is outside under an overhang, not near any other electronics; it is on a GFCI circuit that has very few other devices on it, all of which are off 90+% of the time. And again I'll note that I'm also working on determining if the device is defective (which perhaps would be the easiest solution, haha).
  • #38 20954111
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14654
    Help: 655
    Rate: 12661
    Pull ups and pull downs are working in OpenBeken. Still, maybe just make an experiment and solder extra resistor there?
    Helpful post? Buy me a coffee.
  • #39 20954139
    divadiow
    Level 38  
    Posts: 5092
    Help: 441
    Rate: 900
    mbetter wrote:
    My configuration is as follows:
    Code: text Expand Select all Copy to clipboard
    {
      "vendor": "UME",
      "bDetailed": "0",
      "name": "Tuya Smart LED Outdoor Security Floodlight",
      "model": "N/A",
      "chip": "BK7231T",
      "board": "TODO",
      "flags": "1024",
      "keywords": [
        "TODO",
        "TODO",
        "TODO"
      ],
      "pins": {
        "6": "dInput_NoPullUp;3",
        "8": "Rel;1",
        "9": "Rel;2",
        "23": "ADC;5"
      },
      "command": "",
      "image": "https://obrazki.elektroda.pl/2082550400_1696896808.jpg",
      "wiki": "https://www.elektroda.com/rtvforum/topic4007225.html"
    }


    https://github.com/OpenBekenIOT/webapp/pull/74
  • #40 20963705
    airdrummingfool
    Level 3  
    Posts: 4

    Update on my testing: when installed outside, the unflashed Amico Floodlight device exhibited the same phantom triggering issue that the one flashed with OpenBeken was experiencing. However, when set up inside my house, neither device had any false triggers. I've concluded that the devices are too sensitive (even set to the lowest sensitivity), and are being triggered by the wind.

    Sorry for the unsatisfying update, but I think I'm going to have to ditch this device and try something else. Thank you all again for your help!
  • #41 20963758
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14654
    Help: 655
    Rate: 12661
    You can ship one piece to me and I will test them on my side. I can try to come up with some kind of in-software fix for phantom triggering.
    Helpful post? Buy me a coffee.
  • #42 20970039
    wolek123
    Level 23  
    Posts: 441
    Help: 46
    Rate: 66
    Hello, is it possible to set a minimum, constant trigger time for dinput? I have several HC-SR501 PIR sensors that I wanted to use with LED drivers, the problem is with the sensitivity adjustment - it can be adjusted with a potentiometer, but even the slightest movement changes from a second to about a minute. The sensor works with home assistant but the logs are a mess.
  • #43 20971259
    Sunnysky
    Level 8  
    Posts: 57
    Help: 1
    Rate: 2

    I believe >= VHF reflections with a vertical dipole or monopole hidden wire, will be your best bet to detect motion without interference using a splitter or Directional Coupler and signal conditioning with CW Tx and measuring reflections with a VHF diode and AC amplifier/detector.
  • #44 21328667
    Sn0w3y
    Level 2  
    Posts: 2
    >>20803268

    Hey :)

    I have the Brennenstuhl WF2050P and can confirm that it also uses the same setup.

    Could you tell me a working solution with OpenBK to make the PIR work? :)

    Greetings !

Topic summary

✨ The discussion centers on the BK7231T-based WB3S UME Outdoor Security Floodlight featuring motion-activated LED control with a PIR sensor, ambient light sensor (ADC), and cold white (CW) LED lights. Users successfully soldered to RX1/TX1 pins for serial flashing using "uartprogram" after GUI flasher failures. The PIR sensor output is a digital 0/1 signal on pin P6, while ambient light sensing uses ADC on pin P23. PWM outputs control white balance and brightness (pins P9 and P8). Sensitivity adjustment for the PIR sensor is challenging; the original Tuya firmware uses PWM duty cycle on pin 26 (pirsense_pin) at 1000 Hz to modulate sensitivity, but OpenBK and ESPHome implementations struggle to replicate this fully. I2C scanning for the PIR sensor was suggested but is complicated without opening the device. Users shared ESPHome YAML configurations for PWM light control and discussed flashing OpenBK firmware for enhanced customization. Phantom triggering of the PIR sensor outdoors, likely due to environmental noise such as wind, remains an unresolved issue despite attempts with pull-up/down configurations and PWM frequency adjustments (600 Hz vs. 1000 Hz). Suggestions include improved input filtering, noise mitigation, and sampling algorithms. The Brennenstuhl WF2050P and Amico Smart LED Motion Sensor Floodlight were confirmed to use similar hardware and firmware approaches. Community members offered to develop drivers and test devices to improve PIR sensor handling and sensitivity control.

FAQ

TL;DR: If your WB3S floodlight stalls at 0x00, power it from 9 V through the board regulator and flash with uartprogram; one tester said the GUI flasher “got stuck immediately,” but UART flashing worked. This FAQ is for BK7231T/WB3S motion floodlights that need reliable pin mapping, PIR sensitivity, and autonomous motion logic in OpenBeken or ESPHome. [#20764976]

Why it matters: These lamps share a reusable hardware pattern, so one verified map and control method can save hours of reverse-engineering across UME, Brennenstuhl, LSC, Nedis, and Amico variants.

Option Strength Limitation Best use
OpenBeken Native BK7231T workflow, Tuya config extraction, local scripts PIR handling may need custom logic or tuning Lightweight autonomous control
ESPHome Strong Home Assistant integration, easy scripted delays, PWM slider entities More YAML, some pull-up/pull-down behavior was questioned on WB3S Rich HA-centric automation
Tuya stock firmware Working app UI for distance, lux, and delay settings Cloud dependency, limited local control Reference behavior and calibration

Key insight: P26 is the practical PIR sensitivity control point on this hardware family. The thread’s strongest evidence shows Tuya changes sensitivity by driving P26 with PWM duty levels, while P6 remains the motion output and P23 remains the ambient-light ADC.

Quick Facts

  • Verified common pin map on several BK7231T/WB3S floodlights: P6 = motion input, P8/P9 = CW LEDs, P23 = ambient ADC, P26 = PIR sensitivity PWM. [#20862539]
  • The ambient sensor is inverted in practice: it reads about 0 V or 0 counts in bright light and up to 1.9 V or roughly 3000 counts in darkness. [#20862539]
  • Tuya config values exposed useful defaults: pirfreq 1000 Hz, trigdelay 15 s, pirsense_pin 26, and pirin_pin 6 on one UME-type lamp. [#20790634]
  • Measured Tuya distance control on P26 mapped to PWM: Near ≈ 3.0–3.3 V / 100% duty, Medium ≈ 50% duty, Far ≈ 0% duty. [#20862391]
  • False triggers were reproduced on both stock Tuya and flashed firmware outdoors, then disappeared indoors, pointing to over-sensitivity or environmental triggering rather than flashing alone. [#20963705]

How do I flash a WB3S/BK7231T UME outdoor security floodlight when the GUI flasher gets stuck at reading 0x00, and what wiring and power setup works with uartprogram from hid_download?

Use uartprogram from hid_download instead of the GUI flasher. One successful setup was: 1. Solder to RX1 and TX1 on the WB3S module. 2. Unplug the JST lead and feed VCE and GND with 9 V, which then goes through the AMS1117 regulator. 3. Share ground with the USB-UART adapter, but do not use the adapter’s 3.3 V pin. That exact wiring flashed successfully after the GUI tool stopped at 0x00. [#20764976]

What is a WB3S module, and how does it relate to the BK7231T chip used in Tuya floodlights?

WB3S is the plug-in Wi‑Fi module, and BK7231T is the SoC on that module. "WB3S is a Wi‑Fi module that hosts the BK7231T controller, exposing pins for UART flashing, GPIO, ADC, and PWM control." In this floodlight family, the board is identified as WB3S, while the firmware and pin mapping target the BK7231T chip. That is why tools, configs, and ESPHome/OpenBeken board choices refer to both names. [#20952388]

What is a PIR sensor, and how is it different from the ambient light sensor on these BK7231T floodlights?

The PIR sensor detects motion, while the ambient sensor measures brightness. "PIR sensor is a motion sensor that changes state when movement is detected, usually as a digital 0/1 signal; the ambient light sensor is a light-level sensor that outputs a varying analog value." On these lamps, P6 goes HIGH on motion, but P23/ADC3 changes across a range, from bright conditions near 0 to dark conditions around 3000 counts or about 1.9 V. [#20764976]

How can I map the pins on a UME or Brennenstuhl BK7231T floodlight for motion input, CW LEDs, ambient light ADC, and PIR sensitivity PWM?

Map the common family pins as P6 = motion, P8/P9 = CW LED PWM, P23 = ambient ADC, and P26 = PIR sensitivity PWM. A later hardware check on a Brennenstuhl unit confirmed P6 high on movement, P9 as white-balance PWM, P8 as light-intensity PWM, and P23 as the light sensor. Tuya storage also exposed pirsense_pin: 26 and pirin_pin: 6, which matches the practical mapping used in ESPHome. [#20862539]

What's the best way in OpenBeken to make both CW LED channels turn on together from motion without breaking the selected color temperature?

Drive the light as one logical CW/CW light, then trigger both channels together with a command or script. A direct OpenBeken suggestion was to use a change handler and run led_enableAll 1, instead of binding motion to only one LED channel. That avoids the bad result where only warm or only cool turns on and shifts color temperature. If you need the previous white balance preserved, keep P8 and P9 under the light entity and let motion call the combined enable action. [#20768158]

How do I add an off-delay in OpenBeken or ESPHome so a PIR floodlight stays on for 15 to 30 seconds after motion ends?

Add a delayed action after the motion event or motion release. In OpenBeken, one suggested pattern was led_enableAll 1 plus a single-repeat delayed event, for example 30 seconds, that runs led_enableAll 0. In the Tuya-derived config, one lamp already stored trigdelay: 15, which is a useful starting point. ESPHome examples in the thread used delay: inside scripts, then dimmed or switched off after user-set durations. [#20768158]

Why does the ambient light sensor on P23 read 0 in bright conditions and up to around 3000 or about 1.9 V in darkness on these lamps?

Because this sensor path is inverted: brighter light lowers the reading, and darkness raises it. One tester measured 0 = brightest and about 3000 = darkest on the ADC scale. Another tester measured about 0 V in maximum light and roughly 1.9 V in complete darkness on the same sensor path. That behavior matches the Tuya threshold fields such as dusk, evenfall, evening, and night, which all represent darker conditions with larger values. [#20862539]

How does the PIR sensitivity control work on pirsense_pin P26, and what PWM duty cycles correspond to near, medium, and far distance settings in the Tuya app?

P26 works as a PWM-driven sensitivity input, not as the main motion output. The clearest measurement showed Tuya’s distance settings as Near ≈ 3 V, Medium ≈ 3 V at 50% duty, and Far ≈ 0 V. A logic-analyzer follow-up confirmed that meant Near = 100% duty, Medium = 50% duty, and Far = 0% duty. In practice, P6 still reports motion, while P26 sets how sensitive the PIR front end is. [#20862428]

Where can I find PIR sensitivity, trigger delay, and pin assignments in the extracted Tuya storage JSON or UPK config for these floodlights?

Look in the extracted Tuya JSON or UPK user_param_key section. Useful keys include pirsense_pin, pirin_pin, pirfreq, pirlduty, pirmduty, pirhduty, pirrange, and trigdelay. One dumped config exposed pirsense_pin: 26, pirin_pin: 6, c_pin: 8, w_pin: 9, pirfreq: 1000, and trigdelay: 15. Those fields gave enough information to build a working local config without reopening the lamp. [#20790634]

What causes phantom PIR triggering on BK7231T/WB3S floodlights after flashing OpenBeken or ESPHome, and how do I troubleshoot pull-up, pull-down, PWM frequency, and noise issues?

Phantom triggering can come from real over-sensitivity or environmental noise, not only bad firmware. One tester saw false triggers on both OpenBeken and stock Tuya outdoors, but not indoors, then concluded wind was triggering the sensor. Practical checks were: 1. Try input modes with pull-up, no pull, and pull-down where supported. 2. Test PIR PWM at 1000 Hz and optionally 600 Hz. 3. If needed, add external resistor biasing and inspect for supply or ground noise. This is an edge case where the hardware can remain problematic even when the pin map is correct. [#20963705]

How should I scan for possible I2C devices on a Tuya floodlight when I suspect the PIR sensitivity might be controlled over I2C rather than a simple GPIO?

Start by extracting Tuya config first, because it may reveal the control pins without blind scanning. That suggestion solved one case: after reviewing the dumped config, the user found pirsense_pin: 26 and stopped treating PIR control as a pure I2C mystery. If you still suspect I2C, you would need to guess or trace possible SDA and SCL pins, then scan them systematically. The thread treats that as time-consuming unless you can open the lamp and inspect the sensor board. [#20790096]

OpenBeken vs ESPHome for WB3S motion floodlights — which is better if I need autonomous motion logic, PIR sensitivity control, and Home Assistant integration?

Choose ESPHome if you want fast Home Assistant integration and easy scripted behavior; choose OpenBeken if you want a lighter native BK7231T workflow and Tuya-oriented recovery tools. The strongest ESPHome example exposed P26 as a slider, used P6 for motion, P23 for ambient sensing, and added autonomous delay scripts. OpenBeken, however, was the preferred route when users wanted local device logic without relying on openHAB or cloud behavior. Both worked on this hardware family. [#20866799]

How do I build an ESPHome config for an LSC, UME, Brennenstuhl, Nedis, or Amico BK7231T floodlight with P6 motion input, P23 ambient ADC, P8/P9 CW outputs, and P26 PIR PWM control?

Use binary_sensor on P6, adc on P23, libretiny_pwm outputs on P8 and P9, and a PWM output on P26 for PIR sensitivity. One working config used a cwww light with cold_white = P8, warm_white = P9, plus a template number that called output_pirsense.set_level(x/100). It also added scripts for full brightness, dimming, and delayed off. That layout was reported working on LSC-type hardware and later linked to Brennenstuhl, Nedis, and similar lamps. [#20866799]

Why is Home Assistant MQTT Discovery showing the PIR sensor state reversed for an OpenBeken binary sensor, and how should pl_on and pl_off be configured?

The reported issue was that Discovery published reversed payloads for that PIR entity. The captured JSON showed pl_on: "0" and pl_off: "1", while the tester expected the opposite because Home Assistant displayed ON when OpenBeken showed the pin low. For a normal active-high motion signal, pl_on should be the asserted value and pl_off the idle value. On that device, the report suggested pl_on = 1 and pl_off = 0 were the correct mapping. [#20950930]

What is a working OpenBK solution to make the PIR operate correctly on the Brennenstuhl WF2050P and similar BK7231T floodlights, including sensitivity and false-trigger handling?

Use the shared pin map, set PIR sensitivity on P26 with PWM, and add software delay or filtering around P6. The most complete thread evidence confirmed Brennenstuhl WF2050P uses the same family layout, with Tuya-style distance control on P26 and motion on P6. For reliable behavior, keep P26 at 0%, 50%, or 100% duty for far, medium, or near, then add delayed-off logic in firmware. If false triggers remain outdoors, treat them as a real sensitivity problem and lower duty or test placement, because some units still triggered from wind. [#21328667]
ADVERTISEMENT