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

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

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.

Maybe we need a better filtering on dInput pin? Better algorithm to ignore random noise spikes?

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

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.

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.

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:

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).

Pull ups and pull downs are working in OpenBeken. Still, maybe just make an experiment and solder extra resistor there?

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

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!

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.

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.

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.

>>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 !