Hello everyone,
I was referred here by the OpenBeken project owner after opening a GitHub discussion about a smart plug whose cloud service is shutting down.
Quick context, kept short: the manufacturer has agreed to talk and is internally reviewing what technical documentation they can release to the open-source community. The company is trying to determine what information can be shared without exposing proprietary know-how, so I'd like to prepare a practical and realistic request list. Nothing is approved for public release yet, so I can't post brand/model names or photos at this stage.
To be clear about scope: I am not asking for firmware source, cloud API internals, proprietary protocols, or anything covered by trade secrets. The goal is strictly the minimum interfacing-level information needed to enable local control using projects such as OpenBeken or ESPHome - the same information that would normally be obtained through a teardown, except provided directly and accurately by the people who designed the board.
This is where I'd like your input. Since the company will only release a limited set of documents, I want the request list to be prioritized correctly. My current draft:
MCU / Wi-Fi module model name (I understand this is the single most important item)
UART pinout and test point locations (TX, RX, 3.3 V, GND, boot/CEN pin)
GPIO mapping table (relay, button, status LED)
Power metering IC model (BL0937/BL0942/etc.) and its interface pins to the MCU
Whether flash read protection or signed firmware is enabled, since this may influence which technical information would be most useful to request first
If the design uses a secondary MCU (e.g. a Tuya-style MCU handling buttons/relay while the Wi-Fi chip acts as a serial bridge), documentation of the inter-MCU serial protocol
Questions for those who have done this before:
- Is the priority order above correct, or would you reorder it?
- Are there items I'm missing that are cheap for a manufacturer to provide but valuable for porting? (e.g. partition map, bootloader entry method, original firmware binary if legally shareable)
- For the dual-MCU case: is a register/command-level description of the serial protocol sufficient, or is timing information also needed in practice?
If the collaboration moves forward, I'll report back here with the results, document everything the manufacturer explicitly approves for public release, and share teardown photos and a chipset-specific follow-up thread. I'll also summarize which pieces of manufacturer-provided information turned out to be the most useful so that the experience may help similar projects in the future.
Thanks in advance.
I appreciate any advice from those who have worked on OpenBeken, ESPHome, Tasmota, or similar local-control projects.
I was referred here by the OpenBeken project owner after opening a GitHub discussion about a smart plug whose cloud service is shutting down.
Quick context, kept short: the manufacturer has agreed to talk and is internally reviewing what technical documentation they can release to the open-source community. The company is trying to determine what information can be shared without exposing proprietary know-how, so I'd like to prepare a practical and realistic request list. Nothing is approved for public release yet, so I can't post brand/model names or photos at this stage.
To be clear about scope: I am not asking for firmware source, cloud API internals, proprietary protocols, or anything covered by trade secrets. The goal is strictly the minimum interfacing-level information needed to enable local control using projects such as OpenBeken or ESPHome - the same information that would normally be obtained through a teardown, except provided directly and accurately by the people who designed the board.
This is where I'd like your input. Since the company will only release a limited set of documents, I want the request list to be prioritized correctly. My current draft:
MCU / Wi-Fi module model name (I understand this is the single most important item)
UART pinout and test point locations (TX, RX, 3.3 V, GND, boot/CEN pin)
GPIO mapping table (relay, button, status LED)
Power metering IC model (BL0937/BL0942/etc.) and its interface pins to the MCU
Whether flash read protection or signed firmware is enabled, since this may influence which technical information would be most useful to request first
If the design uses a secondary MCU (e.g. a Tuya-style MCU handling buttons/relay while the Wi-Fi chip acts as a serial bridge), documentation of the inter-MCU serial protocol
Questions for those who have done this before:
- Is the priority order above correct, or would you reorder it?
- Are there items I'm missing that are cheap for a manufacturer to provide but valuable for porting? (e.g. partition map, bootloader entry method, original firmware binary if legally shareable)
- For the dual-MCU case: is a register/command-level description of the serial protocol sufficient, or is timing information also needed in practice?
If the collaboration moves forward, I'll report back here with the results, document everything the manufacturer explicitly approves for public release, and share teardown photos and a chipset-specific follow-up thread. I'll also summarize which pieces of manufacturer-provided information turned out to be the most useful so that the experience may help similar projects in the future.
Thanks in advance.
I appreciate any advice from those who have worked on OpenBeken, ESPHome, Tasmota, or similar local-control projects.
