Nikobus v2

Yes! I’m still working on migrating my old setup so haven’t had much time but for now everything works.

I have to say that I didn’t have push buttons on my old setup. They were defined as things but not as items. As a matter of fact, I don’t see much use in defining items out of them if I don’t use them in openhab for sending commands. The only use case is if I want to switch my hue. Default is nikobus, so even when OH goes down, I can still switch the lights :blush:

And thank you very much for keeping our nikobus up to date…

1 Like

Unfortunately I get a lot of errors. Everything seems to be configured OK and works from time to time but I get a lot of timeouts. This worked stable on the same RPi with the same cables and settings on OH2. I’m wondering if OH3 is more power hungry and I could need to change to power? Any other ideas?

2020-12-30 17:28:48.256 [WARN ] [nternal.handler.NikobusModuleHandler] - Processing response for ‘B74F’-FIRST failed with Waiting for response timed-out.

java.util.concurrent.TimeoutException: Waiting for response timed-out.

at org.openhab.binding.nikobus.internal.handler.NikobusPcLinkHandler.processTimeout(NikobusPcLinkHandler.java:315) [bundleFile:?]

at org.openhab.binding.nikobus.internal.handler.NikobusPcLinkHandler.lambda$4(NikobusPcLinkHandler.java:305) [bundleFile:?]

at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]

at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]

at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) [?:?]

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]

at java.lang.Thread.run(Thread.java:834) [?:?]

2020-12-30 17:28:48.264 [DEBUG] [nternal.handler.NikobusPcLinkHandler] - Sending retry = 3, command '$1017B74F34DEF2

2020-12-30 17:28:50.268 [DEBUG] [nternal.handler.NikobusPcLinkHandler] - Sending retry = 2, command '$1017B74F34DEF2

2020-12-30 17:28:52.271 [DEBUG] [nternal.handler.NikobusPcLinkHandler] - Sending retry = 1, command '$1017B74F34DEF2

2020-12-30 17:28:54.274 [DEBUG] [nternal.handler.NikobusPcLinkHandler] - Sending retry = 0, command '$1017B74F34DEF2

2020-12-30 17:28:56.279 [WARN ] [nternal.handler.NikobusModuleHandler] - Processing response for ‘B74F’-SECOND failed with Waiting for response timed-out.

java.util.concurrent.TimeoutException: Waiting for response timed-out.

at org.openhab.binding.nikobus.internal.handler.NikobusPcLinkHandler.processTimeout(NikobusPcLinkHandler.java:315) [bundleFile:?]

at org.openhab.binding.nikobus.internal.handler.NikobusPcLinkHandler.lambda$4(NikobusPcLinkHandler.java:305) [bundleFile:?]

at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]

at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]

at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) [?:?]

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]

at java.lang.Thread.run(Thread.java:834) [?:?]

Executing a Nikobus command takes about 300 milliseconds to execute, as below:

06:45:07.353 [DEBUG] [internal.handler.NikobusModuleHandler] - handleCommand '100' for channel 'output-4'
06:45:07.359 [DEBUG] [internal.handler.NikobusModuleHandler] - setting channel 'output-4' to 255
06:45:07.365 [DEBUG] [internal.handler.NikobusPcLinkHandler] - Sending retry = 3, command '$1E150700000000FF0000FF5327F1'
06:45:07.409 [TRACE] [internal.handler.NikobusPcLinkHandler] - Received 36
06:45:07.435 [TRACE] [internal.handler.NikobusPcLinkHandler] - Received 48
06:45:07.439 [TRACE] [internal.handler.NikobusPcLinkHandler] - Received 53
06:45:07.442 [TRACE] [internal.handler.NikobusPcLinkHandler] - Received 49
06:45:07.445 [TRACE] [internal.handler.NikobusPcLinkHandler] - Received 53
06:45:07.449 [DEBUG] [internal.handler.NikobusPcLinkHandler] - Received ack '$0515'
06:45:07.617 [TRACE] [internal.handler.NikobusPcLinkHandler] - Received 36
06:45:07.621 [TRACE] [internal.handler.NikobusPcLinkHandler] - Received 48
06:45:07.625 [TRACE] [internal.handler.NikobusPcLinkHandler] - Received 69
06:45:07.629 [TRACE] [internal.handler.NikobusPcLinkHandler] - Received 70
06:45:07.633 [TRACE] [internal.handler.NikobusPcLinkHandler] - Received 70
06:45:07.636 [TRACE] [internal.handler.NikobusPcLinkHandler] - Received 48
06:45:07.640 [TRACE] [internal.handler.NikobusPcLinkHandler] - Received 55
06:45:07.644 [TRACE] [internal.handler.NikobusPcLinkHandler] - Received 48
06:45:07.647 [TRACE] [internal.handler.NikobusPcLinkHandler] - Received 48
06:45:07.651 [TRACE] [internal.handler.NikobusPcLinkHandler] - Received 48
06:45:07.654 [TRACE] [internal.handler.NikobusPcLinkHandler] - Received 48
06:45:07.656 [TRACE] [internal.handler.NikobusPcLinkHandler] - Received 49
06:45:07.659 [TRACE] [internal.handler.NikobusPcLinkHandler] - Received 55
06:45:07.662 [TRACE] [internal.handler.NikobusPcLinkHandler] - Received 13
06:45:07.665 [DEBUG] [internal.handler.NikobusPcLinkHandler] - Received command '$0EFF07000017', ack = '$0515'
06:45:07.668 [DEBUG] [internal.handler.NikobusModuleHandler] - processWriteCommandResponse '$0EFF07000017'

Binding has timeout set to 2 seconds (+3x retries) so if you see timeouts than there is definitely something strange going on - I never seen timeout in my setup for example. Can you set log level to TRACE and share the logs?

1 Like

I will. In the meantime I changed the PSU and the cable, because when I reboot from command line the connection to nikobus and my zwave stick fail both. On both my RPI 3B+, which work with no issues with both sticks on OH2. The SDcard is brand new, I could still exchange that one too.

Installed OH3 a couple of days ago. Copied my Nikobus .items and .things files form OH2.5 and it looks like alle components are working so far.

But when I make a semantic model as recommended it is then not possible to rename things and items. Behind all .things and .items created in my .items and .things files from OH2.5 a lock is displayed.

Do I have to recreate all items and things in OH3 or is it possible to adjust my OH2.5 files?

You can still use your file-based configuration(s), you just cannot edit (some) aspects of items/things through the UI, but need to edit/update the files itself. This is not binding specific and was the same in OH v2 too AFAIK.

As stated in the doc:

Things/Items configured in files will become visible in Main UI if no Thing/Item of the same name is already present in the system database, but a lock will symbolize that you can NOT change them in the GUI. You can only change them by editing the source files.

Thx crnjan,

What’s youre advise. Continue file-based or rebuild in UI?

What’s confusing to me is all Pushbuttons get an unique name but my 3 switches have the same name when I try to build a semantic model:

> Thing switch-module s1 [ address = "18D4" ]
> 
> Thing switch-module s2 [ address = "1A5F" ]
> 
> Thing switch-module s3 [ address = "193C" ]
> 
> Thing dimmer-module d1 [ address = "3AC5" ]
> 
> Thing rollershutter-module r1 [ address = "0C5B" ]
> 
> //Push button things
> 
> //VIRTUAL PUSH BUTTON THINGS
> 
> //PHISICAL PUSH BUTTON THINGS
> 
> //0.1 Push button things Garage
> 
> //Garage deur voor
> 
> Thing push-button 818AFA "NB_BP1_A" [ address = "818AFA", impactedModules = "switch-module:s1:1" ]
> 
> Thing push-button C18AFA "NB_BP1_B" [ address = "C18AFA", impactedModules = "switch-module:s1:1" ]
> 
> Thing push-button 018AFA "NB_BP1_C" [ address = "018AFA", impactedModules = "switch-module:s1:1" ]
> 
> Thing push-button 418AFA "NB_BP1_D" [ address = "418AFA", impactedModules = "switch-module:s1:1" ]

So far as I know I followed the syntax from the binding configuration. All switches are named “Switch Module” and each output is named “Output 1” etc. 3 times. That’s confusing.

When switching to OH3 I switched from text based to UI completely - rebuilding, cleaning and unifying my setup.

I manually added modules in the UI:

And then linked channels while building my semantic model …

For buttons I used the discovery feature (described a couple of posts above) and added 100+ buttons - finally mapped all :slight_smile:

So - not 100% sure how text defined things map to UI since I haven’t used that, but it’s not binding specific … Maybe worth checking here.

Thx

I already doubted whether I would start again, but now I am convinced to do so.

Do you have any tips on building a semantic model for a Nikobus installation? The setup for locations is clear, but I find it difficult to understand the distinction between equipment and properties. Light? Lightbulb? Switch?

Groet :wink:

I’m using the following layout

So each light, for example, is an equipment:

and contains points:

Two comments on above - since there is only one property in most of my equipment I would probably not bother adding properties to equipment anymore and would just set equipment’s type to switch/dimmer/…

And second - my naming(s) are a bit too general in some cases - while it plays fine in the ‘Locations’ tab, where you have per-location breakdown and you know which location equipment belongs, it does not play so well for Equipment tab

So you need to plan for what and how you are going to use the model.

Any improvement suggestions more than welcome.

EDIT: removed rollershutter definition since its not following the equipment -> point “design”, need to change this in my setup too …

Started all over again (2 times already :slight_smile:):

I found it difficult to understand the difference between Equipement and Points. I also don’t know if the long names are useful, but for now I will leave it that way.

Some additional questions:

  • My rollershutters reverse: Up is down and down is up. Also the category blinds shows a reverse animation. Is it possible to change this.
  • I have not yet defined the pushbuttons. I do think this is necessary to properly configure these for impacted modules (status Rollershutters). Where can I define that in UI?

I changed my model a bit and I like how the auto-generated cards are now rendered :partying_face:

Basically I added room name prefix to each equipment - “table lights” → “living table lights” so now I know where they belong in Equipment tab + name is (still) not too long in “Locations” tab …

For rollershutters I used equipment directly and set type to rollershuttter (so without points) - this also renders the location card with rollershutters closed count correctly

Regrading your questions:

My rollershutters reverse: Up is down and down is up

Binding uses same setup as if you set it up in Nikobus installation with Nikobus push buttons - tapping upper button will open (moving UP) rollershutters and tapping bottom button will close the rollershutters (moving down). There is currently no way to change this behaviour in the binding - one way to resolve this is to switch the cables on the Nikobus rollershutter module (only if you know what you are doing, 220V hazard!!) … if this is not an option, please let me know and we can think of a way to make this configurable …

  • I have not yet defined the pushbuttons. I do think this is necessary to properly configure these for impacted modules (status Rollershutters). Where can I define that in UI?

You can use the new discover option - when you tap a physical Nikobus button, it will be added into your OH inbox and you can configure it than from there - there is no more poking around the logs needed - see a couple of posts above for more details or the docs.

1 Like

Hi @crnjan

Thanks again for the binding. At the moment everything is working fine, except for the reboot, but with my nikobus everything works.

1 Like

Hello community, best wishes for the new year!

Can someone assist me in controlling my Nikobus installation at home?
These are the steps i performed and the question i have:

Download and burn the openHABian SD card image for Raspberry Pi from: Download openHAB.
Local keyboard and monitor connected to RPi 2B. Also connected USB to serial to Niko PC-Link module.
Power on and Installation.
After installation, on console, changed keyboard layout to Belgian with
sudo dpkg-reconfigure keyboard-configuration
Generic 105-key PC (intl.) and Belgian and Belgian (Wang 724 AZERTY) and default settings
A reboot was performed after that

Launched browser to http://openhabiandevice:8080/ and followed the wizard, also added “the Nikobus Binding”.
In the GUI went to Things, added the PC-Link via the Nikobus Binding. Status: UNKNOWN
Snapshot 3.1 containts buttons to inbox support
OpenHAB version was 3.0.0
Used openhabian-config command, menu 41 to install the latest SNAPSHOT.
Status of the PC-Link still UNKNOWN
Added “Switch module 1” with PC-Link as Bridge and reversed address from Nikobus software. Sofware says C7C1 i typed in the config of the switch module C1C7.

Added an item (switch) to output 8 of the module and everything was online and the inbox was being populated with the various buttons pressed by my family members.

I would like to achieve the following:
Use openHAB via the available tablet and smartphone app to control our house. But keeping the current functionallity of the Nikobus installation.

Since 90% of my wall buttons have feedback leds i need this to be in sync between the the buttons and the openHAB buttons.

For example. There are 3 places where we can lit a light in our living room. When we press the button for the uplighter in the living room, the feedback let is lit togheter with the feedback led on the 2 other wall buttons. And visa versa.

I already got some info from several members from the community but since i am not a developper i can’t seem to get this working or because i don’t get it how to get it working. :grinning:

I now have a blank openHAB setup. First i want to get a light go on and of with feedback led working on the physical button(s).

How do i get started?

Use the physical buttons collected by the Things Inbox (in the v3.1 crnjan made)? Which seems to be converted to Things.
Use the outputs from the switch modules?
Use a combination of both?

Can i assist crnjan to let him implement this in the Nikobus binding?

Something else:

In Things, the Physical buttons discovered in the Inbox have a parrameter “Impacted Modules” but i don’t understand the purpose of it.

Thanks for your feedback !

You don’t have an item type for rollershutters? As we frequently use the app on the phone - which currently do not support the new concept of pages - the sitemap is the most important for us. Is it possible to render them in a normal sitemap then?

Nevertheless I adore the new layout so … I’m very interested in similar semantic models, but it’s a pity you can’t change it in code…

This is normal behaviour. When you send a command the bus gets activated, and then it comes online in Nikobus.

I do the same. Openhab is on top off. I can unplug openhab and the basis lighting keeps on working, but most of the smart part is disabled.
Smartphone app makes it mandatory to use sitemaps, while the new 3.0 UI is perfect for tablets…

I would assume - given the fact that OH just adds info on the bus - that the LEDs just work.

I’m a developer neither and I got it to work so :slight_smile:

I would first of all define the Things which are the modules, then link new items to the channels on the channel tab.

As modules in nikobus updates the state of a group - for a 12 channel module channel 1-6 are updated, it sets the correct states. I haven’t defined my buttons as of yet - I’m still discovering the new things in OH3, which gives that from time to time when a button is pushed and the module hasn’t been updated another light switches back to the state the module was in before. So a light was on and suddenly on an update it went off because the state in OH was off while in Nikobus was on with the button which wasn’t set up correctly in OH3.

I can only advise you to take a look at the OH3 meetup (https://www.youtube.com/watch?v=pwZ8AOwRDEk&t=4944s) and read the pages that were made from ysc (remaking the documentation).
The ontology has helped me also a lot to get my head around the various; see Semantic Model | openHAB

Hey!

I would first suggest to start small&slow. Unfortunately I’m not familiar with Nikobus buttons with feedback LEDs and cannot test them (since I don’t have one), but IMHO in order to get it working as you want, you should simulate real Nikobus buttons, maybe with something like below:

First select one light you want to control, let’s say output 8 of your switch module, as written in your post. Then locate two buttons that turn your light (output 8) to ON and OFF and link those two button’s channels to items:

so you’ll end up with two items - one for ON and one for OFF (please make sure to set “semantic class” of your linked channel to none since you don’t need it as part of your semantic model, it’s needed just so you can send commands to it).

  • gBasement_HomeOffice_PushButton_Light_Off - is linked to button channel of your Nikobus push-button thing that has the same address as your Nikobus physical button used to turn channel-8 to OFF,
  • gBasement_HomeOffice_PushButton_Light_On - is linked to button channel of your Nikobus push-button thing that has the same address as your Nikobus physical button used to turn channel-8 to ON and
  • gBasement_HomeOffice_Light_Ceiling_Powered - is linked to channel-8 of your switch module, which above two buttons control.

Once above is setup, you can try

component: f7-card
config:
  title: Home Office Light
slots:
  default:
    - component: f7-card-content
      slots:
        default:
          - component: f7-row
            config:
              class:
                - justify-content-center
                - align-items-center
                - padding-bottom
            slots:
              default:
                - component: f7-icon
                  config:
                    f7: lightbulb
                    class:
                      - padding-right-half
                - component: Label
                  config:
                    text: =items.gBasement_HomeOffice_Light_Ceiling_Powered.state
          - component: f7-segmented
            slots:
              default:
                - component: oh-button
                  config:
                    outline: true
                    text: OFF
                    action: command
                    actionCommand: ON
                    actionItem: gBasement_HomeOffice_PushButton_Light_Off
                - component: oh-button
                  config:
                    outline: true
                    text: ON
                    action: command
                    actionCommand: ON
                    actionItem: gBasement_HomeOffice_PushButton_Light_On

which renders

Screenshot 2021-01-06 at 20.07.29

and tapping OFF/ON should turn your actual light on and off respectively. Status next to light should reflect actual light state.

Caveat: please note status next to light will not be reflected immediately but only when refresh period will kick in and read new state from switch module - so keep this in mind while testing - you should see immediate feedback with your physical light. Once you can control your lights as described above please report back if your LEDs are also working as desired. Then we’ll try to figure out how to update the (local) state immediately too (a small code change will be required probably).

Not sure if I follow … of course you have rollershutter type, I’m just saying one needs to follow this rules if you want automatically generated cards in Locations tab to render all the details (no. of lights on, …).

Thanks @bdv and @crnjan for your sugestions and tips.
I’ll make some time to try and test this and get back in touch if i have some results!

Just FYI - yesterday I added a fix so now “simulated” buttons also refresh impacted modules (it’s already merged) so you should have all the bricks in place - but you will need to install latest OH snapshot.