Czujnik kupiony na tej aukcji (snapshot): 1. Connected by CH341A programmer. Shorting CEN to GND for a moment allows you to download and save the flash memory. 2. BK7231GUIFlashTool via mono on linux turned out to be useless and throws the same error every time as in many other forum threads: 3...

flash: OpenBK7231N_1.16.2.rbl Reed switch directly soldered to unused GPIO 8 (PWM 2) and GND. It correctly signals 1 and 0 with DoorSnsrWSleep and DoorSnsrWSleep_nPup. Identical situation - no waking up when it falls asleep with a short circuit, but it wakes up when it falls asleep with a gap and the magnet moves closer. EDIT: I found a solution by deduction - the same state must be used to wake up: new_pins.c // door input always uses opposite level for wakeup for (i = 0; i < PLATFORM_GPIO_MAX; i ) { if (g_cfg.pins.roles == IOR_DoorSensorWithDeepSleep || g_cfg.pins.roles == IOR_DoorSensorWithDeepSleep_NoPup || g_cfg.pins.roles == IOR_DigitalInput || g_cfg.pins.roles == IOR_DigitalInput_n || g_cfg.pins.roles == IOR_DigitalInput_NoPup || g_cfg.pins.roles == IOR_DigitalInput_NoPup_n) { //value = CHANNEL_Get(g_cfg.pins.channels ); value = HAL_PIN_ReadDigitalInput(i); //if (value) { // on falling edge wake up falling = 1; //

Hello, it seems that your device has a slightly different electronically implemented sensor than devices that I had reported as working with the controller. Maybe it's a matter of pull up or down resistors. Does the reed switch have such on the PCB? It's hard to say anything more remotely, but I have an idea - if the programmable pull up version and without resistors doesn't work for you, maybe the pull down version will work? I uploaded an update. Version 1.15.674. Select the _pd pin and try again:

The reed switch works, but there is no countdown to deep sleep at all. It also shows 0 drivers active instead of 1 driver active (DoorSensor) as before.

Ehh, sorry, that's how it is with remote help ... I forgot the condition for autostarting the DoorSensor driver in the case of setting the role of the pin with _pd. You either have to manually enter startDriver DoorSensor in the commands, at least for a test, once, or wait for the build that has now started (22:25) and download the new version in these 10 minutes, it has it fixed, version 1.15.675. Then test it and see if anything works better. If not, we'll think what else could be wrong... You can also physically check on the PCB what are the resistances between the reed switch GPIO and ground and 3.3V and give them to me. Added after 1 [minutes]: One more note, maybe a little helpful: if you set the GPIO of the button as Button, then pressing this button should wake up the sensor anyway. Check and let me know if it works. This is what helps to emergency wake up the device.

I had already set the wake-up to reset pin to make it easier, and before I saw the answer, I had already uploaded autoexec.bat to run DoorSensor. However, the result is the same, i.e. it does not wake up after entering sleep when the magnet is applied.The GPIO of the reed switch to Vcc has no transition, and strange things happen with GND, because with the sensor off (switch) but with batteries inserted, the meter in the 2000Ω mode shows me 1700Ω, with the 20k setting it shows 4.6kΩ, and in the 200k mode 25.8kΩ. No connection with batteries removed.

It's weird. I checked on my board with CB3S in the configuration shorting the GPIO to ground or power and it works for me: Test layout: I need to figure out how to reproduce your problem. But I have another idea - try using maybe this version:

It is still the same with this fw, i.e. it wakes up nicely when it falls asleep with the reed switch open, but sleep with the closed one is eternal. Apparently, falling asleep with a closed reed switch does more than falling asleep with an open one.I also checked the voltage on the reed switch pin with GND and it is 2.6V when closed, 0 when open (normally and during sleep). But when it goes to sleep, it jumps to 3.3V when closed and after opening, it maintains 3.3V all the time.EDIT: However, there is a difference in sleep in the open state, because before the diode was constantly on, and now it goes out and only applying a magnet wakes it up again.EDIT: Shorting the GPIO to ground wakes up the sensor dormant in the closed state. However, apparently opening the reed switch does not short GPIO with GND when the sensor was put to sleep in this state.EDIT: From what I see it is the same as this: only with me ver. 1.3 and not 1.4.

Indeed, it looks like you have exactly the same technical problem as @4139ggn . I'm not sure what else I can do at the moment, because basically we can only set the pin to input mode, either input_pullup or input_pulldown, there's nothing else to do here. You could also combine and dynamically set the mode to pullup or pulldown just before the start of sleep, depending on whether we read on pin 0 or 1, but it probably won't do anything. I had a similar door sensor but on XR809, and XR809 I desoldered for testing, maybe I can find its board and try to reproduce your problem on a physical device. when testing at home, I short-circuit directly to ground / VDD and therefore I am not able to reproduce your problem. I thought pullingdown with this might help, but apparently it didn't help anyway.... That's the _pd we tested. If you have a moment of time and, for example, you have a soldering iron and a resistor, e.g. 10k, you can do an experiment and check whether, for example, soldering 10k between the sensor's GPIO and ground will help wake up from closed mode ...

Now it wakes up in the closed state, but no longer wakes up in the open state, so the situation has simply reversed.I also checked the soldering of the reed switch directly to GPIO and Vcc and on standby the switching works, but after falling asleep it also cannot be woken up.EDIT: For the test, I soldered the switch directly to the free GPIO next to GND and set it to the usual DoorSnsrWSleep (then those don't work). It wakes up from sleep in the open position, and when it sleeps in the closed position it does not.

Do I understand correctly - the switch is between GND and GPIO, and the DoorSnsrWSleep role is set and it does not wake up anyway? Which firmware version - the test private one or the last one from the repository? The one from the repository, check it out.

Yes. That's what I did for the test on another GPIO and it wakes up only when it falls asleep on an open one, and not on a short one. Private trial version. I will check with the repo version, but I won't be able to do it until Sunday or Monday. I'll let you know, because if the reed switch works directly connected to the GPIO and GND, it's probably easier to use such a small modification of the system than to combine what's going on there that it doesn't want to work in the original setting. Btw. is there any option to reduce the standby time and/or the time from waking up to sending payload via mqtt?

Using CH341A Programmer for BK7231N/CB3S Door/Window Sensor PB-69W VER 1.3: UART & OpenBK7231N_QIO

nihildiximus 5958 40

Best answers

Why does my BK7231N/CB3S door sensor only wake from deep sleep when it was asleep with the reed open, and how do I make wake-up work in the closed state too?

Set the wake-up edge to match the sensor’s idle level before sleep: the working fix was `DSEdge 1` for the low-level wake-up case, and another user later confirmed that this solved the same problem for them [#20542881][#20826289] For the original reed-switch wiring, the working combination was `DoorSnsrWSleep_nPup` with a forced edge of `0`; for a direct GPIO-to-GND test setup, `DoorSnsrWSleep` with a forced edge of `1` was needed [#20542881] The issue was that the sensor must wake on the same state it will be in after deep sleep, otherwise opening/closing the reed does not generate the expected wake event [#20542881] If you need to set multiple startup commands, use Tasmota-style `backlog ...; ...;` syntax rather than separating commands with plain semicolons [#20543214]

Treść została przetłumaczona

Zobacz oryginalną wersję tematu

Report a violation of the law

Reply | New topic

#1 20534749 11 Apr 2023 16:33

nihildiximus nihildiximus

Level 9

» | Topic author

Post #1
20534749 11 Apr 2023 16:33

Czujnik kupiony na tej aukcji (snapshot): https://allegro.pl/oferta/autonomiczny-czujni...jYmZhMmNmYjk2YTE4NjY3ZWQzOWQ5NDlhYTZmOTgyNTk=

1. Connected by CH341A programmer. Shorting CEN to GND for a moment allows you to download and save the flash memory.
2. BK7231GUIFlashTool via mono on linux turned out to be useless and throws the same error every time as in many other forum threads:

Quote:
Going to start reading at offset 0x00...
Reading 0x00... failed with serial.BytesToRead 4095 (expected 4111)
The beginning of buffer in UART contains 040EFF01E0FCF4061009000000200069 data.
failed! There was no result to save.

3. uartprogram with hid_download_py it works without any problem.
4. Loaded OpenBK7231N_QIO_1.15.668.bin
5. Leads as in the picture below.

pin 5 = GPIOP_26 PWM5 - (Btn 1 0) battery case button
pin 10 = GPIOP_9 = PWM 3 = (LED 0) diode-
pin 14 = GPIPP_7 = PWN_1 = (DoorSensorWSleep_nPup 0 [regular DoorSensWSleep doesn't work at all]) reed switch

6. The LED lights up after the reed switch is opened, and goes out after the short circuit and the information goes through the MQTT to HomeAssistant. Time until deep sleep is also extended correctly. However, wake-up only works when the sensor has entered deep sleep in the open reed (off) position. When the magnet shorts it (on) and in this state it is put to sleep, there is no possibility of waking up and a reset by turning the power off and on again is necessary.

ADVERTISEMENT
#2 20535312 11 Apr 2023 21:29

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

» | Helpful post? (0)

Post #2
20535312 11 Apr 2023 21:29

Hello, it seems that your device has a slightly different electronically implemented sensor than devices that I had reported as working with the controller. Maybe it's a matter of pull up or down resistors. Does the reed switch have such on the PCB?

It's hard to say anything more remotely, but I have an idea - if the programmable pull up version and without resistors doesn't work for you, maybe the pull down version will work?

I uploaded an update. Version 1.15.674. Select the _pd pin and try again:

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 20535429 11 Apr 2023 22:23

nihildiximus nihildiximus

Level 9

» | Topic author Helpful post? (0)

Post #3
20535429 11 Apr 2023 22:23

p.kaczmarek2 wrote:
I uploaded an update. Version 1.15.674. Select the _pd pin and try again:

The reed switch works, but there is no countdown to deep sleep at all. It also shows 0 drivers active instead of 1 driver active (DoorSensor) as before.
#4 20535432 11 Apr 2023 22:29

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

» | Helpful post? (0)

Post #4
20535432 11 Apr 2023 22:29

Ehh, sorry, that's how it is with remote help ... I forgot the condition for autostarting the DoorSensor driver in the case of setting the role of the pin with _pd.
You either have to manually enter "startDriver DoorSensor" in the commands, at least for a test, once, or wait for the build that has now started (22:25) and download the new version in these 10 minutes, it has it fixed, version 1.15.675.

Then test it and see if anything works better. If not, we'll think what else could be wrong...

You can also physically check on the PCB what are the resistances between the reed switch GPIO and ground and 3.3V and give them to me.

Added after 1 [minutes]:

One more note, maybe a little helpful:

nihildiximus wrote:
there is no possibility to wake up and a reset by turning the power off and on again is necessary.[/b]

if you set the GPIO of the button as Button, then pressing this button should wake up the sensor anyway. Check and let me know if it works. This is what helps to "emergency" wake up the device.

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
#5 20535478 11 Apr 2023 22:51

nihildiximus nihildiximus

Level 9

» | Topic author Helpful post? (0)

Post #5
20535478 11 Apr 2023 22:51

I had already set the wake-up to reset pin to make it easier, and before I saw the answer, I had already uploaded autoexec.bat to run DoorSensor. However, the result is the same, i.e. it does not wake up after entering sleep when the magnet is applied.
The GPIO of the reed switch to Vcc has no transition, and strange things happen with GND, because with the sensor off (switch) but with batteries inserted, the meter in the 2000Ω mode shows me 1700Ω, with the 20k setting it shows 4.6kΩ, and in the 200k mode 25.8kΩ. No connection with batteries removed.
#6 20535553 11 Apr 2023 23:57

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home
» | Helpful post? (0)

Post #6
20535553 11 Apr 2023 23:57

It's weird. I checked on my board with CB3S in the configuration shorting the GPIO to ground or power and it works for me:

Test layout:

I need to figure out how to reproduce your problem.

But I have another idea - try using maybe this version:

Attachments:

test-czujnika-drzwi20230411.zip (611.76 KB) You must be logged in to download this attachment.

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.
#7 20535562 12 Apr 2023 00:14

nihildiximus nihildiximus

Level 9

» | Topic author Helpful post? (0)

Post #7
20535562 12 Apr 2023 00:14

It is still the same with this fw, i.e. it wakes up nicely when it falls asleep with the reed switch open, but sleep with the closed one is eternal. Apparently, falling asleep with a closed reed switch does more than falling asleep with an open one.

I also checked the voltage on the reed switch pin with GND and it is 2.6V when closed, 0 when open (normally and during sleep). But when it goes to sleep, it jumps to 3.3V when closed and after opening, it maintains 3.3V all the time.

EDIT: However, there is a difference in sleep in the open state, because before the diode was constantly on, and now it goes out and only applying a magnet wakes it up again.

EDIT: Shorting the GPIO to ground wakes up the sensor dormant in the closed state. However, apparently opening the reed switch does not short GPIO with GND when the sensor was put to sleep in this state.

EDIT: From what I see it is the same as this: https://www.elektroda.pl/rtvforum/topic3959677.html#20453815 only with me ver. 1.3 and not 1.4.
#8 20535617 12 Apr 2023 02:10

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

» | Helpful post? (0)

Post #8
20535617 12 Apr 2023 02:10

Indeed, it looks like you have exactly the same technical problem as @4139ggn . I'm not sure what else I can do at the moment, because basically we can only set the pin to input mode, either input_pullup or input_pulldown, there's nothing else to do here. You could also combine and dynamically set the mode to pullup or pulldown just before the start of sleep, depending on whether we read on pin 0 or 1, but it probably won't do anything.

I had a similar door sensor but on XR809, and XR809 I desoldered for testing, maybe I can find its board and try to reproduce your problem on a physical device.

Quote:

EDIT: Shorting the GPIO to ground wakes up the sensor dormant in the closed state. However, apparently opening the reed switch does not short GPIO with GND when the sensor was put to sleep in this state.

when testing at home, I short-circuit directly to ground / VDD and therefore I am not able to reproduce your problem. I thought pullingdown with this might help, but apparently it didn't help anyway.... That's the _pd we tested.

If you have a moment of time and, for example, you have a soldering iron and a resistor, e.g. 10k, you can do an experiment and check whether, for example, soldering 10k between the sensor's GPIO and ground will help wake up from closed mode ...

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.
#9 20535826 12 Apr 2023 09:59

nihildiximus nihildiximus

Level 9

» | Topic author Helpful post? (0)

Post #9
20535826 12 Apr 2023 09:59

Now it wakes up in the closed state, but no longer wakes up in the open state, so the situation has simply reversed.
I also checked the soldering of the reed switch directly to GPIO and Vcc and on standby the switching works, but after falling asleep it also cannot be woken up.

EDIT: For the test, I soldered the switch directly to the free GPIO next to GND and set it to the usual DoorSnsrWSleep (then those don't work). It wakes up from sleep in the open position, and when it sleeps in the closed position it does not.
#10 20536852 12 Apr 2023 21:37

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

» | Helpful post? (0)

Post #10
20536852 12 Apr 2023 21:37

nihildiximus wrote:

EDIT: For the test, I soldered the switch directly to the free GPIO next to and GND and set it to the usual DoorSnsrWSleep (then those don't work). It wakes up from sleep in the open position, and when it sleeps in the closed position it does not.

Do I understand correctly - the switch is between GND and GPIO, and the DoorSnsrWSleep role is set and it does not wake up anyway?
Which firmware version - the test private one or the last one from the repository?
The one from the repository, check it out.

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.
#11 20536934 12 Apr 2023 22:24

nihildiximus nihildiximus

Level 9

» | Topic author Helpful post? (0)

Post #11
20536934 12 Apr 2023 22:24

p.kaczmarek2 wrote:
Do I understand correctly - the switch is between GND and GPIO, and the DoorSnsrWSleep role is set and it does not wake up anyway?

Yes. That's what I did for the test on another GPIO and it wakes up only when it falls asleep on an open one, and not on a short one.

p.kaczmarek2 wrote:
Which firmware version - the test private one or the last one from the repository?
The one from the repository, check it out.

Private trial version. I will check with the repo version, but I won't be able to do it until Sunday or Monday. I'll let you know, because if the reed switch works directly connected to the GPIO and GND, it's probably easier to use such a small modification of the system than to combine what's going on there that it doesn't want to work in the original setting. Btw. is there any option to reduce the standby time and/or the time from waking up to sending payload via mqtt?
ADVERTISEMENT
#12 20536977 12 Apr 2023 22:45

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

» | Helpful post? (0)

Post #12
20536977 12 Apr 2023 22:45

The private trial version is not authoritative, I just wanted to check something.

Tomorrow I will check what you write on my dev board, I am convinced that it should work, because in this topic:
https://www.elektroda.pl/rtvforum/topic3960149.html
it was working and not moving. In addition, users of smoke detectors made in a similar way reported that they had approx.

nihildiximus wrote:
Btw. is there any option to reduce the standby time and/or the time from waking up to sending payload via mqtt?

There is a "quick wifi connect" flag or something, which will then be permanently enabled, we just had some strange instabilities a year ago when we turned on WiFi too early and therefore it is a flag to be selected (and not enabled by default).

I'm going to change the standby time so that after the response from MQTT that it received the status, the sensor immediately fell asleep again, but I have to check if there is such an option in the MQTT library used (with LWIP)

But if you want to artificially shorten the timing time for now, it's no problem for me to give this time to the autoexec.bat command.

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
Helpful post

#13 20542631 16 Apr 2023 17:32

nihildiximus nihildiximus

Level 9

» | Topic author Helpful post? (+1)

Helpful post
Post #13
20542631 16 Apr 2023 17:32

flash: OpenBK7231N_1.16.2.rbl
Reed switch directly soldered to unused GPIO 8 (PWM 2) and GND.
It correctly signals 1 and 0 with DoorSnsrWSleep and DoorSnsrWSleep_nPup.
Identical situation - no waking up when it falls asleep with a short circuit, but it wakes up when it falls asleep with a gap and the magnet moves closer.

EDIT:
I found a solution by deduction - the same state must be used to wake up:

new_pins.c
[syntax=c]
// door input always uses opposite level for wakeup
for (i = 0; i < PLATFORM_GPIO_MAX; i ) {
if (g_cfg.pins.roles[i] == IOR_DoorSensorWithDeepSleep
|| g_cfg.pins.roles[i] == IOR_DoorSensorWithDeepSleep_NoPup
|| g_cfg.pins.roles[i] == IOR_DigitalInput
|| g_cfg.pins.roles[i] == IOR_DigitalInput_n
|| g_cfg.pins.roles[i] == IOR_DigitalInput_NoPup
|| g_cfg.pins.roles[i] == IOR_DigitalInput_NoPup_n) {
//value = CHANNEL_Get(g_cfg.pins.channels[i]);
value = HAL_PIN_ReadDigitalInput(i);
//if (value) {
// on falling edge wake up
falling = 1; //
#14 20542751 16 Apr 2023 18:45

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

» | Helpful post? (0)

Post #14
20542751 16 Apr 2023 18:45

Are you sure? If it actually works then good job, I wouldn't have thought of that myself. The above code always sets the wake-up on a falling edge on a given GPIO, so theoretically if the sensor is 0 in the sleep state and 1 appears when the door is opened, then we will have a rising edge and the sensor will not wake up.

What's most interesting, I'm currently testing with a user who has a door sensor based on a different type of sensor (Hall sensor) and the current solution works for him:

In your version, I would have to add 3 separate DoorSensor roles - because with pull up, pull down, and without.

Maybe it's better to add a flag for that? In Config->Flags?

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.
#15 20542881 16 Apr 2023 20:02

nihildiximus nihildiximus

Level 9

» | Topic author Helpful post? (0)

Post #15
20542881 16 Apr 2023 20:02

The situation is that the solution works if you use the direct connection of the switch to a free GPIO and GND. However, with the original setting of the reed switch, no. FW without modification, in turn, does not work either with the original setting or with direct plugging of the reed switch in GPIO and GND. I will test further, because it would be good to run it with the original connection ... Anyway, it's worth adding a flag that would set the same state for waking up regardless of the state of falling asleep, because it may be useful. ;)

EDIT:

SOLVED!
1. For free GPIO GND you need DoorSnsrWSleep and falling =1 hard for both states.
2. For original connections you need DoorSnsrWSleep_nPup and hard falling = 0 for both states.

I think it's best to just add two flags in config with the setting of rigidly falling to zero or one, so as not to multiply the number of entries from DoorSnsr and in new_pins.c a conditional instruction that will check if any is selected and if so, then set it rigidly, omitting setting opposite level.

I guess something like this would suffice:

Code: C / C++
Log in, to see the code

EDIT:
It would also be good to replace the constant setting_timeRequiredUntilDeepSleep = 60 in driver/drv_doorSensorWithSeepSleep.c with a variable that could be set in autoexec, because a minute is good as a default value for testing, but after configuring the device, a shorter time is enough, which can be changed without need to upload new fw.
#16 20543157 16 Apr 2023 22:08

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

» | Helpful post? (0)

Post #16
20543157 16 Apr 2023 22:08

I added the flag before you edited your post. The build should be ready. Only the flag sets falling = 1 hard. It doesn't support the second situation you wrote about. Ew. I'll give you a second flag...

Either I clear the flag and give defaultDoorSensorEdge = 2 or 0 or 1

nihildiximus wrote:

1. For free GPIO + GND you need DoorSnsrWSleep and falling =1 hard for both states.

I have this configuration for buttons (more precisely: Button role, it sets pull up and always has falling = 1), but this is assuming that the button is open by default and the user shorts it only for a moment with ground. This is different from a switch that has two states of stability - either open or closed.

nihildiximus wrote:

It would also be good to replace the constant setting_timeRequiredUntilDeepSleep = 60 in driver/drv_doorSensorWithSeepSleep.c to use a variable that could be set in autoexec, because a minute is good as a default value for testing, but after configuring the device, a shorter time is enough, which can be changed without need to upload new fw.

This question has already appeared, I can put it in a variable for now, but ultimately the plan is to check the MQTT response to publish and then turn off.

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.
#17 20543190 16 Apr 2023 22:32

nihildiximus nihildiximus

Level 9

» | Topic author Helpful post? (0)

Post #17
20543190 16 Apr 2023 22:32

p.kaczmarek2 wrote:
Either I clear the flag and give defaultDoorSensorEdge = -1 or 0 or 1

All in all, it's probably best to set such things by autoexec, because it will be for exceptional situations anyway. But as for the time to fall asleep, I think it's better to leave the default 60 seconds to avoid problems during configuration, leaving the variable in autoexec, where you can either specify the time, or give e.g. 0 which will only wait for MQTT when everything is checked. But that's just my suggestion.
#18 20543206 16 Apr 2023 22:38

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

» | Helpful post? (0)

Post #18
20543206 16 Apr 2023 22:38

I'll convert the flag to command tomorrow.

As for 60 seconds, it seems to me that it is very easy to program the DoorSensor controller so that pressing the button on the housing (the one for pairing - always present) turns on the configuration mode, where the sensor falls asleep, e.g. after 120 seconds. Without this press, he would fall asleep as soon as possible.

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.
#19 20543212 16 Apr 2023 22:44

nihildiximus nihildiximus

Level 9

» | Topic author Helpful post? (0)

Post #19
20543212 16 Apr 2023 22:44

Setting the button is a simple matter, but I'm wondering if someone first sets up mqtt and a reed switch, then they won't lose the ability to enter the configuration in a moment and there won't be a multitude of threads on the forum asking what to do in such a situation.
#20 20543214 17 Apr 2023 09:20

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

» | Helpful post? (0)

Post #20
20543214 17 Apr 2023 09:20

There is always a safe mode - five quick power on and off. You'd need a battery here.

Added after 10 [hours] 35 [minutes]:

Added commands:
https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/commands.md
DSEdge
DSTime

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.
#21 20546015 18 Apr 2023 20:52

nihildiximus nihildiximus

Level 9

» | Topic author Helpful post? (0)

Post #21
20546015 18 Apr 2023 20:52

DSTime does not work in startup command when I type: DSEdge 0; DSTime 15;
When run as a single command on a regular basis it pops up, but after waking up it's 60 seconds again.

But there is also a critical problem that practically prevents the sensor from working properly…

Wifi connection after waking up is very slow and it wouldn't be a critical problem (although it's still a big difference with the original fw, because it's a good half a minute and the quick connect flag doesn't change anything, and with the original maybe a second or two) if it wasn't for that when it happens, it will does not send mqtt with information about the state change that occurred before it was established. In other words, the usual opening and closing time of the door behind each other is 2 to max. 5 seconds (longer only if something is brought into the house). The thief will do it even faster. The sensor wakes up as it should with the DSEdge option, but apparently fw only checks the status when connected, instead of doing it immediately and storing the event queue until wifi is connected to send it (here it is necessary to payload with the state and timestamp, not the state itself to have a full chronology of events). Practically in the current situation no simple door opening and closing behind you is recorded at all in the event log and thus the sensor unfortunately becomes completely useless ...
#22 20546042 18 Apr 2023 21:04

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

» | Helpful post? (0)

Post #22
20546042 18 Apr 2023 21:04

DSEdge and DSTime had one issue due to copy/paste, it was fixed today as the contributor tested it about 15, latest versions should have it working.

In what format do you want to have a report with time to HA? Does HA even have the ability to accept a report over time?

Sending the 'first' state is easy to do, but I don't know about the timestamp at the moment.

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.
#23 20546080 18 Apr 2023 21:21

nihildiximus nihildiximus

Level 9

» | Topic author Helpful post? (0)

Post #23
20546080 18 Apr 2023 21:21

I checked DSTime in OpenBK7231N_1.17.8.rbl downloaded maybe an hour ago.

And as for mqtt, I really do not see that it is possible to enter the time of occurrence of a specific state into HA, but you can probably do a workaround in the form of:

- queuing states when the connection has not been established and sending them in turn after connection;
- creating two new mqtt endpoints - in addition to doors/0/get, you can also add doors/0/laston and doors/0/lastoff with a timestamp (separate entities), then even if the connection to wifi is delayed, it will be saved in the logs exact opening and closing times.

EDIT:
Isn't it so that the original fw does not disconnect from wifi when entering deepsleep? I guess after waking up it doesn't connect again and doesn't download the dhcp address again and maybe that's why it works faster. Can something like this be implemented?

Helpful post

#24 20546210 18 Apr 2023 22:54

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Helpful post

Post #24

20546210 18 Apr 2023 22:54

I just added a quick fix for the issue raised in the post: >>20546015 . At the moment, the soft after reboot remembers the pin state, and DoorSensor sends it via MQTT for the first two seconds (by force) and then sends the current state.

This solution will ensure that at least one second of door opening (or closing) will be recorded in the logs, only the actual door opening time will be distorted due to the lack of timestamps. Anyway, the trace after closing the door will be, tested now:

Deep Sleep is a complete shutdown of almost everything in the CPU, so even if it didn't "disconnect" it would be dropped by DHCP after the lease expired anyway, so I don't think it would be like that...

However, today with the contributor we added two small improvements, namely MQTT should connect faster (improvement of the connection logic) and we added the option static IP which also speeds up.

How fast are you connecting to MQTT? 7 seconds for me:


Info:MAIN:Main_Init_Before_Delay
Info:CFG:####### Boot Count 67 #######
Warn:CFG:CFG_InitAndLoad: Correct config has been loaded with 22 changes count.
Error:CMD:lfs is absent
Info:MAIN:Started DoorSensor.
Info:GEN:PIN_SetupPins pins have been set up.
Info:MAIN:Main_Init_Before_Delay done
Info:MAIN:Main_Init_Delay
Info:GEN:CHANNEL_Set channel 0 has changed to 1 (flags 0)

Info:MQTT:Channel has changed! Publishing 1 to channel 0 
Info:MAIN:Main_Init_Delay done
Info:MAIN:Main_Init_After_Delay
Info:MAIN:ssid:qqqqqqqqqqqqq
Info:MAIN:Using SSID [qqqqqqqqqqqq]
Info:MAIN:Using Pass [qqqqqqqqqqqqqq]
Info:MQTT:MQTT_RegisterCallback called for bT obkDoorN/ subT obkDoorN/+/set
Info:MQTT:MQTT_RegisterCallback called for bT cmnd/obkDoorN/ subT cmnd/obkDoorN/+
Info:MQTT:MQTT_RegisterCallback called for bT obkDoorN/ subT obkDoorN/+/get
Info:HTTP:DRV_SSDP_Init - no wifi, so await connection
Info:MAIN:Started SSDP.
Info:NTP:NTP driver initialized with server=217.147.223.78, offset=0
Info:MAIN:Started NTP.
Error:CMD:LFS_ReadFile: lfs is absent
Info:CMD:CMD_StartScript: failed to get file autoexec.bat
Info:MAIN:Main_Init_After_Delay done
Info:MAIN:Time 1, idle 280330/s, free 73856, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38 
Info:MAIN:Time 2, idle 185265/s, free 73856, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38 
Info:MAIN:Time 3, idle 68683/s, free 73960, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38 
Info:MAIN:Time 4, idle 0/s, free 73960, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38 
Info:MAIN:Time 5, idle 0/s, free 73960, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38 
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_CONNECTING - 1
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_CONNECTED - 4
Info:MQTT:mqtt_userName homeassistant
mqtt_pass ma1oovoo0pooTie7koa8Eiwae9vohth1vool8ekaej8Voohi7beif5uMuph9Diex
mqtt_clientID obkDoorN
mqtt_host 192.168.0.113:1883
Info:MAIN:Time 6, idle 107681/s, free 74208, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:MAIN:Boot complete time reached (5 seconds)
Info:CFG:####### Set Boot Complete #######
Info:MQTT:mqtt_connection_cb: Successfully connected
Info:MQTT:mqtt_subscribed to obkDoorN/+/set
Info:MQTT:mqtt_subscribed to cmnd/obkDoorN/+
Info:MQTT:mqtt_subscribed to obkDoorN/+/get
Info:MQTT:Publishing val 0 to obkDoorN/0/get retain=0
Info:MAIN:Time 7, idle 176455/s, free 62544, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 3/38 
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic obkDoorN/0/get

The testers are more or less the same:

Added after 10 [minutes]:

What you wrote with timestamps separately is also a nice idea, I can add it soon, but not today. We already have NTP, just start the NTP driver and then when it's time from the network, subtract how much has elapsed since the first measurement and send it.

Added after 3 [minutes]:

EDIT: I think I need to check the download of the door state directly after the reboot. Anyway, I'll look into it in the morning.

Added after 4 [minutes]:

EDIT2: ah, I already know, I'm throwing the fix yet.

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.

#25 20546258 18 Apr 2023 23:04

nihildiximus nihildiximus

Level 9

» | Topic author Helpful post? (0)

Post #25
20546258 18 Apr 2023 23:04

With the new fw, the symptoms are:

- Setting "DSEdge 0; DSTime 15;" in "Set/Change/Clear startup command line" doesn't change anything. Still 60 sec. countdown.

- After setting a fixed IP, the time was significantly shortened - in HA, the open state appears within 6 seconds and the closed state within 9 seconds (it's strange that both states do not pop up at once, one after the other). It's a bit slower than with the original fw (I checked again and it's 1-2 sec. state change in HA via localTuya), but acceptable, although I don't understand where this 3 sec. delay when sending the second state (I test by doing a quick disconnect and reconnection).

EDIT:
As for DSTime, the problem is only with the setting from the config level (maybe it ignores the second cmd?), because in autoexec.bat it works without a problem.
#26 20546271 18 Apr 2023 23:17

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

» | Helpful post? (0)

Post #26
20546271 18 Apr 2023 23:17

We have Tasmota syntax, I haven't added automatic semicolon separation yet, you have to write backlog cmdA xyz; cmdB abc; etc , in fact, there is even a "use backlog" comment on this page.

These 3 seconds between sending the first remembered state and the current state are in my driver, it's not a problem. I don't know how HA would react if he received a packet with the value open and then closed at the same time...

For the rest, in the Web App Log, how long does it take you to connect to WiFi and how long to connect to MQTT? This message obk Time 1, etc etc has further MQTT (1) and WiFi (1) (or 0) tags and can be determined after that.

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.
#27 20546280 18 Apr 2023 23:26

nihildiximus nihildiximus

Level 9
» | Topic author Helpful post? (0)

Post #27
20546280 18 Apr 2023 23:26

It seems to me that between sending mqtt a delay, max. 1 sec. because it's just about keeping the order of the messages. This would probably be the last fix and I can start making a full tutorial for this sensor. :)

EDIT:

Code: text Expand Select all Copy to clipboard
mqtt_host 192.168.100.200:1883 Info:MAIN:Time 6, idle 109507/s, free 73672, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 2/38 Info:MAIN:Boot complete time reached (5 seconds) Info:CFG:####### Set Boot Complete #######

EDIT2:
After a long sleep, the time increases significantly for some reason:

Code: text Expand Select all Copy to clipboard
mqtt_host 192.168.100.200:1883 Info:MAIN:Time 19, idle 176735/s, free 73568, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 2/38 Info:MQTT:mqtt_connection_cb: Successfully connected
#28 20546308 19 Apr 2023 00:03

DeDaMrAz DeDaMrAz

Level 22
Helpful post? (0)

Post #28
20546308 19 Apr 2023 00:03

Here is what I got by testing build 1.17.10 and this autoexec.bat

Code: text Expand Select all Copy to clipboard
Battery_Setup 2000 3000 1.885 2400 4096 Battery_cycle 2 mqtt_broadcastInterval 1 mqtt_broadcastItemsPerSec 3 addEventHandler OnHold 20 SafeMode 5 DSTime 5

Both states are published on mqtt connect, previous and new - this is in an event that sensor activation is done quickly (less than 1s between state changes) and before mqtt connect, so there is a log in HA.

If you like my work, support me at: https://paypal.me/openshwprojects
#29 20546462 19 Apr 2023 08:11

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home
Helpful post? (0)

Post #29
20546462 19 Apr 2023 08:11

@DeDaMrAz , if you change
Code: text Expand Select all Copy to clipboard
addEventHandler OnHold 20 SafeMode 5

to:
Code: text Expand Select all Copy to clipboard
addEventHandler OnHold 20 backlog DSTime 6000; SafeMode 5

you will get a bit more fool-proof safe mode, because otherwise device can go to sleep before safe mode will reboot.

You can also consider:
Code: text Expand Select all Copy to clipboard
addEventHandler OnHold 20 DSTime 600

this would just give more time on button hold... maybe it's even better... hm.

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.
#30 20546730 19 Apr 2023 11:24

Adi13089 Adi13089

Level 11

» | Helpful post? (0)

Post #30
20546730 19 Apr 2023 11:24

Will there be any config for setting a fixed IP address on the device?
For some reason the DHCP server doesn't want to assign me an address for the device.
Create an account, log in here. You will receive points by participating in discussions.
Join this discussion.

Install Elektroda application

Reply | New topic

Report a violation of the law

Topic summary

✨ The discussion revolves around using the CH341A programmer to interface with the BK7231N/CB3S door/window sensor (PB-69W VER 1.3) and the OpenBK7231N_QIO firmware. Users report issues with the sensor not waking up from deep sleep when the reed switch is closed, despite various firmware updates and configurations. Solutions proposed include adjusting GPIO settings, using different firmware versions, and implementing specific commands like "DSEdge" to manage wake-up behavior. The conversation highlights the importance of correctly configuring pull-up and pull-down resistors and the need for firmware modifications to ensure proper functionality. Users also discuss the challenges of MQTT connectivity and the timing of state changes after waking from sleep.

FAQ

TL;DR: Users cut MQTT round-trip from 60 s to 6 s by flashing OpenBeken 1.17.10 and issuing “DSEdge 1; DSTime 15” [Elektroda, nihildiximus, post #20546258] “Set the correct wake edge and everything works” —-p.kaczmarek2 [Elektroda, 20543157]

Why it matters: Correct edge, timing and IP settings turn a useless door sensor into a reliable, battery-friendly alarm node.

Quick Facts

• Default deep-sleep delay: 60 s; adjustable 1-600 s via DSTime [Elektroda, p.kaczmarek2, post #20543157] • Wake-to-MQTT time: 6 s static IP vs 9 s DHCP [Elektroda, nihildiximus, post #20546258] • Edge command values: 0 = rising, 1 = falling (forced), 2 = auto [Elektroda, p.kaczmarek2, post #20543214] • Safe-mode entry: 5 rapid power cycles or 20 s button hold [Elektroda, p.kaczmarek2, post #20546462] • RF-partition loss shows MAC ending in 00; fix via “Restore RF partition” in WebApp or UART tool [Elektroda, p.kaczmarek2, post #20546804]

What hardware and software do I need to read or flash the PB-69W (BK7231N/CB3S) sensor?

Use a CH341A USB programmer. Short CEN to GND momentarily, then read or write flash with uartprogram + hid_download_py; BK7231GUIFlashTool under mono errors out [Elektroda, nihildiximus, post #20534749]

Why does BK7231GUIFlashTool under Linux fail with “serial.BytesToRead 4095” and how do I bypass it?

The mono build mismanages UART buffers on Linux. Swap to uartprogram and hid_download_py; they read the entire 2 MB flash without the buffer overflow [Elektroda, nihildiximus, post #20534749]

Which GPIO pins control the button, LED and reed switch on PB-69W v1.3?

• GPIO 26 → housing button (Btn1). • GPIO 9 → blue LED. • GPIO 7 → reed switch input [Elektroda, nihildiximus, post #20534749]

The sensor only wakes if it slept with the reed open. How do I fix that?

Flash ≥1.17.10, then issue DSEdge 1 to force falling-edge wake or DSEdge 0 for rising. Add DSTime to shorten standby. Problem disappears after setting the correct edge [Elektroda, Jerome_H, post #20826289]

What exactly do DSEdge and DSTime do?

DSEdge selects which edge (0 rising, 1 falling, 2 auto) triggers wake from deep sleep. DSTime sets how many seconds the MCU stays awake before re-entering deep sleep (1-600 s) [Elektroda, p.kaczmarek2, post #20543214]

Why does my startup line “DSEdge 0; DSTime 15;” not change DSTime?

The console requires Tasmota-style backlog. Write “backlog DSEdge 0; DSTime 15;” or place commands in autoexec.bat; otherwise only the first instruction runs [Elektroda, p.kaczmarek2, post #20546271]

How can I cut wake-to-MQTT latency?

Assign a static IP in Configure IP. Users report 6 s MQTT publishing with static IP versus 9 s via DHCP—33 % faster [Elektroda, nihildiximus, post #20546258] Enable Quick WiFi Connect flag for another small gain [Elektroda, p.kaczmarek2, post #20536977]

Flashing erased my MAC and the device stays in safe mode. What now?

You overwrote the RF partition. Open WebApp → Flash Memory → Restore RF partition, or run “Restore RF” in BK7231GUIFlashTool over UART. A new random MAC restores Wi-Fi and DHCP [Elektroda, p.kaczmarek2, post #20546804]

How do I enter safe mode if the web UI is unreachable?

Remove power.
Apply power five times quickly (<8 s total).
Device boots in safe mode AP, SSID ends with “_SAFE” [Elektroda, p.kaczmarek2, post #20543214]

Can I restore functionality without rewiring the reed switch?

Yes. Keep original wiring, set role DoorSnsrWSleep_nPup and DSEdge 0. This wakes on both closed-sleep and open-sleep states [Elektroda, nihildiximus, post #20542881]

What firmware version should I use and how do I upgrade OTA?

Use ≥1.17.10.rbl for full DSEdge/DSTime/UI features. WebApp → OTA → “Select remote OTA file”, choose the newest .rbl, then drag-drop onto “Drop OTA here” [Elektroda, nihildiximus, post #20546801]

How do I configure battery reporting?

Add to autoexec.bat:

Battery_Setup 2000 3000 1.885 2400 4096
Battery_cycle 2 These lines calibrate 2.0–3.0 V cells and push MQTT every two cycles [Elektroda, DeDaMrAz, post #20546308]

Is there a quick 3-step setup for a fresh sensor?

Flash OpenBeken 1.17.10 via CH341A.
In WebApp: assign static IP, map pins (26 Button, 9 LED, 7 DoorSnsrWSleep), backlog DSEdge 1; DSTime 15.
Reboot; pair Wi-Fi; add MQTT credentials. Sensor now wakes and reports in ~6 s [Elektroda, compiled].

What edge-case still breaks wake-up?

If DSTime is set too low, the sensor may re-enter sleep before Wi-Fi handshake, dropping the MQTT message. Keep DSTime ≥5 s unless static IP and strong signal are confirmed [Elektroda, p.kaczmarek2, post #20546462]