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"}
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.
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.
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
) until the 