[velux] New OpenHAB2 binding - feedback welcome!

It’s really great to see this binding. Thanks for the hard work @gs4711. Based on this binding, I’m about to order 9 new windows from VELUX. The windows I’m ordering include an outside sun protector and an inside blackout blind. These are apparently controllable by the KLF200. How many KLF200s would I need to buy for controlling the sun/blackout blinds on 8 windows? Would I then create duplicate binding configurations for each KLF?

Also out of curiosity I noticed that the binding includes a window open/closed indicator. Presumably this only works for electrically openable windows or did I miss the part where VELUX is shipping reed switches?

Quoting the technical manual (p. 25 of 119),

the gateway can store up to 200 actuators and up to three Beacons (RF repeaters).

Therefore, you’ll need only one KLF200.

For sensing the state of the windows, I have added some HomeMatic components HM-Sec-SCo for each windows to get a clearer view on the windows which are not maintained by the Velux stuff.

with the following files, the klf200 is connected to openhab.

velux.things:

Bridge velux:klf200:home  [bridgeIPAddress="192.168.0.177", bridgeProtocol="slip", bridgeTCPPort=51200, bridgePassword="xxxxxxxxxx", timeoutMsecs=15000, retries=15]

velux.cfg:

bridgeIPAddress=192.168.0.177
bridgeProtocol=slip
bridgeTCPPort=51200
bridgePassword=xxxxxxxx
timeoutMsecs=15000
retries=15

velux.items:

String  Velux_Firmware  "Firmware [%s]" { velux="thing=bridge;channel=firmware" }  
String  Velux_Status    "Status [%s]" { velux="thing=bridge;channel=status" } 
String  Velux_Check     "Velux Config Check [%s]" { velux="thing=bridge;channel=check" } 

Rollershutter DgZr_VeluxUnten	"DgZr Velux unten [%d]"	{ velux="thing=actuator;channel=serial#53:14:1E:26:12:25:03"}
Rollershutter DgZr_VeluxOben	"DgZr Velux oben [%d]"	{ velux="thing=actuator;channel=serial#53:14:1E:26:12:25:03"}

but i have three open questions.

  1. Value Velux_Firmware und Velux_Cehck are not available, always “-”

  2. the second problem is the configuration of two solar_sliders.
    the log-file show me the two solar slider with the same serial.

2018-12-11 17:57:56.429 [DEBUG] [ng.velux.bridge.VeluxBridgeActuators] - getProducts() storing new product Product "Rollo Samuel unten" / SOLAR_SLIDER (bridgeIndex=0,serial=53:14:1E:26:12:25:03,position=0000).

2018-12-11 17:57:56.432 [DEBUG] [ng.velux.bridge.VeluxBridgeActuators] - getProducts() storing new product Product "Rollo Samuel oben" / SOLAR_SLIDER (bridgeIndex=1,serial=53:14:1E:26:12:25:03,position=0000).

2018-12-11 17:57:56.435 [DEBUG] [ng.velux.bridge.VeluxBridgeActuators] - getProducts() finally has found products 444 members: Product "Rollo Samuel oben" / SOLAR_SLIDER (bridgeIndex=1,serial=53:14:1E:26:12:25:03,position=0000).

how can i configure this two sliders, when the serial is the same?

  1. the response time is very high … but this can problably be because a wrong configuration
    above

thanks for a good tip

Just to make sure to look onto the right issue:

The output of the binding starting with

2018-12-... [INFO ] [.binding.velux.internal.VeluxBinding] - Active items are:

is followed by the defined items mentioned in square brackets?

Just try this one for the file velux.items:

String V_BRIDGE_STATUS "Velux Bridge Status" { velux="channel;status" }

Sorry for the inconvenience but I’ve got only little experiences with the compat. mode.

Thanks for the tip … but it doesn’t work.

If I config the item like the post then this error is output in the log:

String  Velux_Status    "Status [%s]" { velux="channel;status" } 
2018-12-12 23:10:26.134 [ERROR] [el.item.internal.GenericItemProvider] - Binding configuration of type 'velux' of item 'Velux_Status' could not be parsed correctly.

Sorry: my mistake of having two similar entries for testing. Does this one work for you:

String V_STATUS "Status [%s]" { velux="thing=bridge;channel=status" }

With a fresh OH2 this leads me to a successful registration of the item:

2018-12-12 23:50:43.220 [TRACE] [internal.VeluxGenericBindingProvider] - getBindingType() called, returning velux.
2018-12-12 23:50:43.223 [TRACE] [internal.VeluxGenericBindingProvider] - validateItemType(itemName,thing=bridge;channel=status) called.
2018-12-12 23:50:43.226 [TRACE] [internal.VeluxGenericBindingProvider] - VeluxGenericBindingParser() thingIdentifierKey=thing.
2018-12-12 23:50:43.229 [TRACE] [internal.VeluxGenericBindingProvider] - VeluxGenericBindingParser() thingIdentifier=bridge.
2018-12-12 23:50:43.233 [TRACE] [internal.VeluxGenericBindingProvider] - VeluxGenericBindingParser() channelIdentifierKey=channel.
2018-12-12 23:50:43.235 [TRACE] [internal.VeluxGenericBindingProvider] - VeluxGenericBindingParser() channelIdentifier=status.
2018-12-12 23:50:43.239 [DEBUG] [internal.VeluxGenericBindingProvider] - VeluxGenericBindingParser() channelIdentifier=status, channelValue=.
2018-12-12 23:50:43.241 [TRACE] [binding.velux.internal.VeluxItemType] - getByThingAndChannel(bridge,status) called.
2018-12-12 23:50:43.245 [TRACE] [binding.velux.internal.VeluxItemType] - getByThingAndChannel() work on scene and action.
2018-12-12 23:50:43.247 [TRACE] [binding.velux.internal.VeluxItemType] - getByThingAndChannel() work on scene and silentMode.
2018-12-12 23:50:43.251 [TRACE] [binding.velux.internal.VeluxItemType] - getByThingAndChannel() work on bridge and status.
2018-12-12 23:50:43.253 [TRACE] [binding.velux.internal.VeluxItemType] - getByThingAndChannel() returns enum.
2018-12-12 23:50:43.257 [TRACE] [internal.VeluxGenericBindingProvider] - found config ‘thing=bridge;channel=status’: Item itemName is of type ‘StringItem’, which is allowed.
2018-12-12 23:50:43.260 [DEBUG] [internal.VeluxGenericBindingProvider] - validateItemType() returned w/o exception.
2018-12-12 23:50:43.263 [TRACE] [internal.VeluxGenericBindingProvider] - processBindingConfiguration(velux.items,V_B_STATUS,thing=bridge;channel=status) called.
2018-12-12 23:50:43.266 [TRACE] [internal.VeluxGenericBindingProvider] - VeluxGenericBindingParser() thingIdentifierKey=thing.
2018-12-12 23:50:43.269 [TRACE] [internal.VeluxGenericBindingProvider] - VeluxGenericBindingParser() thingIdentifier=bridge.
2018-12-12 23:50:43.272 [TRACE] [internal.VeluxGenericBindingProvider] - VeluxGenericBindingParser() channelIdentifierKey=channel.
2018-12-12 23:50:43.276 [TRACE] [internal.VeluxGenericBindingProvider] - VeluxGenericBindingParser() channelIdentifier=status.
2018-12-12 23:50:43.278 [DEBUG] [internal.VeluxGenericBindingProvider] - VeluxGenericBindingParser() channelIdentifier=status, channelValue=.
2018-12-12 23:50:43.280 [TRACE] [internal.VeluxGenericBindingProvider] - processBindingConfiguration() working on thing=bridge,channel=status.
2018-12-12 23:50:43.282 [TRACE] [internal.VeluxGenericBindingProvider] - processBindingConfiguration() found THING_VELUX_BRIDGE
2018-12-12 23:50:43.285 [TRACE] [ng.velux.internal.VeluxBindingConfig] - VeluxBindingConfig(constructor:bridge/status,thing=bridge;channel=status) called.
2018-12-12 23:50:43.287 [TRACE] [.binding.velux.internal.VeluxBinding] - getName() called.
2018-12-12 23:50:43.290 [DEBUG] [internal.VeluxGenericBindingProvider] - processBindingConfiguration(velux.items,V_B_STATUS,thing=bridge;channel=status) successfully finished.

Hello,

as far as I undestand for firmware 0.2.x it is necessary to install the 1.13.0 binding instead of 2.4.0. I am using the latest nightly of OpenHAB 2.4.0 and am then getting the following error message:

2018-12-16 15:27:36.516 [INFO ] [org.openhab.binding.velux           ] - FrameworkEvent INFO - org.openhab.binding.velux
org.osgi.framework.BundleException: The bundle class path entry "lib/gson-2.2.4.jar" could not be found for the bundle "osgi.identity; type="osgi.bundle"; version:Version="1.13.0.201811051916"; osgi.identity="org.openhab.binding.velux""

And the binding seems not to work (at least I don’t get a status of the KLF200 for the item). I followed the item, configuration and service settings from this thread.

But is it right that I need version 1.13.0? The error message seems to tell me different. Yet, the 2.4.0 binding doesn’t work either and talks about timeouts.

The OH2 binding does (up to now) only support the JSON protocol implemented in Velux firmware version 1.x. Therefore, if you activate this binding for a KLF with v2 firmware, you’ll end up with timeouts as the web interface for JSON communication has been disabled by Velux on the LAN interface.

Up the completion of the updated OH2 binding, the OH1 binding does run under OH2 in compatibility mode (with a minor warning about the mentioned missing lib - which is only used for JSON communication) fully supporting the new introduced SLIP message exchange of Velux firmware version 2.x.

Unfortunatelly the OH1 binding requires the old syntax of the item files, which might be misleading during the configuration phase.

1 Like

Hello @gs4711

thanks for your reply. I tried 1.13.0 but keep getting issues. It seems I cannot authenticate with the KLF, though I have not changed the password (velux123) nor done anything than add my Somfy products.

Is there a way to perform a request myself from my computer (like curl) to see whether the KLF responds?

Here’s my log output. Do you have any idea of what’s wrong?

2018-12-16 22:21:05.188 [TRACE] [g.velux.bridge.slip.io.SSLconnection] - send() called, writing 39 bytes.
2018-12-16 22:21:05.188 [TRACE] [g.velux.bridge.slip.io.SSLconnection] - send() finished after having send 39 bytes: C0 00 23 30 00 76 65 6C 75 78 31 32 33 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 51 C0
2018-12-16 22:21:05.188 [TRACE] [ng.velux.bridge.slip.SlipVeluxBridge] - io(): wait time 15000 msecs.
2018-12-16 22:21:20.188 [TRACE] [ng.velux.bridge.slip.SlipVeluxBridge] - io(): receiving bytes.
2018-12-16 22:21:20.189 [TRACE] [g.velux.bridge.slip.io.SSLconnection] - receive() called.
2018-12-16 22:21:20.189 [TRACE] [g.velux.bridge.slip.io.SSLconnection] - receive() finished after having read 8 bytes: C0 00 04 30 01 01 34 C0
2018-12-16 22:21:20.189 [TRACE] [ng.velux.bridge.slip.SlipVeluxBridge] - io(): received packet with 8 bytes: C0 00 04 30 01 01 34 C0
2018-12-16 22:21:20.190 [TRACE] [ng.velux.bridge.slip.SlipVeluxBridge] - io() finished.
2018-12-16 22:21:20.190 [TRACE] [ng.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(): received packet C0 00 04 30 01 01 34 C0.
2018-12-16 22:21:20.190 [TRACE] [g.velux.bridge.slip.util.SlipRFC1055] - decode() for packet size 8 called.
2018-12-16 22:21:20.190 [TRACE] [g.velux.bridge.slip.util.SlipRFC1055] - decode() provides payload: 00 04 30 01 01 34.
2018-12-16 22:21:20.191 [TRACE] [.velux.bridge.slip.util.SlipEncoding] - SlipEncoding(constructor) called for decoding a packet with size 6.
2018-12-16 22:21:20.191 [TRACE] [.velux.bridge.slip.util.SlipEncoding] - getCommand() returns 0x3001 .
2018-12-16 22:21:20.191 [TRACE] [.velux.bridge.slip.util.SlipEncoding] - getData() returns 1 bytes: 01.
2018-12-16 22:21:20.192 [TRACE] [.velux.bridge.slip.util.SlipEncoding] - SlipEncoding(constructor) successfully initialized with command 0x3001 and data 01.
2018-12-16 22:21:20.192 [TRACE] [.velux.bridge.slip.util.SlipEncoding] - getCommand() returns 0x3001 .
2018-12-16 22:21:20.192 [TRACE] [.velux.bridge.slip.util.SlipEncoding] - getData() returns 1 bytes: 01.
2018-12-16 22:21:20.192 [DEBUG] [ng.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(): working on response GW_PASSWORD_ENTER_CFM with 1 bytes of data.
2018-12-16 22:21:20.193 [TRACE] [ng.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(): passes back command 0x3001 and data 01.
2018-12-16 22:21:20.193 [DEBUG] [ab.binding.velux.bridge.slip.SClogin] - setResponse(GW_PASSWORD_ENTER_CFM with 1 bytes of data) called.
2018-12-16 22:21:20.193 [TRACE] [ab.binding.velux.bridge.slip.SClogin] - setResponse(): handling response GW_PASSWORD_ENTER_CFM (0x3001).
2018-12-16 22:21:20.193 [TRACE] [ab.binding.velux.bridge.slip.SClogin] - isLengthValid() called for GW_PASSWORD_ENTER_CFM (0x3001) with 1 bytes of data.
2018-12-16 22:21:20.194 [TRACE] [ab.binding.velux.bridge.slip.SClogin] - isLengthValid() returns true.
2018-12-16 22:21:20.194 [DEBUG] [ab.binding.velux.bridge.slip.SClogin] - setResponse(): returned status: The request failed.
2018-12-16 22:21:20.194 [TRACE] [ab.binding.velux.bridge.slip.SClogin] - setResponse(): finished=true,success=false.
2018-12-16 22:21:20.194 [DEBUG] [ng.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(GW_PASSWORD_ENTER_REQ) returns failure.
2018-12-16 22:21:20.195 [TRACE] [hab.binding.velux.bridge.VeluxBridge] - bridgeCommunicate(Get Bridge Device Status,authenticated) called.
2018-12-16 22:21:20.195 [TRACE] [hab.binding.velux.bridge.VeluxBridge] - isAuthenticated() returns false.
2018-12-16 22:21:20.195 [TRACE] [hab.binding.velux.bridge.VeluxBridge] - bridgeCommunicate(): no auth token available, aborting.
2018-12-16 22:21:20.195 [TRACE] [velux.bridge.VeluxBridgeDeviceStatus] - retrieve() finished with failure.
2018-12-16 22:21:20.196 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): updating of item V_STATUS (type BRIDGE_STATUS) failed.
2018-12-16 22:21:20.196 [TRACE] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel() done.
2018-12-16 22:21:20.196 [DEBUG] [.binding.velux.internal.VeluxBinding] - execute() done.
2018-12-16 22:21:35.196 [DEBUG] [.binding.velux.internal.VeluxBinding] - execute() called.
2018-12-16 22:21:35.197 [TRACE] [.binding.velux.internal.VeluxBinding] - execute(): working with VeluxBindingProvider org.openhab.binding.velux.internal.VeluxGenericBindingProvider@892d3bc.
2018-12-16 22:21:35.197 [TRACE] [internal.VeluxGenericBindingProvider] - getInBindingItemNames() returns [V_FIRMWARE, V_CHECK, V_STATUS].
2018-12-16 22:21:35.198 [TRACE] [internal.VeluxGenericBindingProvider] - getConfigForItemName(V_FIRMWARE) called.
2018-12-16 22:21:35.198 [TRACE] [internal.VeluxGenericBindingProvider] - getConfigForItemName() returns thing=bridge;channel=firmware.
2018-12-16 22:21:35.198 [TRACE] [binding.velux.internal.VeluxItemType] - isToBeRefreshed() returns false.
2018-12-16 22:21:35.199 [TRACE] [.binding.velux.internal.VeluxBinding] - execute(): ignoring item V_FIRMWARE as not-refreshable.
2018-12-16 22:21:35.199 [TRACE] [internal.VeluxGenericBindingProvider] - getConfigForItemName(V_CHECK) called.
2018-12-16 22:21:35.199 [TRACE] [internal.VeluxGenericBindingProvider] - getConfigForItemName() returns thing=bridge;channel=check.
2018-12-16 22:21:35.200 [TRACE] [binding.velux.internal.VeluxItemType] - isToBeRefreshed() returns true.
2018-12-16 22:21:35.200 [TRACE] [binding.velux.internal.VeluxItemType] - getRefreshDivider() returns 5760.
2018-12-16 22:21:35.200 [TRACE] [.binding.velux.internal.VeluxBinding] - execute(): refresh cycle not yet come for item V_CHECK.
2018-12-16 22:21:35.200 [TRACE] [internal.VeluxGenericBindingProvider] - getConfigForItemName(V_STATUS) called.
2018-12-16 22:21:35.201 [TRACE] [internal.VeluxGenericBindingProvider] - getConfigForItemName() returns thing=bridge;channel=status.
2018-12-16 22:21:35.201 [TRACE] [binding.velux.internal.VeluxItemType] - isToBeRefreshed() returns true.
2018-12-16 22:21:35.201 [TRACE] [binding.velux.internal.VeluxItemType] - getRefreshDivider() returns 1.
2018-12-16 22:21:35.202 [TRACE] [.binding.velux.internal.VeluxBinding] - execute(): refreshing item V_STATUS.
2018-12-16 22:21:35.202 [DEBUG] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(item=V_STATUS,command=null,config=org.openhab.binding.velux.internal.VeluxBindingConfig@50e5f57e,provider=org.openhab.binding.velux.internal.VeluxGenericBindingProvider@892d3bc) called.
2018-12-16 22:21:35.203 [TRACE] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): work on updated bridge configuration parameters.
2018-12-16 22:21:35.203 [DEBUG] [.velux.handler.VeluxBridgeHandlerOH1] - bridgeParamsUpdated() called.
2018-12-16 22:21:35.203 [DEBUG] [.velux.handler.VeluxBridgeHandlerOH1] - bridgeParamsUpdated(): choosing SLIP as communication method.
2018-12-16 22:21:35.203 [TRACE] [hab.binding.velux.bridge.VeluxBridge] - bridgeLogin() called.
2018-12-16 22:21:35.204 [TRACE] [ng.velux.bridge.slip.SlipVeluxBridge] - bridgeAPI() called.
2018-12-16 22:21:35.204 [TRACE] [ab.binding.velux.bridge.slip.SClogin] - setPassword(velux123) called.
2018-12-16 22:21:35.204 [TRACE] [hab.binding.velux.bridge.VeluxBridge] - bridgeCommunicate(Authenticate / login,unauthenticated) called.
2018-12-16 22:21:35.205 [TRACE] [hab.binding.velux.bridge.VeluxBridge] - isAuthenticated() returns false.
2018-12-16 22:21:35.205 [TRACE] [hab.binding.velux.bridge.VeluxBridge] - bridgeCommunicate(): no auth token available, continuing.
2018-12-16 22:21:35.205 [TRACE] [ng.velux.bridge.slip.SlipVeluxBridge] - bridgeAPI() called.
2018-12-16 22:21:35.206 [TRACE] [ding.velux.bridge.slip.SlipBridgeAPI] - bridgeDirectCommunicate(org.openhab.binding.velux.bridge.slip.SClogin@1a90d71a,false) called.
2018-12-16 22:21:35.206 [TRACE] [ng.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(Authenticate / login,unauthenticated) called.
2018-12-16 22:21:35.206 [DEBUG] [ng.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(GW_PASSWORD_ENTER_REQ,unauthenticated) called.
2018-12-16 22:21:35.206 [DEBUG] [ng.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(): working on request GW_PASSWORD_ENTER_REQ with 32 bytes of data.
2018-12-16 22:21:35.207 [TRACE] [.velux.bridge.slip.util.SlipEncoding] - SlipEncoding(constructor) for command 0x3000 with data size 32 called.
2018-12-16 22:21:35.207 [TRACE] [.velux.bridge.slip.util.SlipEncoding] - SlipEncoding(constructor) successfully initialized, storing bytes: 00 23 30 00 76 65 6C 75 78 31 32 33 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 51.
2018-12-16 22:21:35.208 [TRACE] [ng.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(): transportEncoding=00 23 30 00 76 65 6C 75 78 31 32 33 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 51.
2018-12-16 22:21:35.208 [TRACE] [g.velux.bridge.slip.util.SlipRFC1055] - encode() for data size 37 called.
2018-12-16 22:21:35.208 [TRACE] [g.velux.bridge.slip.util.SlipRFC1055] - encode() provides transfer encoding: C0 00 23 30 00 76 65 6C 75 78 31 32 33 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 51 C0.
2018-12-16 22:21:35.208 [TRACE] [ng.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(): sending 39 bytes to 10.0.2.176:51200.
2018-12-16 22:21:35.208 [TRACE] [ng.velux.bridge.slip.SlipVeluxBridge] - io(10.0.2.176,51200,39 bytes) called.
2018-12-16 22:21:35.209 [TRACE] [ng.velux.bridge.slip.SlipVeluxBridge] - io(): sending packet with 39 bytes: C0 00 23 30 00 76 65 6C 75 78 31 32 33 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 51 C0
2018-12-16 22:21:35.209 [TRACE] [g.velux.bridge.slip.io.SSLconnection] - send() called, writing 39 bytes.

Hello,
thanks for this trace-level log which definitely shows that the KLF refuses the access:

The returned data byte with value one simply means that the device is responding with a login-failed according to the Velux specification.

You won’t have success with a web browser due to the SLIProtocol - but, if you like command line interfaces, you can test the login onto your KLF200 box using the demo script presented on https://www.velux.com/api/klf200 - download demo.

Hi @gs4711

that was a brilliant link to the Python scripts. However, it seems that something is broken. When starting the discover script, it tells me

$ python3 Discover.py
Send valid password
Received:  00:04:30:01:ab:34

Discover all node types
Received:  00:04:00:00:ac:08

Error: No SLIP frame!

Received:

Finished

Do you have any idea what the cause there might be? I have not changed the default password (velux123). Interestingly, the setup.py has a velux1234 default password in there (which doesn’t work either).

If neither this python script nor the binding works, there might be a problem with the KLF200. I suggest to try a factory reset and start with the default password, again.

Hi Guenther,
sorry to disturb you but i have the same error in the log msg about the bundle but can login to the klf200 and it and it shows the products and scenes in the log msg.
But what about the error ?
i received the error after upgrading from openhabian 2.3 to 2.4 with openhabian-config.

org.osgi.framework.BundleException: The bundle class path entry “lib/gson-2.2.4.jar” could not be found for the bundle “osgi.identity; type=“osgi.bundle”; version:Version=“1.13.0.201811051916”; osgi.identity=“org.openhab.binding.velux””

also my shutters seems to work in the habpanel en basic ui, classic ui, but not on my windows, i asume that there is a problem in the items or sitemap files wich i created with the demo homebuilder.
i have searched for item and sitemap files but cannot find some where the velux shutters are used, maybe you have something as reference ?

Hi John, what firmware version do you use on the KLF200? The JSON library is only necessary for the firmware v1 being contacted via the webinterface with JSON/HTTP.

What is the exact issue if the items work with basicUI and classicUI?

Hi Guenther,
i am running the new firmware 0.2.0.0.71.0 on the klf200 .
The problem is that i see below msg in the log
[2018-12-26 19:17:37.719 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Time zone set to ‘Europe/Amsterdam’.

2018-12-26 19:17:37.735 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Locale set to ‘nl_NL’.

2018-12-26 19:17:37.799 [INFO ] [ebuilder.internal.HomeBuilderServlet] - Started Home Builder at /homebuilder

2018-12-26 19:17:37.865 [INFO ] [panel.internal.HABPanelDashboardTile] - Started HABPanel at /habpanel

2018-12-26 19:17:46.653 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘Onshuis.items’

2018-12-26 19:17:46.909 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘Velux.items’

2018-12-26 19:17:50.241 [INFO ] [thome.model.lsp.internal.ModelServer] - Started Language Server Protocol (LSP) service on port 5007

2018-12-26 19:17:51.416 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘Onshuis.sitemap’

2018-12-26 19:17:51.839 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘Velux.things’

2018-12-26 19:17:52.936 [INFO ] [inding.velux.internal.VeluxActivator] - velux binding has been started.

2018-12-26 19:17:53.070 [INFO ] [.dashboard.internal.DashboardService] - Started Dashboard at http://192.168.0.29:8080

2018-12-26 19:17:53.074 [INFO ] [.dashboard.internal.DashboardService] - Started Dashboard at https://192.168.0.29:8443

2018-12-26 19:17:53.708 [INFO ] [.binding.velux.internal.VeluxBinding] - Active items are: [V_FIRMWARE, V_CHECK, V_STATUS].

2018-12-26 19:17:53.717 [INFO ] [.binding.velux.internal.VeluxBinding] - velux refresh interval set to 15000 milliseconds.

2018-12-26 19:17:53.739 [INFO ] [.binding.velux.internal.VeluxBinding] - veluxConfig[bridgeProtocol=slip,bridgeIPAddress=192.168.0.6,bridgeTCPPort=51200,bridgePassword=********,timeoutMsecs=15000,retries=15,refreshMsecs=15000,isBulkRetrievalEnabled=true]

2018-12-26 19:17:53.745 [INFO ] [b.core.service.AbstractActiveService] - velux Refresh Service has been started

2018-12-26 19:17:53.778 [INFO ] [g.velux.bridge.slip.io.SSLconnection] - Starting velux bridge connection.

2018-12-26 19:17:55.063 [INFO ] [arthome.ui.paper.internal.PaperUIApp] - Started Paper UI at /paperui

2018-12-26 19:17:55.826 [INFO ] [ui.habmin.internal.servlet.HABminApp] - Started HABmin servlet at /habmin

2018-12-26 19:18:13.435 [INFO ] [ab.binding.velux.bridge.slip.SClogin] - velux bridge connection successfully established (login succeeded).

2018-12-26 19:18:58.591 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - Found velux scenes:

Scene "slaapkamer sluiten" (index 0) with non-silent mode and 0 actions

Scene "Keuken openen" (index 3) with non-silent mode and 0 actions

Scene "Slaapkamer openen" (index 1) with non-silent mode and 0 actions

Scene "Keuken sluiten" (index 2) with non-silent mode and 0 actions	.

2018-12-26 19:19:13.660 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - Found velux actuators:

Product "Keuken" / ROLLER_SHUTTER (bridgeIndex=1,serial=00:00:00:00:00:00:00,position=C800)

Product "Slaapkamer" / ROLLER_SHUTTER (bridgeIndex=0,serial=53:2A:5D:5A:12:10:3A,position=9D10)	.

2018-12-26 19:19:13.663 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - velux Bridge is online,]

I have controls for the shutters on the habpanel and Basic ui and the Classic ui, but fysical there is nothing moving only the shutter icons on the panels are changing but the shutters self are not.
And i dont know where to put trhe scenes and the actuators, now the scenesare in the velux.things and actuators in the velux.items

Hi John,

just try this configuration. For convenience, the items are split into a generic bridge part and the device specific part:

// Velux Bridge channels

String	V_FIRMWARE	"Firmware [%s]"				 	{ velux="thing=bridge;channel=firmware" }
String	V_STATUS	"Status [%s]"				 	{ velux="thing=bridge;channel=status" }
String	V_CHECK		"Velux Config Check [%s]"			{ velux="thing=bridge;channel=check" }

// Velux IO-homecontrol devices

Rollershutter V_Keuken	"Keuken [%d]"					{ velux="thing=actuator;channel=serial#00:00:00:00:00:00:00" }
Rollershutter V_Slaapkamer "Slaapkamer [%d]"				{ velux="thing=actuator;channel=serial#53:2A:5D:5A:12:10:3A" }

//
// end-of-items/velux.items
//

For using it with classicUI, just define a sitemap like:

sitemap default label="MySweetHome"
{
	Frame label="IO-Homecontrol" {
		Switch	item=V_Keuken
		Switch	item=V_Slaapkamer
		Text	item=V_STATUS
	}	
}

Then, the both shutters should be managable.

BTW the serial number of 00:00:00:00:00:00 sounds strange to me - is this an original velux device?

Hi Guenther,
your right, they move now but it looks that when i pushed up they go down, any idea how to change that ?
and also the serial with the zeros thats correct it isnt a Velux but a shutter that has a Somfy io motor in it.
when i started with the shutters on my home i just tryed if the KLF200 wich was on the old firmware could find it and it did, so that is why the serial is only zeros i think.
I asume that if i would change it to a real Somfy binding i also need a bridge from them ?

Thanks for your help sofar, i am afraid that i have more questions later because i am just a starter in this.

Thanks, John, for the feedback. In general, the somfy devices should work as well as expected.

In fact, I’d like to dig deeper whether there is an issue with the values returned and expected from the somfy devices. Could you please turn on the debugging with level TRACE and share the output for a sequence of opening or closing the shutters? For your convenience you could send the logfile via PM to avoid much noise within this topic.

Hi Guenther,

I did install the Velux 1.13 binding and I can confirm that some Rollo’s moved at least up and down but not all at once. Somehow stored scene were not discovered. But I have an other problem with the items configuration. Binding discovered all products, but ID was no unique.

2018-12-29 22:54:30.111 [DEBUG] [ng.velux.bridge.VeluxBridgeActuators] - getProducts() storing new product Product "Rollo 1" / SOLAR_SLIDER (bridgeIndex=0,serial=53:14:1E:26:11:26:00,position=C800).
2018-12-29 22:54:30.112 [DEBUG] [ng.velux.bridge.VeluxBridgeActuators] - getProducts() storing new product Product "Rollo 2" / SOLAR_SLIDER (bridgeIndex=1,serial=53:14:1E:26:12:03:02,position=0000).
2018-12-29 22:54:30.112 [DEBUG] [ng.velux.bridge.VeluxBridgeActuators] - getProducts() storing new product Product "Rollo 3" / SOLAR_SLIDER (bridgeIndex=2,serial=53:14:1E:26:12:03:02,position=0000).
2018-12-29 22:54:30.112 [DEBUG] [ng.velux.bridge.VeluxBridgeActuators] - getProducts() storing new product Product "Fenster 1" / WINDOW_OPENER (bridgeIndex=3,serial=56:24:5C:26:11:2D:00,position=C800).
2018-12-29 22:54:30.113 [DEBUG] [ng.velux.bridge.VeluxBridgeActuators] - getProducts() storing new product Product "Fenster 2" / WINDOW_OPENER (bridgeIndex=4,serial=56:24:5C:26:11:2D:00,position=C800).
2018-12-29 22:54:30.113 [DEBUG] [ng.velux.bridge.VeluxBridgeActuators] - getProducts() storing new product Product "Fenster 3" / WINDOW_OPENER (bridgeIndex=5,serial=56:24:5C:26:12:03:00,position=C800).
2018-12-29 22:54:30.114 [DEBUG] [ng.velux.bridge.VeluxBridgeActuators] - getProducts() storing new product Product "Rollo 4" / SOLAR_SLIDER (bridgeIndex=6,serial=53:14:1E:26:12:0A:09,position=C800). 

Configuring them in my common.items I need not just to declare products serial but also the bridge ID.
Do you have any idea how to solve the situation.