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