I recently bought an Xtreme Smart Wifi Window/Door Sensor model XHS7-2001-WHT. They are being sold at my local Princess Auto (for any Canadians who want to pick one up). It uses the Tuya CBU module which uses BK7231N. The flashing and auto configuration worked great. I switched it to use the...

I have this pr currently installed on 2 devices. One is cht8310 sensor with 1000mah li-ion battery, supported by a solar panel. The other one is a door sensor, with 2x1000mah 1.2v ni-mh batteries, and i haven't had a problem with it for 4 months. The batteries are still working.

I was under impression that our DoorSensor driver has it solved, are you using it? Or are you manually scripting your device? Maybe we can improve DoorSensor driver for you, or try to come up with autoexec.bat that will first store initial channel value (in separate channel) and then, once MQTT is online, publish it along with current value. Maybe this can help improve connection speeds: It's stuck due to the lack of testing, maybe we can gather some time, @insmod @divadiow @DeDaMrAz and try to get it working?

@protectivedad Can you share your config and autoexec file. I remember we did some work on it and I tested the reporting (same issue you are mentioning) and we got it solved. If I remember correctly you will have to have waitfor MQTT state in your autoexec to be sure it has mqtt connection before going to deep sleep again. Don't quote me on that 100% as it was some time ago but I can certainly check as I still have that door sensor somewhere. @p.kaczmarek2 I was having troubles testing that PR at the time, was not able to make it work on my N test module. It was stuck on boot every time with the changes but I am always all in on improvements. Will order 10 more CB3S modules for testing as I ran out and some of them had issues so I am not sure at this point if I used some of them for testing.

I am using the DoorSensor no pull up version. Also I forgot to mention I'm using a version without a TuyaMCU. That is exactly what I was thinking of implementing. I'll start testing this. Even with a quicker reconnect I like the idea of storing the open value in a separate channel and publishing it just in case the mosquitto server is slow. No autoexec.bat but I do use the startup command. It's always connected to the MQTT before going to sleep. For my MQTT I use the IP (not name) and I started a non-tls instance. Code: JSONLog in, to see the code When I was testing the log always says: Code: TextLog in, to see the code Added after 1 [hours] 6 [minutes]: I cherry picked the PR on top of the 1.8.12, compiled and installed it. I attached the rbl I used (zipped). The device doesn't connect to the wifi and I don't currently have serial access. I can safe boot. How do I resest the wifi credentials to make sure that is not the problem. I tried just changing the password hoping that would work but no luck. I have more then one AP with the same SSID on different channels so I created a test SSID and retried connecting still no luck. Also I can't flash an OTA update anymore. It goes through the OTA process looks like it is working and when it reboots it still says 1.8.12p. Even when I tried using an older 1.8.8. Any ideas without reconnecting the serial connection?

Remember that OBK has AP safe mode mechanism that will run if boots are marked as failed. Change the required uptime seconds in options/flags&general. If you want to change WiFi password and ssid from UART, you can use our flasher:

Sorry didn't see this when I was updating my post with more test results. I have booted into safe mode then I Converted to open access wifi. Restarted. I then re-entered the wifi credentials but still no connection. Also, as I mentioned, it will no longer accept OTA updates. Any NON UART suggestions?

Have you tried clearAll command from safe mode? Backup what you need before as it will reset everything.

I had not. I was searching the command reference for the word erase I never thought to look for clear I used a custom 1.17.571 I had around for testing mqtt-tls. That flashed and I then went back to the stock 1.18.12 (a5e439f0) (NOT 1.8.12). I then flashed the 1.18.12p (a5e439f0 with PR 1297 applied). This was all done with my test ssid. And it worked. I also turned off dhcp (maybe that was causing extra time) and set up a static IP. So it gone from 12 seconds to under three. I was definitely doing something wrong before. It is now behaving very differently. Before when the door sensor was triggered it was always flashing to indicate reconnecting to the network. Now it goes solid blue. Could it have been the DHCP setup that was causing my issues? I feel like a bit of an idiot for not doing that sooner. I swear I read three or four topics on the door sensors and I never tripped over setting a static IP. Well doesn't seem like DHCP was the problem. I had to erase and reinstall the flash when I switched from my test to my home SSID. During that I forgot to set up a static IP. With the DHCP it still connects really quickly.

>>21381870 Thanks for the autoexec. I've set flag 37 but from the code just having the pin set to be a door sensor with sleep does the same thing. With the psk update it is now quite snappy, although it might occasionally have a problem, still testing. For the most part it is working well.I might have been getting the quick on/off but I was never able to see it because it happened too quickly. I set up a trigger rule. If the door sensor has problems connecting it will take time but the open seems to get there eventually.Thanks for the help.

So, to sum up, do you think this new fast connect feature is production-ready, or what is still missing? Btw, I saw you mention mqtt-tls, how is it stable for you? I am asking because I am considering merging both quick connect and mqtt-tls pull requests. Which PR do you think we could merge?

Xtreme Smart Wifi WindowDoor Sensor - Model XHS7-2001-WHT - CBU Module

protectivedad 1464 13

Report a violation of the law

Reply | New topic

#1 21380546 06 Jan 2025 19:16

protectivedad protectivedad

Level 9

Topic author

Post #1
21380546 06 Jan 2025 19:16

I recently bought an "Xtreme Smart Wifi Window/Door Sensor" model XHS7-2001-WHT. They are being sold at my local Princess Auto (for any Canadians who want to pick one up). It uses the Tuya CBU module which uses BK7231N. The flashing and auto configuration worked great. I switched it to use the door sensor driver no pull-up and it wakes up from deep sleep properly. The only real issue which is kind of a deal breaker is the time it takes to connect to the wifi/mqtt. A burglar would have to be kind enough to hold the door open for at least 5 seconds before the home system would receive the open signal. I wanted to see if anyone had a solution to this problem.

OpenBK seems just to send the status of the sensor at connection to the mqtt broker. So if the door is opened and closed within 5 seconds or so it just resends a closed signal. Is there an option that allows the signals to be queued and then sent to the mqtt broker? I would then at least get an open "blip" that I could work with.

I looked at the source code and noticed that with the door sensor it will automatically select quick wifi connect but I selected the flag anyway which made no difference. I did see mention of `RL_SUPPORT_FAST_CONNECT` which is disabled because of the conflict with where OpenBK stores settings in the flash. In the comments I've seen on github it would "only save 3-4 seconds." I think that is a long time when it comes to devices that are not powered all the time and need to go from deep sleep to wake to deep sleep. Any chance of shifting the settings to allow fast connect to work?

There was another post on the esphome (tinylibre) which talked about speeding up the wifi connecting by adding a feature that allows the use of a PSK (64-byte string) instead of the current passphrase. Any ideas if this is feasible? Maybe this is already a feature and we only need to enter a 64 byte string and it will take it to be the PSK.

Thanks.
AI: Could you provide the current firmware version of your Xtreme Smart Wifi Window/Door Sensor? This might help in identifying if the issue is related to a specific firmware version.
OpenBK version 1.18.8
AI: Can you share more details about your MQTT broker and network configuration? This information could be crucial in understanding the delay in connection time.
WPA2, mosquitto running on OpenWrt.

ADVERTISEMENT
#2 21380886 06 Jan 2025 21:50

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Helpful post? (0)

Post #2
21380886 06 Jan 2025 21:50

I was under impression that our DoorSensor driver has it solved, are you using it? Or are you manually scripting your device? Maybe we can improve DoorSensor driver for you, or try to come up with autoexec.bat that will first store initial channel value (in separate channel) and then, once MQTT is online, publish it along with current value.

Maybe this can help improve connection speeds:
https://github.com/openshwprojects/OpenBK7231T_App/pull/1297
It's stuck due to the lack of testing, maybe we can gather some time, @insmod @divadiow @DeDaMrAz and try to get it working?

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

Helpful post? Buy me a coffee.
#3 21381070 07 Jan 2025 00:05

DeDaMrAz DeDaMrAz

Level 22

Helpful post? (0)

Post #3
21381070 07 Jan 2025 00:05

@protectivedad

Can you share your config and autoexec file. I remember we did some work on it and I tested the reporting (same issue you are mentioning) and we got it solved. If I remember correctly you will have to have waitfor MQTT state in your autoexec to be sure it has mqtt connection before going to deep sleep again. Don't quote me on that 100% as it was some time ago but I can certainly check as I still have that door sensor somewhere.

@p.kaczmarek2

I was having troubles testing that PR at the time, was not able to make it work on my N test module. It was stuck on boot every time with the changes but I am always all in on improvements.

Will order 10 more CB3S modules for testing as I ran out and some of them had issues so I am not sure at this point if I used some of them for testing.

If you like my work, support me at: https://paypal.me/openshwprojects
ADVERTISEMENT
Helpful post

#4 21381078 07 Jan 2025 00:21

insmod insmod

Level 31

Helpful post? (+1)

Helpful post
Post #4
21381078 07 Jan 2025 00:21

I have this pr currently installed on 2 devices. One is cht8310 sensor with 1000mah li-ion battery, supported by a solar panel.
The other one is a door sensor, with 2x1000mah 1.2v ni-mh batteries, and i haven't had a problem with it for 4 months. The batteries are still working.
#5 21381479 07 Jan 2025 13:11

protectivedad protectivedad

Level 9
Topic author Helpful post? (0)

Post #5
21381479 07 Jan 2025 13:11

p.kaczmarek2 wrote:
I was under the impression that our DoorSensor driver has it solved, are you using it? Or are you manually scripting your device? Maybe we can improve DoorSensor driver for you, or try to come up with autoexec.bat that will first store initial channel value (in separate channel) and then, once MQTT is online, publish it along with current value.

I am using the DoorSensor no pull up version. Also I forgot to mention I'm using a version without a TuyaMCU.

p.kaczmarek2 wrote:

Maybe this can help improve connection speeds:
https://github.com/openshwprojects/OpenBK7231T_App/pull/1297
It's stuck due to the lack of testing, maybe we can gather some time, @insmod @divadiow @DeDaMrAz and try to get it working?

That is exactly what I was thinking of implementing. I'll start testing this. Even with a quicker reconnect I like the idea of storing the "open" value in a separate channel and publishing it just in case the mosquitto server is slow.

DeDaMrAz wrote:

Can you share your config and autoexec file. I remember we did some work on it and I tested the reporting (same issue you are mentioning) and we got it solved. If I remember correctly you will have to have waitfor MQTT state in your autoexec to be sure it has mqtt connection before going to deep sleep again. Don't quote me on that 100% as it was some time ago but I can certainly check as I still have that door sensor somewhere.

No autoexec.bat but I do use the startup command. It's always connected to the MQTT before going to sleep.
For my MQTT I use the IP (not name) and I started a non-tls instance.
Code: JSON
Log in, to see the code

When I was testing the log always says:
Code: Text
Log in, to see the code

Added after 1 [hours] 6 [minutes]:

I cherry picked the PR on top of the 1.8.12, compiled and installed it. I attached the rbl I used (zipped). The device doesn't connect to the wifi and I don't currently have serial access. I can safe boot. How do I resest the wifi credentials to make sure that is not the problem. I tried just changing the password hoping that would work but no luck.

I have more then one AP with the same SSID on different channels so I created a test SSID and retried connecting still no luck. Also I can't flash an OTA update anymore. It goes through the OTA process looks like it is working and when it reboots it still says "1.8.12p". Even when I tried using an older 1.8.8. Any ideas without reconnecting the serial connection?

Attachments:

OpenBK7231N_App_1.8.12p.zip (489.84 KB) You must be logged in to download this attachment.
#6 21381599 07 Jan 2025 13:26

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Helpful post? (0)

Post #6
21381599 07 Jan 2025 13:26

Remember that OBK has AP safe mode mechanism that will run if boots are marked as failed. Change the required uptime seconds in options/flags&general.

If you want to change WiFi password and ssid from UART, you can use our flasher:
https://github.com/openshwprojects/BK7231GUIFlashTool

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

Helpful post? Buy me a coffee.
ADVERTISEMENT
#7 21381646 07 Jan 2025 14:01

protectivedad protectivedad

Level 9

Topic author Helpful post? (0)

Post #7
21381646 07 Jan 2025 14:01

p.kaczmarek2 wrote:
Remember that OBK has AP safe mode mechanism that will run if boots are marked as failed. Change the required uptime seconds in options/flags&general.

If you want to change WiFi password and ssid from UART, you can use our flasher:
https://github.com/openshwprojects/BK7231GUIFlashTool

Sorry didn't see this when I was updating my post with more test results. I have booted into safe mode then I "Converted to open access wifi". Restarted. I then re-entered the wifi credentials but still no connection. Also, as I mentioned, it will no longer accept OTA updates. Any NON UART suggestions?
#8 21381663 07 Jan 2025 14:13

DeDaMrAz DeDaMrAz

Level 22

Helpful post? (0)

Post #8
21381663 07 Jan 2025 14:13

protectivedad wrote:
Any NON uart suggestions?

Have you tried clearAll command from safe mode? Backup what you need before as it will reset everything.

If you like my work, support me at: https://paypal.me/openshwprojects
ADVERTISEMENT
#9 21381735 07 Jan 2025 15:05

protectivedad protectivedad

Level 9

Topic author Helpful post? (0)

Post #9
21381735 07 Jan 2025 15:05

DeDaMrAz wrote:

protectivedad wrote:
Any NON uart suggestions?

Have you tried clearAll command from safe mode? Backup what you need before as it will reset everything.

I had not. I was searching the command reference for the word "erase" I never thought to look for "clear"

I used a custom 1.17.571 I had around for testing mqtt-tls. That flashed and I then went back to the stock 1.18.12 (a5e439f0) (NOT 1.8.12). I then flashed the 1.18.12p (a5e439f0 with PR 1297 applied). This was all done with my test ssid. And it worked. I also turned off dhcp (maybe that was causing extra time) and set up a static IP. So it gone from 12 seconds to under three.

I was definitely doing something wrong before. It is now behaving very differently. Before when the door sensor was triggered it was always flashing to indicate reconnecting to the network. Now it goes solid blue. Could it have been the DHCP setup that was causing my issues? I feel like a bit of an idiot for not doing that sooner. I swear I read three or four topics on the door sensors and I never tripped over setting a static IP.

Well doesn't seem like DHCP was the problem. I had to erase and reinstall the flash when I switched from my test to my home SSID. During that I forgot to set up a static IP. With the DHCP it still connects really quickly.

#10 21381870 07 Jan 2025 16:47

DeDaMrAz DeDaMrAz

Level 22

Post #10

21381870 07 Jan 2025 16:47

Just for reference, this was the testing autoexec from my door sensor that later got reduced to remove some timeouts and checks.

Battery_Setup 2000 3000 2 2400 4096
//measure batt every 2s
Battery_cycle 2
mqtt_broadcastItemsPerSec 3
// use P28 click to prolong the awake time this session
addEventHandler OnClick 28 addChannel 10 120
// channel 10 is number of seconds to keep alive
setChannel 10 120
// always wake up on rising edge on dInput (when smoke sensor starts alarm)
DSEdge 0
// now wait for MQTT
waitFor MQTTState 1
// extra delay, to be sure
again:
delay_s 1
// decrease counter by 1
addChannel 10 -1
echo Before sleep, loop is now $CH10
// repeat loop if > 0
if $CH10>0 then goto again
// go back to sleep
PinDeepSleep

There were flags set, flag 2 for mqtt and flag 37 for quick connect to improve on the connection time, as well as Uptime seconds required to mark boot as OK: set to 2 or 3 seconds. Static IP helped as well and overall brough down response time to 5 seconds or less in the tests we did back then.

If you like my work, support me at: https://paypal.me/openshwprojects

#11 21382657 08 Jan 2025 04:13

protectivedad protectivedad

Level 9

Topic author Helpful post? (0)

Post #11
21382657 08 Jan 2025 04:13

>>21381870 Thanks for the autoexec. I've set flag 37 but from the code just having the pin set to be a door sensor with sleep does the same thing. With the psk update it is now quite snappy, although it might occasionally have a problem, still testing. For the most part it is working well.

I might have been getting the quick on/off but I was never able to see it because it happened too quickly. I set up a trigger rule. If the door sensor has problems connecting it will take time but the open seems to get there eventually.

Thanks for the help.
#12 21382888 08 Jan 2025 10:29

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Helpful post? (0)

Post #12
21382888 08 Jan 2025 10:29

So, to sum up, do you think this new fast connect feature is production-ready, or what is still missing?

Btw, I saw you mention mqtt-tls, how is it stable for you?

I am asking because I am considering merging both quick connect and mqtt-tls pull requests.
Which PR do you think we could merge?

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

Helpful post? Buy me a coffee.
#13 21382906 08 Jan 2025 10:46

insmod insmod

Level 31

Helpful post? (0)

Post #13
21382906 08 Jan 2025 10:46

>>21382888 I believe it would have to be enabled via a flag, not how it is currently done.
And maybe add another hal function that connects via a saved bssid.
#14 21383155 08 Jan 2025 13:31

protectivedad protectivedad

Level 9

Topic author Helpful post? (0)

Post #14
21383155 08 Jan 2025 13:31

p.kaczmarek2 wrote:
So, to sum up, do you think this new fast connect feature is production-ready, or what is still missing?

Btw, I saw you mention mqtt-tls, how is it stable for you?

I am asking because I am considering merging both quick connect and mqtt-tls pull requests.
Which PR do you think we could merge?

I'd really like to see mqtt-tls merged. I would be happy to test it if it can be added to the current 1.18.12.

I'm not sure about the current implementation of PSX. I'd need to put a serial connection back on a device and look at it closer. It got hung up on changing from one SSID to another (maybe the internal settings need to be cleared on an SSID change). I need to do more testing on what happens if one AP goes done and it switches to a different AP. Having a BSSID and PSX save option in the wifi HTTP page would I think be the most ideal. The wifi passphrase is limited to 63 characters so if it is 64 characters it is taken as the PSX. It might be nice to key off the size and allow the user to enter a premade PSX. Not sure if that would do the same thing.
Create an account, log in here. You will receive points by participating in discussions.
Join this discussion.

Install Elektroda application

Didn't find an answer? Ask Artificial Intelligence

*I agree to send the question to OpenAI, Anthropic PBC, Perplexity AI, Inc., Kagi Inc., Google LLC - owners of language models in order to prepare the best response. The companies may monitor and log information entered into the form.

*I agree to publicly display my question and answer. The question and answer will be publicly available to everyone. The process may take a few minutes. Upon completion, you will be redirected to the page with the answer.

Wait...(2min)

Reply | New topic

Report a violation of the law

Topic summary

✨ The discussion revolves around the Xtreme Smart Wifi Window/Door Sensor model XHS7-2001-WHT, which utilizes the Tuya CBU module with a BK7231N chip. Users report successful flashing and configuration, but a significant issue arises with the sensor's delayed connection to WiFi/MQTT, which could allow a burglar to bypass the system. Suggestions include using the DoorSensor driver, implementing an autoexec.bat script to store initial channel values, and ensuring MQTT connection before deep sleep. Users also discuss the benefits of static IP settings and the potential for a quick connect feature to improve responsiveness. Testing of various configurations and pull requests (PRs) is ongoing to enhance performance and stability.

Home page
/
Forum
/
Smart Home
/
Smart Home IoT
/
Xtreme Smart Wifi WindowDoor Sensor - Model XHS7-2001-WHT - CBU Module

FAQ

TL;DR: Fast-connect can cut wake‑to‑MQTT to under 3 seconds; “So it gone from 12 seconds to under three.” Use PR 1297, optional static IP, and a short autoexec to wait for MQTT so door opens never get lost. For OpenBK users of XHS7‑2001‑WHT/BK7231N seeking faster, reliable alerts. [Elektroda, protectivedad, post #21381735]

Why it matters: Missed door opens undermine security; this guide gets your sensor reporting fast and reliably.

Quick Facts

Model XHS7‑2001‑WHT uses a Tuya CBU with BK7231N; flashing and auto‑config worked, DoorSensor no pull‑up wakes from deep sleep. [Elektroda, protectivedad, post #21380546]
Real‑world improvement: <3 s wake‑to‑MQTT after applying fast‑connect PR 1297 and testing with static IP. [Elektroda, protectivedad, post #21381735]
Default behavior can miss quick opens; an ~5 s join gap may resend only “closed.” [Elektroda, protectivedad, post #21380546]
Field runtime: door sensor on 2×1000 mAh Ni‑MH reported trouble‑free operation for 4 months. [Elektroda, insmod, post #21381078]
Recovery: OBK AP Safe Mode after failed boots; UART edits via BK7231GUIFlashTool if needed. [Elektroda, p.kaczmarek2, post #21381599]

How do I cut wake-to-MQTT below 3 seconds on this sensor?

Test a build with the fast‑connect changes (PR 1297) applied. Optionally assign a static IP to remove DHCP latency. One user reported going from 12 seconds to under three after these changes. Keep DoorSensor with sleep enabled. Validate with a dedicated test SSID before production. [Elektroda, protectivedad, post #21381735]

Can I avoid missed door events while Wi‑Fi is joining?

Use an autoexec to save the initial state and publish after MQTT connects. How‑To: 1. On wake, copy the door channel to a spare channel. 2. Run waitFor MQTTState 1. 3. Publish the saved value, then PinDeepSleep. This ensures the “open” blip is delivered reliably. [Elektroda, DeDaMrAz, post #21381870]

Should I enable fast connect via a flag or rely on the driver?

Set Flag 37 if you want explicit quick‑connect. However, assigning the pin as DoorSensor with sleep already enables quick‑connect logic. In testing, setting the flag was redundant on this model. [Elektroda, protectivedad, post #21382657]

Does setting a static IP actually speed things up?

It can. A tester saw wake‑to‑publish drop from about 12 seconds to under three with fast‑connect and a static IP. Later, DHCP also proved fast on the same setup. Use static IP if your DHCP adds delay. [Elektroda, protectivedad, post #21381735]

How can I keep the device awake until MQTT is online?

Use an autoexec loop with a countdown channel and waitFor MQTTState 1. Include DSEdge 0 to trigger on rising edges, and finish with PinDeepSleep. This pattern delivered reliable reporting and ≲5 s responses in earlier tests. [Elektroda, DeDaMrAz, post #21381870]

What if the fast-connect patch makes my BK7231N hang on boot?

This is an edge case seen on some N modules. If it happens, revert to a known‑good build and retest later. Validate on additional modules before broad deployment. [Elektroda, DeDaMrAz, post #21381070]

OTA won’t apply and Wi‑Fi won’t connect—what worked for others?

One fix sequence was: flash a prior custom build, then stock 1.18.12, then the PR‑1297 build. Use a test SSID during recovery. After this, Wi‑Fi connected quickly and OTA succeeded. [Elektroda, protectivedad, post #21381735]

How do I enter AP Safe Mode and reset Wi‑Fi without UART?

OBK enters AP Safe Mode after repeated failed boots. Adjust the “uptime seconds to mark boot OK” in Flags & General to tune this. From Safe Mode, convert to open access and re‑enter Wi‑Fi credentials. [Elektroda, p.kaczmarek2, post #21381599]

Can I change Wi‑Fi credentials over UART if the UI is unreachable?

Yes. Use BK7231GUIFlashTool to set SSID and password from UART. This lets you recover connectivity without a full device teardown. [Elektroda, p.kaczmarek2, post #21381599]

Is using a 64‑byte PSK faster than a passphrase here?

A build with PSK support made reconnection “quite snappy” for one tester. They continued long‑term testing afterward. PSK can reduce join time versus passphrases. [Elektroda, protectivedad, post #21382657]

Any PSK edge cases I should expect?

After enabling PSK, the device hung when changing SSIDs until settings were cleared. The user requested BSSID and PSK fields in the Wi‑Fi page, with 64‑char PSK detection. [Elektroda, protectivedad, post #21383155]

Will fast-connect and MQTT‑TLS be merged into OpenBK?

The maintainer is considering merging both. They asked for stability reports to decide the order. Community testing will accelerate merging. [Elektroda, p.kaczmarek2, post #21382888]

What pin mapping works for XHS7‑2001‑WHT on OpenBK?

Example mapping: P6 Btn; P7 WifiLED_n; P8 DoorSnsrWSleep_nPup; P23 BAT_ADC; P26 BAT_Relay. Include dsedge and Battery_Setup per your thresholds. [Elektroda, protectivedad, post #21381479]

How long must a door stay open to guarantee a report without tweaks?

About 5 seconds were needed before, causing quick open‑close cycles to be missed. The driver reports the state at connection, which can resend “closed.” Use the autoexec buffer to avoid this. [Elektroda, protectivedad, post #21380546]

Can this sensor run for months on batteries?

Yes. A door sensor with 2×1000 mAh Ni‑MH kept working for months. “i haven't had a problem with it for 4 months.” A solar‑assisted unit also ran well. [Elektroda, insmod, post #21381078]

What Wi‑Fi and MQTT stack did people use while testing?

WPA2 security with Mosquitto running on OpenWrt. The broker was addressed by IP. This setup underpinned the reported timings. [Elektroda, protectivedad, post #21380546]