logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

[RTL8710CF] How to Reflash Firmware on Kasa HS200 WiFi Smart Switch (US)

Jerther 4959 44
ADVERTISEMENT
Report a violation of the law
Reply | New topic
  • Helpful post
    #1 21384347
    Jerther
    Level 5  
    Posts: 30
    Help: 1
    Rate: 8
    Kasa Smart Single Pole Light Switch by TP-Link (HS200)

    The case is a bit difficult to crack open, but it's possible by using only a flat head screwdriver and by prying the sides. Here's the PCB on both sides:

    PCB of TP-Link Kasa HS200 light switch with marked pads.

    View of the backside of the TP-Link Kasa HS200 smart light switch PCB with marked GPIO0 and 3V3 pads.

    I connected the 5V pad on the PCB to the 5V rail of the USB Serial Converter. The rest of the pads are clearly labeled in the pictures. It's like it was meant to be reflashed ;)

    Short the GPIO0 pad to the 3V3 pad next to it to enable bootloader mode. Use the "Restart" tact switch to restart the MCU. The "Reset" tact switch is just another input.

    The rest is easy! Follow this guide to flash the firmware: https://www.elektroda.com/rtvforum/topic4097185.html

    Here's a partial template I've come up with. It allows control of the relay and the main LED by the main switch. The "Reset" switch and the tri-color "wifi" LED are mapped but I'm not sure what to do with them. I'd like to use them for their original intended purpose but I don't know how. I hope that helps :)

    Code: JSON
    Log in, to see the code
  • ADVERTISEMENT
  • #2 21385105
    divadiow
    Level 38  
    Posts: 4845
    Help: 421
    Rate: 853
    thank you for the template and the firmware backup you sent. I've not been able to get it into a pairable state to determine much from it at this point.
  • #3 21385142
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    Jerther wrote:
    the tri-color "wifi" LED are mapped but I'm not sure what to do with them. I'd like to use them for their original intended purpose but I don't know how.

    There are "LED_WIFI" and "LED_WIFI_n" to use the WiFi LED. Will they do what you want?
  • #4 21385370
    Jerther
    Level 5  
    Posts: 30
    Help: 1
    Rate: 8
    max4elektroda wrote:
    Jerther wrote:
    the tri-color "wifi" LED is mapped but I'm not sure what to do with them. I'd like to use them for their original intended purpose but I don't know how.

    There are "LED_WIFI" and "LED_WIFI_n" to use the WiFi LED. Will they do what you want?

    I just found the documentation for pin roles. I'll do some tests.

    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/ioRoles.md

    Added after 7 [hours] 1 [minutes]:

    I have fiddled a bit with the LED_WIFI roles and the best I could come up with is to use the green led, and it follows the behavior described in the documentation but that's quite a bit far from the original:

    Blinking Amber and Green: App-Config mode initiated.
    Green: Lit up for about 30 seconds when successfully connected to the Wi-Fi network, then turns off.
    Blinking Amber: Resetting.
    Red: No Wi-Fi connection.

    Now it's ok if the behaviors are different, but the led staying lit is a bit annoying, and I'd like to make use of the red and amber colors too if that's possible.

    The led works by combining P7 and P9:
    P7 only = green
    P9 only = red
    P7+P9 = amber

    Any ideas?
  • #5 21424140
    divadiow
    Level 38  
    Posts: 4845
    Help: 421
    Rate: 853
    did you get any further since you last posted? I forgot about this thread and have not yet posted added your template

    Added after 20 [minutes]:

    info from dump

    Code: Text
    Log in, to see the code
  • #6 21424326
    Jerther
    Level 5  
    Posts: 30
    Help: 1
    Rate: 8
    I haven't. My last post is as far as I went.
  • ADVERTISEMENT
  • #7 21424343
    divadiow
    Level 38  
    Posts: 4845
    Help: 421
    Rate: 853
    how would you like the LEDs to behave?

    Flashing amber for wifi connecting? (not even sure you can assign two wifi_led roles and they function together without some autoexec script)
    then green for socket on and red for socket off?

    Added after 11 [minutes]:

    I've assigned a two-LED plug I have both WifiLed and they behave as one - purple wifi connecting indicator in my case - red/blue
  • #8 21424498
    Jerther
    Level 5  
    Posts: 30
    Help: 1
    Rate: 8
    It would be nice if the wifi LEDs behaved like the original and used the full three colors. If it is not possible, then at least have the green led turn off after some time when wifi is connected. Right now it is always lit and it's a bit annoying because of the way the switch was designed.
  • #9 21425991
    Jerther
    Level 5  
    Posts: 30
    Help: 1
    Rate: 8
    Here's what the switch looks like when it's on with my current template. The white circle is on when the switch is on, and it is off when the switch is off. The green wifi LED is always lit.

    Wall switch turned on with green wifi LED and glowing white circle.
  • #10 21426900
    divadiow
    Level 38  
    Posts: 4845
    Help: 421
    Rate: 853
    I guess it'd be something to script, change the role of each pin depending on the state of the wifi (or other state/trigger). Here's a basic example that could be built upon

    https://www.elektroda.com/rtvforum/topic4012418.html#20804036

    Added after 18 [minutes]:

    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/autoexecExamples.md

    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/commands-extended.md

    Added after 1 [minutes]:

    https://youtu.be/kXi8S12tmC8?si=0ni9o9E2WePYspU_
  • #11 21490774
    Jerther
    Level 5  
    Posts: 30
    Help: 1
    Rate: 8
    I haven't had time to play with scripts yet, but I've had a wifi outage yesterday. Of course the wifi led on the switch started to blink red-green in alternance, which is expected. But once the wifi came back up, the switch did not reconnect automatically. The wifi led kept on blinking for hours, until I hit the small "restart" button on the switch. Then it reconnected fine.

    It's like the microcontroller gives up reconnecting at some point, and I believe it's not intended, because other IoT devices I've reflashed with openbk reconnected without my intervention.
  • #12 21528518
    divadiow
    Level 38  
    Posts: 4845
    Help: 421
    Rate: 853
    ah interesting. That's a bit of a show-stopper for RTL87X0C devices running OpenRTL.

    I think @max4elektroda did some stuff on several platforms regarding wifi reconnection behaviour, but maybe that was (just?) SSID2 support.

    Added after 3 [minutes]:

    and maybe @insmod who ported RTL
  • ADVERTISEMENT
  • #13 21528550
    insmod
    Level 31  
    Posts: 1353
    Help: 160
    Rate: 425
    I don't have a RTL87X0C device, but i have RTL8710B and RTL8720D devices running, and they all share wifi code.
    What version are you using? I improved wifi code some, previously it could've crashed the device. Also, in recent update i turned on realtek own auto reconnect feature, in addition to openbeken one.
    I don't have problems with wifi anymore, and my RTL8710B plug uptime is at about a month, with wifi outages.
    This particular plug is pretty unstable with wifi when there's any load. I've had 1.5 hours today of when the plug disconnected and didn't reconnect, but it eventually did.
    You could also try to enable flag 51, but i doubt that it would change anything.
  • #14 21528562
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    divadiow wrote:
    I think @max4elektroda did some stuff on several platforms regarding wifi reconnection behaviour, but maybe that was (just?) SSID2 support.

    Yes, some SSID2 stuff and a faster try for reconnect during the first seconds after startup.
    All the WiFi code is usually in a library blob from the manufacturer, I expect the same here.
    If you don't have a serial connection to see logs during this time it will be hard to figure out. Maybe SSID is not found, authentication failed...
  • #15 21528635
    Jerther
    Level 5  
    Posts: 30
    Help: 1
    Rate: 8
    The version I'm using is the one introducing support for RTL8710C. I understand there's been multiple improvements since, so I'll update the firmware and check if I can make the switch fail to reconnect again.

    Meanwhile, what needs to be done about the template so it makes the official list?
  • #17 21528672
    Jerther
    Level 5  
    Posts: 30
    Help: 1
    Rate: 8
    No way! :D

    So it looks like I'm golden then! Nice! I will report back if I find anything about the WiFi.
  • #18 21528674
    divadiow
    Level 38  
    Posts: 4845
    Help: 421
    Rate: 853
    well, that PR's been open a month, I think @p.kaczmarek2 has been busy
  • #19 21528696
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14400
    Help: 650
    Rate: 12330
    There are no pending Web App pull requests?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #20 21528701
    divadiow
    Level 38  
    Posts: 4845
    Help: 421
    Rate: 853
    oh dear. my bad 😳

    would help if I had opened one
  • #21 21528804
    Jerther
    Level 5  
    Posts: 30
    Help: 1
    Rate: 8
    1.18.12

    "Sorry, OTA update not implemented for OpenRTL87X0C"

    Oh no :( so I have to remove the switch from the wall and reflash the firmware the hard way...

    Is OTA implemented in later versions, so I don't have to do that again?
  • #22 21528805
    insmod
    Level 31  
    Posts: 1353
    Help: 160
    Rate: 425
    >>21528804
    OTA was implemented even before the release, so don't worry.
  • Helpful post
    #23 21528852
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    Jerther wrote:
    Sorry, OTA update not implemented for OpenRTL87X0C

    I don't recall if the "new" OTA on the Configure menu was present in that version, maybe it wasn't. If that's the problem you should be able to do OTA from the Web App.

    Added after 20 [minutes]:

    Just checked the code, that should be the case, this new approach for OTA was implemented while @insmod was doing the heavy lifting with OpenRTL so it's not present in 1.18.12 yet.
    But Web Application OTA should work
  • #24 21529248
    Jerther
    Level 5  
    Posts: 30
    Help: 1
    Rate: 8
    Ok there's an OTA menu in the web app. Phew! 😅
  • #25 21535393
    Jerther
    Level 5  
    Posts: 30
    Help: 1
    Rate: 8
    I went ahead and ordered about a dozen of these switches and while the MCU is the same, the board layout is different. Shouldn't be a problem since all test points are still accessible. I'll post pictures and more details when I can.
  • #27 21550066
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14400
    Help: 650
    Rate: 12330
    Thank you, merged. Let me know if you have any futher ideas for improvements.
    Helpful post? Buy me a coffee.
  • #28 21598616
    Jerther
    Level 5  
    Posts: 30
    Help: 1
    Rate: 8
    Ok so four updates:

    1) I've made a new PR to set the wifi led to actual wifi led in the configuration: https://github.com/OpenBekenIOT/webapp/pull/207

    2) I have no picture of the new PCB revision, but all the test pads are still present, and on the same side of the PCB. You need to remove the little foam pad to access one of them.

    3) We've stopped using devices from Kasa at work after one had a capacitor blow up. A quick search on google revealed that many MANY of these devices suffer the same fate, so we've stopped using them. BUT at home I still use them and I've preventively replaced the suspicious cap (the only 470µF 10V) by a Rubicon 470µF 16V 8000h@105C. Should last a while ;)

    4) I've started using the MQTT feature with home assistant. The switch works fine, but the extra info (build, IP, rssi, ssid, uptime) all become "unknown" after a while. Any clue why this happens?
  • #29 21605761
    Jerther
    Level 5  
    Posts: 30
    Help: 1
    Rate: 8
    @p.kaczmarek2 can you take a look at the PR I mentioned in my previous comment?
  • #30 21605763
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14400
    Help: 650
    Rate: 12330
    Sure, I merged it, however it looks like just a LED role swap, so probably there are two LEDs with different colors?
    Helpful post? Buy me a coffee.
Reply | New topic
Report a violation of the law

Topic summary

✨ The discussion focuses on reflashing the firmware of the TP-Link Kasa HS200 WiFi Smart Single Pole Light Switch using the RTL8710CF microcontroller. The device's PCB is accessible by prying open the case, revealing clearly labeled pads for serial connection. Bootloader mode is enabled by shorting GPIO0 to 3.3V and restarting the MCU. A partial firmware template was shared, enabling relay and main LED control, with mapping for the reset switch and tri-color WiFi LED. Users explored LED behavior customization, noting the WiFi LED uses pins P7 and P9 to produce green, red, and amber colors, but replicating the original LED patterns proved challenging. Suggestions included scripting pin roles dynamically based on WiFi state. Firmware versions supporting RTL8710C were discussed, highlighting improvements in WiFi reconnection and OTA update capabilities. OTA updates are not implemented in early versions (e.g., 1.18.12) but are available via the Web App in later releases. Issues with WiFi reconnection after outages were reported, with some devices requiring manual restart. Contributions included a pull request to enable the reset button to trigger safe mode. Newer switch batches with different board layouts but the same MCU were mentioned, with test points remaining accessible for reflashing.
Generated by the language model.
Today's popular

FAQ

TL;DR: For Kasa HS200 owners reflashing RTL87X0C hardware, 2 board variants exist, and one expert note says, "OTA was implemented even before the release." Use 5V, TX, RX, and short GPIO0 to 3V3, then restart to enter bootloader. This FAQ solves flashing, templates, Wi‑Fi LED behavior, safe mode, and OTA confusion for both HS200 revisions. [#21528805]

Why it matters: The thread shows that the HS200 is refl ashable, but success depends on choosing the right template for the exact PCB revision and understanding how OpenBeken/OpenRTL handles LEDs, buttons, OTA, and Wi‑Fi recovery.

HS200 variant Main pinout clue Relay pin Main button pin Extra button pin Notes
Original board Wi‑Fi LED uses P7+P9 8 12 19 Tri‑color Wi‑Fi LED from two pins
Newer board Different layout, same accessible pads 18 17 19 Two-pin bi‑color LED, updated template needed

Key insight: The hardest part is not flashing the HS200. The real risk is using the wrong board template, which can break LED behavior, require double presses, or force unwanted safe-mode behavior.

Quick Facts

  • The original HS200 reflashing method uses 5V power from the USB serial converter, with GPIO0 shorted to 3V3 and the Restart tact switch used to reboot into bootloader mode. [#21384347]
  • One flash dump shows dual firmware slots: Fw1 at 0x010000, length 0x0f0000, and Fw2 at 0x100000, length 0x0f0000. [#21424140]
  • The original tri-color Wi‑Fi LED is built from 2 pins: P7 = green, P9 = red, and P7+P9 = amber. [#21385370]
  • A user replaced the suspect electrolytic with a 470µF 16V, 8000h @ 105C capacitor after reports involving the stock 470µF 10V part. [#21598616]

How do I put a TP-Link Kasa HS200 smart switch with an RTL87X0C chip into bootloader mode and reflash it with OpenBeken?

Put the HS200 into bootloader by shorting GPIO0 to 3V3, then pressing the Restart tact switch. Use a USB serial converter connected to the labeled pads, power the board from the 5V pad, and then flash it with the OpenBeken/OpenRTL guide linked in the thread. 1. Connect 5V, TX, RX, and ground. 2. Short GPIO0 to 3V3. 3. Press Restart and flash. The separate Reset switch is only another input, not the bootloader trigger. [#21384347]

Which PCB pads on the Kasa HS200 should I connect to a USB serial converter for flashing, including 5V, GPIO0, 3V3, TX, and RX?

Connect the HS200’s labeled test pads directly to your USB serial converter: 5V to the converter’s 5V rail, plus TX, RX, and ground on their matching pads. Short the GPIO0 pad to the nearby 3V3 pad only to enter bootloader mode, then reboot with Restart. Later posts confirm that even the newer PCB revision keeps the flashing test pads accessible, though one pad may sit under a small foam pad. [#21598616]

Why does the Kasa HS200 WiFi LED stay lit after connecting in OpenBeken, and how can I make it behave more like the stock firmware?

The Wi‑Fi LED stays lit because the available LED roles do not fully reproduce the stock three-color logic on this switch. One user got only partial behavior: green stayed on for about 30 seconds after Wi‑Fi connection, red showed no connection, and amber/green blinking showed app-config mode. To get closer to stock behavior, the thread points to scripting and role changes, because the HS200 combines two pins for three colors instead of using a simple single-color Wi‑Fi LED. [#21385370]

What pin template works for the original TP-Link Kasa HS200 board revision with the RTL8710C/RTL87X0C MCU?

The original HS200 template uses relay on pin 8, main switch on pin 12, reset input on pin 19, and LEDs on pins 4, 7, and 9. The posted JSON maps pin 4 to LED_n;0, pin 7 to LED_n;1, pin 8 to Rel;0, pin 9 to LED_n;1, pin 12 to Btn;0, and pin 19 to Btn;1. It was enough to control the relay, the main LED, and map the Wi‑Fi LED hardware for further testing. [#21384347]

What template should I use for the newer Kasa HS200 board variant with the different pinout and accessible test pads?

Use the updated template for the newer HS200 variant, not the original one. The final posted mapping sets pin 2 to WifiLED;0, pin 3 to AlwaysHigh;0, pin 4 to LED;0, pin 17 to Btn;0, pin 18 to Rel;0, and pin 19 to Btn;1. Its command line is backlog setButtonTimes 50 0 255; addEventHandler OnHold 19 SafeMode. That version also sets the white LED to turn off when the relay is on. [#21767614]

How can I use the HS200 reset button to trigger OpenBeken safe mode instead of leaving it unmapped?

Map the extra reset button to a normal button role and attach an OnHold event that enters SafeMode. The working example for the newer variant uses addEventHandler OnHold 19 SafeMode and a 5-second hold behavior was described for safe-mode entry. A later pull request was merged specifically to make the reset button useful instead of leaving it inactive. [#21767614]

What is safe mode in OpenBeken, and how is it useful when experimenting with templates on devices like the Kasa HS200?

Safe mode is OpenBeken’s recovery state that lets the device boot with risky template logic bypassed, so you can fix bad pin mappings or scripts. "Safe mode" is a recovery feature that boots the firmware in a safer state, avoids normal automation behavior, and helps restore access after template or button mistakes. On the HS200, users explicitly repurposed the extra reset button to enter SafeMode after a 5-second hold. [#21767614]

What is CEN on Realtek RTL87X0C-based boards, and how is it different from a normal GPIO-connected reset button?

CEN is the hardware reset line, not a normal software-mappable GPIO input. "CEN" is a hardware control pin that resets the Realtek MCU directly, bypassing normal GPIO logic, so a button wired to it restarts the chip instead of acting like a configurable template button. In this thread, the Restart button was identified as connected to CEN, while the other reset-labeled button was just another GPIO. [#21623063]

Why might an OpenRTL87X0C-flashed Kasa HS200 stop reconnecting after a Wi‑Fi outage until the restart button is pressed?

It can happen because earlier RTL87X0C Wi‑Fi behavior was still being improved, and reconnect logic could stall after an outage. One user reported the HS200 blinking red-green for hours after Wi‑Fi returned, only reconnecting after the Restart button was pressed. Another expert reply said recent updates improved the Wi‑Fi code, enabled Realtek’s own auto-reconnect, and that older code could even crash devices under some conditions. [#21528550]

Which OpenBeken or OpenRTL firmware versions improved Wi‑Fi reconnection on RTL8710B, RTL8720D, and RTL87X0C devices?

Later builds after the first RTL8710C-support release improved reconnection behavior. The user with the HS200 said they were running the version that first introduced RTL8710C support, and the maintainer replied that newer updates had improved Wi‑Fi handling and enabled Realtek’s own auto-reconnect. The same reply also said an RTL8710B plug had stayed up for about 1 month despite Wi‑Fi outages, though load-related instability still appeared on one device. [#21528550]

What’s the difference between the OTA update option in the device Configure menu and OTA from the OpenBeken Web App on RTL87X0C devices?

On version 1.18.12, the device’s Configure menu could report that OTA was not implemented for OpenRTL87X0C, while OTA from the Web App still worked. One maintainer checked the code and explained that the newer Configure-menu OTA approach was not yet present in that version, but Web Application OTA should still function. The user then confirmed that the Web App had an OTA menu available. [#21528852]

How do LED_WIFI and LED_WIFI_n roles work in OpenBeken when a device uses a two-pin or tri-color Wi‑Fi status LED?

They let OpenBeken drive Wi‑Fi state LEDs, but multi-color hardware may need two pins or scripting to match stock behavior. In the original HS200, two pins create three colors: P7 alone gives green, P9 alone gives red, and P7+P9 gives amber. Another user also reported that assigning two WiFiLed roles on a two-LED device made both behave as one combined indicator, producing a purple reconnect/search effect. [#21424343]

Btn vs Btn_n in OpenBeken templates for the Kasa HS200: which button role matches the hardware and prevents double-press or safe-mode boot issues?

Btn matched the newer HS200 hardware better and fixed the double-press problem. A user updated pin 17 from Btn_n to Btn after seeing that Btn_n required two presses to toggle the light and created noisy Button_OnLongPressHold logs. The same follow-up also noted that using Btn_n on pin 19 earlier in the thread had contributed to the switch boot-looping into safe mode. [#21796863]

Why do MQTT entities like build, IP, RSSI, SSID, and uptime become 'unknown' in Home Assistant after a while on an OpenBeken-flashed HS200?

The thread reports the symptom but does not provide a fix yet. The user said the switch itself worked fine with MQTT and Home Assistant, but the extra entities for build, IP, RSSI, SSID, and uptime all became “unknown” after some time. No later reply in the thread explains the cause, so the only thread-grounded answer is that it remained unresolved as of July 6, 2025. [#21598616]

What hardware reliability issues have users reported with Kasa HS200 switches, including the failing 470uF 10V capacitor, and what replacement parts are safer?

Users reported capacitor failures on some Kasa devices, centered on the board’s only 470µF 10V electrolytic. One user said their workplace stopped using Kasa hardware after a capacitor blew up, adding that a quick Google search found many similar reports. For home use, they preemptively replaced that capacitor with a Rubicon 470µF 16V rated 8000h at 105C, calling it a safer long-life substitute. [#21598616]
Generated by the language model.
ADVERTISEMENT