[BK7231T WB3S] UltraPro WFD4001 3-Way Smart Wall Switch

Subternatural 1629 25

Reply Cool? Ranking DIY | New topic

Notify about new articles

Helpful post? (+2)

#1 31 Jan 2023 01:57

The UltraPro WFD4001 is a 120V 3-way Wifi smart switch under the UltraPro brand of Jasco. It uses a WB3S Tuya chip, which can be exploited over the air using Tuya-Cloudcutter.

Purchase link: Amazon
Manufacturer Instructions: UltraPro WFD 4001
Alternate Wiring: Alternate Wiring

Product Image:

Teardown:

This is pretty easy to get into, just pop off the front switch cover by pulling on the tabs on either side. Once the front cover is off, you can easily get to the 4 triangle screws (not sure the proper name of these, but I happened to have a bit in a precision screwdriver set from Klein). Once these are removed, the entire metal faceplate can be easily removed.

The board is split into two parts that I will call the control board and the power board. Both of these boards can be removed by just pulling them out, no other screws or tabs are holding them in, although the power board is held in a little bit by the screws terminals, but these can be pushed out from the side. The control board sits on top and has the WB3S chip, as well as the up and down buttons. This is connected to the power board via a 6-pin header, so be careful to pull the control board straight out so the pins don't get bent. A closer look at the 6-pins has them labeled as REL, 5V, GND, 3-WAY, ZEROX, and NC. The REL is also labeled as PWM in some spots - I'm not sure if this is because it terminates to a PWM pin on the WB3S chip, or if there is some other functionality that I don't know about. I could not find where the NC and ZEROX pins go to, so I'm not sure what they are used for. The NC doesn't seem to go anywhere on the board, but the ZEROX looks to be connected to a few components.

The power board has an 0B2222MCP chip which is described as a "PWM Power Switch", but I'm not sure if there is anything useful for us here.

As mentioned earlier, this device can be exploited with tuya-cloudcutter. There is already a device-profile available for it making the conversion pretty easy.

Because this switch has 2 buttons, the config has a bit more steps than normal, but not too bad.
Settings:

Pin # Pin Name Description Settings

P8 PWM2 Up Button Btn_ScriptOnly

P9 PWM3 Down Button Btn_ScriptOnly

P24 PWM4 Front LED LED or LED_n

P26 PWM5 Switch Relay Rel

You will need to create some event handlers to properly handle the buttons. I did this by creating an autoexec.bat file with the following code:
Code: text Expand Select all Copy to clipboard
addEventHandler OnClick 8 setChannel 1 1 addEventHandler OnClick 9 setChannel 1 0

3-Way:
I still haven't figured this out yet, but here is the progress that I've made. Using a multimeter, I determined that the 3-WAY pin connects directly to the ADC3 pin on the WB3S module (0Ω). It looks like the 3-WAY pin also goes to a KL4 chip which looks to be an ADC chip as well, but I couldn't find where it goes from here. When I set the ADC3 pin to ADC mode and put it on its own channel, I can get some values, but nothing that is exactly usable to control the 3-way function. When the traveler wire is low, the ADC values hover in the range of 15-27. When the traveler is high (120V), the ADC output seems to slowly go from the same low range, all the way to 4095 which I assume is the max that can be measured, but then falls back to the low values. It just cycles from low to high indefinitely. I tried watching all of the other pins to see if anything happens when I switch the traveler, but so far I haven't found anything. I don't think I wired anything incorrectly, as I tried the same configuration with a stock switch and it worked fine with the traveler.

Not sure if anyone has experience with something similar, but any help figuring this out would be much appreciated!

Cool? Ranking DIY
About Author
Subternatural Subternatural

Level 3
Offline

Joined: 23 Jan 2023

Posts: 8

Posts rating: 3

Points: 126
Subternatural wrote 8 posts with rating 3. Been with us since 2023 year.
#2 31 Jan 2023 05:25

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Helpful post? (+1)

#2 31 Jan 2023 05:25

Very interesting research. I've been testing Intertek TreatLife 3-way switch, SS02 (FCC ID 2ANIFSS01), and I quickly realized that in case of this device, the stair function is made by using both relay contacts, both NC (normally closed) and NO (normally open), just like on that Wikipedia animation:

In case of SS02, they didn't do any voltage checks to determine is the load currently on and the Tuya app was unable to tell whether light is on or off. The only thing interesting was the way they powered the device - there were extra full bridge rectifiers on both traveler lines.
[BK7231T/WB3S] Treatlife SS02 FCC ID 2ANIFSS01) 3-Way-Smart-Switch
so your review is very interesting and informative for me.

Also I wonder, why is your device using two buttons, one to set on and one to set off?

And btw, 0B2222MCP is OB2222MCP , as in "OnBright", chip name is based on the manufacturer.

Regarding 3-way functionality, wouldn't it just work to simply use our Tasmota Device groups support on any 2 switches to act like a stair pair?
Only one of them would toggle relay in reality. Second would be just a state sender.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600 and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects
#3 31 Jan 2023 06:08

Subternatural Subternatural

Level 3

Topic author Helpful post? (0)

#3 31 Jan 2023 06:08

I actually have a few of the older Treatlife SS01 switches that still used the TYWE3S module, so I was able to flash Tasmota onto them. I believe they are basically rebrands of this MOES 3-way switch Link. It looks like they function pretty similarly to the one that you have, just with the updated Tuya module. I think DigiBlur used to have a pretty detailed write up about them, but I can’t find that post anymore.

The answer to the two buttons questions is yes - the “up” button is on and the “down” button is off, it’s supposed to mimic a traditional rocker switch. This is one of the reasons that I got these switches, I liked that they matched the other rockers that I have, and I also liked that they used a metal frame so they are a bit thinner than some other smart switches that are just plastic and they are able to sit flush with my existing wall plates in multi-gang switch boxes.

Also thanks for the note on the OB chip - I even looked it up and saw that it was OnBright but for some reason didn’t put two and two together

As for the final question, since I already had a 3-way switch where I installed this, I’d prefer to only replace one switch with a new smart switch instead of both - plus if the internet ever goes out I’d like for the switches to continue having full functionality…. Which might be a little weird for me to say since right now I have no 3-way functionality! I’ve also got a TON of 3-way switches in my house, so replacing each pair would be a bit more expensive and I’d prefer to only have to replace a single switch if possible. I bought these in a 4-pack so I still have two that are stock firmware and I’ve debated trying to get the original firmware off of them but I’m trying to avoid soldering if possible…. I might try using the lightleak software to do it OTA, but I haven’t had the chance to get there yet, and I don’t know if the stock firmware would really help me solve this problem.
#4 31 Jan 2023 06:44

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home
Helpful post? (0)

#4 31 Jan 2023 06:44

If you want to replace just one of two switches, then you really need to have some mechanism to determine whether the light is currently on or off.

Quote:

When the traveler wire is low, the ADC values hover in the range of 15-27. When the traveler is high (120V), the ADC output seems to slowly go from the same low range, all the way to 4095 which I assume is the max that can be measured, but then falls back to the low values. It just cycles from low to high indefinitely.

so we would basically need some kind of driver to report the light state based on the measurement on the ADC?
Something like:
Code: text Expand Select all Copy to clipboard
if ADC value is lower than 50 for some time report_light_off else report_light_on

?
I could add such mechanism for you.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600 and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects
#5 31 Jan 2023 07:05

Subternatural Subternatural

Level 3
Topic author Helpful post? (0)

#5 31 Jan 2023 07:05

This switch works a bit differently from the one that you have, it only has a single relay and a single traveler line, so the switch is able to reliably/accurately report its state (the one relay output is either 1 or 0). The ADC value is only measuring the output of the traveler wire/secondary switch and is independent of the relay - whether the relay is on or off, the traveler/ADC will report the value of the secondary switch. I was hoping that as soon as I switched the traveler, the ADC would either go high or low (the state of the secondary switch), but this doesn’t seem to be the case unfortunately.

Another note, the way this 3-way switch is set up is a bit different from a normal 3-way switch, but is typical of some other 3-way smart switches I’ve used. In a traditional installation, two traveler wires run between the two switches and behave like the animation in your first reply. In this setup, one traveler is tied directly to the load, and the other traveler is just used to pass a signal to the “master” switch (the smart switch). The master will then use the signal from the traveler to toggle the relay. The code I was trying to use was something like:
Code: text Expand Select all Copy to clipboard
addChangeHandler ADC > 50 toggleChannel 1 addChangeHandler ADC < 50 toggelChannel 1

Unfortunately the ADC value is not reliably high when the secondary switch is high which seems crazy to me… maybe I need to double check the wiring to make sure I actually set it up correctly - I hope I didn’t miss something obvious :/
#6 31 Jan 2023 10:00

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Helpful post? (+1)

#6 31 Jan 2023 10:00

That code would not work for two reasons.
1. you need to first save ADC value to channel, and use channel with given index and not "ADC" as variable
2. the changes are quick and change handlers don't do debouncing/filtering
Again, I can create a simple driver especially for your use case, but I need to know how it should work.
Quote:

When the traveler is high (120V), the ADC output seems to slowly go from the same low range, all the way to 4095 which I assume is the max that can be measured, but then falls back to the low values. It just cycles from low to high indefinitely.

How long does the cycle take? Can we, for example, assume, that if ADC is below 500 for 1 second, that light is off?

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600 and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects
#7 31 Jan 2023 17:53

Subternatural Subternatural

Level 3

Topic author Helpful post? (0)

#7 31 Jan 2023 17:53

Oh right, in my testing I did assign the ADC value to a new channel, I was just trying to make the code clear that I was using the ADC value.

Before you invest time in developing a new driver for this let me do some more testing on my side. It might be helpful to log the values and build a graph so I can better explain what is going on. A 1 sec debounce doesn't look like it would work, the value actually changes quite slowly, over the course of a minute or so, I'm not sure if using only the ADC value will even be able to do what I want.

Is there any built in functionality to create a log output of a specific channel on the device itself? Or would it be best to try and grab the value using either MQTT or an API call to the device and log it on a separate machine? It wouldn't be too difficult to build something to do that.
#8 31 Jan 2023 18:45

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Helpful post? (0)

#8 31 Jan 2023 18:45

I've worked on that about a week or two ago and added lfs_append, etc commands so scripts can log to files but I don't think so they are reliable when you need to log things so often. That could work if you needed to, for example, log a temperature value every minute or so... but not several times a second.

I can write a customizable debounce driver fast, no problems here. It would allow you to set a debounce time.

If the value changes over the course of minute, then how fast, just theoretically, would the switch detect the change of power state in traveler wire?

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600 and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects
#9 01 Feb 2023 02:06

Subternatural Subternatural

Level 3

Topic author Helpful post? (+1)

#9 01 Feb 2023 02:06

Ya that makes sense, I don't think MQTT would be great for logging multiple times a second either, but I should be able to get a value every 1-2 seconds which might be enough to tell what's going on.

As far as the debounce, I think it would depend on the value when the switch is changed. It seems like the value follows some increasing/decreasing pattern regardless of the state of the traveler, so sometimes when the secondary switch is switched high, the value will immediately jump to 4095, and other times it will just stay low until the next cycle comes around. I'll try getting some logs of the values to see if there is a pattern in the values we could take advantage of. Another note, when the secondary switch is switched low, the ADC value will always immediately go low.

Thanks for all of the help with this! Hopefully the logs I can get will help us better understand this.

Added after 5 [hours] 32 [minutes]:

Well I tried changing the switch with a stock switch, and the 3-way functionality worked, so at least we know its not my installation that was off.

I was also able to log some data from the ADC pin. Here are a couple of screenshots of charts:

I've also attached the raw CSV file with the values. WFD4001_20...6_logs.csv Download (115.53 kB)
A couple of notes on this
- The first few minutes (around 4:08 to 4:12) the secondary/traveler is off, and we can see the values stay low, in the 21-29 range (I think there is only one spike to 29)
- At 4:12, I turned the traveler on, and we can see continual spikes from the 20s all the way up to 4095
- The values and timestamps were taken over MQTT, but the timestamp doesn't change unless the value changed. I added a new row every second regardless, so there are many duplicated values.
- There is a gap between 5:04:05 and 5:07:38 where I stopped logging. Nothing interesting happened here, there is just missing data.
- After I initially turned on the traveler, it stayed on for the rest of the logging.

I don't think there is really any useful information here, but interesting to see what its doing. My thought is that this won't prove to be useful, but perhaps there is something that happens the moment the traveler changes state - I will need to do some more testing to see if any other pins can provide more info. I did test every pin with ADC to see if they did anything, and I found that P2, P3, P4, P5, P12 and P13 all report some values, but they don't seem to change at all when the traveler state is changed.

One final thing - P14 does not report a value when set to ADC, but when set to TglChannelOnTgl, it continually toggles the channel its associated with. I'm not sure what this pin does, but best guess is some sort of clock? Not exactly sure what else I can do to test it further.
#10 12 Feb 2023 00:38

Subternatural Subternatural

Level 3
Topic author Helpful post? (0)

#10 12 Feb 2023 00:38

I know its been a little while, but I finally had a little more time to play with this switch, and I have an update! I feel a little silly that I didn’t try this earlier, but if you set the ADC pin (pin 23) to a Btn, and set Flag 6 (the instant touch flag), the traveler will toggle the channel when going from low to high. I ended up setting Pin 23 to a “Btn_ScriptOnly” and using an event handler so that I have a bit more control over what’s happening. I tried setting an event handler for OnRelease, but it seems this doesn’t work. When the traveler is set high, the OnRelease event will continually fire. So basically I’m halfway there - I can toggle the relay when the traveler goes from low to high, but I don’t know how to sense when it goes from high to low. Here is the event handler I am using at the moment.

Code: text Expand Select all Copy to clipboard
addEventHandler OnPress 23 toggleChannel 1

In the logs, there is also an event that shows up on button press, but nothing shows up when the traveler is changed from high to low.
Code: text Expand Select all Copy to clipboard
Info:GEN:23 Button_OnInitialPressDown

Finally, I noticed if I restart the smart switch and the traveler is low, the logs are continuously outputting the command below, but it stops showing up once I switch the traveler. It also does not show up if the traveler is high when the switch is restarted.
Code: text Expand Select all Copy to clipboard
Info:GEN:23 Button_OnLongPressHold
#11 29 Aug 2023 02:07

eternicode eternicode

Level 4
Helpful post? (0)

#11 29 Aug 2023 02:07

I hope 6 months isn't too long to bring a thread back to life, but I recently bought and flashed one of these WFD4001 switches, and I think I have some new data and insights to bring to the topic.

After setting pins according to @Subternatural's first post (many thanks, this thread has been very helpful in getting me this far), along with ADC_Button on Pin 23, I ran the following commands:

Code: text Expand Select all Copy to clipboard
StartDriver ADCButton AB_Map 2060

and watched the logs though the webapp. Unlike MQTT, which gets updates once per second at most, the logs seem to be showing around 8 samples per second. When the traveler is low, the values hang out in the 25-30 range, and when high, they fluctuate anywhere between 25 and 4095. Logs for each scenario attached.

I believe this comes down to the input being AC (120v 60Hz) vs what I assume is the normal ADC use case of DC. When the traveler is low, some noise is being picked up as the 25-30 value signal, and when high, the signal is fluctuating smoothly between 25 and 4095, peaking 60 times per second. The chip sampling at 8Hz or so doesn't stay in phase with the 60Hz signal (60/8 = 7.5), resulting in sporadic values being read, and the MQTT graphs @Subternatural posted (which match what I was seeing from MQTT values, as well).

One solution would be to smooth the fluctuating signal out, either by taking a moving-window average over the past N samples (which, for this application, might result in a signal around 2060), or by taking the highest value of the past N samples. The latter seems more reliable to me, and considering most sets of 8 samples contain a 4095 instance, N=8 would give the smoothed value a response time of <=1s, which might be reasonable for a smart light switch. Based on my logs, N=4 might even be possible.

Is there anything in the current version of OpenBeken that would accomplish this smoothing? Happy to experiment here to get this working 100%.

Attachments:

logs_traveler_low.txt Download (9.91 KB)

logs_traveler_high.txt Download (9.53 KB)
#12 29 Aug 2023 08:11

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Helpful post? (0)

#12 29 Aug 2023 08:11

There isn't, but maybe I can add something like that for you?
Here's a draft:
https://github.com/openshwprojects/OpenBK7231T_App/commit/9366190698506990f7e84b0c08cb535c7a53fe5c

I will expand this draft in a moment, what kind of parameters do we need? I am thinking about:
- window size (samples count)
- sampling interval in ms
- sampling source pin index
- target channel for smoothed value

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600 and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects
#13 29 Aug 2023 14:34

eternicode eternicode

Level 4

Helpful post? (0)

#13 29 Aug 2023 14:34

Those seem reasonable. Maybe also a flag to choose smoothing algorithm between avg and max?
#14 29 Aug 2023 15:18

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home
Helpful post? (0)

#14 29 Aug 2023 15:18

I am adding it as a separate driver, not as a core feature. So not a flag, but maybe a command param.

The question is, once I determine whether the given value on ADC is high or low, what do I have to do it further?

Detect a change in order to do:
Code: text Expand Select all Copy to clipboard
addChangeHandler ADC < 50 toggelChannel 1

?

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600 and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects
#15 29 Aug 2023 16:24

Subternatural Subternatural

Level 3

Topic author Helpful post? (0)

#15 29 Aug 2023 16:24

This is great! It's funny just 2 days I started looking at this again and noticed the same thing when I tried the AB_Map, glad to see all of the progress made on OpenBeken!

My initial thought was to use a timer in a script that would set a dummy channel to 1 whenever it saw >~2000 and restart the timer, then if the timer ran out it would set that channel to 0. I would then use that dummy channel to toggle the main channel. I couldn't get it to work like I wanted, but having an avg or max over a rolling window would certainly help.

With an avg implemented I think we would only need two change handlers, one when it goes high (>~50) and one when it goes low, both would toggle the main channel.
#16 29 Aug 2023 17:14

eternicode eternicode

Level 4

Helpful post? (0)

#16 29 Aug 2023 17:14

Sorry, yes, I meant a "flag" argument to the driver, not a core flag. We're on the same page there.

If we're exporting the value to a channel, being able to detect change on that channel should be enough to do what we need.

Edit: personally, I have plans to decouple all buttons, including the ADC, from the main relay, and reroute them to logic in my home assistant instance, if that affects implementation. With that in mind, I do want to get the baseline, non-smart 3-way functionality working before I start tackling that extra functionality.

#17 29 Aug 2023 19:30

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

#17 29 Aug 2023 19:30

Maybe a command could look like that?


// ADCSmoother [Pindex] [TotalSamples] [SampleIntervalMS] [TargetChannelADCValue] [MarginValue] [TargetChannel0or1]
// TargetChannelADCValue is a channel which will get smoother value, like 640, etc
// MarginValue is a value that used to tell which smoothed adc values are considered high and which are low
// TargetChannel0or1 will be set depending on MarginValue to either 0 or 1
// something like:
// ADCSmoother 27 10 50 10 2048 11
//

Then you could use (of course, it's just a random example from docs, I do not suggest sending GET to another device here):


// when channel 11 becomes 0, send OFF
addChangeHandler Channel11 == 0 SendGet http://192.168.0.112/cm?cmnd=Power0%20OFF
// when channel 11 becomes 1, send ON
addChangeHandler Channel11 == 1 SendGet http://192.168.0.112/cm?cmnd=Power0%20ON

I don't have any way to test my code. I will push it tomorrow morning and I will need help with testing.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600 and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

#18 29 Aug 2023 19:48

eternicode eternicode

Level 4

Helpful post? (0)

#18 29 Aug 2023 19:48

Looks good. Happy to give it a spin on my device, though it may have to wait for the weekend.
#19 30 Aug 2023 01:56

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home
Helpful post? (0)

#19 30 Aug 2023 01:56

I pushed untested version, usage:
Code: text Expand Select all Copy to clipboard
StartDriver ADCSmoother // ADCSmoother [Pindex] [TotalSamples] [SampleIntervalMS] [TargetChannelADCValue] [MarginValue] [TargetChannel0or1] ADCSmoother 27 10 50 10 2048 11

It will print values every N ms like:

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600 and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects
#20 30 Aug 2023 02:56

Subternatural Subternatural

Level 3
Topic author Helpful post? (0)

#20 30 Aug 2023 02:56

Wow! About 10 minutes of tuning and I think I have a decent config, although I probably need a bit more time to make sure it behaves like I want. Here's the code I added to my startup:

Code: text Expand Select all Copy to clipboard
StartDriver ADCSmoother ADCSmoother 23 10 50 10 50 11 addEventHandler onChannelChange 11 toggleChannel 1

The ADC Pin on this model is 23.
Set 10 and 50 for samples and milliseconds - I tried reducing the samples down to 4 but was getting erroneous changes, so I see most of the tuning being needed here.
Set channel 10 for smoothed value.
Set 50 for switch value, as when the switch is low the actual values pretty much stay at 26-28, so we could probably reduce this down to even 30.
Set channel 11 for my toggle.

Thank you again for implementing this, so far its working exactly as expected! I will keep an eye on it and report back once I've had some time with it.
#21 30 Aug 2023 03:10

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Helpful post? (0)

#21 30 Aug 2023 03:10

I am glad to hear it's working. I didn't expect it to be so straightforward, especially that I haven't even tested my code on a real physical device before submitting, I only ran it in simulator:

Let's test it a bit longer and we will see if any issue arise.

Futhermore, I will already note here, that soon I might have to disable this driver by default to save flash memory size and come up with some kind of configured build (multiple OTA files with multiple features enabled), so just keep it in mind... I am not sure how I will approach this issue yet

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600 and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

#22 31 Aug 2023 23:42

eternicode eternicode

Level 4

#22 31 Aug 2023 23:42

Alright, I got a chance to set the driver up in various configurations to test stability of the low/high value, and I think with tight enough values, this is working very well and can be very responsive when flicking the traveler switch, to the point you wouldn't think there was any smart delay happening.

Wall of text detailing my testing, with numbers and logic and graphs, in the spoiler tag:

Spoiler:

For testing, I configured the following pins, and enabled flag 6:

P2	Rel	10
P3	Rel	11
P23	ADC_Button	5

P2/P3 are set to Relay so their values automatically get sent to MQTT, and P23 is set to ADC_Button on a dummy channel so the raw values are not sent to MQTT. I then used mqtt-explorer to graph the reported values for channels 10/11 over time, watching for consistency in channel 10 (smoothed values) and stability in channel 11 (high/low value).

Before I get to the results, a bit about why I picked the values I picked.

Firstly, the ADC cycle being 60hz, it's (theoretically) important to pick a driver sample rate that will avoid "syncing" with the input (simply, you want a rate that does not divide evenly into the input); if that happens, your sampling will (again, theoretically) always hit the same points in the cycle, meaning you will get a consistent, but limited, smoothed value. On a practical level, there will probably be some drift over time, which may be what @Subternatural saw with a 50ms / 20hz sample rate -- the initial sample segment was high, but over time it drifted downward, triggering the low. Choosing an out-of-phase sample rate causes the sample segment to fluctuate quickly, avoiding staying in the "low" range for too long.

Secondly, a response time of around 250ms or less "feels" best when physically flipping the traveler switch. I'm pretty sure there's research to back that up, but it's certainly subjectively true; I tried configurations that allowed anywhere from 250ms to 1,000ms lag between flipping the switch and seeing the lights change state, and anything above about the 333ms mark starts to feel clunky.

So here are the results of various test runs. Graphs are from mqtt-explorer, taken after running the command, deleting channel 10's data, and letting it re-accumulate until the graph begins scrolling.

Test #	Command	Samples per second (Hz)	Samples averaged	Response time (samples/Hz)	Stability	Smoothed graph
1	ADCSmoother 23 4 60 10 50 11	16.666Hz	4 samples	240ms	Unstable
2	ADCSmoother 23 8 60 10 50 11	16.666Hz	8 samples	480ms	Stable for 1hr
3	ADCSmoother 23 15 37 10 50 11	27.04Hz	15 samples	555ms	Stable for 1hr
4	ADCSmoother 23 8 134 10 50 11	7.46Hz	8 samples	1,007ms	Stable for 1hr
5	ADCSmoother 23 8 124 10 50 11	8.06Hz	8 samples	995ms	Stable for 1hr
6	ADCSmoother 23 9 37 10 50 11	27.04Hz	9 samples	333ms	Stable for 1hr
7	ADCSmoother 23 11 19 10 50 11	52.63Hz	11 samples	209ms	Stable for 1hr
8	ADCSmoother 23 7 37 10 50 11	27.04Hz	7 samples	258ms	Unstable
9	ADCSmoother 23 12 8 10 50 11	125Hz	12 samples	96ms	Stable for 1hr
10	ADCSmoother 23 24 4 10 50 11	250Hz	24 samples	96ms	Stable for 1hr
11	ADCSmoother 23 100 1 10 50 11	1000Hz	100 samples	100ms	Breaks MQTT publishing?

The configuration I ended up with for a "purely physical" (ie, not hooked up to home assistant) setup:

P8	Btn	1	"Up" button
P9	Btn	2	"Down" button
P23	ADC_Button	5
P24	WifiLED
P26	Rel	0

Flags: Just flag 6 (I also have flags 2, 10, and 21 enabled, but those are MQTT related)

autoexec.bat:


# Channels:
# relay = 0
# up btn = 1
# down btn = 2
# adc smoother high/low = 3

StartDriver ADCSmoother
ADCSmoother 23 11 19 4 50 3

addEventHandler onChannelChange 1 setChannel 0 1
addEventHandler onChannelChange 2 setChannel 0 0
addEventHandler onChannelChange 3 toggleChannel 0

With this setup, the lights responding to the traveler switch feels instantaneous, and of course the up and down buttons work exactly as expected (up always turns lights on, down always turns lights off).

My HA integration is going to be a whole other journey, but I expect it will be in line with other threads describing "detached" switches.

Thanks again @Subternatural for kicking this off and @p.kaczmarek2 for whipping this driver up for us! If there are any more performance concerns with this driver, I'm happy to poke at them, but for the moment it seems to be working for me.

#23 01 Sep 2023 09:03

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Helpful post? (0)

#23 01 Sep 2023 09:03

Very good and detailed test. Good job. I am happy to hear it's working in a reliable matter for you.

Regarding the case that breaks MQTT publishing - what happens in the Web App Log at that time? Is it because of too many publishes being made? Or... I don't think so. It may be caused by the processing overheat of the CPU. If so, there is not much we can do about it.

Also... one more thing. You don't need ADCButton role to use the smoother driver! I'd rather say it's better not to use that role, it causes extra load on the CPU.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600 and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

#24 01 Sep 2023 17:07

eternicode eternicode

Level 4

#24 01 Sep 2023 17:07

Alright, I changed P23 back to ADC rather than ADC_Button. I chose ADC_Button because that didn't send values to MQTT; considering I don't care about these values (just the state of each of the buttons, the relay, and the ADC H/L), I'd like to minimize the bandwidth/activity, is there a better way to do this than using ADC_Button?

As for the MQTT cutoff, I tried it again with a script polling /lograw of the device every second and saving the lines with timestamps to a file:


[2023-09-01T10:47:39.171001] Info:MQTT:Channel has changed! Publishing 1500 to channel 10
[2023-09-01T10:47:39.171001] Info:MQTT:Publishing val 1500 to obk12476622/10/get retain=1
[2023-09-01T10:47:39.171001] Info:DRV:AS: raw 4095, smoothed 1540, LowHigh 1
[2023-09-01T10:47:39.171001] Info:GEN:CHANNEL_Set channel 10 has changed to 1540 (flags 0)
[2023-09-01T10:47:39.171001] Info:MQTT:Channel has changed! Publishing 1540 to channel 10
[2023-09-01T10:47:39.171001] Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic obk12476622/10/get
[2023-09-01T10:47:59.233527] et channel 4 has changed to 1283 (flags 0)
[2023-09-01T10:47:59.233527] Info:DRV:AS: raw 3742, smoothed 1620, LowHigh 1
[2023-09-01T10:47:59.233527] Info:GEN:CHANNEL_Set channel 4 has changed to 1620 (flags 0)
[2023-09-01T10:47:59.233527] Info:DRV:AS: raw 27, smoothed 1596, LowHigh 1
[2023-09-01T10:47:59.233527] Info:GEN:CHANNEL_Set channel 4 has changed to 1596 (flags 0)

See the jump between :39 and :59, as well as the channels reverting to what I have set in autoexec.bat. I guess it's not a problem with MQTT publishing, but the device actually crashing/rebooting/resetting with this frequency.

#25 01 Sep 2023 17:19

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Helpful post? (0)

#25 01 Sep 2023 17:19

The driver is written in such a way that you dont' have to set any role for chosen pin. It will initialize the ADC anyway. That is best way to use it.

The crash may be caused by just too many samples of ADC..

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600 and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects
#26 01 Sep 2023 18:00

eternicode eternicode

Level 4

Helpful post? (0)

#26 01 Sep 2023 18:00

Ah, that... is very obvious in retrospect, and works quite nicely.

Thanks again!
Create an account, log in and become active in a forum and ads will not appear. You will receive points by participating in discussions.
Join this discussion.

Log in with Google

Reply Cool? Ranking DIY | New topic

Notify about new articles

Home page
/
Forum
/
Smart Home IoT
/
Smart Home Devices Teardowns
/
[BK7231T WB3S] UltraPro WFD4001 3-Way Smart Wall Switch

Pin #	Pin Name	Description	Settings
P8	PWM2	Up Button	Btn_ScriptOnly
P9	PWM3	Down Button	Btn_ScriptOnly
P24	PWM4	Front LED	LED or LED_n
P26	PWM5	Switch Relay	Rel