Custom Component: Nikobus

fdebrus · December 29, 2024, 4:09pm

0.2.6 is out and has buffer_time = full operation time

fdebrus · January 2, 2025, 7:53pm

The below is my current understanding of how cover operate. It will help further troubleshooting as needed:

No native position feedback from Nikobus
We simulate the position in HA (0–100%) using timing.

Physical (Nikobus) button press

If the cover is moved via a physical button, we typically want HA to “stay out of it.”
Nikobus has its own internal timer to stop powering the relay when it reaches the end of travel.
However, if the cover was already moving due to HA’s command, and then a physical Nikobus command is received, things can get out of sync.
Sometimes Nikobus will respond with 0x03 if it sees an unexpected state (e.g., the cover is moving from HA, but Nikobus doesn’t “know” about it).
Sending a stop command from HA may “reset” or “re-sync” the state in that scenario.

HA commands (open, close, stop, set position)

When an HA user initiates open/close, HA sends the command to Nikobus.
HA does not rely on the Nikobus internal timer in these cases; rather, it sends a follow-up “stop” to free the relay at the end of travel (full open/close) or partial position.
For partial open or close, once the cover arrives at the requested position, a single “stop” is sent.
Do not send extra or duplicate stops.

State 0x03 (Error/Unknown) Handling

If Nikobus is unaware the cover is already moving (or vice versa), it can yield 0x03.
An acceptable workaround is to send a stop from HA to re-sync.
Alternatively, we could try to implement more sophisticated logic to track when/why 0x03 occurred and handle it gracefully (e.g., finalize the cover position, set the state to STOPPED, log a warning, etc.). No the case today.

fdebrus · January 6, 2025, 2:41pm

@MarcVZ could you let me know if you close a cover from OpenHAB and revert the direction with a Nikobus physical button. What is happening ?

I think, unless openHAB has a different logic to be confirmed, we will not get better than current implementation:

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.

alternative would be to fully operate the cover in the opposite direction, but my logic is that if you invert an ongoing movement you want it to stop. Then if you wish to fully operate in this direction, just push a second time.

dewildep · January 7, 2025, 7:16am

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:

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 · January 7, 2025, 7:47am

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 · January 7, 2025, 11:43am

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 · January 7, 2025, 11:50am

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 · January 7, 2025, 7:56pm

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 · January 12, 2025, 1:23pm

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 · January 12, 2025, 4:14pm

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 · January 12, 2025, 4:34pm

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 · January 12, 2025, 4:43pm

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 · January 12, 2025, 4:47pm

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 · January 13, 2025, 12:41pm

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 · January 14, 2025, 12:57pm

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 · January 15, 2025, 5:15pm

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 · January 15, 2025, 5:29pm

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 · January 15, 2025, 7:44pm

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 · January 15, 2025, 8:18pm

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 · January 15, 2025, 9:58pm

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