And here I am again 
. I have added all my Velux actuators as things via PaperUI. These things have a single channel âPositionâ. With this I created items in my .items file:
Slider Window_FF_Office "Window" (FF_Office, Windows, WindowsWest) {channel="velux:window:4d14cadc:Fenster_Treppe:position"
To these I refer in the sitemap but when moving the slider nothing happens.
Do I have to create the things manually in a .things file or what am I doing wrong?
@saua,
thanks for your log. According to this file, the binding has found two scenes and 12 products with different names. What does really make problems, is the following entry:
Product "" / UNDEFTYPE (bridgeIndex=11,serial=,position=C800)
Is this a real device - just with a missing name?
Hello Jonas (@sloth0815),
if you are within paperUI, you can just add the item (personally I prefer Rollershutter) via Configuration->Items->PLUS with using the identifier found at Configuration->Things->Fenster_Treppe->Channels->Control->CopyToClipboard-Button as name (with replacing the colons by underscores).
Much easier is the way to enable auto-link (Configuration->System-> Item Linking->SimpleMode = ON).
I think that is the issue. I only see a single channel âPositionâ and no âControlâ channel. When clicking on the âshow moreâ button the only additional button I see is âlinked itemsâ.
Actually, now I see âPositionâ and âEnabling silent modeâ after clicking on âshow moreâ.
Thanks for the analysis, @gs4711. That product was one that I found but not named, so it had the default name in the UI (âExternal Ventian Blind 11â). Iâll remove it since it was one that was âaccidentallyâ connected to anyway (probably one of my neighbours ;-)).
After forcing sequential handling (I think!) and removing the âunnamedâ entry from the KLF200, I still see the same (or very similar) exceptions in my log:
2019-09-17 11:18:48.609 [DEBUG] [ng.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(): working on response GW_GET_ALL_NODES_INFORMATION_FINISHED_NTF with 0 bytes of data.
2019-09-17 11:18:48.611 [DEBUG] [ding.velux.bridge.slip.SCgetProducts] - setResponse(GW_GET_ALL_NODES_INFORMATION_FINISHED_NTF with 0 bytes of data) called.
2019-09-17 11:18:48.614 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): handling response GW_GET_ALL_NODES_INFORMATION_FINISHED_NTF (0x205).
2019-09-17 11:18:48.616 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): got GW_GET_ALL_NODES_INFORMATION_FINISHED_NTF.
2019-09-17 11:18:48.618 [DEBUG] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): finished-packet received.
2019-09-17 11:18:48.621 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): finished=true,success=true.
2019-09-17 11:18:48.623 [DEBUG] [ng.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(GW_GET_ALL_NODES_INFORMATION_REQ) returns success.
2019-09-17 11:18:48.625 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - getProducts(): returning array of 11 products.
2019-09-17 11:18:48.631 [DEBUG] [ng.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(GW_COMMAND_SEND_REQ,authenticated) called.
2019-09-17 11:18:48.638 [DEBUG] [ng.velux.bridge.slip.SlipVeluxBridge] - io(): sending packet of size 73.
2019-09-17 11:18:49.641 [DEBUG] [ng.velux.bridge.slip.SlipVeluxBridge] - io(): received packet with 9 bytes.
2019-09-17 11:18:49.645 [DEBUG] [ng.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(): working on response GW_GET_ALL_NODES_INFORMATION_CFM with 2 bytes of data.
2019-09-17 11:18:49.649 [WARN ] [ding.velux.bridge.slip.SCsendCommand] - Gateway response GW_GET_ALL_NODES_INFORMATION_CFM (515) cannot be handled at this point of interaction.
2019-09-17 11:18:49.654 [DEBUG] [ng.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(GW_COMMAND_SEND_REQ) returns failure.
2019-09-17 11:18:49.657 [DEBUG] [ding.velux.bridge.slip.SCgetProducts] - getRequestCommand() returns GW_GET_ALL_NODES_INFORMATION_REQ (0x202).
2019-09-17 11:18:49.661 [DEBUG] [ng.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(GW_GET_ALL_NODES_INFORMATION_REQ,authenticated) called.
2019-09-17 11:18:49.666 [DEBUG] [ng.velux.bridge.slip.SlipVeluxBridge] - io(): sending packet of size 7.
2019-09-17 11:18:50.671 [DEBUG] [ng.velux.bridge.slip.SlipVeluxBridge] - io(): received packet with 131 bytes.
2019-09-17 11:18:50.697 [DEBUG] [ng.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(): working on response GW_GET_ALL_NODES_INFORMATION_NTF with 124 bytes of data.
2019-09-17 11:18:50.709 [DEBUG] [ding.velux.bridge.slip.SCgetProducts] - setResponse(GW_GET_ALL_NODES_INFORMATION_NTF with 124 bytes of data) called.
2019-09-17 11:18:50.714 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): handling response GW_GET_ALL_NODES_INFORMATION_NTF (0x204).
2019-09-17 11:18:50.718 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): got GW_GET_ALL_NODES_INFORMATION_NTF.
2019-09-17 11:18:50.722 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - isLengthValid() called for GW_GET_ALL_NODES_INFORMATION_NTF (0x204) with 124 bytes of data.
2019-09-17 11:18:50.726 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - isLengthValid() returns true.
2019-09-17 11:18:50.731 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): ntfNodeID=0.
2019-09-17 11:18:50.738 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): ntfOrder=0.
2019-09-17 11:18:50.744 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): ntfPlacement=0.
2019-09-17 11:18:50.749 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): ntfName=Wohnzimmer SchiebetĂŒr.
2019-09-17 11:18:50.755 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): ntfVelocity=1.
2019-09-17 11:18:50.759 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): ntfNodeTypeSubType=1088.
2019-09-17 11:18:50.765 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): ntfProductGroup=0.
2019-09-17 11:18:50.770 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): ntfProductType=0.
2019-09-17 11:18:50.774 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): ntfNodeVariation=0.
2019-09-17 11:18:50.777 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): ntfPowerMode=0.
2019-09-17 11:18:50.780 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): ntfSerialNumber=[0, 0, 0, 0, 0, 0, 0, 0].
2019-09-17 11:18:50.783 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): ntfState=5.
2019-09-17 11:18:50.786 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): ntfCurrentPosition=0.
2019-09-17 11:18:50.789 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): ntfTarget=51200.
2019-09-17 11:18:50.792 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): ntfFP1CurrentPosition=63487.
2019-09-17 11:18:50.794 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): ntfFP2CurrentPosition=63487.
2019-09-17 11:18:50.796 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): ntfFP3CurrentPosition=63487.
2019-09-17 11:18:50.798 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): ntfFP4CurrentPosition=63487.
2019-09-17 11:18:50.800 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): ntfRemainingTime=0.
2019-09-17 11:18:50.802 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): ntfTimeStamp=1325483165.
2019-09-17 11:18:50.804 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): ntfNbrOfAlias=0.
2019-09-17 11:18:50.806 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): ntfAliasOne=0.
2019-09-17 11:18:50.811 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): ntfAliasTwo=0.
2019-09-17 11:18:50.819 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): ntfAliasThree=0.
2019-09-17 11:18:50.822 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): ntfAliasFour=0.
2019-09-17 11:18:50.825 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): ntfAliasFive=0.
2019-09-17 11:18:50.827 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): nodeId=0.
2019-09-17 11:18:50.830 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): nodeName=Wohnzimmer SchiebetĂŒr.
2019-09-17 11:18:50.833 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): productNodeTypeSubType=1088 (UNDEFTYPE).
2019-09-17 11:18:50.837 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): productProductType=0.
2019-09-17 11:18:50.840 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): productCurrentPosition=0.
2019-09-17 11:18:50.843 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): productNodeVariation=0.
2019-09-17 11:18:50.846 [DEBUG] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): device provided invalid serial number, using name 'Wohnzimmer SchiebetĂŒr' instead.
2019-09-17 11:18:50.850 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.openhab.binding.velux.handler.VeluxHandler@1d38d95': 11
java.lang.ArrayIndexOutOfBoundsException: 11
at org.openhab.binding.velux.bridge.slip.SCgetProducts.setResponse(SCgetProducts.java:225) ~[?:?]
at org.openhab.binding.velux.bridge.slip.SlipVeluxBridge.bridgeDirectCommunicate(SlipVeluxBridge.java:341) ~[?:?]
at org.openhab.binding.velux.bridge.slip.SlipVeluxBridge.bridgeDirectCommunicate(SlipVeluxBridge.java:149) ~[?:?]
Iâm still under the impression that multiple commands are running at the same time (which may be fine) and get confused by getting each others responses.
It looks like SCsendCommand is getting the GW_GET_ALL_NODES_INFORMATION_CFM response and doesnât know how to handle it, thus SCgetProducts doesnât get it and doesnât reset productArray and nextProductArrayItem and just writes out of bounds.
Hello Joachim,
the message
occurs whenever the bridge returns more items as previously stated within the protocol handshake. Will take it back to Velux but for the time being, the binding will crosscheck the real number of returned actuator elements. If there is still an error (hopefully any places where empty product names might be confusing should be eliminated, now), please set loglevel to TRACE and send me the startup log information.
Thanks in advance, Guenther
BTW just for updating the README: the Somfy shutters does not provide a serial number and it is possible to give them an empty name?
I donât think thatâs actually the case here. As you can see in my log the AIOOBE happens on the very first GW_GET_ALL_NODES_INFORMATION_NTF message after the GW_GET_ALL_NODES_INFORMATION_REQ. If it were the case that you described I would expect one much later to go wrong.
Iâll experiment a bit more later today to hopeful produce a good log.
The Somfy shutters donât provide a serial number and the âempty nameâ was the result of just not manually providing one in the KLF 200 management UI (i.e. the items showed up with the default name of something like âExternal Ventian Blind 11â in the web interface).
Please try the latest jarfile which has included more sanity check. Thx.
One other question. I read in tech specs that a KLF 200 can control only:
âą A maximum of 5 individual motors for individual control or
âą A maximum of 200 VELUX INTEGRAÂź products divided into 5 groups
Can this be true?
I control 7 rollershutters with no problem.
Donât believe the technical specs or even the Velux support in this case. They donât seem to know what their own device can do.
couldnât agree more. The API spec says The system table in the gateway can store up to 200 actuators and up to three Beacons (RF repeaters). (page 25), Additionally the gateway has 10 contact input and 5 output relays. (page 106) And, in addition, on page 92 it is stated The KLF200 gateway can hold up to 32 scenes, holding up to 192 node positions. For example, one scene with 192 node positions or 32 scenes each holding 6 node positions.
Could you please share the source of this information, i.e. document id / release date? It must be outdatedâŠ
It is in german only
or here:
Thanks for this pointer. Iâll pass it back to the product manager ⊠he will not be amused about this translation.
This is weird. I get the same exceptions with the same line numbers in this version, even though the array access is now on a different line.
Iâve double-checked that Iâm using the new snapshot file (the one without a date appended from https://github.com/gs4711/org.openhab.binding.velux/commit/4ab0fc70b9816c501c31727a4a7e1646a38d5542). Iâve deleted the old copy from the system, so I donât know whatâs going on here âŠ
just got the confirmation: the handling of 200 nodes is no problem.
IMHO it should be sufficient for a normal use case 
.
Thanks for your efforts and sorry for this inconvenience: Could you please raise the debugging level to TRACE and provide the log file (PM possible, of course)?
This has something to do with the non-Velux device and I do not get the clue whatâs going on⊠
Apparently there is an OSGI cache that basically means manually replacing the snapshot jar does nothing unless the cache is cleaned (I even tried compiling the addon myself and when my manual addition didnât show up I got extra-suspicious).
Iâll try to produce a useful log file with full TRACE level logging and PM it to you soon.
Edit: my manual addition did show that my âisSequentialEnforcedâ config did apparently not take, so Iâll try to set that as well.
Hello,
I cantâ connect to my KLF200. I did the folowing, can anybody have a look if I missed something or did something wrong, please?
KLF 200, FW:KLF200-v2.0.0.71
Some Roof Windows connected to the KLF via thhe Webinterface (Wifi)
DHCP off, static IP to the KLF, itâs pingable.
OH2.4.0-1 openhabian on Raspi
copied the new
org.openhab.binding.velux-2.5.0-SNAPSHOT.jar
from 16.09.2019 to usr/share/openhab2/addons
(do I need OH2.5 for that Binding or is it working in OH2.4 as well)
Paper-UI:
Inbox -> + -> Velux Binding -> Searching⊠Nothing found
add manually -> Velux KLF200 -> static IP of KLF and PW (Wifi PW printed on case) set
Configuration -> Things: Velux KLF200 shows up, but offline
Log:
2019-09-18 16:57:54.411 [WARN ] [ing.velux.handler.VeluxBridgeHandler] - velux bridge login sequence failed; expecting bridge is OFFLINE.
2019-09-18 16:57:55.439 [INFO ] [ing.velux.handler.VeluxBridgeHandler] - handleCommand(): updating of item velux:klf200:388157aa:status (type velux:klf200/status) failed.
2019-09-18 16:57:56.463 [WARN ] [ing.velux.handler.VeluxBridgeHandler] - velux bridge login sequence failed; expecting bridge is OFFLINE.
So far⊠Did I miss something or did something wrong?
Thanks in advance,
Ingo
Hello Ingo @Windrad,
the installation steps, you have described, look fine to me. openHAB2.4.0 is fine - works well!
Could you please review the logfile for a line like:
[INFO ] [.binding.velux.internal.VeluxBinding] - veluxConfig[protocol=slip,ipAddress=192.168.1.1,tcpPort=51200,password=********,timeoutMsecs=1000,retries=5,refreshMsecs=10000,isBulkRetrievalEnabled=true]
Alternatively you could take a look into the properties of the KLF200 Thing within the paperUI to verify the settings.
Iâm not sure why this happens - but there are some users who reported that they had to use the default password velux123 for enabling the binding. Could you give it a try?
Regards, Guenther