After overwriting the binding and changing the Bridge Thing definition (removing -serial), the PC-Link thing remains in state "UNINITIALIZED - HANDLER_CONFIGURATION_PENDING”
The serial port is not filled)in and cannot be changed via PaperUI (conflict)
My bad, portName also changed to port, sorry 
.
So you need to change existing bridge definition to:
Bridge nikobus:pc-link:mypclink [ port = "<serial port>", refreshInterval = <interval> ] {
Changing the portName to port did the trick. All is working with the latest version.
Do you have an idea how to send a UP/DOWN/STOP command in a rule to a rollershutter.
In the community I find different commands (integer, ON, UP,…).
I’m no way a script/rule expert but maybe UP, DOWN, STOP? Please note Nikobus roller-shutter modules do not support setting its position (i.e. 30%) nor they are able to provide feedback about position …
Hi Bart,
Out of curiosity, what did you do make Nikobus MQTT compatible?
Did you create some kind of MQTT client/server that is connected to the PC-link?
Hi crnjan,
Just see that you are working on a v2 binding for Nikobus. That is really great!
I planned to build me an extra OH2.5 server (I don’t want to experiment to mush on my running 2.4 set-up, the housemates would not like this). Now I see that there is an possibility to connect over IP? How do you do this? is this with some RS232 to IP converter?
Hi guys,
I also want to build an extra OH server to try this Nikobus v2 binding.
Does any of you know if it’s possible to use two different OH-Nikobus installations (v1 and v2) simultaneously using both a connection to a PC-Link and a PC-Logic? Or is this a bad idea?
Also interested in an IP connection to my Nikobus installation.
Nikobus v2 binding was merged about two weeks ago and should be available with latest OH snapshots.
That said, please note there is one change pending:
EVERY thing must at least have one configuration parameter, but it seems you have a few that do not have those at all. Note that the Thing id must not carry any semantics, but it can be defined by the user in any way he wants. Your address should thus probably be a configuration parameter.
This is purely a configuration change so instead of
Thing dimmer-module 6B00
one will need to use
Thing dimmer-module XXXX [ address="6B00" ]
where XXXX can be whatever one wants to use 
So long story short - if you use the available v2 Nikobus binding now, please keep in mind that you will need to update the config as written above when binding is updated.
If one wants to use a TCP/IP connection, please use something like //<ip>:<port>
Bridge nikobus:pc-link:mypclink [ port = "//192.168.3.52:3000" ]
You can use a ser2net or similar tool to do the serial/tcpip bridge.
Yesterday I started to create an extra Openhab setup to test this new Nikobus V2 binding. I created a Openhab 2.5M4 server and used a snapshot Nikobus V2 binding.
So far so good, but now I have a problem creating the bridge and the things.
In the log I see this: Cannot create thing. No binding found that supports creating a thing of type 'nikobus:pc-link'. But when I see in the “Configuration > Bindings” of the paper UI, the Nikobus binding is there.
When I login into the opehab console and check the status of the binding I get this:
244 x Waiting x 80 x 2.5.0.201910230335 x org.openhab.binding.nikobus
Why is the status waiting? and how can I set is to active?
When I remove the snapshot binding and use the paper UI to install the 2.5M4 Nikobus binding it seems to work (the binding is active). But I don’t know or the 2.5M4 binding is the lasted version of the Nikobus V2 binding and if this is working well.
I would say that any Nikobus v2 version that you were able to install through the PaperUI is safe to use 
ok, thanks!
At this moment I am conversing my Nikobus setup to the new binding.
By the way, is there a way to check that the serial connection to the PC-link is ok?
The status of my PC-link thing is “unknown” and I think that the connection is not ok.
when I use:
Thing dimmer-module D1 "dimmer module 1" [ address="6B00" ]
I got a error message in the log:
2019-10-27 11:22:50.572 [ERROR] [ome.core.thing.link.ThingLinkManager] - Exception occurred while informing handler: Address must have 4 chars but got 'D1'
java.lang.IllegalArgumentException: Address must have 4 chars but got 'D1'
when I use:
Thing dimmer-module 6B00 "dimmer module 1"
I got no errors, what is now the correct manner to do this?
EDIT
It worked with the following notation:
Bridge nikobus:pc-link:PCL1 [port="/dev/ttyUSB0", refreshInterval=30]{
Thing switch-module 7026 "Nikobus switch module 1"
Thing push-button A07C1A "Nikobus button BP53-A" [impactedModules = "7026-1"]
Thing push-button E07C1A "Nikobus button BP53-B" [impactedModules = "7026-1"]
}
It seems to update very well.
Next thing I want to test → emulate buttons.
How do I make the difference between a short and a long press?
A small question, do you use this binding on a OH2.4 setup?
I was wondering if it is possible to use this binding already on my working OH2.4 setup.
Now I build a extra OH2.5M4 setup to test the binding.
Hi!
Until PR is merged you will need to use the
Thing dimmer-module 6B00
syntax. As said, this is (pending) configuration change while functional wise the binding should work.
That said, there is no separation between long/short press in v2 (and Nikobus does not contain such differentiation AFAIK) so v2 binding will trigger each button press to OH - I guess one can use rules or other OH features to transform/get long press from Nikobus button events, if needed.
No, I use 2.5M3
Can you give some examples how to detect/extract a long press from a Nikobus button press event?
I have no idea how to do that.
I need long press detection to perform for example “all off” functionality from a long nikobus button press to other OH bindings.
When you press a Nikobus button, this button keeps sending it’s button address as long as you presses the button (for a maximum of about 7 seconds). So you can use the amount of time that the address is received to define a short of long press.
I don’t know how it is working in the v1 binding but isn’t it possible to convert the long press detection from the v1 binding in your v2 binding?
Today I tested with the rollershutter module and I see two strange things:
- Status of the output (icon) is not changing when I use a Nikobus button to control the shutter output. When I use the controls of the “classic UI” the icon is changing according to the movement of the shutter module.
- When using the controls of the “classic UI” and you change the direction from up to down or vice versa, the motor suddenly changes direction. This is verry bad for the motors. Is it possible to have every direction command preceded by a stop command and a waiting time of at least 500ms? This way there wil a stop and a delay when changing the direction of the motor.
Hi everyone,
thanks a lot to crnjan for this amazing work.
i’m totaly new to OH and just installed OH2.5 in order to use this binding.
i don’t have a pc-link (05-200) in my setup, but only a feedback-module 05-207.
it seems like in the binding V1 we could use this module as our main communication medium. is it still a possibility with this new binding ?
if it is i’d love to have a little more gidance cause i’m not able to make it works at the time.
thanks again for yout work, looking forward to contribute
Hi TouF, welcome to the community!
Normaly you can use the PC-link, PC-logic and feedback module.
keep in mind that you can’t connect openhab and a touchscreen at the same time to the feedback module!
thanks @DaanDW.
if 05-207 should be compatible, then i still have connectivity issue.
i’m running RPi3 with openhab and the daily build OH2.5, i only installed this binding.
i’m connecting to the feedback module threw a usb/serial adapter that is recognized as /dev/ttyUSB0
the “bridge” is seen as being “online”, although i don’t really know the tests it does to validate that status.
13:44:49.096 [INFO ] [s.internal.protocol.NikobusConnection] - Connected to /dev/ttyUSB0
13:44:49.106 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'nikobus:pc-link:mypclink' changed from UNKNOWN to ONLINE
appart from that “online” status, i’m still under the impression that i have connectivity issue.
when i look at the logs, it doesn’t seems to communicate
13:51:48.980 [DEBUG] [internal.handler.NikobusModuleHandler] - Refreshing nikobus:switch-module:mypclink:7830 - [FIRST]
13:51:48.986 [DEBUG] [internal.handler.NikobusModuleHandler] - Refreshing group FIRST of switch module '7830'
'3:51:48.997 [DEBUG] [internal.handler.NikobusPcLinkHandler] - Sending retry = 3, command '$10127830563C9C
'3:51:51.006 [DEBUG] [internal.handler.NikobusPcLinkHandler] - Sending retry = 2, command '$10127830563C9C
'3:51:53.013 [DEBUG] [internal.handler.NikobusPcLinkHandler] - Sending retry = 1, command '$10127830563C9C
'3:51:55.021 [DEBUG] [internal.handler.NikobusPcLinkHandler] - Sending retry = 0, command '$10127830563C9C
13:51:57.030 [WARN ] [internal.handler.NikobusModuleHandler] - Processing response for '7830'-FIRST failed with Waiting for response timed-out.
java.util.concurrent.TimeoutException: Waiting for response timed-out.
i also got no feedback when i push the yellow button of the modules, even thew i do here a bip and see the transmit leds of the feedback module blinking.
i saw a reference to “serial transport v2”.
it seems that it should be auto installed as a core module when the dependances requieres it. is there a way to check if i have the correct version ?
i also tried feature:install openhab-transport-serial but my results are still the same.
does anyone have any idea of the thing i could be missing ? or any kind of further testing i should try ?