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) …
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 …
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?
@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 …
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.
@crnjan thank you for the workarround, this seems to work.
3 other questions:
How I can create a rule triggered by a Nikobus pushbutton thing (otherwise I also need to create extra items for all my button things)? I tried
when
Thing “nikobus:push-button:PCL1:BP31_A:button” received update ON
then
but this isn’t working
When I create a testrule which is send me a e-mail when pressing a Nikobus button I see that this rule is executed more than once (this is different behaviour as with the v1 binding). is there a manner to avoid this?
Can you give me some tips how I can detect long presses?
I find it easier to use the module addresses as seen in the Niko PC application (as opposed to the ones seen on the bus). To enable this I have proposed an update to the binding. @crnjan I did a PR for which you are now reviewer. Could you have a look if you would want to incorporate this?
Nikobus v1 binding handled button presses differently. While v2 forwards all button press events, v1 did not - when physical Nikobus button is pressed, it triggers a press command (button sends its address to the bus) every couple of milliseconds. V1 binding did not forward these events immediately and if 25 such events were received, each in window of 85ms (so no more than 85ms passed between each event), then it triggered a long press event. Otherwise we got short press.
Since above behaviour is somehow artificial (not directly related to Nikobus) and has a side effect of delaying every button press action to be precessed by OH (pressing button is not immediately processed by the binding) so causing additional delays with updating the UI it was removed from v2. Now every event is directly forwarded and can be processed at will.
However, I’m still planning to enable this short/long press functionality to be available via v2 binding too, when I have the time to do so …
This is Awesome. Was pointed to the fact a V2 version of the Nikobus was released when I saw in the press release that the V1 are not supported anymore in openhab 3.X . I gave up hope as Nikobus is not really know outside Belgium I think, making it a very niche product. Nikobus was the reason I started using Openhab. Great seeing it live on.
So I started immediately updating from V1 to V2. I went very smooth. No issues that I know off apart some related to openhap upgrade going from 2.2 to 2.5 .
Left with one button that gives a “OFFLINE - CONFIGURATION_ERROR” fault. Weird as the address is the same one as in the V1 version. Need to double check that address.
All “push button” items without the impactedModules = "<moduleType>:<moduleId>:<channelGroup>" in the configuration gives me a “OFFLINE-CONFIGURATION_ERROR” status.
? If yes, please see a couple of posts above for a workaround, there is already a PR that fixes that …
EDIT: I’m almost sure I’m the only one with Nikobus installation in my country
Thank you for your quick reply.
Found the problem. With the V1 version I added the Item switch (A switch that is programmed in the Nikobus controller to switch off all the lights) directly in the sitemap. Now in V2 this switch has become a Thing Push Button and it cannot be added anymore in the sitemap. Not sure yet how to do the same now its V2.5 binding, am not yet so familiar with V2 bindings.
The reason why I did this in V1 is because in V1 the bus got overloaded with all the commands if I wanted to switch off all the lights. (I have 1 big dimmer module and 3 big switch modules, so 48 channels in total). Something which made Google Assistant also less useful as it was impossible to command many lights at once. It was always a hit and miss of all the lights responded.
Didn’t have time to experiment yet much with the V2 binding, is this something that should be resolved in V2 or is this impossible due to the nature of Nikobus serial bases bus ?
Big thanks for the v2 update of the binding.
In the beginning of the post, you mentioned that we can auto detect the buttons.
Is this feature in the final release? I can’t find it.
I see that we can add them via paper UI manual.
V2 version has an improved communication implementation between binding and Nikobus PC-LINK - this means that even if a lot of commands are received (i.e. all lights off), binding will still process them, one by one - comparing with v1 where receiving a lot of commands in a short time could put the communication out-of-sync.
Each command send to Nikobus takes ~300ms if I remember correctly - so in order to turn off a light it will take about 300ms to execute. For normal use (turning on/off a single light) this is barely noticeable. But if we consider executing an “all off” scenario, this would take:
48 * 300ms = ~15 seconds
This is where a huge improvement could be made - Nikobus modules read/write values (channels) in groups, so 6 per operation. If binding would implement grouping of commands than we would get:
8 * 300ms = ~2.5 seconds
so - having 4 big modules (12 outputs) and 2 groups (6 outputs per group) per module -> 4 * 2 = 8
So a short answer would be - compared to v1, v2 should execute all commands reliable, but does not group them, so while being executed, it will take a bit of time.
) until the 
