Custom Component: Nikobus

[dewildep]

@fdebrus

0.2.6 is out and has buffer_time = full operation time

Hi, I see some strange behaviour with this version and there are no roller errors logged in the system log about this.

So they just get out of sync and stop moving. And we have to press multiple times on the physical button to fix it.

Normally we have 3 rollers that open via an automation.
But sometimes we open them manually in the morning. The physical buttons are not far away from each other so we press up in room one, up in room 2 and up in room 3.
But most of the time one or 2 of them stop moving after a couple of seconds. No error logged and the state in HA shows they are moving/ opened.

Another thing I noticed is that if an HA automation opens or closes a roller. And we interrupt it via a wall button (all rollers have a 2 button config (open/stop & close/stop). Then it does not work correctly anymore.
You also mention this above:

@fdebrus

In the rare case when you start a cover rmovement from HA and invert it using Nikobus button, the cover will operate in the opposite direction for a couple of seconds and stop.

Anything I can do to better understand what is going on?
Enable debug logging?
Can it be due to the automation? I have one automation that closes 5 rollers when the sun goes down. Sometimes one is still open. Never had this with Nikobus schedules. I already put a 1 second pause between them. But maybe I need to try with 5 seconds or so.

[jhhbe]

those buttons are standard, I ordered them from Reichelt and soldered on new ones for my whole installation. If you want I can look up the reference, it’s a bit more than a year ago and all is still good. I had buttons where the rubbers were so worn out they came off.

[fdebrus]

@dewildep

The physical buttons are not far away from each other so we press up in room one, up in room 2 and up in room 3.

You should be fine with 0.2.7, there was a bug in previous release. operating a cover then taking action on another cover from a Nikobus button where both cover are from the same module would stop the first cover movement.

There are so many scenario’s, I hope I’ve tested and solved them all now

This should also be solved:

I have one automation that closes 5 rollers when the sun goes down.

[fdebrus]

@dewildep

Another thing I noticed is that if an HA automation opens or closes a roller. And we interrupt it via a wall button (all rollers have a 2 button config (open/stop & close/stop). Then it does not work correctly anymore.

Yes, that’s the typical 0x03 error state.

You open or close a shutter from HA, then you interrupt the movement with a Nikobus button. Nikobus is not happy about it, as to Nikobus internal state the cover is not moving (we cannot sync or talk to Nikobus internal state) so everytime you start a movement from HA, Nikobus is not aware (internal state not updated) so if you take action towards that moving cover from Nikobus → 0x03 (Error).

The workaround that it currently in place, is that any “reverting” Nikobus action towards a cover will start to movement in the oppositive direction for 1second and stop the cover.

I could not think of any better and technically possible way to handle this scenario. Now, I’m curious on how the binding from OpenHAB do manage those scenario if it does ? waiting to see if @MarcVZ can still test it for us.

[fdebrus]

Nikobus Cover State Synchronization Issue & Possible Workarounds

Let me summarize it this way:

• Nikobus is not aware that a cover is moving if the movement was triggered from outside Nikobus. This is because we manipulate the output relay, not the internal Nikobus state machine.
• If you interact with the cover using a Nikobus button while it’s moving (triggered externally), it results in a 0x03 state (Error).

Key Implications:

• If a cover is stopped, whether by Nikobus or an external trigger, it can be controlled via a Nikobus button without issue, as both Nikobus and Home Assistant (HA) recognize it as stopped.
• If a cover is moving (triggered externally), Nikobus cannot control it correctly because its internal state is not in sync with reality.

Possible Workarounds:

• There is no direct fix, only a mitigation:
  When HA detects the 0x03 state, move the cover for 1 second and then stop it. This action ensures that both HA and Nikobus revert to a stopped state, bringing them back in sync.

Alternative Approach to Test:

• Instead of sending commands directly to the output relay, define the button controlling the cover in the module config file:

  {
    "description": "not_in_use output_1",
    "operation_time": "00",
    "led_on": "**Button Address to Open Shutter**",
    "led_off": "**Button Address to Close Shutter**"
  }
  

  This method simulates a button press instead of directly controlling the relay, which should update both the output state (relay) and the internal Nikobus state machine.

Note:
This approach is untested. If anyone tries it, please share your findings.

[promy]

I’m currently using a diy arduino based pcb to connect to my Nikobus.
Most of the times it works ok and captures everything, but some buttons are a challenge (something to do with the cut-off voltage).
So i ordered a 2nd hand Feedback module thats arriving next week.

Your plugin provides all of the things that i used (buttons/state and position for the shutters), but i’m missing one: a “virtual” button.
Can i just define a button in the config that does not exist and have it “pressed” by Homeassist when another button is pressed?
I’m using this to use the (left-over) channels on a rollershutter module. If I would use a “real” button i have to use 2 (one for up and one for down).

Update about the Cover State:
I’m new to Homeassist and this binding (but i’m using a diy interface and commands), so i may be getting only a part of the problem, but:
If you emulate a button-press (from Homeassist) to get the shutter up or down, the internal nikobus state will be ok? I guess that now you try to set the module itself?
As far as i know the openhab interface works this way (i think i gave the author some info 10 years ago or so )

[fdebrus]

Hello,

I guess, I’ve not tried, that you can define a non existing button in the config file, then that button address will be sent to Nikobus everytime your trigger it in HA.

have it “pressed” by Homeassist when another button is pressed?

That I do not get what you mean ? could you explain it again ?

If you emulate a button-press (from Homeassist) to get the shutter up or down, the internal nikobus state will be ok?

Yes

I guess that now you try to set the module itself?

Both option exist, you can trigger the module output (set the relay of the module with the downside that the internal Nikobus state is not updated) or send emulated button.

Happy to work together to make the integration more robust send me your feedback. I will try the virtual button out of curiosity.

[promy]

@fdebrus

have it “pressed” by Homeassist when another button is pressed?

Sorry for my english (dutch speaking belgian ), i meant when a real nikobus button is pushed i would like homeassistant to react by sending the code for the virtual one (push the virtual button)

[fdebrus]

You can do that over automation in ha, listen for the nikobus_button_press even that matches the physical button address and as action push the virtual one.

Example to get you started, listen to nikobus_button_press event for the Nikobus button with address 9A93EE then send an open command to Velux cover. You just need to adapt the action to your needs

alias: Velux - OPEN
description: ""
mode: single
triggers:
  - event_type: nikobus_button_pressed
    event_data:
      address: 9A93EE
    trigger: event
conditions: []
actions:
  - data: {}
    target:
      entity_id:
        - cover.volet_escalier
        - cover.volet_corridor
    action: cover.open_cover

[fdebrus]

something like

alias: my automation
description: ""
mode: single
triggers:
  - event_type: nikobus_button_pressed
    event_data:
      address: 404E2C
    trigger: event
conditions: []
actions:
  - action: button.press
    metadata: {}
    data: {}
    target:
      entity_id: button.nikobus_push_button_352a02

or try also with the sensor entity associated with each button as trigger

alias: my automation
description: ""
mode: single
triggers:
  - trigger: state
    entity_id:
      - binary_sensor.nikobus_button_sensor_404e2c
conditions: []
actions:
  - action: button.press
    metadata: {}
    data: {}
    target:
      entity_id: button.nikobus_push_button_352a02

button.nikobus_push_button_352a02 would be here your virtual button to trigger

With event you get more control, as following a button press you can listen for the below events for a specific button address, or all.

nikobus_button_pressed
nikobus_button_released
nikobus_short_button_pressed
nikobus_long_button_pressed
nikobus_button_pressed_1 (button press detected after release for 1 second)
nikobus_button_pressed_2 (button press detected after release for 2 seconds)
nikobus_button_pressed_3 (button press detected after release for 3 seconds)
nikobus_button_timer_1 (Button press detected for 1 second)
nikobus_button_timer_2 (Button press detected for 2 seconds)
nikobus_button_timer_3 (Button press detected for 3 seconds)

[fdebrus]

@MarcVZ

That was also what I was thinking, to take the buffer-time equal to the full cover time of the shutter.

The reason why they are sometime out of sync in my case is that I sometimes still switch to OpenHAB to see that all my automation and items are migrated to HA, but I can image that also in other case they can get out of sync. Maybe when doing a reboot after update HA, and someone press the real button…

There is a downside of operating the cover with a buffer operation time that is equal to the full operation time, here is why

If you operate a cover fully (target 0 or 100) from HA and you press a Nikobus button before the full operation time has passed (buffer), it will not work and generate a 0x03 error. As Nikobus believe the cover is stopped, but the stop command from HA following the operation command has not been sent yet.

This is managed by the integration by sending immediatly a stop command to resync HA and Nikobus. so the next push on the Nikobus button will work, while the first one if before the “buffer” time will always fails.

We will never get it perfect. We just have to know and accept the limitation of integrating something that is not designed to be integrated

[fdebrus]

Release 0.3.0 is out

I needed to refactor the config_flow and others to comply with the latest HA standard.

I also took this opportunity to make most of the component platinium ready Integration quality scale | Home Assistant Developer Docs getting closer to an official integration release.

I advice to delete the integration and re-install, do not touch your config files. only the Integration to be removed and added back. I did it many times without issue but as always, take a BACKUP before

[promy]

Sorry, force of habit: changed it in english:

Has anyone made their own usb-rj11 cable yet? I bought an 05-207 (feedback module) and want to connect it and test it with the nikobus program (v 3.2.3).
However, I get a message that the pc-link (I suspect this may also be a feedback module) is not responding.

The link above is somewhat contradictory…
I have now tested:

• hang the black cable and green cable to GND (from a usb-serial dongle)
• the yellow cable to RXD
• the red cable to TXD

The contradiction is (for me anyway) that the pinnrs on the screenshot does not match the RJ11 plug drawn.
Can anyone tell me how to do it?

PS: i managed to make the cable (by color)

[fdebrus]

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

The Nikobus program from Niko can only be used with a PC-Link not with a feedback module.

The HA integration can be used with both, but if you connect to a feedback module use the refresh rate not the feedback module refresh which can only be used if you connect to a PCLink and the installation has a feedback module. So for your case, do it like this

Leave the checkbox unchecked.

[promy]

Tnx…it’s still a challenge, since i’m trying to run it in docker on a synology.
I managed to install the usb drivers and i’m seeing /dev/ttyUSB0 via ssh.
I gave acces (chmod 777 /dev/ttyUSB0 ), but homeassistant is still telling me “Serieel apparaat niet gevonden of geen toegang”

[fdebrus]

Yeap, been there, done that… moved away from synology for running dockers

It’s just planning for headacke and failure .trust me, buy an small box to run docker aside from syno

At the time, I was using robertklep/dsm7-usb-serial-drivers: Synology DSM 7 USB serial drivers and then check my post in usb-serial-drivers.sh is unnecessary · Issue #7 · robertklep/dsm7-usb-serial-drivers to get the driver persistent after reboot

what’s your homeassistant docker compose ? I guess you are not passing the USB device to the docker container, that would explain the behaviour you have

[Nick4 (Nick)]

FYI: this is an English only forum https://community.home-assistant.io/t/how-to-help-us-help-you-or-how-to-ask-a-good-question/114371#zero-language-3

[fdebrus]

PC-Link has the full Nikobus configuration in memory (eeprom). We could read from all the PC-Link registers and decode.

Does anyone wants to contribute ? bits and bytes, CRC, … lot of fun. let me know.

Example extract from a Register

$2EF5860400000023000080501220000100000047C6F1

Current level of decoding…

2025-01-26 20:54:00.370 DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsing response: $2EF5860400000023000080501220000100000047C6F1
2025-01-26 20:54:00.370 DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Classified Module Type: Switch Module (Bits: 04)
2025-01-26 20:54:00.370 DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Extracted Impacted Module Address: 5012
2025-01-26 20:54:00.370 DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] PC-LINK Address: F586, Module Address: 5012, Module Type: Switch Module
2025-01-26 20:54:00.370 DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Decoded Channels: ['Channel 1', 'Channel 2', 'Channel 6']
2025-01-26 20:54:00.370 DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Decoded Configuration: Channels=['Channel 1', 'Channel 2', 'Channel 6'], Timer=8 seconds, Mode=M01 (On/Off)
2025-01-26 20:54:00.370 DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] PC-LINK Address: F586
2025-01-26 20:54:00.370 DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Impacted Module Address: 5012 (Switch Module)
2025-01-26 20:54:00.371 DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Linked Channels: Channel 1, Channel 2, Channel 6
2025-01-26 20:54:00.371 DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Timer: 8 seconds
2025-01-26 20:54:00.371 DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Mode: M01 (On/Off)

[fdebrus]

making progress on loading the inventory of the Nikobus from the domotic system itself instead of user config file… Still a long way to go, but that’s super cool

DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Dimmer Module (Hex: 03) at Address 006C0E
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: PC Link (Hex: 0A) at Address 00F586
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Roller Shutter Module (Hex: 02) at Address 000591
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Roller Shutter Module (Hex: 02) at Address 000591
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Roller Shutter Module (Hex: 02) at Address 009483
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Switch Module (Hex: 01) at Address 00A5C9
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: PC Logic (Hex: 08) at Address 000C94
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Compact Switch Module (Hex: 31) at Address 00055B
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Switch Module (Hex: 01) at Address 000747
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Feedback Button with 2 Operation Points (Hex: 3F) at Address 004E65
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Feedback Module (Hex: 42) at Address 006C96
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Button with 4 Operation Points (Hex: 06) at Address 80B443
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: IR Button with 4 operation Points (Hex: 0C) at Address 40801C
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: RF Button with 4 operation Points (Hex: 23) at Address 805012
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: RF Button with 4 operation Points (Hex: 23) at Address 801549
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Feedback Button with 4 operation Points (Hex: 40) at Address 002B15
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Button with 4 Operation Points (Hex: 06) at Address 8054C5
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Button with 4 Operation Points (Hex: 06) at Address 80121F
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Button with 4 Operation Points (Hex: 06) at Address 80182F
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Button with 4 Operation Points (Hex: 06) at Address 80848D
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Feedback Button with 4 operation Points (Hex: 40) at Address 006936
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Button with 2 Operation Points (Hex: 04) at Address 8072EF
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: IR Button with 4 operation Points (Hex: 0C) at Address 40C0FE
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Button with 2 Operation Points (Hex: 04) at Address 80FE09
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Button with 4 Operation Points (Hex: 06) at Address 80A61E
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Button with 2 Operation Points (Hex: 04) at Address 80560C
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Button with 2 Operation Points (Hex: 04) at Address 80CCC1
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Button with 4 Operation Points (Hex: 06) at Address 00A0FB
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Button with 4 Operation Points (Hex: 06) at Address 804A0D
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Button with 2 Operation Points (Hex: 04) at Address 80020C
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Button with 4 Operation Points (Hex: 06) at Address 804AFE
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Button with 2 Operation Points (Hex: 04) at Address 804C16
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Button with 2 Operation Points (Hex: 04) at Address 807E12
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Button with 2 Operation Points (Hex: 04) at Address 80D41E
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: RF Button with 4 operation Points (Hex: 23) at Address 80FFFF
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Button with 4 Operation Points (Hex: 06) at Address 809EF3
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Button with 4 Operation Points (Hex: 06) at Address 8040A8
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Switch Interface (Hex: 44) at Address 00DC34
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Button with 2 Operation Points (Hex: 04) at Address 807C15
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Button with 2 Operation Points (Hex: 04) at Address 808214
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Button with 2 Operation Points (Hex: 04) at Address 80D81E
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Button with 4 Operation Points (Hex: 06) at Address 80480D
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Button with 8 Operation Points (Hex: 12) at Address 4056F2
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Button with 8 Operation Points (Hex: 12) at Address 40E0F1
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Button with 2 Operation Points (Hex: 04) at Address 804A05
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Button with 2 Operation Points (Hex: 04) at Address 80C81E
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Button with 2 Operation Points (Hex: 04) at Address 80F8F2
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: Button with 2 Operation Points (Hex: 04) at Address 804C58
DEBUG (MainThread) [custom_components.nikobus.nkbdiscovery] Parsed Module Type: RF Transmitter with 2 Operation Points (Hex: 1F) at Address 80F658

[fdebrus]

does anyone has a Nikobus catalog ? hard to find on internet. I would like to make sure all modules / buttons type are listed with their correct “Model”

    device_types = {
        # Known Device Types
        "01": {"Category": "Module", "Model": "05-000-02", "Name": "Switch Module"},                            # A5C9, 0747
        "02": {"Category": "Module", "Model": "05-001-02", "Name": "Roller Shutter Module"},                    # 0591, 9483
        "03": {"Category": "Module", "Model": "05-007-02", "Name": "Dimmer Module"},                            # 6C0E
        "31": {"Category": "Module", "Model": "05-002-02", "Name": "Compact Switch Module"},                    # 055B
        "04": {"Category": "Button", "Model": "05-342", "Name": "Button with 2 Operation Points"},              # 72EF, FE09, 560C, CCC1, 020C, 4C16, 7E12, D41E, 7C15, 8214, D81E, 4A05, C81E, F8F2, 4C58
        "06": {"Category": "Button", "Model": "05-346", "Name": "Button with 4 Operation Points"},              # B443, 54C5, 121F, 182F, 848D, A61E, A0FB, 4A0D, 4AFE, 40A8, 480D, 9EF3
        "08": {"Category": "Module", "Model": "05-201", "Name": "PC Logic"},                                    # 0C94
        "0A": {"Category": "Module", "Model": "05-200", "Name": "PC Link"},                                     # F586
        "0C": {"Category": "Button", "Model": "05-348", "Name": "IR Button with 4 Operation Points"},           # 801C, C0FE
        "12": {"Category": "Button", "Model": "05-349", "Name": "Button with 8 Operation Points"},              # 56F2, E0F1
        "1F": {"Category": "Button", "Model": "05-311", "Name": "RF Transmitter with 2 Operation Points"},      # F658
        "23": {"Category": "Button", "Model": "05-312", "Name": "RF Transmitter with 4 Operation Points"},      # 5012, 1549, FFFF
        "25": {"Category": "Button", "Model": "05-055", "Name": "All-Function Interface"},                      # 8723, 6621
        "3F": {"Category": "Button", "Model": "05-344", "Name": "Feedback Button with 2 Operation Points"},     # 4E65
        "40": {"Category": "Button", "Model": "05-347", "Name": "Feedback Button with 4 Operation Points"},     # 2B15, 6936
        "42": {"Category": "Module", "Model": "05-207", "Name": "Feedback Module"},                             # 6C96
        "44": {"Category": "Button", "Model": "05-057", "Name": "Switch Interface"},                            # DC34
    }