Custom Component: Nikobus

[Vdbroeku]

Hi,

This might be a trivial question. I tried to automate some of the aspects of HA with voice control. When I ask to put all light out HA will successfully trigger this event but this seems to be a slow operation the system tries to put out all lights one by one. I do have a button near my front door that triggers nikobus itself and that is almost instantly. The specific nikobus event is only triggered when I press the button more than 1 sec. I’m trying to automate the speech event to send nikobus the same event (i.e. shut down all lights) How can I expose the ‘nikobus 1 sec’ button to HA so I can use it in automations? (Maybe it is already exposed and just can’t find it.)

[dewildep]

Hi @reesing322
the captured errors were after pressing real Nikobus buttons. If that is what you mean.

So for the 8 and 4 button push switches, they were pressed physically.
The Nikobus actors (PIR detectors) were also detecting a person.

[dewildep]

For this error:

Message length mismatch: got 13, expected 4 (based on length field 05). message $0512#NFD1182

“Berging - Wasplaats doorgang #NFD1182” (Nikobus 8-button with feedback led) when this one was pushed, the feedback led did not turn on (out of sync)

does that matches what happend:

• i pushed the physical button, the feedback led in the button turned on, but the light itself did not.
• i pushed the physical button again, the feedback led in the button turned off, and the light itself turned on.
• when i left, i pushed the physical button again, the feedback led turned on, and the light turned off

so i left with a feedback status that was not in sync.
this morning, the led was ok (i presume due to a feedback update/refresh)

[fdebrus]

@Vdbroeku Nikobus is for the year 2000 and serial, do not expect today’s technology speed and way of working.

Nikobus was not designed to receive commands by serial, it’s slow, we have to wait command processing and feedback. We are not ‘talking’ to the bus like a physical button but to a serial interface (PCLink or Feedback module). Slow by design.

That’s been said we have way around to mitigate.

1- Look at scene definition, it’s in the github documentation. You can have scene that trigger group of module at once vs one output at a time.

3- ‘nikobus 1 sec’ button, I guess you mean a physical button event that is triggered after 1 second ? back to the github documentation, check firing events where you have many time based trigger for button.

Hope this help get you going, revert with question if any

[fdebrus]

@dewildep

i pushed the physical button, the feedback led in the button turned on, but the light itself did not.

That’s worrying, I’ve designed the integration so it never interfere with any Nikobus command issued from Nikobus.

So If you take a Nikobus action (pushing a button, …) and the expected action, outcome is not happening, nothing to do with HA nor the integration.

I’ve also from time to time to push a physical button twice for the action to happen. This was also happening when Nikobus was not connected to any integration. Nikobus is single command, so 2 commands at almost the same time will fail. I press living light on and wife sofa light on, it fails 100% of the time. Nikobus way of working.

So when this fail, is it then we are getting a $0512button on the bus ??

[fdebrus]

@reesing322

Are you sending ‘button press events’ from your homeassistant itself, to simulate a real button press and trigger the nikobus logic that way?

@dewildep has Feedback Leds, so he is not triggering module outputs but sending simulated button press.

[fdebrus]

@reesing322

As a result, the light in the corridor turns on (as expected) for 2 minutes, but also the lights in the bedroom turn on again (not wanted).

I do not get it, you are only using physical buttons. HA is not supposed to send any commands to Nikobus. It refresh status, not sending any update nor command to Nikobus. So I need to debug that behavior as not expected to happen. HA monitor Nikobus and not send any message unless triggered from HA.

why do you get, if you have only used Nikobus Physical Buttons ?

2025-03-04 08:11:49.923 DEBUG (MainThread) [custom_components.nikobus.nkbcommand] Setting output state - Address: 91AD, Channel: 3, Value: 255

[reesing322]

I use physical buttons, yes, but that second button/press has no config in Nikobus anymore. There is an automation+script in homeassistant for that button/press, and that script will turn on the zigbee bulb, wait for 2 minutes, and turn it off again. Indeed, that logic should not interact with nikobus anymore, as the module out is always on anyway.
On the other hand, even when there is no config in nikobus for hat button, probably still some messages are put on the bus by the button hardware because of the button-press.

[fdebrus]

Could you share your automation code ? I clearly see from the log that a command is sent from HA to Nikobus, which should not happen as you are interacting with Nikobus from physical button, HA shall only monitor and react, eg execute your automation but not send command.

[dewildep]

oh yes, i can confirm this statemant. From before the HA was connected.
If we press a push button on 2 locations at the same time, or somebody is long pressing to dim up or down and another one is pressing a button. This doesn’t always work as expected. Like the bus is full and ignoring the button press.

When you started with the integration the first versions could also excell this behaviour. Disconnecting HA would then solve this because of less traffic on the bus i think. But this is now stable and ok with the current version of the integration.

So maybe we are hitting a Nikobus issue here.

It is possible that my push from yesterday fell togheter with multiple buttons being pressed at almost the same time.
I went to feed the cat and put it outside for the night.
The others went upstairs to go to their room, bathroom, toilet etc…

so maybe a “collision” on the bus generates $0512
i’ll keep an eye on it if i can force it or detect it when it happens.

regarding the feedback led i mentioned. I just checked and i was wrong. It was still out of sync with the Nikobus.
I do have an “all lights out button” that is only defined in Nikobus when i press it 5 seconds. So pressing this one fixes the feedback led status.
When all lights that are behind this “all lights out button” are off, the feedback led of that button is lit, so we can see all lights are out. When one light of the group is on, the feedback led of the “all lights out” button is off.
When the feedback led status of any button is out of sync, then the “all lights off” button is also out of sync. So apparently this is solely relying on the feedback module status.
Hopefully i don’t introduce new complexity by mentioning this since i now mix both the $0512 and the feedback status

[fdebrus]

@dewildep

so maybe a “collision” on the bus generates $0512

Well spotted ! So I keep pressing a Nikobus physical button and then pushed another button, I have 2 physical buttons close enough so I can push both at the same time and indeed I got the $0512button.

Deep diving to understand was it the first button address that was being kept down or the second ? if the second, easy call as Nikobus did not act on the second button (light did not turned on) as it was busy with the first button press we can just ingore that message from the bus as nothing happened.

by the way, keeping pushing a button for a very extended period of time could lead to an error on the Nikobus refresh from HA, as even with a 3 retries on failure if you keep pushing long enough, the refresh will fail as the bus is busy. Very unlikelly to happen, I pushed for a very extended period of time and was unlucky enough to have a refresh happening at the same time.

Timeout getting output state for module 0E6C: Failed to receive ACK and state for command '$10126C0E4E16A4' after 3 attempts.

[reesing322]

By copy-pasting that automation/script, I already noticed I was telling you lies
In the script, the very first command turns on that module output that should be always on anyway. I probably did that ‘just to be sure’, but if that command is not taking into account the new state, the issue I was having is explained.
I’ll disable that first command and observe the situation again.

[fdebrus]

ok, now it make sense. So by pushing the light of the corridor it trigger only an automation, but that automation change the controller 91AD group status which has just been updated by turning off the light in the bedroom.

So the automation send an “obsolete” status to the very same controller group turning on the bedroom light again.

Pushing the bedroom light off triggers a status refresh, it take time, you already loose 0.5 sec of waiting (as defined in const.py) as I need to wait for the controller to reflect its status. Querying the controller right after a button press would give me previous state and not the new state following a button press

REFRESH_DELAY: Final[float] = 0.5  # Delay before retrieving status after button press

Then I need to send a refresh command, wait the feedback, record it in HA.

Overall, I have not timed it, but probably 0.7sec if everything goes as planned, or else 2/3 seconds if I have to retry because the bus is busy.

I do not immediatly see optimization, we have to deal with how Nikobus is designed.

I had similar ‘trouble’ and a moved light to another group of the same module as a workaround.

I have looked at not refreshing the data from Nikobus but trusting an HA internal state following a button press, but it gives more trouble than it solves as we have no way to know if the button press was successfull and trigerred the outcome, so we might end up out of sync.

by the way, even worst for dimmer

DIMMER_DELAY: Final[int] = 1  # Delay before retrieving dimmer status

As dimmer, dim down, I have to wait 1 full second before to get it final status or else I get an interim status and not final state

[reesing322]

In this case it was my own fault, there was no need for that extra command.
And indeed, if we want to keep on using some ancient-old hardware+protocol,
then we have to accept the limitations.

[fdebrus]

I have that old hardware since 2009 and not a single failure, I hear a lot about button fragility, but it has not happened to me yet (I mostly use HomeKit / Siri and automation not so much the physical buttons) and the module hardware never failed me. I only wish that Niko documented their protocol

[fdebrus]

ok, so next release will ignore $0512 or $0517 followed by a Button address

            # Check if the message starts with a refresh command immediately followed by the button command prefix.
            if any(message.startswith(refresh + BUTTON_COMMAND_PREFIX) for refresh in MANUAL_REFRESH_COMMAND):
                _LOGGER.debug("Ignored message: %s", message)
                return

I have checked the bus and when those commands are received, nothing more is happening. My guess so far is that it’s safe to ignore. Which the current release they are just logged as error in HA log, no impact.

Back to decoding 8 buttons payload for the discovery…

[fdebrus]

Hello everyone,

I need your assistance with the following steps. If you are a PCLink owner, please try the below:

1. Backup Your Configuration Files:

• Make sure to create a backup of your module button JSON files found in the config directory. This step is essential to safeguard your current settings.

2. Install the Latest Release:

• Update your system to version 0.5.0 to ensure you have the latest improvements and fixes.

3. Execute the Service Call After Full Startup:

• Wait until Home Assistant (HA) is fully started. Once confirmed, open the developer console and execute the service call query_module_inventory.

Wait a couple of minutes for the process to complete.

1. New File Creation:
   A file named nikobus_module_discovered.json will be generated in your Home Assistant configuration directory.

• Action Required: Open this file and carefully review it for any discrepancies, errors, or missing details—such as a module that isn’t reported.

2. Enhanced Button Information:
   Each of your buttons will now include a new discovered_info section.

• Action Required: Check every button to ensure that:
  • The discovered_info section is present.
  • The information provided is complete and accurate.
  • There are no errors or missing details.
• If you find any button lacking this section or containing incorrect or incomplete information, please report it.

    "nikobus_button": [
        {
            "description": "BT_GF_Living_Sofa_Wall_Light_Up",
            "address": "004E2C",
            "impacted_module": [
                {
                    "address": "0E6C",
                    "group": "1"
                }
            ],
            "discovered_info": [
                {
                    "type": "IR Button with 4 Operation Points",
                    "model": "05-348",
                    "address": "0D1C80",
                    "channels": 4,
                    "key": "1C"
                }
            ],

Finally, please perform the following:

• Review the Logs:
  Check the Home Assistant logs using the regular log filter with the keyword “niko”. There’s no need to enable debug logging.

• Action Required:
  Look through the filtered log output for any errors. If you find any error messages, report them.

I can only validate the discovery process against my own installation. I’d really appreciate feedback from others, especially those using specific modules or unique configurations, to help ensure everything works seamlessly across different setups. Your input will be invaluable for refining the process.

Thank you for your support!

PS/ nothing should happen to your current integration way of working, but like I said, better safe than sorry so DO BACKUP your configuration files.

[MarcVZ]

Hi,

Sorry for the late reply, since I was to busy with other programs
Today I installed the latest release, and now the problem with the wrong-feedback is gone.

II will test it now to see that everything is fine now.
Thank you for this great component.

[fdebrus]

Thank you for those who already provided feedback !

added so far to the discovery

RF Button
RF Remote with 1 push button
IR Button
Switch Interface

I you have more “type” of devices, buttons, not discovered. Revert here or DM

[fdebrus]

Next to CRC check I’ve also found that within a ACK from Nikobus following a command

If instead of receiving $0EFF6C0E0060 where 6C0E is the address of the module we get FF 01 or FE 00 then Nikobus failed to process the command.

For next release…