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

Question

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

nihildiximus · Accepted Answer

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; //

p.kaczmarek2 · Accepted Answer

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.

p.kaczmarek2 · Answer

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:

nihildiximus · Answer

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.

p.kaczmarek2 · Answer

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.

nihildiximus · Answer

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.

p.kaczmarek2 · Answer

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:

nihildiximus · Answer

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.

p.kaczmarek2 · Answer

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.

nihildiximus · Answer

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.

p.kaczmarek2 · Answer

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.

nihildiximus · Answer

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?

p.kaczmarek2 · Answer

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.

p.kaczmarek2 · Answer

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.

nihildiximus · Answer

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:

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.

p.kaczmarek2 · Answer

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

nihildiximus · Answer

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.

p.kaczmarek2 · Answer

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.

nihildiximus · Answer

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.

p.kaczmarek2 · Answer

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: DSEdge DSTime

nihildiximus · Answer

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

p.kaczmarek2 · Answer

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.

nihildiximus · Answer

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?

nihildiximus · Answer

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.

p.kaczmarek2 · Answer

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.

nihildiximus · Answer

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:


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:


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

DeDaMrAz · Answer

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

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.

p.kaczmarek2 · Answer

@DeDaMrAz , if you change


addEventHandler OnHold 20 SafeMode 5

to:


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:


addEventHandler OnHold 20 DSTime 600

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

Adi13089 · Answer

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.

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

Post #1

Post #2

Post #3

Post #4

Post #5

Post #6

Post #7

Post #8

Post #9

Post #10

Post #11

Post #12

Post #13

Post #14

Post #15

Post #16

Post #17

Post #18

Post #19

Post #20

Post #21

Post #22

Post #23

Post #24

Post #25

Post #26

Post #27

Post #28

Post #29

Post #30

Topic summary