As per conversations in this thread, the “naive” v1 binding based rollershutter implementation is not satisfactory therefore decided to spice it up a bit. Added an optional configuration parameter to rollershutter module’s channels (outputs) describing how much time does it take for a rollershutter to completely open (or close)
Binding uses this information to interpolate rollershutter’s position, please note the animating rollershutter (left of “Window” text):
On startup binding will assume completely open rollershutters but opening/closing a rollershutter once should bring it back in sync. Binding also turns off the module’s output after 5s, meaning if one sets
duration = 30s
binding will automatically switch Nikobus rollershutter module’s output to OFF after
30s + 5s = 35s
This can be changed in settings.
EDIT2: OH3 RC already contains all described features.
EDIT3: Stop-time was changed from 150% to a configurable amount of time, if not specified rollershutter’s output will be turned OFF after 5s. Updated post to reflect this info.
I’m using OH3 with Nikobus and working without a problem so far … can you share more details? Maybe which version of the binding are you using and you configuration? Thx!
Perform a module status query every x seconds (optional, defaults to 600 (10 minutes)).
refresh=60
On OH3 final it doesn’t work.
Config: binding 3.0.0
Openhabian 1.6.2
Rpi 3B+ (works perfect with zwave dongle and prolific serial-to-usb, so power seems not an issue)
user openhab added to dialout
Openhabian fixed permissions
lsusb
Bus 001 Device 005: ID 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090) - UZB
Bus 001 Device 004: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
dmesg
usb 1-1.3: pl2303 converter now attached to ttyUSB0
log:
21:25:39.193 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing ‘nikobus:pc-link:ead36cb534’ changed from UNKNOWN to UNINITIALIZED
21:25:39.300 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing ‘nikobus:pc-link:ead36cb534’ changed from UNINITIALIZED to UNINITIALIZED (DISABLED)
21:25:40.935 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing ‘nikobus:pc-link:ead36cb534’ changed from UNINITIALIZED (DISABLED) to INITIALIZING
21:25:40.975 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing ‘nikobus:pc-link:ead36cb534’ changed from INITIALIZING to UNKNOWN
I’m guessing a bit here, but it seems you were using v1 binding in your OH 2.3 based on your post above.
Nevertheless, if it worked with v1 binding, it should work with v2 too. Some comments on (a bit cryptic) info shared above:
21:25:40.975 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing ‘nikobus:pc-link:ead36cb534’ changed from INITIALIZING to UNKNOWN
your bridge seems to be configured fine, UNKNOWN probably just means there is no channel/item attached to it so bridge will not connect, adding a properly configured module/button will fix this.
Address does not look right, can you double check? Probably just B74F. Can you share your v1 config? Same address should be used as in v1.
-> Thing ‘nikobus:push-button:ead36cb534:eb7af8e5ca’ changed from UNKNOWN to OFFLINE (CONFIGURATION_ERROR): UID must have at least 3 segments.
Button’s configuration is also not correct - impactedModules is in wrong format, as error states, something like this should be used:
impactedModules: switch-module:19110213bc:2
Would suggest to start with a single switch module and when connection is established, build from there… Also, please check the docs since some things changed a bit from v1 -> v2 (as the impactedModules format for example).
EDIT: Regarding buttons - might be easier to use the new discovery feature (described a couple o posts above) to setup them … I have ~100 buttons and using discovery feature I finally added/mapped all (which was a bit painfull before)
Am checking right now with the modules. I added an output and tadaaa, works. All came online!
from time to time the concept of channels / things / items goes wrong in my head
But here nevertheless my actual setup which I’ll be converting tonight! Thanks a lot for pointing me in the right direction (even though my fuzzy question :))
I have a similar setup with a bridge, a dimmer module and 2 switch modules. The bridge is online, but the switch modules and dimmer module go offline. I tried adding a channel to a specific output used in Nikobus.
Seems as there is no ACK received from your modules - did you ever had a successful setup, either using v1 or v2 binding? How did you get module’s addresses? Can you set log level to DEBUG:
java.util.concurrent.TimeoutException: Waiting for response timed-out.
at org.openhab.binding.nikobus.internal.handler.NikobusPcLinkHandler.processTimeout(NikobusPcLinkHandler.java:315) [bundleFile:?]
at org.openhab.binding.nikobus.internal.handler.NikobusPcLinkHandler.lambda$4(NikobusPcLinkHandler.java:305) [bundleFile:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
openhab> log:tail
11:13:37.078 [DEBUG] [internal.handler.NikobusPcLinkHandler] - Received ack ‘$0517’
11:13:38.913 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler ChromecastHandler tried updating the thing status although the handler was already disposed.
11:13:39.056 [WARN ] [internal.handler.NikobusModuleHandler] - Processing response for ‘C45A’-SECOND failed with Waiting for response timed-out.
java.util.concurrent.TimeoutException: Waiting for response timed-out.
at org.openhab.binding.nikobus.internal.handler.NikobusPcLinkHandler.processTimeout(NikobusPcLinkHandler.java:315) [bundleFile:?]
at org.openhab.binding.nikobus.internal.handler.NikobusPcLinkHandler.lambda$4(NikobusPcLinkHandler.java:305) [bundleFile:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
11:14:01.040 [DEBUG] [internal.handler.NikobusModuleHandler] - Nothing to refresh for ‘nikobus:dimmer-module:d07b4f95c3:D1’
11:14:09.671 [DEBUG] [internal.handler.NikobusPcLinkHandler] - Received command ‘$1CE5C800FF0000000000691DFF’, ack = ‘$0517’
11:14:09.673 [DEBUG] [internal.handler.NikobusPcLinkHandler] - Processing response but no command pending
11:14:09.922 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler ChromecastHandler tried updating the thing status although the handler was already disposed.
11:14:31.043 [DEBUG] [internal.handler.NikobusModuleHandler] - Nothing to refresh for ‘nikobus:switch-module:d07b4f95c3:S2’
11:14:39.837 [DEBUG] [internal.handler.NikobusPcLinkHandler] - Received command ‘$1C5AC400000000000000FFF1E5’, ack = ‘null’
11:14:39.839 [DEBUG] [internal.handler.NikobusPcLinkHandler] - Processing response but no command pending
11:14:40.932 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler ChromecastHandler tried updating the thing status although the handler was already disposed.
11:15:01.045 [DEBUG] [internal.handler.NikobusModuleHandler] - Refreshing nikobus:switch-module:d07b4f95c3:S1 - [SECOND]
11:15:01.046 [DEBUG] [internal.handler.NikobusModuleHandler] - Refreshing group SECOND of switch module ‘C45A’
'1:15:01.047 [DEBUG] [internal.handler.NikobusPcLinkHandler] - Sending retry = 3, command '$1017C45A2B409B
11:15:01.071 [DEBUG] [internal.handler.NikobusPcLinkHandler] - Received ack ‘$0517’
'1:15:03.048 [DEBUG] [internal.handler.NikobusPcLinkHandler] - Sending retry = 2, command '$1017C45A2B409B
11:15:03.075 [DEBUG] [internal.handler.NikobusPcLinkHandler] - Received ack ‘$0517’
'1:15:05.051 [DEBUG] [internal.handler.NikobusPcLinkHandler] - Sending retry = 1, command '$1017C45A2B409B
11:15:05.078 [DEBUG] [internal.handler.NikobusPcLinkHandler] - Received ack ‘$0517’
'1:15:07.055 [DEBUG] [internal.handler.NikobusPcLinkHandler] - Sending retry = 0, command '$1017C45A2B409B
11:15:07.099 [DEBUG] [internal.handler.NikobusPcLinkHandler] - Received ack ‘$0517’
The address of the switch module seems to be correct
Cannot 100% see what address you have set for your module from above log, but you should have the address parameter set to 5AC4 imho (address from Nikobus software for module is not 1:1 due keeping backward compatibility with the v1 binding and same format is used in v2 too).
Great news! This address thing is actually very confusing - v1 binding (and consequently v2 since it follows same format) vs. Nikobus software. Probably should be better explained in readme/documentation … Will try to add something in this direction, but honestly I’m not the best at writing docs … so fell free to jump in …