Custom Component: Nikobus

no no, PCLink and Modules are only query once at installation setup, then only the local HA storage is used.

.storage/nikobus.modules and buttons

check those files, you can now remove your files from the /config directory. No longer needed. Only the .storage ones are used.

Avoid manual update, always use the integration configuration pannel to update.

its not verbose because it’s doing nothing. the file is now useless as it’s imported. Your debuglog is from an integration starts, it just warn the file to be present and useless.

it you run discovery again, you will see the file being imported in the log and the result of the import.

have fun !

@fdebrus

Hi,

I’m trying to integrate an existing Nikobus installation using a Niko PC-Link 05-200, and I’m currently stuck during PC-Link discovery.

I’ve done quite a bit of troubleshooting and I think the situation is now reasonably well isolated.

My setup:

  • Home Assistant OS 18.2
  • Home Assistant Core 2026.8.2
  • Nikobus-HA 3.10.2
  • Niko PC-Link 05-200
  • Dedicated PC running HA OS natively (no VM / Proxmox / libvirt / USB passthrough)
  • Waveshare USB-to-RS232/485 adapter configured for RS232
  • FTDI FT232R chipset (0403:6001)
  • HA detects it correctly as /dev/ttyUSB0
  • 9600 8N1

The physical wiring has been continuity-tested and validated. RS232 idle voltage is approximately -10 V at the PC-Link and approximately -8.7 V at the far end of the structured cabling.

The interesting part is what happens in HA.

The DEBUG log shows:

Connected to Nikobus on /dev/ttyUSB0
Starting Nikobus handshake
Nikobus handshake completed successfully

So the initial PC-Link handshake succeeds.

The integration then sends:

#A

After 8 seconds:

No PC-Link response within 8.0s

The inventory consequently finishes with:

discovered 0 device(s):
0 module(s), 0 button(s), 0 scene(s)

There is another important point: I also tested the official Niko Nikobus software using the exact same PC-Link, wiring and FTDI adapter.

The official software opens the COM port and transmits data, but ultimately reports that the PC-Link cannot be detected.

So the problem does not appear to be specific to Nikobus-HA.

The PC-Link itself appears to be alive on the Nikobus side:

  • LED B lights when there is activity from the Nikobus modules.
  • “Check Error” reports “No Error”.
  • The existing Nikobus installation continues to operate normally.
  • Using “SEND ID (0569)” also produces activity from the PC-Link towards the PC.

I also found a very similar recent case involving a 05-200 where communication was eventually established after switching to FTDI and correcting the USB/VM configuration. In my case, however, I am already using an FTDI adapter and HA OS is running natively, so there is no VM/libvirt/USB passthrough involved.

At this point I’m wondering whether this could be related to the specific generation or firmware of the 05-200 and the discovery/initialisation sequence.

Could you advise what you would check next?

In particular:

  • Is #A expected to work with all 05-200 generations?
  • Could the 05-200 firmware affect the inventory discovery?
  • Does a successful handshake followed by an 8-second timeout on #A indicate a known behaviour?
  • Would a raw RS232 capture of the official Niko software versus Nikobus-HA be the most useful next diagnostic?

I can provide the full DEBUG log and HA diagnostics, and I can also capture the raw serial traffic if that would help.

Thanks for your help!

It looks like you have a problem with your module, not so much the HA integration.
If the official software isn’t able to detect the module it makes sense HA can’t either.

I would suggest trying to fix the Nikobus problem first (possible with Niko if they still give support) and once you can connect with the official software the integration most likely will work as well.

Thanks for the feedback! I totally agree with your reasoning, and I think contacting Niko would normally be the right next step.

I’m posting the issue here mainly because it seems very similar to a few other 05-200 cases that were discussed previously in this thread. In those cases, the initial symptoms also looked like an HA integration problem, but the underlying issue was actually the same problem preventing communication with the official Nikobus software.
So I thought it would still be useful to document the case here and get the community’s/developer’s perspective, especially since I have already gone through quite a few hardware and communication checks.

As for Niko support, unfortunately I’m not very optimistic there. The 05-200 is quite an old product and, as far as I understand, Niko stopped supporting this module many years ago. So I don’t expect much assistance from Niko themselves.

In any case, thanks again for taking the time to look at it and for the suggestion. I agree that getting the official software to communicate with the PC-Link is the key first step, and I’ll keep investigating that side as well.

Was your PCLink pre-owned ? was it used to program your Nikobus ? Until we solve Nikobus PCLink side of things, not much to do in HA.

Thanks for asking. The PC-Link was purchased specifically for the purpose of integrating my existing Nikobus installation with Home Assistant. it comes from a demo box. It was not used to program or configure the original Nikobus installation, so unfortunately I have never seen this particular PC-Link working with the installation before.

That said, the PC-Link itself appears to be operational at least from the bus side. When there is activity on the Nikobus bus, the B/Bus activity LED reacts, and the PC-Link’s Check Error function reports “No Error” The display also appears to be working normally.

I have also tested the “Send ID” function directly from the PC-Link’s buttons. This function can be activated from the PC-Link itself and is shown on its display, and it appears to send the module ID as expected.

So while I cannot confirm that the PC-Link has ever successfully communicated with the Nikobus software, several of its functions appear to be working correctly and it is clearly detecting activity from the Nikobus bus.

This is why I’m trying to determine whether we are dealing with a communication/configuration issue between the PC-Link and the software, rather than a completely dead PC-Link.

Integrating my existing Nikobus installation was actually one of the primary reasons I set up Home Assistant in the first place.The Nikobus system is now quite old and increasingly obsolete, so being able to integrate it with Home Assistant is particularly important to me as a way of preserving and extending the existing installation rather than having to replace the whole system.

So your feedback and help on the PC-Link side is particularly valuable to me, and I’ll continue investigating that side as you suggest.

Thanks again for taking the time to look into this.

ok, so the PCLink was never integrated into your installation and is not aware of your setup. It needs to be integrated using the Nikobus software.

When you connect the PCLink to your laptop are you able to have a working communication ? does the software reports “connected” ?

all the Nikobus documentation is here Nikobus-HA/documentation at main · fdebrus/Nikobus-HA

Nikobus-HA/documentation/PHNikobus_EN.pdf at main · fdebrus/Nikobus-HA

it details how to add a PCLink to an existing installation. I will provide more guidance later. busy day :slight_smile:

Hi fdebrus,

Thanks for pointing me to the Nikobus documentation. I’ve started going through the PHNikobus_EN.pdf, especially the distinction between Load Project Overview and Load Existing Installation. This confirms that our immediate priority is to establish proper communication with the PC-Link before attempting the discovery.

On my installation, I have now verified:

  • L/N power to the PC-Link is correct.
  • B1/B2 are correctly connected.
  • The Nikobus bus is active: the B LED lights while a physical button is pressed.
  • The PC-Link reports no bus error.
  • Send ID also behaves correctly.

So the remaining issue appears to be the PC-Link ↔ PC communication.

I’m going to test this independently with a Windows laptop and a new USB-RS232 adapter:

PC-Link → RS232 → USB/RS232 → Windows → Nikobus v3.2.3

The first test will simply be whether Connect detects the PC-Link. If successful, I’ll then try Load Project Overview.

However, I don’t want to rule out the HA integration at this stage. Our analysis of the Nikobus-HA logs showed that the PC-Link was detected and the handshake succeeded, but the integration then timed out after about 8 seconds. So there may still be an integration/protocol/timing issue involved.

The test with the official software should therefore give us a useful reference point.

Before I proceed, do you have any other suggestions for investigating this? In particular, is there anything specific you would check regarding the RS232 pinout, COM settings, PC-Link initialisation/handshake sequence, or the 8-second timeout in the integration?

Thanks again!

One thing I want to correct before you go further, because it changes how you should read your own HA log: the “handshake succeeded” message does not mean what it appears to mean.

It sends the five or six init commands to the serial port, pauses briefly after each one, and then, regardless of whether the PC-Link replied to any of them, logs “completed successfully.”. The handshake step is really just “did my writes to the serial port succeed without an OS-level error” nothing more because regarless of success or failure at PCLink level, it will never send a feedback.

Focus on getting the Nikobus software talking to your install, HA is next.

check this for the wiring

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

Thanks, that’s a very useful clarification. I understand now that the “handshake succeeded” message only confirms that the serial writes succeeded at OS level, not that the PC-Link actually responded. I’ll therefore focus first on establishing communication with the official Nikobus software and will carefully recheck the RJ12/DB9 wiring against the pinout discussed in the thread. I’ll come back with the results once I have tested the new USB-RS232 adapter.

1 Like

Hi fdebrus,

Thanks again for your help and for pointing me to the documentation. The corrected RS232 wiring did the trick: the PC-Link now communicates properly with Nikobus-HA, and the initial PC-Link inventory completes successfully.

I can now see 53 devices and 90 entities. Interestingly, the integration seems to be discovering the push buttons, but I don’t seem to see the output modules in the list as I expected.

When I run “Load Existing Installation”, however, the module analysis starts and consistently fails at around 7%, after which the connection/diagnostic status becomes unavailable and the progress resets to 0%.

Rather than continuing to troubleshoot HA immediately, I think the best next step is to first get the installation completely cleaned up and documented in the official Nikobus software: modules, buttons, addresses and, most importantly, their existing links.

Once I have a clean and consistent Nikobus project, I’ll retry the HA integration and see how far the discovery and installation analysis gets.

Thanks again — getting the PC-Link communication working is already a major step forward!

1 Like

Hi;
In this post you added a helper to ‘remember’ the state of the inputs.
https://community.home-assistant.io/t/custom-component-nikobus/732832/798?u=marcvz
I had tested it , and it was working.

I didn’t had time to connect everything until now, So I didn’t look at it
Now, I connected the ‘real’ sensors, and have problem, that. it doesn’t work anymore.
None of the A/B helpers change. I have sensors thay are connected to the Logic-module, and also to the Interface-Module, and none of them change. The connection to the modules are correct, since the status is shown correct on the modules screen.
Is the something changed on that part?
I will test tomorrow all 12 imputs in detail again.

Check that the sensor is not disabled ?


if you try, enable debuglog before, we always need it to troubleshoot

All the connection to the module are normaly 1.
When opening a window, the become 0.

I have created the debug-log-file, I opened the window that is connected to the 1st input of the interface, module, an closed it again.
Where can I upload it, because it’s to big for the forum

Open an issue on the GitHub Issues · fdebrus/Nikobus-HA · GitHub

What’s in the making… not ready for testing outside beta users…

Backup your module programming

Every Nikobus switch, dimmer and roller module keeps its complete configuration in its own memory: which button drives which output, in which mode, with which timer. Until now that data only existed inside the module and in whatever project file the installer kept. Many of us no longer have the PC software or the project file.

adds a “Backup module programming” button on the Nikobus Bridge device (also available as the nikobus.backup_modules action). It reads the full memory image of every output module and stores it under config/nikobus_backup/, one .nkm file per module plus a summary.json. Read-only on the bus, nothing is written to any module. Run it once and keep the folder somewhere safe. If a module ever fails, you have its exact programming.

Verify that your modules are healthy

Each module can report its status and a checksum it computes over its own memory. “Verify module programming” (or nikobus.verify_modules) asks every module for that, reads its memory back and compares. Results land on a new Programming health diagnostic sensor, with per-module detail in the attributes, and any module with an EEPROM error or a checksum mismatch raises a Repair issue naming it. On a real installation the checksums match bit for bit on all module types, so a mismatch means something is genuinely wrong.

PC-Link clock

The PC-Link has its own clock, used by the calendar functions of the Nikobus application. It never knew about daylight-saving changes. A new PC-Link clock diagnostic sensor shows it, with the drift against Home Assistant as an attribute, and a Sync PC-Link clock button (or nikobus.sync_pc_link_clock) sets it from Home Assistant’s local time. The sensor re-reads hourly.

Covers that stay calibrated

Any cover motion commanded from Home Assistant that ends at fully open or fully closed sends a stop frame after a configurable delay by channel. That erases the small drift the position estimate accumulates over time. Intermediate positions and an explicit Stop are unchanged.

A roller channel that still carries the discovery placeholder of 30 seconds takes its travel time from the run time programmed into the module itself, so the position model matches the hardware out of the box. A value you set on the channel yourself still wins.

Discovery improvements

Discovery now asks each module how many links it holds and reads exactly that, instead of scanning a fixed band. Dimmer ramp times are decoded as well. This needs nikobus-connect 0.35.1 or later, which HACS installs automatically.

Housekeeping

  • Bridge buttons grey out while any bridge action runs. One bus action at a time.
  • The device-registry deprecation warnings that Home Assistant 2027.8 and 2027.9 started logging are gone.

Upgrade notes

The three new buttons and two new sensors show up on the Nikobus Bridge device.

The backup is a plain memory image and the library documents the layout, so the files remain useful outside Home Assistant.

Restoring a backup into a module is not part of this release. It is technically within reach, but it erases the module before writing. I’m always against writting towards something undocumented, you never know, could work for me, fail for others. Why backup then ? the backup can be loaded into the official Nikobus software and then restored to your modules. To be used only when everything else as failed.

Feedback welcome, especially from installations with module types I do not have myself.

Update on the feedback-module LED import in the BETA

To read a feedback module’s configuration the LED-to-button definitions, the links, and so on the module first has to be switched into “link mode”. That is the same programming mode used to erase and rewrite a module’s memory: it’s the write-enable gateway, not a plain read.

I’m not willing to rely on that. I won’t implement anything that depends on putting an undocumented device into its write mode, however careful the code is the downside if it ever goes wrong is a corrupted module, and that’s not a risk I’ll take on hardware I can’t get official specs for.

So I’m removing the feedback-LED dump from the beta. Everything else stays: switch, dimmer and roller backup and verification (which are plain reads), and the real-time state feedback the module already provides are unaffected. LED trigger addresses can still be set by hand where needed.