Do I have to install a specific add-on for “serial.transport”? Seems that I don’t get a connection to my system.
Now with a complete new windows install and Openhab2.5.0M5 and Zulu Java (instead of Oracle).
21:14:47.944 [WARN ] [org.apache.karaf.shell.ssh.Activator ] - Error starting activator
java.lang.IllegalStateException: Service not tracked for class interface org.osgi.service.cm.ConfigurationAdmin
at org.apache.karaf.util.tracker.BaseActivator.getTrackedService(BaseActivator.java:369) ~[bundleFile:?]
at org.apache.karaf.util.tracker.BaseActivator.ensureStartupConfiguration(BaseActivator.java:154) ~[bundleFile:?]
at org.apache.karaf.shell.ssh.Activator.doStart(Activator.java:96) ~[bundleFile:?]
at org.apache.karaf.util.tracker.BaseActivator.run(BaseActivator.java:312) [bundleFile:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_232]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_232]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_232]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_232]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_232]
21:14:58.295 [INFO ] [del.core.internal.ModelRepositoryImpl] - Loading model 'nikobus.things'
21:15:00.803 [INFO ] [rthome.model.lsp.internal.ModelServer] - Started Language Server Protocol (LSP) service on port 5007
21:15:01.819 [INFO ] [i.dashboard.internal.DashboardService] - Started Dashboard at http://192.168.10.231:8080
21:15:01.835 [INFO ] [i.dashboard.internal.DashboardService] - Started Dashboard at https://192.168.10.231:8443
21:15:02.319 [INFO ] [mebuilder.internal.HomeBuilderServlet] - Started Home Builder at /homebuilder
21:15:02.428 [INFO ] [.openhab.ui.paper.internal.PaperUIApp] - Started Paper UI at /paperui
21:15:02.538 [INFO ] [bpanel.internal.HABPanelDashboardTile] - Started HABPanel at /habpanel
21:15:05.522 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'nikobus:pc-link:mypclink' changed from UNINITIALIZED to INITIALIZING
21:15:05.522 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'nikobus:pc-link:mypclink' changed from INITIALIZING to UNKNOWN
21:15:05.553 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'nikobus:switch-module:mypclink:s1' changed from UNINITIALIZED to INITIALIZING
21:15:05.569 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'nikobus:switch-module:mypclink:s1' changed from INITIALIZING to UNKNOWNHi,
I tried the TCP/IP connection in my .things file which has only the bridge configured
Bridge nikobus:pc-link:mypclink [ port="//10.0.0.104:3333", refreshInterval=30 ] { }
Log:tail output:
> 15:09:16.444 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'nikobus:pc-link:mypclink' changed from UNINITIALIZED (HANDLER_MISSING_ERROR) to INITIALIZING
> 15:09:16.457 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'nikobus:pc-link:mypclink' changed from INITIALIZING to UNKNOW
On the ser2net server I don’t see any connections (netstat -aln)
How can I troubleshoot?
Thanks for the advice.
Regards.
Managed to get it working.
Thx.
Hello everyone,
i have a question about the nikobus V2 binding
I have installed openhab V2.5 and the nikobus binding.
Also i have created a nikobus.things file with the bridge and the modules and 2 push-buttons
And a nikobus.items file with 3 switches.
Tthis is working fine except that after toggling theSwitch “Button_on” or Switch “Button_off”, the status from the module is not read back and the switch “LP_hal” is not updated.
the action is well done and the output from the switch-module is switching
During the automatic periodic update (refreshInterval=300) the status from the modules is updated en correct.
if i use the serial port for the bridge connection i get the same behavior
Can someone tell me what i am doing wrong or where the configuration is not correct.
thank in advance,
Jack
nikobus.things
Bridge nikobus:pc-link:mypclink [ port = "//192.168.178.110:8200", refreshInterval=300 ] {
Thing switch-module s1 [ address = "bb08" ]
Thing switch-module s2 [ address = "C307" ]
Thing rollershutter-module r1 [ address = "6348" ]
Thing dimmer-module d1 [ address = "B7C0" ]
Thing dimmer-module d2 [ address = "49C1" ]
Thing push-button BP21_A "BP21_A" [ address = "9E784F", impactedModules="switch-module:s1:2" ]
Thing push-button BP21_B "BP21_B" [ address = "DE784F", impactedModules="switch-module:s1:2" ]
}
Nikobus.items
Switch LP_hal "hal" <light> (Beneden_verdieping) { channel="nikobus:switch-module:mypclink:s1:output-8" }
Switch Button_on "Button hal on" {channel="nikobus:push-button:mypclink:BP21_A:button"}
Switch Button_off "Button hal off" {channel="nikobus:push-button:mypclink:BP21_B:button"}
events.log (8.8 KB) openhab.log (344.2 KB)
Yes, that is current behaviour - when manipulating push-button Thing from OH (Nikobus binding) -> Nikobus installation, this will not trigger a module’s status update.
Status update will only be triggered when physical Nikobus button will be pressed - so if button BP21_A with address 9E784F will be pressed then second group of switch module with address bb08 will be read.
Is there a special reason you need to have
Switch Button_on "Button hal on" {channel="nikobus:push-button:mypclink:BP21_A:button"}
Switch Button_off "Button hal off" {channel="nikobus:push-button:mypclink:BP21_B:button"}
Usually one just binds to
Switch LP_hal "hal" <light> (Beneden_verdieping) { channel="nikobus:switch-module:mypclink:s1:output-8" }
and you don’t need to specify the Button_on and Button_off in .items file …
thanks for your quick response,
the reason is that i am also using ambiance settings so with one physical Nikobus button i control multiple dimmers (done in nikobus logic)
so to call a certain ambiance setting i want to use the “Thing push-button …” and simulate the physical Nikobus button
also i have physical Nikobus button’s with multiple action’s (one button that switch all lamps off , etc)
another physical Nikobus button is starting a timer in the nikobus module and after 10 min the light is going off
i say that when i am pussing a physical Nikobus button the status update is triggered.
I use this often in my config as well for very similar reasons. In the old binding this was done by adding
[<moduleAddress>-<channelGroup>, <moduleAddress>-<channelGroup>, ...]
That being said, the old binding was far from perfect when it came to this forced update, it didn’t work for dimmers as the update was requested before the dimming delay was finished so a dimmer being turned off provided 30% as feedback and also update of a lot of modules was problematic.
But a feature that allows for a forced status update of a module would in indeed be needed to keep statuses in sync. Ideally there is a configurable delay between the button push and the status request of the module.
@rswennen - v2 version has this in place too, i.e.
Thing push-button BP21_B "BP21_B" [ address = "DE784F", impactedModules="switch-module:s1:2" ]
as you can see in the example above + it also includes enhanced handling for dimmers to make sure the correct value/status is read back. BUT this is done in the physical button -> OH direction, not vice versa as discussed above - and that was not supported in v1 binding as well AFAIK.
@jackbal - adding such status refresh to the binding should be fairly easy, but might not solve all cases - i.e. if light will go off in 10 minutes as in your example, binding has no knowledge about that and will not trigger another status refresh … what you can do is to send a channel refresh command to the Nikobus binding from a rule and add a timer there as well so after 10 minutes a new status refresh is triggered …
ok
if i understand well the “thing push-button” is only used to trigger a module status update after a physical button is pressed.
i think it will be nice that when can send (simulated) button presses (thing push-button) from oh we also get a status update from the affected modules.
I know it will not solve the status after the timer action but for that we have to wait for the automatic periodic update.
but for the other items like multiple outputs with one button or using ambiance setting in Nikobus it works.
what did you mean with “adding such status refresh to the binding should be fairly easy”
is that something i can do in the configuration or is it a change in the binding software ?
also how do i send a channel refresh command to the Nikobus binding ?
I’m not behind a computer right now so just re for - “send a channel refresh command” - please use something like
myItem.sendCommand(REFRESH)
my bet is that if you send above command to i.e. LP_hal it should trigger a status refresh …
There are many samples on how to use the REFRESH command, i.e. SystemInfo - Refresh Items Manually … Please let me know how it goes if you decide to give it a spin - so trigger a REFRESH when i.e. Button_on gets turned ON via Paper UI (or whatever UI you use) …
1 Like
i tried it en it is working fine
when a status change from Button_on trigger’s a REFRESH for the item LP_hal the module status is updated.
tomorrow i will play some more with it
Hi everyone,
I’m discovering openhab and just migrated from OH2.4 on windows to OH2.5 on openhabian on RPI 3b. I’ve been using the nikobus v1 binding on windows and wanted to start using the nikobus V2 binding on my RPI.
I cannot get the pc-link binding to connect.(I use a prolific 2303 USB to serial connector, connected to /dev/ttyUSB0)
Status remains ‘unknown’ :
2019-12-28 14:44:56.556 [hingStatusInfoChangedEvent] - ‘nikobus:pc-link:070facbf’ changed from UNINITIALIZED to INITIALIZING
2019-12-28 14:44:56.583 [hingStatusInfoChangedEvent] - ‘nikobus:pc-link:070facbf’ changed from INITIALIZING to UNKNOWN
To make sure there is no hardware issue, I installed the nikobus v1 binding on the RPI and it immediately connected to the pc-link module and works correctly.
Any idea what I could be doing wrong ?
Hi! Please note defining bridge only is not enough to get it online - you need to define items linked to things in order for bridge to connect and communicate with a Nikobus PC Link - the reason for this is - if there is no item defined than there is no-one interested in anything bridge can offer - so no point to connect to the Nikobus installation …
So please define at least one thing (module) in the bridge and link at least one of its channels …
Also please do not forget to remove the v1 binding …
1 Like
At this moment I’m migrating my OH2.4 installation to OH2.5.
I changed all my config files for the change of Nikobus v1 binding to Nikobus v2 binding.
Now I see that some of my Nikobus inputs (like my movement sensors) are “OFFLINE-CONFIGURATION_ERROR” why is that and how can I solve this?
thing config:
Bridge nikobus:pc-link:PCL1 [port=“/dev/ttyUSB1”, refreshInterval=30]{
Thing push-button INT5_A “movement driveway” [address=“AC00B2”]
}
Most of the buttons work fine!
Thanks crnjan !
Everything is working like a charm now.
WGE - glad to hear 
@DaanDW - at first glance config looks fine - can you please share what is the exact message for things with OFFLINE-CONFIGURATION_ERROR status? You can get more details in PaperUI AFAIK …
what is “PaperUI AFAIK”?
I’m configuration almost everything with the configuration files.
I think I found the problem.
All “push button” items without the impactedModules = "<moduleType>:<moduleId>:<channelGroup>" in the configuration gives me a “OFFLINE-CONFIGURATION_ERROR” status.
how can I solve this? this items don’t need a “impactedModules” configuration because thay are not linked to a Nikobus module (but are used in rules to controle “not” Nikobus related outputs.
Currently the impactedModules parameter is mandatory … I will make it optional to support your case - please note it might take a while - not sure how to add changes to 2.5+ version since we already have a release
Nevertheless - please add impactedModules to your buttons and use some not existing thing id for reference - this way no update will be made since thing (module) will not be found, i.e.:
impactedModules = "switch-module:XXX:1"
You can use above workaround (assuming there is no thing with id = XXX defined in your configuration 
) until the impactedModules gets optional.