Great. Glad you got it working. Think it looks pretty good now, well structured and should be easier to look after or debug issues.
Let me know if you need anything else.
BTW, for some reason, I don’t get alerts from this thread, so PM me for anything.
Thank you so much for doing this!
Just bought a house with an old Nikobus system and was able to integrate it with HA in no time!
My favorite thing so far is using the buttons as triggers for other things.
The only issues I have right now:
impacted_module yet, though 
The module works by group of 6 outputs at a time. so a switch module with 12 outputs is updated 6 by 6, even if you change output 1 only, output 1 to 6 will be updated. (nikobus internal ways of working, can’t be changed)
So HA needs to know correct status of the outputs, if you have not set “impacted_module” yet for your buttons, you can be between 2 scheduled refreshes and the output state in HA is not yet in sync.
Changing the output 1 to ON with others first 6 OFF, will send 01 00 00 00 00 00 to Nikobus.
Now you turn on output 2 on a physical button, as you are between 2 refresh cycle and “impacted module” for the button is not defined, HA is unaware yet, will be at next refresh.
Before next refresh, you change output 3 in HA, it will send 01 00 01 00 00 00, so turning OFF output 2 as HA trust the state is OFF as unaware yet you turned output 2 ON by physical button.
I could refresh the module state each time a button is pressed, to make sure I have the latest status from Nikobus, but this is reducing the user experience as integration would be slower to answer to user commands etc… so if you set ALL you button impacted module, you will be fixed.
On the USB side, I would not recommand your solution, but fix /dev/usbxxx. There are many documentation on the matter out there. if you share how you run HA, which platform etc… I could advice.
example how to lock your USB behaviour, give me more details about your setup so I can be more specific
udevadm info --name=/dev/ttyUSB1 --attribute-walk
sudo nano /etc/udev/rules.d/99-usb-serial.rules
SUBSYSTEM==“tty”, ATTRS{idVendor}==“067b”, ATTRS{idProduct}==“2303”, SYMLINK+=“ttyUSBProlific”
sudo udevadm control --reload-rules
sudo udevadm trigger
Hey, thank you for your reply!
I configured the impacted_modules and everything works flawlessly now!
Regarding USB, may I know why you recommend against what I suggested?
FYI, I run HA OS on a rasberry PI. Which means I don’t have access to udevadm.
Seems like “a lot” of people are complaining about this exact problem of USB devices not being stable.
If you want to go that path:
go to /config/custom_components/nikobus/nkbconnect.py
Replace def _validate_connection_string with the below
def _validate_connection_string(self) -> str:
try:
ipaddress.ip_address(self._connection_string.split(':')[0])
return "IP"
except ValueError:
return "Serial"
return "Unknown"
It will allow any string as a serial path, by removing this
if re.match(r'^/dev/tty(USB|S)\d+$', self._connection_string):
Let me know if this works, thanks
Next release will have
if re.match(r'^(/dev/tty(USB|S)\d+|/dev/serial/by-id/.+)$', self._connection_string):
return "Serial"
Which will allow /dev/serial/by-id/(anything) on top of /dev/ttyUSB(digit) and /dev/ttyS(digit)
New release is available
Thank you 
I was actually really curious as to why you advise against using this method.
I just tried the newest version. I can no longer configure the integration at all (even if I use change nothing to the configuration and click submit).
Found the problem, working on
Try to delete the entry and re-create, not update. The problem is within the “update” config not “create”. it will sort it out till new release.
UPDATE: new release with bug fix available
