My Cord One’s silent failure during Octopus setup

I followed Cord’s Octopus instructions

My charger is a Cord One, built on EN Plus hardware. I wanted to use it with Intelligent Octopus Go and followed Cord’s own Octopus onboarding guide. The guide sends owners through EVChargo before completing the setup in the Octopus Energy app. I wasn’t choosing an unrelated platform or trying to invent my own integration.

I could reach the charger’s local web interface and change its network settings. EVChargo reported a successful configuration attempt, yet the charger’s server status remained disconnected. The result on screen gave me no useful explanation of what had failed. I could repeat the configuration, but I still could not complete the connection.

That distinction between accepting settings and connecting to a server became important. A success message from the configuration step was not confirmation that the charger had reached EVChargo. The useful errors were buried in the charger’s logs, outside the app’s normal setup feedback.

The charger did have a working network path. Its logs showed a successful connection to Powerverse, including an accepted OCPP BootNotification. Changing to EVChargo produced failed connections and certificate trust errors. That gave me a way to narrow the fault beyond “check your Wi-Fi”.

The unit reported charger firmware V1.7.739 and gateway firmware V43.178.481. I have kept the full hardware and firmware details in the reference section.

I have omitted the charger serial number, the modem’s identity numbers and my PIN from this public account. None is needed to explain the fix.

I initially contacted EN Plus on 20 October. I asked for the correct update process and compatible firmware, and supplied the versions and connection failures. Support needed the charger online on their platform before they could help with the update. That left me with a circular problem: I needed an update, but first I needed the connection that wasn’t working.

I asked Cord for help. I didn’t get a reply.

I emailed Cord on 19 October to explain that I was following its Intelligent Octopus Go instructions but could not connect the charger to EVChargo. On 22 October, I followed up with the manufacturer’s diagnosis and the certificate/configuration options EN Plus had supplied.

Powerverse directed me to Cord’s technical-support address, so I wrote there too on 22 October. That email included the firmware versions, the working Powerverse connection, the failed EVChargo connection and the certificate issue. I asked Cord to arrange the certificate or configuration change needed to complete its own onboarding process. I also asked whether the charger should remain connected to Powerverse while someone made that change.

As of 26 October 2026, Cord had not replied to my support emails. I had contacted both the general contact address and the technical-support address. This describes my experience during this investigation, rather than a claim about how Cord handles every support request.

Cord’s onboarding page says its team can help owners who get stuck. In my case, the useful diagnosis and eventual instructions came from EN Plus, the manufacturer behind the charger. I was still trying to finish the setup Cord had directed me to use.

EN Plus explained why Powerverse worked and EVChargo didn’t

On 21 October, EN Plus support identified the issue in my logs. The charger was using OCPP SecurityProfile 2, and support said only the Powerverse CA certificate was present. That explained the difference between the working Powerverse connection and the failing EVChargo connection.

They offered two routes: deliver the required communication certificate through the Powerverse platform, or use the platform to set the security profile to 0. I preferred the certificate route because I wanted to retain secure communication. Support supplied an EN-SYSTEM-ROOT-CERT.pem file, but having the certificate file did not give me a documented way to install it locally.

The logs and certificate checks contained several distractions. They referenced Amazon Root CA 1 and an older EN Plus self-signed certificate for ocpp.dev.en-plus.cn, which had expired on 16 February 2024. The EVChargo endpoint presented a certificate issued by Enplus CentralSystemRootCertificate. Reaching the server from a computer did not make the charger trust its certificate.

I also had failures on more than one port. An early attempt on port 33000 included errno 113 and connection errors. Those errors alone are not proof of a certificate problem; support’s diagnosis came from the fuller logs and configuration. The endpoint I was trying to reach for the update was:

wss://ocpp16.evchargo.com:33033/

My working Powerverse endpoint was:

wss://ocpp.powerverse.com:443/

These are the endpoints involved in my investigation. Cord also publishes separate installer commissioning guidance about the Cord platform and Powerverse endpoint. My support emails identified the specific Octopus onboarding guide I was following and asked Cord to confirm the correct route for this charger. I did not receive that clarification from Cord during this investigation.

The next question was whether I could change the setting from the device itself. On 22 October, support explained that I needed a TTL data cable and a local serial connection to the board.

A USB–TTL cable and two three-pin headers

I used a DTECH KJ-6882 USB-to-3-pin TTL serial cable, with 3.3 V signalling. macOS identified its FTDI chip as an FT232R USB UART and exposed a /dev/cu.usbserial-… port. The existing driver could open that port; installing another driver was not the missing step.

EN Plus’s Amazon screenshot showed cables with 3.3 V TTL signals. Some pictured cables also had a red 5 V power lead. Those are different specifications: the voltage of a power lead is not necessarily the voltage of the UART signals. Support’s actual connection instructions used only RX, TX and ground. My three-wire cable did not need a power connection to the charger.

On 23 October, support supplied the baud rate, the wiring picture and the configuration command:

setkey SecurityProfile 0

They specified 115200 baud, and described the cable connections as RX (green), TX (white) and GND (black). The colour descriptions apply to their pictured cable. They are not a universal USB–TTL colour standard.

Inside my charger I found two three-pin headers. CN3 sits beside the small push-button and the mounting screw, near the board edge. CN2 sits below the SIM holder and has RX, TX and GND markings. Support’s wiring photo used CN3. The presence of similar pins on CN2 did not establish that it exposed the same console.

The push-button caused another diversion. Viewed one way round, its marking looked like “LMS”. Rotating and enlarging the photograph showed SW1, printed upside down relative to the surrounding view. I had been trying to interpret a switch reference as an acronym. I found no verified instruction to hold it down or press it to enable this console.

The electrical connection follows the usual crossover: the adapter’s transmitter goes to the board’s receiver, and its receiver goes to the board’s transmitter. Ground connects to ground. A wire labelled TX on the adapter should not go to a board pin labelled TX.

The cable worked. The console still wouldn’t answer.

At first, the terminal stayed blank. We checked that the Mac was using the intended adapter by unplugging it, watching the serial device disappear, then reconnecting it. Some reconnection attempts failed to enumerate the USB device. Once it returned, the correct port opened again.

I found and removed a jumper joining the cable’s TX and RX. A connection like that is useful for a loopback test, but I removed it before connecting the cable to the charger.

With the cable disconnected from the charger, we deliberately joined TX to RX and ran a loopback test. All three 32-byte test patterns came back exactly, at 115200 baud, 8N1 and with flow control disabled. That established that the adapter, cable and Mac driver could transmit and receive independently of the charger.

We also tried other settings while listening: 9600, 19200, 38400, 57600 and 230400 baud, plus parity/data-bit variants at 115200. Those attempts received zero bytes. Once I had readable boot output at the support-specified 115200, there was little reason to keep guessing baud rates.

After reconnecting to CN3 and rebooting, I finally saw readable ESP32 startup messages. That was progress, but it did not prove that the charger was accepting commands. The adapter could receive the charger’s output even if its transmit connection was wrong, or if the application had not enabled command access.

I typed the supplied command. There was no useful confirmation. We tried Return (CR), CR+LF, and LF alone. We tried help. Text appeared in the terminal, but there was no help list, prompt or meaningful error. A question mark on screen briefly looked like a response; I had typed it myself. Echoed text was not evidence that the charger had executed anything.

EVChargo also reported a successful configuration attempt, while the server status remained disconnected. Those are separate results. The app accepting its configuration did not prove a successful OCPP connection, or that the serial security-profile command had changed anything.

The frustrating part was that we now knew the cable worked, and we could read the charger, yet the command still appeared to do nothing.

The full boot capture exposed a separate crash

We left the terminal open and captured a complete power-on sequence. It began with normal flash boot and successful secure-boot verification:

rst:0x1 (POWERON_RESET),boot:0x16 (SPI_FAST_FLASH_BOOT)
secure boot v2 enabled
secure boot verification succeeded

Secure boot is separate from OCPP SecurityProfile. The first checks firmware at startup; the second belongs to the charger’s server-communication configuration. Seeing “secure boot v2 enabled” was not evidence that the OCPP setting had failed to change.

The capture then showed SD-card initialisation, Bluetooth warnings and a web/Bluetooth task starting. Shortly after a log-compression message, the gateway hit an assertion and restarted:

creat_web_check ble task
sZipTask 206 file /sdcard/log/SN[REDACTED]_19700101/00.log size:3746 bytes

assert failed: 0x40096d7a

Backtrace:0x4008158e:0x3ffd1100 0x400921b9:0x3ffd1120
0x400978de:0x3ffd1140 0x40096d7a:0x3ffd1180
0x4009761c:0x3ffd11a0 0x400852df:0x3ffd11c0
0x40097929:0x3ffd11e0 0x4000bbda:0x3ffd1200
0x40002067:0x3ffd1220 0x400020b5:0x3ffd1240
0x401ad238:0x3ffd1260 0x401af425:0x3ffd1280
0x401609e0:0x3ffd12a0 0x40160b37:0x3ffd1410

ELF file SHA256: 7b5b0b863f4ee174
Rebooting...

The second boot reported SW_CPU_RESET and reached the web/Bluetooth task again. The 19700101 directory shows that this log used an unset/epoch-era date at that point. It does not prove a clock fault caused the crash or the certificate failure.

The compression message preceded the assertion; we did not establish causation. Without matching firmware symbols, the addresses alone do not identify the source-level fault. I kept this as a separate finding rather than treating it as the explanation for the silent command interface.

EN Plus supplied the final missing instruction

I replied to EN Plus with the facts: the adapter passed loopback, CN3 produced readable boot messages at 115200, but commands returned no acknowledgement. I asked about the pin order, line endings, SW1 and whether command input needed enabling.

Support’s next reply supplied the step that had been missing from the original procedure:

debugon <YOUR_AP_MODE_LOGIN_PIN>

They explained that the PIN is the charger’s AP-mode login password. It is not the Wi-Fi password of the home network, an invented service password, or a value to copy from somebody else’s screenshot.

Their screenshot showed the command with a space before the PIN, followed by:

password verify successful...

Detailed logs followed that message. The reply gave me the missing debug-authentication step. I could receive boot and Bluetooth output before authenticating, so that output alone had not established that I had the access needed for the supplied procedure.

The sequence EN Plus’s replies gave me was therefore: connect using the specified serial settings, enable debug access with my AP-mode PIN, then issue their setkey SecurityProfile 0 command.

On 26 October I replied to EN Plus to confirm that the charger was now working as I wanted. Support acknowledged the result. I’m grateful for their help; the final reply supplied the detail I needed.

I have not recorded a final firmware-version readback or a separate end-to-end Intelligent Octopus Go test in this note. My closing email records my overall success report; it does not list a separate result for each of those later stages.

The step I would put at the start of the same procedure is specific: authenticate with debugon before trying the supplied configuration command. I would still verify the cable and wiring, but I would not treat silent commands as proof of a broken TX lead before following that instruction. The earlier session did not independently prove why each unauthenticated command went unanswered.

What I wish the setup process had told me

A connection can fail after an app has accepted its settings. In my case, the charger needed to trust a different server’s certificate chain, and EN Plus found that its existing configuration did not provide what EVChargo needed. Re-entering the same settings in the app did not explain or correct that underlying mismatch.

I would have saved time if the setup had exposed the connection error, distinguished “configuration saved” from “server connected”, and directed me to a documented fix for this hardware and firmware. Instead, I downloaded logs, compared certificates, contacted multiple support teams and connected a serial cable to an internal board.

The UART commands are useful to record because another owner may face the same obstacle. The larger issue was getting stuck while following the supplied onboarding instructions, with little useful feedback and no response from Cord. EN Plus did respond, reviewed the logs and supplied the details that brought the investigation to a close.

The connection details in one place

Support described green as cable RX, white as cable TX and black as GND. The wiring photographs in my investigation recorded the physical arrangement I used. Verify your cable’s documentation and your board revision rather than inferring pin functions from those colours.

Opening the port on macOS

List the serial ports:

ls /dev/cu.*

Then open the actual USB serial device at 115200, with screen’s flow control disabled:

screen -fn /dev/cu.usbserial-XXXXXXXX 115200

Replace XXXXXXXX with the suffix shown on your own Mac. To quit screen, press Ctrl + A, then \, then confirm with Y. Only one program should own the serial port at a time.

What I would check before changing anything else

1. Confirm that macOS detects the adapter and that the intended port opens.
2. Test loopback with the cable completely disconnected from the charger. Remove the TX–RX link before reconnecting it.
3. Verify the ground and crossed TX/RX connections against the correct board and cable documentation.
4. Keep the terminal open through startup. Readable output establishes reception, not authenticated command access.
5. Use debugon <your AP-mode PIN> and look for the password-verification response.
6. Follow the manufacturer’s instruction for the intended configuration change. Check the resulting connection and logs rather than relying on text echo.

We tried CR, CR+LF and LF before discovering the missing debug login. This investigation does not establish which line ending the authenticated parser requires. Nor did support document a save command, a readback command or a required post-change reboot. I have not filled those gaps with guesses.

Other owners, related hardware and sources

I searched beyond Cord because EN Plus supplies other branded chargers. That turned up useful evidence, but also enough board differences to make copying a pinout risky.

An EVSwitch / EN Plus Caro owner, posting as demod on Whirlpool on 30 July 2024, described finding TX, RX and GND on the network board, connecting a TTL–USB adapter, receiving command/error responses and using settls false. That is an older command reported by another owner. It is not a proven substitute for the command EN Plus supplied for my firmware.

EVSwitch owner logs in the evcc project show V43.178.555 and the project name EESP32WIIIHome3_7670_V43, plus a writable SecurityProfile value. That is useful corroboration of a related gateway family. The published charger model is 48, while mine reports 207.

The warp-more-hardware project documents an older EN Plus AC011K platform sold under names including Autoaid, Entratek Power Dot Eco and EVSEDO. AXIbox owners also discuss FTDI access. The project documents 3.3 V serial wiring and SW1 reset behaviour for its own target. It does not establish the function or pin order of similarly named connectors on my cellular gateway.

1. Primary evidence for my unit: my emails to Cord on 19 and 22 October; EN Plus support correspondence, 20–26 October 2026; my board photographs; the serial session and boot capture. I have paraphrased the private correspondence, published the necessary command syntax and omitted PINs and device identity numbers.
2. Cord: Octopus onboarding guide. The guide I identified in my support email and was following during the investigation. Also see the separate installer commissioning guidance.
3. DTECH: USB-to-TTL 3-pin cable. FTDI, 3.3 V TTL and virtual COM-port driver background.
4. Whirlpool: demod’s original successful UART report, 30 July 2024. Related EVSwitch/Caro hardware, with settls false.
5. evcc: request to add EN Plus Caro. Owner logs identifying the V43/A7670 gateway family and its configuration.
6. warp-more-hardware: EN Plus AC011K reverse-engineering notes, and AXIbox owner discussion. Useful for related generations, not a pinout guarantee for this one.
7. Espressif: ESP32 boot modes. Normal flash boot and firmware-download mode are different; entering the download bootloader is not the same as unlocking EN Plus’s application console.

This is a record of one charger and the information available during the investigation. It does not establish a universal EN Plus service procedure, a fix for the incidental assertion failure, or that every related brand accepts the same commands.