logo elektroda
logo elektroda
X
logo elektroda

OBK Startup Delay Optimization for BK7238 and BK7231N Devices: Is 250ms Needed?

protectivedad 36 5
ADVERTISEMENT
  • #1 21803043
    protectivedad
    Level 9  
    I noticed OBK has a 250 ms delay for the BEKEN_NEW (BK7238) and BK7231N devices. Is this still necessary?

    In my builds, I created:
    #elif PLATFORM_BEKEN
    ...
    #if PLATFORM_BK7231N || PLATFORM_BEKEN_NEW
    // Default 250ms needs to be in increments of 10ms
    #define OBK_STARTUP_MS_DELAY               250
    ...
    

    For my BK7231N device, I changed it to 0 ms, and for the BK7238 device it is 10 ms (0 ms causes the Wi-Fi connection to crash intermittently). In my timing tests, I get over 10% improvement in my door sensor posting time with the change.

    Adding this change would allow people to easily compile for testing. Creating a "fast" variant is just adding maintenance. Would reducing the default make sense? Any opinions?
  • ADVERTISEMENT
  • ADVERTISEMENT
  • #3 21803130
    protectivedad
    Level 9  
    insmod wrote:
    For BK7231N, even reducing it to 100ms can bring problems. Don't know about 7238.
    https://github.com/openshwprojects/OpenBK7231T_App/issues/1852

    I run a door sensor 7231N with 0ms and it works ok.

    Alright, then I guess a custom build is necessary. For my door sensors. Do you think there is enough of a base that a custom variant would be beneficial? One that reduces the amount of drivers to a minimum: TuyaMCU/DoorSensor/Battery and reduces the delay to 0 ms for 7251N and 10 ms for the 7238.
  • ADVERTISEMENT
  • ADVERTISEMENT
  • #5 21803349
    p.kaczmarek2
    Moderator Smart Home
    How much will it increase a build process time on GitHub?
    Helpful post? Buy me a coffee.
  • #6 21803379
    insmod
    Level 29  
    >>21803349
    2 new variants, ~1-2 mins each
ADVERTISEMENT