logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

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

protectivedad 579 13
ADVERTISEMENT
Reply | New topic
  • #1 21380546
    protectivedad
    Level 7  
    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.
    Rust on Embedded Online Conference on 16 July with 33 per cent discount for elektroda users
  • ADVERTISEMENT
  • #2 21380886
    p.kaczmarek2
    Moderator Smart Home  
    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?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #3 21381070
    DeDaMrAz
    Level 20  
    @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.
  • ADVERTISEMENT
  • Helpful post
    #4 21381078
    insmod
    Level 24  
    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.
    Graph showing door sensor voltage over time from September to January.
  • #5 21381479
    protectivedad
    Level 7  
    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:
  • #6 21381599
    p.kaczmarek2
    Moderator Smart Home  
    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
    Helpful post? Buy me a coffee.
  • #7 21381646
    protectivedad
    Level 7  
    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
    DeDaMrAz
    Level 20  
    protectivedad wrote:
    Any NON uart suggestions?


    Have you tried clearAll command from safe mode? Backup what you need before as it will reset everything.
  • #9 21381735
    protectivedad
    Level 7  
    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.
  • ADVERTISEMENT
  • #10 21381870
    DeDaMrAz
    Level 20  
    Just for reference, this was the testing autoexec from my door sensor that later got reduced to remove some timeouts and checks.

    Code: text Expand Select all Copy to clipboard
    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.
  • #11 21382657
    protectivedad
    Level 7  
    >>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
    p.kaczmarek2
    Moderator Smart Home  
    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?
    Helpful post? Buy me a coffee.
  • #13 21382906
    insmod
    Level 24  
    >>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
    protectivedad
    Level 7  
    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.
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.
Summary generated by the language model.
Popular Topics
ADVERTISEMENT