Custom Component: Nikobus

[fdebrus]

@goofyke

I have a SONOFF SNZB-06P motion detector. It also has a light sensor. I want to create an automation with the motion detector as a trigger. The light shouldn’t turn on when it’s light, but should turn on when it’s dark. Unfortunately, I can’t select this option in HA, even though it does indicate it.

template:
  - binary_sensor:
      - name: "Living Room Is Dark"
        state: >
          {{ states('sensor.snzb_06p_illuminance') | float < 15 }}

[fdebrus]

@goofyke

I also have a Sonoff camera. I can open the stream in VLC, but I can’t open it in HA. I keep getting the message “timeout” with both gen-camera and onvif.

Use Frigate or go2rtc, I recommand Frigate NVR it integrate very well with HA and will manage your camera.

[GeertMertens]

Hello,

First of all thank you for this awesome Nikobus integration.

I have a question concerning using a nikobus button as trigger in an automation with the visual editor.

I experience that the results of ‘nikobus button sensor’ and the ‘nikobus push button’ are somehow reversed?

Isn’t the state of the “Button Sensor” = “idle” or “pressed” and not “on” or “off”?

When I create a manual state with trigger entity “Nikobus Button Sensor…” and use the custom state ‘pressed’ all works fine:

Can you please advise what i am doing wrong?

Kind regards, Geert

[fdebrus]

You should look at events, they are more rich and allow more granular control

fdebrus/Nikobus-HA

I will look at the behaviour you have with button, but triggered event is the right path. revert might you need any assistance to set this up.

[fdebrus]

I will have to retry with the current public version, but upcoming release 0.8.0 will be like

But I’m focusing on the integration performance for upcoming release,… couple of weeks still needed.

[fdebrus]

There is indeed a naming conflict with button and button sensor in the current release. will be solved in the next one.

[MarcVZ]

Hi,

I just upgraded the Nikobus intergartion to Version 0.7.4, and now my cards doesn’t find the enities anymore. Are those been change again? I know that I had to recreate them all after upgrading to 0.7.0 , and change all my cards

[fdebrus]

should not, but if so it’s a 5 min fix.

let say you had entity kitchen_light

if somehow a new entity was created because of unique_id change you should now have

kitchen_light - unavailable
kitchen_light2 - the new entity

If this is the case, go to Nikobus integration - Entities

Filter on the entities that are not available

select them all from this button

Then top right 3 dots

Delete them all and restart, you might have to restart 2x

Then back to normal, your kitchen_light - unavailable is gone and kitchen_light2 - the new entity is back to kitchen_light

Changing internal unique_id never influence your code or card; your are always using the entity_name and you can always recreate the name.

Could you tell me how you upgraded ? using HACS ? or copy/paste ? this should not happen, either way, easy fix

Any message in the log ? I will be out this evening but will check tomorrow for feedback.

[MarcVZ]

Recreating the entities did the trick. Now it’s working again.
I did the upgrade, by just clicking ‘Update’, in the Setting-list list where there all the available updates are listed.

[fdebrus]

great ! `Have you changed the module output type in the config file ? like declare a switch module output as a light that was a switch before ?

like

{
    "switch_module": [
        {
            "description": "switch_module_s1",
            "model": "05-000-02",
            "address": "C9A5",
            "channels": [
                { "description": "Extérieur Porte Entrée", "entity_type": "light" },
                { "description": "Extérieur Chemin Piéton", "entity_type": "light" },
``

[rswennen]

@fdebrus I did in my setup and I can confirm that it works. Thanks for the great work !!!

[MarcVZ]

@fdebrus

`Have you changed the module output type in the config file

I didn’t you changed the module output type in the config file. I just upgraded to the latest release. Do I have to change something in the config-files?
What is the difference if I change it to light? Everything that is connected to my switch-modules are lights.

[fdebrus]

all your switch outputs are now seen and defined in ha as switch.. you can keep it that way, the below is only an option if you wish to.

some user to ease the integration in ha and code wish to have light. vs switch.

this can now be done by using entity_type in the config file

Entity type by module

entity_type controls how Home Assistant exposes each channel. If you omit it, the integration uses the module default.

Module key	Default entity_type	Allowed entity_type values	Notes
switch_module	switch	switch, light	Useful when you want a switch output to show up as a light.
dimmer_module	light	light	Dimmers are always exposed as lights.
roller_module	cover	cover, switch, light	switch maps to open on “on” and stop on “off”.

[fdebrus]

To answer some general queries from integration users I’ve received lately

Nikobus is a CSMA/CA bus (only one device can talk at a time), HA cannot get a clean answer from the module while you are physically holding the button down.

So if you press for a cover movement and keep pressing the button for more than 1 second, the nikobus is flodded with button press and HA cannot query the cover module for status ‘eg closing / opening or stopping’

That’s why you have sometime desync of a few second between cover status and HA.

Release 0.8.0 is in the making with faster fails and retries to get module status following a button press, so while it will not erase the delay it should reduce it.

[wimu (Willem)]

What “operation_time” will work better for a Rollershutter? A little too long “operation_time” or maybe a little too short. In which will there be less desync?

[rswennen]

I do a bit too long otherwise the rollershutter won’t clos or open entirely. It will stop too early

[wimu (Willem)]

@rswennen How many? One second or more?

[fdebrus]

Pro Tips for Timing Your Covers:

• Always time the opening phase: Because gravity helps the cover down, closing is naturally a bit faster. Base your configuration on the slightly longer opening time to ensure accuracy.
• Re-time annually: As physical motors age, the time it takes to complete a full movement tends to increase. Checking your timings once a year will keep your setup perfectly in sync.

Coming in Version 0.8.0: Built-in Movement Buffer To make setting up and using the integration easier, the upcoming 0.8.0 release introduces a new safeguard: COVER_MOVEMENT_BUFFER = 3.0.

When moving to a fully open or fully closed position, this automatic 3-second buffer is added on top of your configured operation_time. This guarantees the cover has enough time to reach its physical limit switch before the integration cuts power to the motor with a final stop command.

While doing some research on how to improve the Nikobus integration, I noticed that other custom integrations (like hass-cover-time-based) use separate timers for the “Up” and “Down” travel times.

Because gravity helps a cover roll down faster than it rolls up, using a single timer can lead to the position slider drifting out of sync with reality. Implementing separate timers for the Nikobus integration would be relatively easy and would make the position simulation much more accurate.

I know this means a little extra setup work with a stopwatch, so my plan is to make the time_down parameter completely optional. If a user doesn’t configure a down timer, the integration will simply fall back to using the time_up value for both directions, meaning zero breaking changes for existing setups.

Would you vote for this feature? Let me know if you think it’s worth adding!

Something like:

{ "description": "Salon Volet Terrasse", "operation_time": "45", "operation_time_down": "42" },

UPDATE:
Just tested and I have 2 seconds delta on a cover up vs down operation. So I will implement the “operation_time_down” as described above aka optional non breaking

{ “description”: “Salon Volet Sofa”, “operation_time”: “29”, “operation_time_down”: “27” },

[fdebrus]

Other question; no one using HomeKit, Alexa or other to send command to Nikobus ?

[rswennen]

Hi I have both Apple home LinkedIn and Google home. Apple via the homekit add on and Google by exporting them as matter devices and it works great.