Support for RTL8710CM?

[craggyh]

Is there support for RTL8710CM yet? I have a couple of devices (Tapo L920 LED controllers) using this chip and would love to be able to flash them with libretuya/esphome.

[kuba2k2]

No, not yet. See #37 and #36.

[Nold360]

anything we can do to push support forward? idk what's missing/required :(

[kuba2k2]

Not really, unless you either know C/C++ well and are comfortable working in crappy vendor SDKs, or can buy me more time :smile:

[Rain]

I've successfully compiled and ran the PinScan example (amazingly helpful, btw!) and flashed libretiny-esphome on a RTL8710CM with your recent changes.

Everything I was able to test seems to work using the generic-rtl8720cf-2mb-992k board (with the exception of esphome OTAs, but it doesn't look like OTAs are implemented for any of the libretiny-supported RTL MCUs at the moment). The boards I'm playing with (TP-Link EP25/KP125 Smart Plugs) are extremely simple though so outside of WiFi & GPIOs there isn't much. Only minor issue is I cannot seem to read the onboard BL0937 (see: HLW8012). I might have it configured incorrectly, though; I need follow the traces again and/or try interfacing directly instead of using esphome.

It seems compiling a project with PlatformIO and/or libretiny doesn't pull in the AT command CLI from the SDK. Is there a configuration option and/or flag I've glossed over that enables it? This would allow use of the built-in OTA functionality. I had to flash the flash.bin image directly onto the SPI flash because the EP25s refuse to go into UART download mode (even after flashing a libretiny-built project).

[kuba2k2]

RTL8720C only has very draft support. Some people (incl. me) have reported ESPHome to work, but not stable.

OTA is implemented for Beken and RTL8710B - only RTLC doesn't support it at present.

The AT CLI is a default "demo" application of the SDK - it isn't (and won't be) available in LibreTiny. The built-in OTA functionality is very basic and also will not be supported. Instead, UF2 OTA will be implemented (at some point...), just like on Beken and the other Realtek. This is a universal and safe format that we're using for everything in LibreTiny.

Download mode hasn't been documented yet (as in: very draft support), but can be activated by pulling PA0 and PA13 to 3.3V, and resetting the chip/power cycling while doing that. It takes a few attempts to do so, but gets easy after you get it.

Note: after you first flash LT, download mode can be entered automatically (or by sending ping\n on UART2). That's not tested well enough, and from my attempts writing has been failing sometimes in this mode.

As for the BL0937, see https://upk.libretiny.eu/ - find a plug with power monitoring, generate a YAML for it, and see which pins usually need the invert: true flag.

[Rain]

Thanks for the information!

Yes, I realized support for the RTL8720C family is in the very early stages. Just figured I'd report my findings.

That makes sense regarding the AT CLI. Since the stock TP-Link EP25 had it I assumed it was standard and always built w/ the RTL MCUs. Their firmware must be based off the "demo" (which makes sense, I guess).

A quick perusal through their stock firmware revealed that there seems to be a way to trigger the SDK-included OTA function remotely. It may be possible replace the stock firmware on these smart plugs wirelessly without opening them up! 😎

I'll poke around some more with download mode. I've tried ping\n on UART2 but I wasn't aware of the PA0/PA13 combination. These EP25 plugs are hard enough to get open so anything that makes re-flashing easier will be helpful.

[kuba2k2]

Eventually OTA will be supported.

Have you dumped the original firmware prior to flashing? If yes, you can always mess with it by just flashing it back.

[asozio]

I've got a couple of tp-link KP115 Kasa Smart Wi-Fi Plug (slim energy monitoring) which appear to contain RTL8710CF modules (12-pin pcb mounted through hole on the main board)

I'm keen to test these out with libretiny if someone has some pointers for how I get started?

[kuba2k2]

As indicated in this thread (and in LibreTiny docs -> boards, chips, features) RTL8720C is not yet fully supported. Thus, the documentation pages are also not fully written.

[asozio]

Kinda why I was asking here ;-)

I'm an out of practice embedded C/C++ developer who is willing to have a play with it, but thought rather than re-doing work that's already been done I'd ask the question.

[nmschulte]

I was playing with a Tuya WBR3-laden ME81H (thermostat for a heater). I see above documentation that I found from this page during my trials: https://developer.tuya.com/en/docs/iot/burn-and-authorize-wbr-series-modules?id=Ka78imt8pf85p#title-7-Method%202%3A%20Separated%20solutions%20for%20flashing%20and%20authorization

After fixing up ltchiptool to support Linux (https://github.com/libretiny-eu/ltchiptool/pull/13), I was able to dump the OEM Flash and ROM, and to burn a build of ESPHome/generic-rtl8720cf-2mb-992k to the module. Booting this image however is troublesome; I run into a bootloader verification failure, and so booting halts:

INFO Starting log output from /dev/ttyACM1 with baud rate 115200
[19:48:39]
[19:48:39]== Rtl8710c IoT Platform ==
[19:48:39]Chip VID: 5, Ver: 3
[19:48:39]ROM Version: v3.0
[19:48:39]
[19:48:39]== Boot Loader ==
[19:48:39]Dec  5 2019:14:02:18
[19:48:39]
[19:48:39]fwx SELE[fffffffe]
[19:48:39]fw SELE Bitidx 1, fw1 valid 0, sn 0, fw2 valid 1, sn 1
[19:48:39]fw2 USE, return sn 1
[19:48:40]
[19:48:40]== Rtl8710c IoT Platform ==
[19:48:40]Chip VID: 5, Ver: 3
[19:48:40]ROM Version: v3.0
[19:48:40]
[19:48:40]== Boot Loader ==
[19:48:40]Dec  5 2019:14:02:18
[19:48:40]
[19:48:40]fwx SELE[fffffffe]
[19:48:40]fw SELE Bitidx 1, fw1 valid 0, sn 0, fw2 valid 1, sn 1
[19:48:40]fw2 USE, return sn 1
[19:48:40][MISC Err]Hash Result Incorrect!
[19:48:40]Boot Load Err!

Comparing the dumped images, it seems the initial (and trailing?) portions of Flash are the same; I see "hash" related strings at the same offsets (I have not poked with Ghidra yet, lacking the time currently).

I wonder if using the Tuya "RTL8720CF chip burning tool" would program the correct hash, or if this has been reversed yet?

Download and run the RTL8720CF chip burning tool."

Anyway, it seems I'm at a dead end with this board, and support is in progress, so kudos for everything so far and in the works. In the mean time, I've ordered an ESP32-C3-12F module to replace this unit (which seems to operate fine without the Tuya module installed, in case anyone needed to know).

As such, let me know if there's anything I can test or help reverse to support the Tuya WBR3/RTL8720CF.

[kuba2k2]

@nmschulte I can look into this if you post the OEM firmware dump - it contains the hash keys, so that I can check if they are the same as used in LT.

[nmschulte]

I can look into this if you post the OEM firmware dump

me81h_16-wbr3-oem-dump.tar.gz

[kuba2k2]

This firmware uses OTA1 address of 0x10000, while the board you've chosen has it at 0xC000 - it's incompatible with WBR3.

As you've noticed, support is in progress. The WBR3 board (with correct offsets) is available in feature/realtek-update branch of LibreTiny. If you checkout that branch (I believe you can use version: dev under framework: and then add source: https://github.com/libretiny-eu/libretiny#feature/realtek-update, or something similar) you'll be able to use board: wbr3.

That being said, when RTL8720CF support rolls out, it will automatically adjust flash addresses to match the chosen board code (same will be done for RTL8710BN shortly).

[nmschulte]

The WBR3 board (with correct offsets) is available in feature/realtek-update

You rock. I'll give it a whirl.

[nmschulte]

You rock. I'll give it a whirl.

Success!

INFO Successfully uploaded program.
INFO Starting log output from /dev/ttyACM1 with baud rate 115200
[12:10:22]
[12:10:22]Boot Loader <==
[12:10:22]
[12:10:22]== RAM Start ==
[12:10:22]I [      0.000] LibreTiny v1.4.1+sha.d41d328 on wbr3, compiled at Nov  2 2023 11:53:56, GCC 10.3.1 (-Os)

[12:10:33]Interface 0 IP address : 192.168.1.176[I][wifi:560]: WiFi Connected!

[12:10:33][D][wifi:569]: Disabling AP...
[12:10:33][C][ota:097]: Over-The-Air Updates:
[12:10:33][C][ota:098]:   Address: thermostat.local:8892
[12:10:33][C][api:025]: Setting up Home Assistant API server...
[12:10:33][I][app:062]: setup() finished successfully!
[12:10:33][I][app:102]: ESPHome version 2023.11.0-dev compiled on Nov  2 2023, 11:51:43

[12:10:33][C][lt.component:013]: LibreTiny:
[12:10:33][C][lt.component:014]:   Version: v1.4.1+sha.d41d328 on wbr3, compiled at Nov  2 2023 11:51:25, GCC 10.3.1 (-Os)
[12:10:33][C][lt.component:015]:   Loglevel: 3
[12:15:22][I][ota:117]: Boot seems successful, resetting boot loop counter.
[12:15:22][D][lt.preferences:104]: Saving 1 preferences to flash...
[12:15:22][D][lt.preferences:132]: Saving 1 preferences to flash: 0 cached, 1 written, 0 failed

---

WiFi shortly there-after disassociated but subsequently reconnected:

[12:15:48]wifi link err:001f0002
[12:15:48]dissconn reason code: 4
[12:15:48]receive deassoc
[12:15:48]handshake done, connected stage, recv deauth/deassoc

[12:15:52]Interface 0 IP address : 192.168.1.176[W][component:214]: Component wifi took a long time for an operation (4.33 s).
[12:15:52][W][component:215]: Components should block for at most 20-30ms.
[12:15:52][I][wifi:560]: WiFi Connected!

[12:15:52][D][wifi:569]: Disabling AP...
[12:15:52][W][component:214]: Component wifi took a long time for an operation (0.06 s).
[12:15:52][W][component:215]: Components should block for at most 20-30ms.

---

And later, after another (minutes after) diss-/re-assoc; perhaps this is expected, as I'm unfamiliar w/ ESPHome and didn't do anything but let the code run:

[12:25:33][E][api:128]: No client connected to API. Rebooting...
[12:25:33][I][app:127]: Forcing a reboot...
[12:25:33]trace task is needed to print trace log
[12:25:33]hci_uart_deinit: deinit c}ll twice
[12:25:33]
[12:25:33]== Rtl8710c IoT Platform ==
[12:25:33]Chip VID: 5, Ver: 3
[12:25:33]ROM Version: v3.0
[12:25:33]Test Mode: boot_cfg1=0x20
[12:25:33]Download Image over UART2[tx=16,rx=15] baud=115200

[nmschulte]

If you checkout that branch (I believe you can use version: dev under framework: and then add source: https://github.com/libretiny-eu/libretiny#feature/realtek-update, or something similar) you'll be able to use board: wbr3.

Initially, I hacked my way through this, unaware that I could specify these things in the device YAML; I platformio install'd the libretiny branch, and then manually ran generate_components.py and patched ltchiptool. But, to use this mechanism, one must specify like so in the device YAML, to have PlatformIO/ESPHome automatically pull the correct version:

rtl87xx:
  board: wbr3
  framework:
    version: 0.0.0
    source: https://github.com/libretiny-eu/libretiny.git#feature/realtek-updates

Mainly, version needs to be a proper semver, and cannot match something listed in ARDUINO_VERSIONS, otherwise this error arises:

Framework version needs to be explicitly specified when custom source is used.

It seems the trend is to use a version: 0.0.0 spec in this kind of scenario.

I guess ltchiptool could be installed in the same way w/ platformio install https://github.com/libretiny-eu/ltchiptool.git#feature/flasher-update (or perhaps pip install git+https://github.com/libretiny-eu/ltchiptool.git#feature/flasher-update); I still manually patched whichever instance is in use.

[nmschulte]

Also, it seems the firmware insists on outputting to UART2 (LOG_TX / LOG_RX), messages from WiFi driver: [Driver]: ....

As well, I can't seem to configure ESPHome to output on the other exposed UART (TXD / RXD; 13 and 14 I believe). This is stumping me.

[nmschulte]

After modifying libretiny to define PIN_SERIAL0_RX and PIN_SERIAL0_TX, I now have a Tuya Climate device working seemingly well on the WBR3. Kudos!

[kuba2k2]

UART2 is the default port for log messages, same applies for Tuya firmware. Why did you need to change it, and how did you try to do so? Setting LT_UART_DEFAULT_PORT to 0 or 1 should redirect all UART output to that port. If you need to get rid of the WiFi messages specifically, try using LT_UART_SILENT_ALL.

PS I notice that PIN_SERIAL0_RX_0 is defined instead; this is because WBR3 has two GPIOs which can be used as Serial0 pins. i assume that your issue is that Serial0 is not defined because of the additional _0 suffix. This has been fixed on feature/i2c-spi branch already, and thus will be available on the master branch at some point.

[nmschulte]

UART2 is the default port for log messages, same applies for Tuya firmware. Why did you need to change it, and how did you try to do so?

I didn't need to change the logging UART. Though, because I was unable to use the other UARTS (HW_UART1 and HW_UART2, because the hardcoded checks against PIN_SERIALn_RX/..._TX, which seem to default to -1/255), I did try disabling the logging and connect this UART (HW_UART2) to the Tuya comm interface ... but because the WBR3 firmware/driver outputs to/configures it regardless, this failed (ME81H seems to require 9600 baud, as well).

Then, I noticed in the debug output that the UART0 and UART1 RX/TX pins were outputting as -1/255 (due to falling into SoftwareSerial) and so discovered the issue that feature/i2c-spi purportedly resolves; I couldn't find any uses of PINS_SERIALn_..., and so just jammed in PIN_SERIAL0_... with 13 and 14, and then ESPHome/LT picked up the Tuya uart: YAML and configured the correct UART for Tuya comms (UART0; WBR3 TXD/RXD pins).

diff --git a/boards/variants/wbr3.h b/boards/variants/wbr3.h
index 40f6595..d40a1d5 100644
--- a/boards/variants/wbr3.h
+++ b/boards/variants/wbr3.h
@@ -28,8 +28,10 @@
 // ------------
 #define PIN_SERIAL0_RX_0 12u // PIN_A12
 #define PIN_SERIAL0_RX_1 13u // PIN_A13
+#define PIN_SERIAL0_RX   13u // PIN_A13
 #define PIN_SERIAL0_TX_0 11u // PIN_A11
 #define PIN_SERIAL0_TX_1 14u // PIN_A14
+#define PIN_SERIAL0_TX   14u // PIN_A14
 #define PIN_SERIAL1_CTS  4u  // PIN_A4
 #define PIN_SERIAL1_RX_0 2u  // PIN_A2
 #define PIN_SERIAL1_RX_1 0u  // PIN_A0

Setting LT_UART_DEFAULT_PORT to 0 or 1 should redirect all UART output to that port. If you need to get rid of the WiFi messages specifically, try using LT_UART_SILENT_ALL.

The build is already proceeding w/ these defines, yet the WiFi output still persists. This is not an issue though as it's on the logging UART: -DLT_UART_SILENT_ALL=1, -DLT_UART_SILENT_ENABLED=1

[ferbulous]

Hi @nmschulte just wondering how stable is LT running on the thermostat since?

[nmschulte]

Admittedly I haven't yet put it into production, only had it running for about a day trial during the above. It dropped WiFi a few times, but re-authed each time. Seemed to have no issues then; I'm just going to put it into service and see how it fares ... soon-ish (maybe a week or two) I should be able to install it and give better feedback.

Have the branches merged yet? I assume not; am hesitant to alter my dev. environment until then.

[ferbulous]

It dropped WiFi a few times, but re-authed each time.

How frequent did that happen and does it stay offline for too long before reconnecting?

[nmschulte]

How frequent did that happen and does it stay offline for too long before reconnecting?

I only noticed less than a handful of times, and it basically immediately reconnected each time. I wasn't sure the cause. Admittedly, I didn't pay it much mind; the overnight test, showed no issues with the temperature history displayed in HASS.

[rtorrente]

Hello,

I just saw a new tuya module to control a pellet stove today. It is based on WBR1

I tried to flash ESPHome. I used generic-rtl8720cf-2mb-992k to compile ESPHOME. It work fine and I can flash, but I have the same HASH Result incorrect as for the WBR3 above in this issue.

I presume it's the same problem of offset as WBR3. Unfortunately, I think I'm unable to make the same commit as you made for WBR3 but i I can provide some informations about the module to help in development of this lib

Here is the OEM Dump

Flash : ltchiptool_ambz2_2023-12-11_13-15-16.bin.zip

Rom : ltchiptool_ambz2_2023-12-11_19-39-16_rom.bin.zip

[kuba2k2]

You can use the dev branch. In my post about offsets there are instructions what should be added to your ESPHome YAML.

[nmschulte]

instructions what should be added to your ESPHome YAML.

I shared what I found to work here (it has specifics): https://github.com/libretiny-eu/libretiny/issues/44#issuecomment-1791694851

I still had to do the serial modification; the spi-i2c branch didn't seem to have what I needed, but maybe my config was wrong or I misunderstand somehow.

Also, I haven't put my device in to service yet; still waiting ... but I'm confident it will work fine.

[rtorrente]

You can use the dev branch. In my post about offsets there are instructions what should be added to your ESPHome YAML.

Sorry, I didn't realize that the instructions for WBR3 would maybe work with WBR1 as I don't see WBR1 in your commit in feature/realtek-update. I'll test with board: WBR3 tonight and report back here.

[rtorrente]

I can confirm that the WBR1 boot fine with WBR3 config from the dev branch after flashing. Offset seems identicals

For the moment, this board is a spare part for me, so do not hesitate if you need any tests that can help to push support for RTL8710Cx forward

[craggyh]

Sorry if I sound stupid here but I can’t get esphome to see wbr3 as a valid board type.

Can someone give brief instructions on how they got the necessary version of esphome installed?

thanks.

[rtorrente]

Sorry if I sound stupid here but I can’t get esphome to see wbr3 as a valid board type.

Can someone give brief instructions on how they got the necessary version of esphome installed?

thanks.

Hello,

Here is my code in yaml

rtl87xx:
  board: wbr3
  family: rtl8720c
  framework:
    version: 0.0.0
    source: https://github.com/libretiny-eu/libretiny.git#feature/realtek-update

I had the same problem as you before put family: rtl8720c

[kuba2k2]

WBR1 and WBR3 (and all Tuya RTL8720CF boards) are identical except for the pinouts, so they will run fine. Generic rtl8720cf has a different offset, since it's meant for BW15 board (which has a separate definition too).

[craggyh]

@rtorrente That worked :-) I was able to compile esphome firmware without issue. However, when I try to install the firmware with ltchiptool it fails after about 5% write with this error:

send error: expected ACK; got b'\x15' for block 16

Anyone seen this before or know the reason?

[craggyh]

How are you guys writing the firmware to the modules? Are you using ltchiptool or something else?

[nmschulte]

How are you guys writing the firmware to the modules? Are you using ltchiptool or something else?

Yes, ltchiptool works fine for me (though on Linux I need a different version, which I manually patched in-place because I'm unsure how to specify a different version/branch to use for platformio).

https://github.com/libretiny-eu/libretiny/issues/44#issuecomment-1789939635:

After fixing up ltchiptool to support Linux (https://github.com/libretiny-eu/ltchiptool/pull/13) ...

[craggyh]

What board are you flashing? RTL8710CM or RTL8720CF? Mine is a CM, maybe that's the issue!

[uioi]

I have a TP-Link Tapo P100 smart plug which has a RTL8720CF. Tried board:generic-rtl8720cf-2mb-992k, got the "Hash result incorrect" message on boot. Then I tried board: WBR3 with the following:

rtl87xx:
  board: wbr3
  framework:
    version: 0.0.0
    source: https://github.com/libretiny-eu/libretiny.git#feature/realtek-updates

The device can boot and connect to WiFi. But I can't switch the relay on. I tried all GPIO from 0 to 23. None of them switch on the relay or the LED indicator.

Any thoughts?

[nmschulte]

Any thoughts?

https://www.youtube.com/watch?v=P8cm8HFuG6s

Though it looks like it may differ by specific model, though I expect the GPIO is the same (no idea why they'd change it): https://www.youtube.com/watch?v=99iAK1JeAeo

[uioi]

Did you make it work with ESPhome? What is your gpio configuration for the relay, LED, and button?

[uioi]

I've successfully compiled and ran the PinScan example (amazingly helpful, btw!) and flashed libretiny-esphome on a RTL8710CM with your recent changes.

Everything I was able to test seems to work using the generic-rtl8720cf-2mb-992k board (with the exception of esphome OTAs, but it doesn't look like OTAs are implemented for any of the libretiny-supported RTL MCUs at the moment). The boards I'm playing with (TP-Link EP25/KP125 Smart Plugs) are extremely simple though so outside of WiFi & GPIOs there isn't much. Only minor issue is I cannot seem to read the onboard BL0937 (see: HLW8012). I might have it configured incorrectly, though; I need follow the traces again and/or try interfacing directly instead of using esphome.

It seems compiling a project with PlatformIO and/or libretiny doesn't pull in the AT command CLI from the SDK. Is there a configuration option and/or flag I've glossed over that enables it? This would allow use of the built-in OTA functionality. I had to flash the flash.bin image directly onto the SPI flash because the EP25s refuse to go into UART download mode (even after flashing a libretiny-built project).

How can you use pinscan? I want to find the correct pin in a TP-Link Tapo P100 smart plug which has a RTL8720CF.

[Rain]

How can you use pinscan? I want to find the correct pin in a TP-Link Tapo P100 smart plug which has a RTL8720CF.

Ensure you have PlatformIO installed. Review the Quick Start Guide if you haven't used PlatformIO directly before.

Clone the PinScan repo. Edit src/pinscan.h and change USE_WIFI to 1 and enter your WiFi information into WIFI_SSID/WIFI_PASS. Add the following to platformio.ini:

[env:rtl8720cf]
board = generic-rtl8720cf-2mb-992k

You should then be able to build by running pio run -e rtl8720cf. Flash the firmware to the device you're working with. Let it connect to your WiFi network (monitor your DHCP server to figure out what IP address it got). You should then be able to telnet into the device and use PinScan as described in the README.

Be careful what pins you manipulate arbitrarily, though. Don't have the device plugged into the mains when manipulating it. Power the 3.3v rail only (as you would when flashing). There may be pin configurations that damage/break the device; I'd highly recommend tracing the PCB traces as much as possible before switching random pins to OUTPUT and toggling them on and off.

---

As an aside, how difficult was it to get into the TP-Link Tapo P100? The TP-Link EP25/KP125 Smart Plugs were an absolute pain to open without causing visible damage. Maybe with practice you could do it. They seem like great plugs that are well-built. With libretiny, Esphome seems to run great. I'm waiting on OTA support before I can really start using them, though.

[uioi]

How can you use pinscan? I want to find the correct pin in a TP-Link Tapo P100 smart plug which has a RTL8720CF.

Ensure you have PlatformIO installed. Review the Quick Start Guide if you haven't used PlatformIO directly before.

Clone the PinScan repo. Edit src/pinscan.h and change USE_WIFI to 1 and enter your WiFi information into WIFI_SSID/WIFI_PASS. Add the following to platformio.ini:

[env:rtl8720cf]
board = generic-rtl8720cf-2mb-992k

You should then be able to build by running pio run -e rtl8720cf. Flash the firmware to the device you're working with. Let it connect to your WiFi network (monitor your DHCP server to figure out what IP address it got). You should then be able to telnet into the device and use PinScan as described in the README.

Be careful what pins you manipulate arbitrarily, though. Don't have the device plugged into the mains when manipulating it. Power the 3.3v rail only (as you would when flashing). There may be pin configurations that damage/break the device; I'd highly recommend tracing the PCB traces as much as possible before switching random pins to OUTPUT and toggling them on and off.

As an aside, how difficult was it to get into the TP-Link Tapo P100? The TP-Link EP25/KP125 Smart Plugs were an absolute pain to open without causing visible damage. Maybe with practice you could do it. They seem like great plugs that are well-built. With libretiny, Esphome seems to run great. I'm waiting on OTA support before I can really start using them, though.

I successfully flashed the PinScan example. (I need to use the board= wbr3 and feature/realtek-update branch though. Otherwise, it boots with a hash error).

However, by using the PinScan tool, I still cannot find the GPIO of the relay or the status LED. Very weird.

The TP-Link Tapo P100 is also very hard to open.

[Rain]

I successfully flashed the PinScan example. (I need to use the board= wbr3 and feature/realtek-update branch though. Otherwise, it boots with a hash error).

However, by using the PinScan tool, I still cannot find the GPIO of the relay or the status LED. Very weird.

I'm glad you got it flashed. It definitely took some fiddling to figure out the pinout and PinScan over telnet was a bit finicky. Two things to keep in mind:

• If you're powering the device from a USB UART adapter, it may not provide enough power to drive the relay (ie: you won't hear it click). A multimeter may help.
• The LEDs on these devices are commonly "active low." If you only tried switching pins to OUTPUT and turning them HIGH, also try toggling them to LOW.