@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.
Unfortunately no - I removed it when doing the PR since I used the discovery during development and testing - so tapping a physical Nikobus button did add it to Inbox. To be honest I was expecting mainly people migrating from v1 -> v2 where usually they already have all the addresses …
If a lot of people would find this use-full than might give it another shot
in the meanwhile I’m also trying to move my Nikobus setup from V1 to V2. There’s 1 issue I’m still struggling with: virtual buttons.
I have configured virtual buttons in the Nikobus software that behave like a Pushbutton. I’m using them for scenes, …
Unfortunately I don’t find how to trigger those pushbuttons by using rules. I want to trigger for instance a virtual pushbutton (in a rule) which activates then for instance a scene.
I have used the following command in a rule, but it doesn’t seem to work:
Gen_knop_4A_Nikobus.sendCommand(ON)
“Gen_knop_4A_Nikobus” is defined as a thing and should behave like a pushbutton.
Above setup feels fine and should work the way described - to be honest haven’t really tried if it actually works so might be a bug. Can you please share your setup so I can give it a spin?
If I understand correctly, than you should not need a rule - just use Gen_knop_4A_Nikobus_1_7 as a switch - so in .items file define
Switch Gen_knop_4A_Nikobus_1_7 "Test"
and add it to your sitemap - when switched on, it should send B3F3CF to the Nikobus … Haven’t tried that myself, so please let me know if it works, otherwise I can take a look …
Let’s assume then a different scenario. I want to activate " Gen_knop_4A_Nikobus_1_7" based on a cron job.
rule "Test cron" when Time cron "0 00 06 ? * MON-SUN " then Gen_knop_4A_Nikobus_1_7.sendCommand(ON)
Gen_knop_4A_Nikobus_1_7 (virtual button in Nikobus software) would then activate a scene/sphere (created in the Nikobus software). According to me this will not work with the rule described …
Just tried locally and works fine. Seems as I didn’t read your post thoroughly, but your item is not correct - you need to reference thing’s channel from your item, i.e.:
Hello, thank you for your answer. I changed the syntax but it doesn’t work yet. My Nikobus push button address is: 166F56. Is it necessary to transform it as for the output modules?
