Nikobus PC-Link 05-200 via PL2303 USB-serial: discovery (#A) gets no response

[JeanVandamme]

Hi @fdebrus,

I’ve spent significant time diagnosing a PC-Link inventory issue and have isolated it quite precisely — hoping this detailed report helps figure out what’s going on.

Hardware:

Niko PC-Link 05-200, purchased/installed in 2004, running continuously for 23 years (minus power outages). Firmware shows as “PC Link v3.0” on the LCD at boot.

Connection chain:

PL2303 USB-serial adapter → DB9 (with RTS↔CTS and DCD↔DTR loops) → RJ12 cable → RJ45 patch (structured cabling through the house) → RJ12 → PC-Link. Home Assistant runs in a KVM VM with the PL2303 passed through via USB hostdev (libvirt). What works: - Serial connection establishes successfully (handshake completes, /dev/ttyUSB0 opens fine) - Full electrical loopback test (shorting RxD/TxD at the RJ12 connector that plugs into the PC-Link) returns sent data perfectly — confirms the entire cable chain is electrically sound - The Nikobus bus itself is alive: physical push-buttons and module “mode” buttons trigger visible LED activity on the PC-Link and on the modules - PC-Link is healthy: LCD displays correctly, clock/date accurate, “M” indicator active, Check Error = “No error”

The core problem — and a crucial discovery in the debug logs:

Running “Discover modules & buttons” always times out after 8.0 seconds with “no PC-Link response”. However, looking carefully at the debug logs, I found this:

12:28:16.283 PC-Link inventory enumeration started

12:28:16.292 Bus frame #A ← command sent + echo received

12:28:26.285 inventory-phase finalize ← timeout after 8s, integration gives up

12:28:28.202 Bus frame $10110000B8CF9D ← PC-Link responds ~12 seconds later!

The PC-Link IS responding to #A, but with a delay of approximately 12 seconds — well after the 8-second timeout. By the time the response arrives, the integration has already abandoned the discovery and the frame is treated as an orphan. This same frame $10110000B8CF9D appears identically in two separate debug log captures (taken at different times), suggesting it is always the same module responding consistently.

Questions:

1. Is the 8-second inventory timeout configurable anywhere (config entry, YAML option, or source code constant)?

2. Is $10110000B8CF9D a valid module response frame? Can you confirm whether B8CF9D is the module address?

3. Could the “PC-Link is older than Gen 3” option affect the timeout duration or response format expected?

I’m happy to run any further tests — I have full serial access and can reproduce this reliably.

Thanks for the great integration and for your time

[fdebrus]

Whaou, what a debug thanks that helps a lot. let me deep dive and revert

[fdebrus]

Could you provide your full installation inventory ? I'm after your modules references... you might not be able to use discovery with previous generation modules, but there is other way to get the integration setup. Let's first confirm all your module generation.

Can already tell your PCLink is not answering, answer are $18 prefix not $1011, see nikobus-connect/nikobus_connect/const.py at main · fdebrus/nikobus-connect

$10110000B8CF9D seen on the wire is the handshake being retried from the integration as it fails to connect

COMMANDS_HANDSHAKE: Final[list[str]] = [
    "++++",
    "ATH0",
    "ATZ",
    "$10110000B8CF9D",
    "#L0",
    "#E0",
    "#L0",
    "#E1",
]

If you get nothing back from #A specifically, that points to the gen-1/2 firmware (LCD "v3.0" is the software version, not necessarily the bus protocol generation) not implementing the bulk inventory broadcast that newer PC-Links do.

Find out why it reconnects. The handshake reappearing means the link dropped. Worth checking: HA debug log for a disconnect/reconnect around 12:28:2x, the PL2303 USB-passthrough stability under libvirt (cheap PL2303 clones + KVM hostdev are a known source of mid-session drops), and whether the DB9 RTS↔CTS / DCD↔DTR loopback is actually satisfying the driver (the lib opens with rtscts=False, dsrdtr=False, so those loops shouldn't be needed but a half-working loop can confuse some PL2303 clones).

We should start by your module reference, to understand if they are Gen 1 / 2 or 3. No worries, we can still setup your integration to talk to module prior Gen3 you would be able to turn/on/off dimmer, use shutters but not advanced features.

Suffix on the label	Generation
none or -01	1st gen
-02	2nd gen (e.g. switch 05-000-02, roller 05-001-02, dimmer 05-007-02)

[JeanVandamme]

Hi @fdebrus,

Here is my full installation inventory:

• 1 × 05-200 (PC-Link)
• 3 × 05-000-02 (12-channel switch module, Gen 2)
• 1 × 05-008-02 (4-channel switch module, Gen 2)
• 2 × 05-707 (bus coupler/power supply)
• 30 × 05-064 (push buttons)

So all output modules are Gen 2 (-02 suffix).
Looking forward to your guidance on manual configuration!

[fdebrus]

You need to be on a release 1 version; fdebrus/Nikobus-HA at 1.0.0

Read the doc about "nikobus_module_config.json", that is the one manual file you need.

Install V1
create the nikobus_module_config.json with all your module data
check that you can manipulate module outputs in HA

from there we will updgrade to V2 and get some automation going, but let's secure V1 first.

you have a manual config file example here: Nikobus-HA/custom_components/nikobus/nikobus_module_config.json.default at 1.0.0 · fdebrus/Nikobus-HA

Post your file for my review once completed, we will then go for V2 then V3...

[JeanVandamme]

Hi fdebrus,

Following your advice, I have now installed v1.0.0 and I'm ready to create the nikobus_module_config.json manually.

My installation:

• 3× switch module 05-000-02 (12 channels each)
• 1× switch module 05-008-02 (4 channels)
• 2× bus couplers 05-707
• 30× push buttons 05-064
• PC-Link 05-200 connected via PL2303 USB-serial adapter → /dev/ttyUSB0 in HAOS VM (KVM/libvirt on Fedora)

To fill in the module addresses in the config file, I tried the classic method: press and hold the yellow mode button on each module to trigger its identification frame on the bus, while listening on /dev/ttyUSB0 with:

stty -F /dev/ttyUSB0 9600 cs8 -cstopb -parenb raw && cat /dev/ttyUSB0 | xxd

Unfortunately nothing appears on the serial port — not from push button presses either (though the PC-Link LCD shows no error, mode is 'M', and the bus is active: push buttons do control the modules normally).

A loopback test (RxD↔TxD bridged at the RJ12 end) was successful, confirming the full electrical chain is healthy.

So my question is: given that our Gen 2 modules don't support automatic discovery via #A, and passive serial listening yields nothing, is there an alternative method to retrieve the module addresses? Could the Nikobus PC software be used for this, or is there another approach you would recommend?

Thank you for your continued support!

[JeanVandamme]

Hi fdebrus,

Quick update on our progress.

Good news: we managed to retrieve the module addresses without passive serial listening (which still yields nothing on our setup). The Nikobus PC software stores its configuration in a .nkb file, which is actually a ZIP archive containing a Microsoft Access database (niko.mdb). Using mdbtools on Linux, we extracted the module addresses from the Component table.

v1.0.0 is installed and we have created the nikobus_module_config.json as you suggested. Here it is for your review:

{
    "switch_module": [
        {
            "description": "Switch Module M1",
            "model": "05-000-02",
            "address": "24BB",
            "channels": [
                {"description": "Spots extérieurs garage", "led_on": "", "led_off": ""},
                {"description": "Spots exterieurs bureau", "led_on": "", "led_off": ""},
                {"description": "Spots terrasse exterieure", "led_on": "", "led_off": ""},
                {"description": "Spots Terrasse couverte", "led_on": "", "led_off": ""},
                {"description": "Spots extérieurs Coté living", "led_on": "", "led_off": ""},
                {"description": "Plafonnier WC R d c", "led_on": "", "led_off": ""},
                {"description": "Eclairage garage", "led_on": "", "led_off": ""},
                {"description": "Chevet chambre Etage Fabienne", "led_on": "", "led_off": ""},
                {"description": "Chevet chambre Etage Jean", "led_on": "", "led_off": ""},
                {"description": "Eclairage dressing", "led_on": "", "led_off": ""},
                {"description": "Eclairage grenier", "led_on": "", "led_off": ""},
                {"description": "Spots ESCALIER", "led_on": "", "led_off": ""}
            ]
        },
        {
            "description": "Switch Module M2",
            "model": "05-000-02",
            "address": "242C",
            "channels": [
                {"description": "Plafonnier Bureau", "led_on": "", "led_off": ""},
                {"description": "Applique G ch R d Ch", "led_on": "", "led_off": ""},
                {"description": "Applique DR ch R d Ch", "led_on": "", "led_off": ""},
                {"description": "Applique Hall 1", "led_on": "", "led_off": ""},
                {"description": "Applique Hall 2", "led_on": "", "led_off": ""},
                {"description": "Non utilisé M2C6", "led_on": "", "led_off": ""},
                {"description": "Néons living", "led_on": "", "led_off": ""},
                {"description": "Plafonnier Chambre Andrew", "led_on": "", "led_off": ""},
                {"description": "Spots hall rez de ch.", "led_on": "", "led_off": ""},
                {"description": "Plafonnier living", "led_on": "", "led_off": ""},
                {"description": "Plafonnier chambre d'amis etage", "led_on": "", "led_off": ""},
                {"description": "Plafonnier cuisine + spots armoire", "led_on": "", "led_off": ""}
            ]
        },
        {
            "description": "Switch Module M3",
            "model": "05-000-02",
            "address": "2350",
            "channels": [
                {"description": "Lampe murale SDB bas", "led_on": "", "led_off": ""},
                {"description": "Applique SDB Etage", "led_on": "", "led_off": ""},
                {"description": "Spots SDB etage (relay bypass applied)", "led_on": "", "led_off": ""},
                {"description": "Applique tableau living", "led_on": "", "led_off": ""},
                {"description": "Spots couloir étage", "led_on": "", "led_off": ""},
                {"description": "Non utilisé M3C6", "led_on": "", "led_off": ""},
                {"description": "Plafonnier cellier", "led_on": "", "led_off": ""},
                {"description": "Plafonnier ch de coralie", "led_on": "", "led_off": ""},
                {"description": "Spots cuisine", "led_on": "", "led_off": ""},
                {"description": "Plafonnier chambre parents R d Ch", "led_on": "", "led_off": ""},
                {"description": "Spots ext cuis hall de nuit", "led_on": "", "led_off": ""},
                {"description": "Ventilation WC rez", "led_on": "", "led_off": ""}
            ]
        },
        {
            "description": "Switch Module M4",
            "model": "05-008-02",
            "address": "XXXX",
            "channels": [
                {"description": "M4 Canal 1", "led_on": "", "led_off": ""},
                {"description": "M4 Canal 2", "led_on": "", "led_off": ""},
                {"description": "M4 Canal 3", "led_on": "", "led_off": ""},
                {"description": "M4 Canal 4", "led_on": "", "led_off": ""}
            ]
        }
    ]
}

Two remaining questions:

1. The 05-008-02 (4-channel module) address is missing — it was not present in the Nikobus PC database. We also found a 'Dimcontroller compact' entry (address FF30) in the database. Could the 4-channel module be related to this, or is it a separate device we need to locate differently?
2. Passive serial listening on /dev/ttyUSB0 still yields nothing (no frames from button presses, no response to #A). The PC-Link LCD shows no error, mode is 'M', bus is active. Could this be a
3. problem with our setup, or is it expected behavior with Gen 2 modules and this version?
4. We also see in the logs: Length mismatch: expected 25 chars, got 29 (frame: $1A16BB2400000000FF00FFEC8DCD) — so some frames ARE being received, but with unexpected length. Could this be related to Gen 2 module response format?

Thank you!

[fdebrus]

Nice, let's progress.

1- you can clean your file of led_on led_off, this is only needed if you use nikobus button with feedback led. Cleaner to leave them out.
2- remove M4 for now, it might confuse the integration with having no address for the module.

{
    "switch_module": [
        {
            "description": "Switch Module M1",
            "model": "05-000-02",
            "address": "24BB",
            "channels": [
                {"description": "Spots extérieurs garage"},
                {"description": "Spots exterieurs bureau"},
                {"description": "Spots terrasse exterieure"},
                {"description": "Spots Terrasse couverte"},
                {"description": "Spots extérieurs Coté living"},
                {"description": "Plafonnier WC R d c"},
                {"description": "Eclairage garage"},
                {"description": "Chevet chambre Etage Fabienne"},
                {"description": "Chevet chambre Etage Jean"},
                {"description": "Eclairage dressing"},
                {"description": "Eclairage grenier"},
                {"description": "Spots ESCALIER"}
            ]
        },
        {
            "description": "Switch Module M2",
            "model": "05-000-02",
            "address": "242C",
            "channels": [
                {"description": "Plafonnier Bureau"},
                {"description": "Applique G ch R d Ch"},
                {"description": "Applique DR ch R d Ch"},
                {"description": "Applique Hall 1"},
                {"description": "Applique Hall 2"},
                {"description": "Non utilisé M2C6"},
                {"description": "Néons living"},
                {"description": "Plafonnier Chambre Andrew"},
                {"description": "Spots hall rez de ch."},
                {"description": "Plafonnier living"},
                {"description": "Plafonnier chambre d'amis etage"},
                {"description": "Plafonnier cuisine + spots armoire"}
            ]
        },
        {
            "description": "Switch Module M3",
            "model": "05-000-02",
            "address": "2350",
            "channels": [
                {"description": "Lampe murale SDB bas"},
                {"description": "Applique SDB Etage"},
                {"description": "Spots SDB etage (relay bypass applied)"},
                {"description": "Applique tableau living"},
                {"description": "Spots couloir étage"},
                {"description": "Non utilisé M3C6"},
                {"description": "Plafonnier cellier"},
                {"description": "Plafonnier ch de coralie"},
                {"description": "Spots cuisine"},
                {"description": "Plafonnier chambre parents R d Ch"},
                {"description": "Spots ext cuis hall de nuit"},
                {"description": "Ventilation WC rez"}
            ]
        }
    ]
}

so now, in the integration you should have 3 modules and their outputs ? right ? what happen if you try to turn a light on ?

Could you enable debuglog on the integration ? top right corner - 3 dots - enable debug logging
Restart HA, turn on a light, go to settings - log - filter on "niko" - show full log, provide me with that log

[fdebrus]

You should have traffic on the bus, but if the handshake is not succesful, button press will not be emitted on the serial.

Let's see that log

[fdebrus]

bad news, you have physical issue. Look at the received frame.

$1A16BB2400000000FF00FFEC8DCD

Field	Hex	Meaning
Start	$	Frame delimiter
Length	1E (received as 1A)	0x1E = 30 → 29-char frame. Corrupted single bit dropped it to 1A
Function	16	Command code 0x16 = set output states, group 2 (0x15 is group 1)
Address	BB24	Module address, little-endian on the wire → real address 24BB
Payload	00 00 00 00 FF 00	Six channel-state bytes for group 2 (channels 7–12)
Terminator	FF	Fixed payload terminator byte
CRC-16	EC8D	CRC-16/IBM over the data field 16BB2400000000FF00FF — validates
CRC-8	CD	CRC-8/ATM over $1E…EC8D — validates (only with length = 1E)

This confirm with CRC that 1E was expected but in the frame 1A is present.

1A vs 1E is a single-bit flip: 00011010 vs 00011110, XOR = 0x04. One bit got knocked off the length byte in transit.

Everything is fine, except your cabling, and the above confirms it 100%

If the corruption happened in USB transport or VM passthrough, it'd hit a whole USB packet, fail USB's own CRC, and get retransmitted or dropped you'd see byte loss, truncation, or timeouts, not a clean single-bit flip that still satisfies the Nikobus payload CRC. A faithfully-delivered single flipped bit means the corruption happened before the byte entered USB i.e. at the PL2303's UART input sampling the wire. That puts the fault between the PC-Link's UART output and the PL2303's sampling point: the cable chain and the two UARTs' timing.

Prioritised suspects, given your chain:

1. Signal integrity over the structured-cabling run. This is the unusual element and my lead suspect. Cat5e/6 is 100 Ω differential UTP designed for Ethernet; you're pushing single-ended serial through it. If the installer didn't pair each signal (TXD, RXD) with a ground return in its own twisted pair, you get crosstalk and reflections, which produce exactly this kind of occasional bit error that worsens with run length and frame length. The RJ12→RJ45→RJ12 transitions also depend on the pinout being sane.
2. Ground-reference integrity through those same transitions. Single-ended serial is only as good as the common ground between the two ends; a high-resistance or noisy signal-ground path through the patch panels makes every bit's threshold marginal.
3. PL2303 baud/UART accuracy. Many PL2303s in the wild are clones with imprecise baud generation. A small clock mismatch with the PC-Link causes sampling errors that surface as sporadic bit flips, more visible on longer frames. Genuine FTDI is the reliable reference.
4. USB passthrough lowest for this symptom (see above), but still worth eliminating.

The decisive tests, in order:

• Bypass the house wiring. Connect the PL2303 to the PC-Link with a short direct cable, skipping the structured cabling entirely, and watch for length-mismatch errors. This is the A/B test your loopback couldn't be it uses the PC-Link as the real source over a short path. Errors gone → it's the long run. This is the single most informative thing to try.
• Swap the adapter to a genuine FTDI. Rules out PL2303 clone baud/UART issues.
• Capture more mismatch frames. One flip isn't a pattern. If the corrupted bit is always the same position/value (always 1E→1A), that's systematic points at baud sampling or a specific reflection whereas scattered random flips point at noise. This tells us which of the above it is.

[JeanVandamme]

Hi fdebrus,

Following your analysis of the corrupted frame, we ran the direct cable test you recommended as the top priority.

Test setup:

• Laptop (Fedora) connected directly to the PC-Link 05-200 via the PL2303 adapter, a DB9 female screw-terminal adapter, and a short 15cm RJ12 cable
• No structured cabling involved — completely bypassing the house wiring
• Port recognized immediately as /dev/ttyUSB0
• Listening with: stty -F /dev/ttyUSB0 9600 cs8 -cstopb -parenb raw && cat /dev/ttyUSB0 | xxd

Result: absolutely nothing appears on the serial port, even after activating and deactivating about a dozen Nikobus circuits using the push buttons. The PC-Link LCD shows no error, mode is 'M', and the LED on the PC-Link blinks with every button press — confirming the bus is active and the PC-Link sees the traffic.

This is the same behavior we observed before with the full house cabling chain. So the structured cabling does not appear to be the culprit.

This leads us to a question: does the PC-Link 05-200 only forward bus frames to the serial port when it is actively communicating with software (i.e. after receiving the handshake/init sequence), or should it forward frames passively at all times regardless of whether any software is connected?

If it requires an active software session to start forwarding, that would explain everything we have seen so far — the only frame we ever received ($1A16BB24...) appeared precisely while the Nikobus-HA integration was running and sending commands.

Thank you for your continued help!

[fdebrus]

what's the pin out of your cable ? check my post in the forum

Custom Component: Nikobus - Share your Projects! / Custom Integrations - Home Assistant Community

[fdebrus]

Pinout (DB9 female on the PC side → RJ12 at the PC-Link)

RJ12 pins below are numbered clip up, cable pointing away from you, 1–6 left to right. State your own orientation if you redraw this — half the bad cables come from numbering the RJ12 the other way round.

DB9 pin	RS-232 signal	Direction	RJ12 pin
3	TXD (PC out)	→ PC-Link RX	2
2	RXD (PC in)	← PC-Link TX	4
5	GND	common ground	1 (and 3)

[JeanVandamme]

Hi fdebrus,

Here is a full update following your pinout suggestion and our latest tests.

1. Pinout change (DB9 screw-terminal adapter)
We swapped TXD and RXD on the DB9 screw-terminal adapter as per your pinout table (TXD on pin 3, RXD on pin 2). Loopback test confirmed the chain is electrically healthy with the new wiring.

2. Direct cable test (laptop + short 15cm RJ12, no house wiring)
With the laptop connected directly to the PC-Link via the short cable (bypassing all structured cabling), we listened on /dev/ttyUSB0 with:

stty -F /dev/ttyUSB0 9600 cs8 -cstopb -parenb raw && cat /dev/ttyUSB0 | xxd

Result: absolutely nothing received, even after activating and deactivating about a dozen circuits using the push buttons. The PC-Link LED blinks on every button press, confirming the bus is active.

This is the same result as before with the full house cabling. So the structured cabling is not the culprit.

3. Current hypothesis
The only frame we have ever received ($1A16BB24..., the corrupted one you analysed) appeared while the Nikobus-HA integration was actively running and sending commands — never during passive listening alone.

This leads us to believe the PC-Link 05-200 may require a software handshake/init sequence before it starts forwarding bus frames to the serial port. Could you confirm whether this is expected behavior? If the PC-Link only becomes 'active' after receiving an init sequence from the software, that would explain everything we have seen so far.

Thank you!

[fdebrus]

Hello,

Can you use the Nikobus software from the vendor on your laptop ? Does it connects ?

[JeanVandamme]

Hi fdebrus,

I wanted to give you a full update on everything we have done since your last messages, and also take a moment to express how much your support means to us.

Following your diagnosis of the corrupted frame ($1A vs $1E — a single-bit flip), we ran a series of tests to isolate the root cause:

1. Direct cable test (laptop + 15cm RJ12, bypassing all house wiring): no frames received at all during passive listening, even with a dozen button presses. The PC-Link LED blinked on every press, confirming the bus was active. This ruled out the structured cabling as the culprit.

2. Pinout change on the DB9 screw-terminal adapter: we swapped TXD and RXD as per your pinout table. Loopback confirmed the chain was electrically healthy. Still no passive frames received.

3. Native DB9 serial port on the server: we attempted to pass through the server's onboard ttyS0 to the HAOS KVM VM, but QEMU/HAOS silently ignored the ISA serial device — it never appeared in the VM.

4. Raspberry Pi 3 with direct USB connection (no KVM, no passthrough): we flashed a fresh HAOS on an SD card, installed Nikobus-HA v1.0.0, connected the PL2303 directly to the Pi 3, and tested. The result was identical to the KVM setup: NikobusTimeoutError on every command, and the same length mismatch ($1A16BB24... instead of $1E16BB24...).

This last test was the decisive one: with the PL2303 connected natively (no virtualization layer), we still get the exact same single-bit flip. This conclusively rules out KVM/USB passthrough as the cause and points directly at the PL2303 itself.

Based on your earlier analysis — that a clean single-bit flip points to UART sampling issues at the PL2303's input — we have ordered a genuine FTDI FT232R adapter (FTDI US232R-100, ordered from Farnell, expected within 72 hours).

This project has been going on for a while and I have to be honest: integrating my Nikobus installation (installed around 2004, ~40 circuits, 30 push buttons) into Home Assistant is something I really care about. Having my 20-year-old wired home automation system talk to modern HA would be incredible. Your patience, expertise, and detailed analysis have been invaluable — the bit-level diagnosis of that corrupted frame was frankly impressive and gave us a clear direction when we were running out of ideas.

We will report back as soon as the FTDI adapter arrives and we have test results.

Thank you so much for everything, fdebrus. This community is lucky to have you.

Jean

[fdebrus]

may be your bus protocol is V3 and the whole problem is the connection from the start. We could retry V3 as you confirm the nikobus vendor software can connect and read your installation.

let's see

[JeanVandamme]

Hi fdebrus,

Good idea about testing with the official Nikobus PC software — we'll set that up while waiting for the FTDI adapter to arrive.

One practical issue: we no longer have any Windows machine. All our computers have been migrated to Linux (Fedora). So we'll need to either run the software under Wine, or set up a lightweight Windows VM.

We also don't have the installer itself anymore — only the PDF documentation (PHNikobus_FR.pdf). We searched all our backup disks but couldn't find the actual setup file. We found one old link to it (a 2017 Mega.nz link from a third-party blog), but we're cautious about running a 9-year-old executable from an unofficial source.

Do you happen to have a copy of the Nikobus PC software (PHNikobus / 05-202-xx) you could share, or know of a reliable official source? That would let us test directly under Wine on Fedora without relying on an unverified file.

Thank you!

[fdebrus]

you can find all nikobus documentations (official) on my github

Nikobus-HA/documentation at main · fdebrus/Nikobus-HA

Nikobus software is still available on niko site

Software

direct link https://dam.nikocdn.eu/assets/Niko/Software/nikobus_v3.2.3.zip

[JeanVandamme]

Hi fdebrus,

After weeks of testing, we have finally reached what seems to be a dead end, but we are not sure why. Here is the full summary of everything we went through:

Hardware chain
PC-Link 05-200 → RJ12 cable → structured house cabling (RJ12→RJ45→RJ12, ~20m, one floor) → DB9 screw-terminal adapter → USB-serial adapter → server/laptop.

What we tried, in order:

1. PL2303 adapter via KVM/libvirt USB passthrough (HAOS VM on Fujitsu Primergy TX140 S2, Fedora host): NikobusTimeoutError on every command. No frames received during passive listening.

2. Loopback test (RxD↔TxD bridged at the RJ12 end): successful — confirmed the full electrical chain was healthy.

3. Direct cable test (laptop connected directly to PC-Link via 15cm RJ12, bypassing all house wiring): still no frames received during passive listening, even after activating a dozen circuits. PC-Link LED blinked on every button press.

4. Pinout change on DB9 adapter (swapped TXD/RXD as per your recommendation): loopback still OK, no change in behavior.

5. Native DB9 serial port passthrough to HAOS VM: QEMU silently ignored the ISA serial device — never appeared in the VM.

6. Raspberry Pi 3 with direct USB connection (fresh HAOS, no virtualization): identical result — same NikobusTimeoutError, and crucially the same length mismatch ($1A instead of $1E — the single-bit flip you diagnosed).

7. Genuine FTDI FT232R adapter (FTDI US232R, ordered from Farnell): recognized immediately on both Linux and Windows. The length mismatch / bit flip disappeared completely — confirming the PL2303 was indeed causing UART sampling errors. However, NikobusTimeoutError persisted.

8. Official Nikobus PC software v3.2.3 on Windows 11 (wife's PC, native Windows, FTDI adapter, full house cabling): no response from PC-Link.

9. Official Nikobus PC software v3.2.3 on Windows 11, direct connection (FTDI connected directly to PC-Link with short cable, bypassing all house wiring): the software displayed an explicit error message: "PC-Link component not detected".

Where we are
We honestly don't know what to conclude. The PC-Link bus side still works (LED blinks on button presses, modules respond normally to push buttons). But nothing we have tried — different adapters, different OSes, different software, direct connection — has managed to get any response from the PC-Link serial port.

We may have missed something. Perhaps there is a specific initialization sequence, a hardware switch position, or a PC-Link mode we are not aware of. We don't want to conclude the PC-Link is broken when we might simply be doing something wrong.

Do you have any idea what we might be missing? Is there anything specific that needs to be done on the PC-Link itself before it will communicate over RS232?

Thank you again for all your help and patience.

Jean