Subject: Success! Communication established — Nikobus-HA now controlling circuits correctly
Hi fdebrus,
First, my apologies for the silence over the past several days — I had to be away and wasn’t able to follow up sooner.
I wanted to share very good news, and to thank you again for your patient guidance and unwavering motivation throughout this — it’s made all the difference in finally getting here.
Wiring — confirmed and validated
I measured directly on the PC-Link’s RJ12 connector with a multimeter (nothing connected on the PC side):
-
Continuity between two pins confirmed the GND pair (0.002 Ω)
-
Voltage on the remaining pin: -9.97V at rest, confirmed stable by reversing the probes (+9.97V) — consistent with RS232 idle “Mark” state
-
Rx identified by elimination
-
Also confirmed the RJ12 cable itself was straight-through (not reversed)
Result matched your proposed mapping exactly: Green->DB9 pin 2 (RxD), Black->DB9 pin 3 (TxD), Red+Yellow->DB9 pin 5 (GND). I also validated this over the house’s structured cabling (RJ12->RJ45->RJ12, full run to the attic) — voltage at the far end was -8.71V, essentially identical to the -8.73V measured right at the electrical panel, so no meaningful signal degradation over that distance either.
A second issue I hadn’t reported yet: a phantom PL2303 hostdev
While troubleshooting, I found that my VM’s libvirt XML config still had the old PL2303 (0x067b:0x2303) defined as a hostdev, left over from before I swapped it for the FTDI. Even though the PL2303 was no longer physically connected, libvirt still tried to present it to the VM, creating a second phantom serial device that competed with the FTDI for /dev/ttyUSB0/ttyUSB1. I removed it via virsh edit (config confirmed clean via --inactive). Worth noting for anyone else in a similar setup: virsh reboot alone did NOT reinitialize the USB passthrough — I had to do a full virsh shutdown + virsh start for the change to take effect.
Confirmed with the official Nikobus software first
Before retesting HA, I connected via the official Nikobus v3.2.3 software on a Windows 11 PC (same FTDI, same wiring) — successfully connected to the PC-Link and read back its stored configuration. This was the first confirmed two-way communication with the PC-Link in this project. Interesting side note: passive listening on the serial port (cat /dev/ttyUSB0) never showed anything, even while operating push-buttons and hearing the relays click — it seems the PC-Link doesn’t transmit spontaneously, only in response to an active connection/query sequence from the client.
Success with Home Assistant
After the hostdev cleanup and a full VM restart, Nikobus-HA started up cleanly, initial sync succeeded (Finished fetching Nikobus data in 2.316 seconds (success: True)), and I tested several light circuits directly from the HA interface (on and off) — all confirmed working visually. The original NikobusTimeoutError no longer appears.
Two questions for you:
-
We’re currently on integration version v1.1 — do you recommend upgrading to a newer version at this point, or is it fine to stay on this one given everything is now working?
-
Any recommendation on how best to monitor/log ongoing command reliability going forward? I noticed there’s no dedicated log line when a turn_on/turn_off command is sent (only for the polling/coordinator side) — not a problem, just curious if that’s intentional.
Next on my side: I want to verify state feedback (does a physical push-button press update the HA toggle automatically?), test more circuits across the other modules (M2/242C, M3/2350), and put together a proper reboot procedure for power-outage recovery (auto-reattach the FTDI, verify the connection came back up, and get a notification if it didn’t).
Thanks again — genuinely glad to finally report a win here.