I have
"pins": {
"1": "WifiLED;0",
Should it be what you posted?
I have
"pins": {
"1": "WifiLED;0",
Should it be what you posted?
Czy wolisz polską wersję strony elektroda?
Nie, dziękuję Przekieruj mnie tam
omniron wrote:
Since that "WiFi" LED has "reversed" powering, it should be WiFiLED there.
Maybe you can kindly fix that, too?
Quote:
Question: My device name ends with 00000, is it normal?
A: Device name is generated based on MAC, that would mean you have accidentally cleared your MAC, so see question below.
Question: I somehow lost my MAC address and I am unable to change it in Options! My MAC ends with 000000, how to fix?
A: You have most likely overwrote the TLV header of RF partition of BK7231. You might have done something wrong while flashing or/and done unnecessary 'Erase all' for the chip. The RF partition is normaly NOT overwritten when a device is flashed correctly, because it starts far after the end of OBK binary. For BK7231, we have a way to restore it - open Web App, go to Flash tab, and press 'Restore RF Config'. Note that removing original RF partition (which was already done, if you have 00000) may slightly reduce your device WiFi range and performance
omniron wrote:
So I thought that maybe the RF data and MAC can be extracted from the dump I posted?
TL;DR: If your Xenon SM-PW801-U2 uses a WB3S/BK7231T module, read a full 2MB dump first and use the correct UART. The key fix was: "TXD1/RXD1 is flashing port". This FAQ helps owners recover, flash OpenBeken, and prepare OTA profiles when CEN is tied to VCC. [#20825513]
Why it matters: This thread shows the exact failure points that stop BK7231T flashing, then documents the settings that finally make both wired flashing and later OTA migration work.
| Tool / method | Best use in this thread | What worked or failed |
|---|---|---|
| BK7231GUIFlashTool | Guided flashing and backups | Worked after using BK7231T mode and TXD1/RXD1; failed in BK7231N mode or on TXD2/RXD2 |
| bkWriter 1.60 | Reading a full flash dump | Used to read the dump; Operate Length had to be set to 0x200000 |
| OTA profile | Flashing additional unopened units | Became possible only after obtaining one correct 2MB dump |
Key insight: The outlet was not blocked by CEN tied to VCC. The real blockers were the wrong UART port, the wrong chip mode, and an incomplete or inconsistent dump.
0x200000 as the read length. [#20827028]WifiLED_n;1, while WifiLED;0 remained an acceptable user preference. [#20950196]Reading 0x00. After correcting the mode, the dump was accepted as valid. [#20827147]0x200000, and the maintainer says not to change Start Address because it will wrap correctly anyway. That full dump is the version needed for GPIO extraction and later OTA profile work. [#20827066]Xenon SM-PW801-US Wall Outlet profile. That profile became available after the 2MB dump was captured and processed. The same post says this method is specifically for flashing without soldering wires on the remaining unopened units. [#20828299]WebButton commands. The maintainer gave the direct command setChannelLabel 1 Xyz, and then pointed to the docs screenshot for changing the visible label text. That is why toggler_name0 failed here: it applies to the toggler driver, not this outlet’s relay UI. [#20838808]addClockEvent. The thread says sunrise and sunset support was added recently and points to the scripting topic dedicated to time and scheduling. That means hard-coded times in older autoexec examples are no longer the only option for this outlet. [#20950196]Restore RF Config, but it restores a usable config, not necessarily the factory-original MAC. [#20954290]WifiLED_n;1. The maintainer later confirmed that both WifiLED and WifiLED_n are acceptable, but many users prefer WifiLED_n because the light stays off when Wi‑Fi is connected. The completed Xenon SM-PW801-U2 template also kept relays on P6 and P9, with buttons on P24 and P10. [#20950196]//. The log explicitly says Label // not found ... will go to the start of file, then confirms started AllLights_off.bat at label //. So BtnScriptOnly was firing on pin 10, but the thread does not show a final fix for why the script body still produced no visible action. [#21064467]