WiFi.disable Implementation for BK7231 & LN882H Similar to ESPHome Feature

rufus4 wrote:

is there a implementation of "wifi.disable" for bk7231 and LN882H like its allready availlable in esphome?

Hello there!

Your question about implementing a "wifi.disable" functionality for the BK7231 and LN882H, similar to what's available in ESPHome, is quite intriguing. As you likely know, ESPHome provides a straightforward way to manage WiFi connectivity on ESP8266 and ESP32 devices, including enabling and disabling WiFi, which can be very handy for power management and security purposes.

For the BK7231 (from the Beken Corporation) and LN882H, the situation is a bit more nuanced, given these are not as widely adopted in the DIY community as the Espressif devices, and direct support in platforms like ESPHome may not exist. However, let's break down what you'd typically need to consider for implementing such a feature and see how we can approach it.

1. Firmware and SDK Support: First, we need to look into the SDK provided by the manufacturers (Beken for BK7231 and the manufacturer of LN882H) to see if they offer direct methods to disable and enable the WiFi module programmatically. Many WiFi chipsets offer low-level commands for power management, including disabling the RF functionality.

2. Community-Driven Projects: For platforms like the BK7231 and LN882H, there often are community-driven projects or third-party firmwares that might have implemented similar functionalities. It would be beneficial to check forums, GitHub repositories, or other platforms for any existing projects.

3. Custom Implementation: If direct support isn't available, you might need to consider implementing the feature yourself. This would involve getting familiar with the SDKs from the manufacturers and possibly writing some low-level code to manage the WiFi module's power state.

4. Power Management vs. Complete Disable: It's also worth noting that there's a difference between disabling the WiFi to save power and completely turning off the module. Some applications might be okay with putting the WiFi module into a low-power state rather than completely disabling it, depending on your requirements.

Could you share more about your application or project? Specifically, what are your exact needs regarding disabling WiFi on these devices? Are you looking to save power, or are there other considerations at play? This information would help narrow down the most suitable approach for your situation.

rufus4 wrote:

(...)
it would be possible to get access for settings on startup of the device and all the rest of its on-time wifi will be completely switched off, because it's not needed anymore.
This is only one example and for sure there are many other use cases where rf is not really needed to be on hold all the time.

Ah, I understand your use case better now. You're aiming for devices that are mostly operating in a "dumb" mode for efficiency and security reasons but can temporarily enable WiFi for configuration purposes. This is indeed a smart approach for devices like light bulbs, where continuous connectivity isn't necessary and can help in significantly reducing power consumption and minimizing potential security vulnerabilities.

Given your specific requirements, here's how you might approach this for chips like BK7231 and LN882H, considering they don't have the same level of out-of-the-box support as ESP devices in something like ESPHome:

### 1. Investigate SDK Capabilities

The first step is to dive deep into the SDKs or development documents provided by the chip manufacturers. You're looking for any functions or commands that control the WiFi module's power state or enable/disable the radio. Both Beken and the manufacturer of LN882H should provide documentation or developer guides that outline how to interact with the hardware at this level.

### 2. Community Resources and Custom Firmware

As I mentioned before, it's worthwhile to explore any community-driven projects. Sometimes, individuals or groups may have tackled similar challenges and shared their solutions online. Places like GitHub, electronics forums (like elektroda.com), and Reddit can be goldmines for such information.

### 3. Implementing a Custom Solution

Based on what you find in the SDK and community resources, you might end up developing a custom solution. Here's a simplified approach to what your implementation might look like, assuming you find the necessary commands in the SDK:

- Initialization: Upon boot, initiate WiFi and allow it to connect to the network.
- Configuration Window: Implement a delay during which the device is receptive to incoming configuration commands. This is similar to your ESPHome example.
- Disabling WiFi: After the configuration window, use the SDK's commands to disable the WiFi module. Ensure you have a method to re-enable it, perhaps by listening for a specific physical input on the device (like a button press).

### 4. Consider Physical Input for Re-enabling WiFi

Since the WiFi will be disabled most of the time, consider implementing a physical interface (like a button on the device) to re-enable WiFi mode for configuration. This way, you don't need to power cycle the device for reconfiguration.

### 5. Power Cycle Concerns

Lastly, remember that any settings changed via WiFi should be stored in non-volatile memory if you want them to persist across power cycles. This is especially important for devices that might be disconnected from power between uses.

Given the specifics of your project, would you be comfortable diving into the SDK documentation and possibly writing some custom code based on what you find? If you have any questions on how to get started with this or need further clarification on any of the steps, feel free to ask!