Custom Component: Nikobus

i'll do my best to do it asap.
Meanwhile i have some extra info that may help.
When i disconnect all from the physical module and make direct connections between the inputs and the common on connection 7 i get these results on the bus:

PCLink address 8DC8

INPUT 1
High: 209D8B
Low: 609D8B

INPUT 2
High: 109D8B
Low: 509D8B

INPUT 3
High: 309D8B
Low: 709D8B

INPUT 4
High: 089D8B
Low: 489D8B

INPUT 5
High: 289D8B
Low: 689D8B

INPUT 6
High: 189D8B
Low: 589D8B

For INPUT 6 for example, this one launches the 22 line scene ( 384102)
On the bus i see 102087 directly after the 189D8B and 502087 directly after the 589D8B on the bus.

Looks like the trickiest part for most folks is nailing those module addresses. I had a similar headache until I double checked the wiring and pulled fresh logs right after a button press. Maybe adding a tiny helper in the UI that warns when an address never shows up in traffic could save people some head scratching. The long and short press events are already a sweet addition.

@yuhinub, thanks for the feedback, and glad the long/short-press events are landing well! :slightly_smiling_face:

Would you mind expanding a bit on the idea and the concept behind it? I want to make sure I'm understanding it correctly before running with it.

For context: in the earlier releases almost everything was manual you had to configure module addresses (and more) by hand, which is exactly the "nailing those addresses" headache you're describing. The version I'm working on now (still in the making) moves away from that: it relies on a discovery mechanism that dumps the module registry straight off the bus, so users shouldn't really need to touch raw addresses anymore.

So I'm trying to picture where your "warn when an address never shows up in traffic" helper would add value on top of that. Which case are you thinking of?

  • a module that's enrolled/configured but physically absent or mis-wired (so it never answers on the bus)
  • a button that does show up in traffic but isn't linked to anything yet
  • validating things after a manual edit
  • or a different scenario entirely

A concrete example of the moment it bit you what you saw vs. what you expected would help me a lot in figuring out the right spot for it. Thanks again for thinking it through!

Nikobus scenes in HA, how would you like them presented?

I'm reworking how Nikobus scenes (Central Functions / light scenes) appear in Home Assistant, and I'd like your input before I commit to a direction.

Quick background, what a Nikobus scene actually is

A scene is defined and executed 100% on the Nikobus bus: a single trigger a wall-button key, or an IR code on a receiver tells a group of output modules to jump to preset dim levels / open-close shutters / switch circuits, all at once. Home Assistant isn't part of that; it just watches the bus and can also fire the same trigger.

Today the integration decodes each scene from the bus and surfaces it like this:

Here, IR_FamilyRoom_TVLights is an IR code from a wall button with an IR receiver. When that code appears on the bus, Nikobus runs the scene HA only sees it and flips the matching sensor.

Under Controls you get the scene entity itself, so you can activate the scene straight from HA:

(Firing the underlying button/IR entity is an equally valid way to trigger it.)

Open the scene's attributes and you can see its full definition the modules, channels and modes it drives:

The naming question

Scenes show up under their internal address (e.g. Nikobus scene DE4E2C), not a friendly name. That's deliberate: any label you gave a scene in the Nikobus PC software lives only in your .nkb file it's not on the bus, so I can't read it during discovery. I could parse the .nkb to pull those descriptions in, but I've held off because many users don't have an up-to-date .nkb to hand. If you think importing names from the .nkb is worth it, let me know.

What I'm after

The data is fully decoded and available, but I'm not happy with the current UX. Before I take it down a new path how would you want scenes presented?

  • Standalone scene entities (today's behaviour), grouped under one "Scenes" device?
  • Linked to the button / IR code that triggers them in Nikobus, so trigger and scene live together?
  • Renamed from the .nkb when it's available?
  • Something else entirely?

A quick sketch of how you'd lay it out on your dashboard is hugely helpful. And as always, any other ideas, pain points or improvements are very welcome.

Nikobus 3.3.2 Latest

Highlights

:card_index: Import device & entity names from your Nikobus .nkb project file The Nikobus PC software keeps every module / button / IR-receiver name (and its room) inside the project file .nkb this release reads it directly in Home Assistant and applies those names.

  • New bridge button: “Import Names from .nkb.” Put your project export in the Home Assistant config directory named nikobus.nkb, then press the button.
  • Names are applied as Name (Room), keyed on the bus address e.g. your dimmer becomes Dimcontroller (Centrale), a wall button Entree (Living).
  • Non-destructive. Anything you've already renamed by hand is never overwritten. Multi-channel modules are named at the device level (the channels
    inherit it, so the same name isn't stamped onto all 12); single-entity devices get their entity row named too.
  • Fully local, no external services. Parsing is pure-Python. The file never leaves your machine.
1 Like

Scenes — Continued

A follow-up on how scenes work in Nikobus, because it's caused some confusion (including mine :grinning_face_with_smiling_eyes:).

TL;DR

Scenes do not exist in the modules. They only exist in the .nkb project file.

How I proved it

You can verify this yourself with the Nikobus software:

  1. Open a blank project.
  2. Load the installation.
  3. Result: modules, buttons and their links all come back… but zero scenes are created.

I also captured the serial traffic during that load and compared it to what the integration reads the official software queries exactly the same registers we do (we actually read a superset). There is no hidden register, sub-byte or module where scenes are stored. If Niko's own software can't rebuild the scenes from the live installation, they simply aren't on the bus.

Why scenes can't be auto-detected

On the bus, a scene is just a button. When you press a scene's trigger, the output modules act on their stored link records the same way they react to any wall button. In a module, a "scene" link looks byte-for-byte identical to an ordinary button that happens to control many outputs:

address → channel → mode

So when discovery sees one address driving 12 outputs across 4 modules, there's no way to know: is this a scene, or just a button that controls a lot of stuff? The "this group is a Central Function" information lives only in the .nkb (and the names too).

The one exception: light scenes

Light scenes are the lucky case. They store a preset level per output, which forces special modes (M04 / M11 / M12 / M14 / M15 / "recall stored level"). Those modes are a real fingerprint that survives into the modules, so light scenes are detected automatically no .nkb needed. Shutters and on/off "master" scenes have no level to recall, so no special mode, so no fingerprint.

So, where scenes stand now

  • Light scenes → detected automatically from the bus. Works for everyone.
  • All other scenes (shutter scenes, master-off, "leave the house"…) → only recoverable from the .nkb.
  • Without a .nkb, those scenes still work they're just shown as their trigger button (pressing it fires the exact same outputs). You only lose the friendly name and the scene.* entity.

What the integration does with your .nkb

Drop your project export in the HA config folder as nikobus.nkb and press Import Names from .nkb. It then:

  • names your modules / buttons / IR receivers,
  • puts each device in a Home Assistant Area matching its Nikobus room,
  • names your light scenes, and
  • creates real scene.* entities for the shutter / master scenes too activated by firing their trigger, so the modules handle roller timing themselves.

This is authoritative, not guesswork: a group only becomes a scene because the .nkb explicitly marks it as a Central Function. Multi-output buttons are never promoted to scenes on their own, and you're never asked to classify anything. (A scene with no trigger button can't be fired from HA, so it's skipped.)

Bottom line

Scenes aren't a bus feature they're a PC-software concept. We surface what the bus can prove (light scenes) automatically, and the rest comes from your .nkb. If you have the file, you get everything named and your shutter/master scenes as proper scenes; if you don't, light scenes still work and every other "scene" is usable as its button.

The config flow has now an upload .nkb config file to ease the process


@promy thanks for the guidance and the tip. :+1:

You can now set your simulated button press from HA repeats, default is 3.