[velux] New OpenHAB2 binding - feedback welcome!

No idea about the difference between Velux and Somfy shutters.

Velux works differently. In German e.g. see here, if somebody falls in the same trap as myself: http://weshare.velux.com/A/We%20Share/64057?encoding=UTF-8&a=0, step 11.
I didn’t try it yet, I somehow got frustrated today as the failing KLF (?) now leads to having to reprogramm all the shutters, which involves climbing halfway onto the roof.

Hi Guenther,
on my klf200 i have some scenes defined and the binding finds them as seen in the logmsg.
on the rollershutter named keuken i created 3 scenes also showing up in the logmsg.
on the sitemap i see the shutters but no scenes, resulting that i could only pushed the up or down button.
But how do i make the scenes visible there so that i could also choose scene “Keuken 75%” or others when i want to.

here my logmsg,

Scene "Badkamer openen" (index 7) with non-silent mode and 0 actions

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 "Badkamer sluiten" (index 6) with non-silent mode and 0 actions

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

Scene "Zolder openen" (index 5) 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

Scene "Keuken 75%" (index 8) with non-silent mode and 0 actions	.

2019-07-14 12:59:25.652 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - Found velux actuators:

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

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

Product "Zolder" / ROLLER_SHUTTER (bridgeIndex=2,serial=53:2A:5D:5A:12:10:3B,position=C800)

Product "Badkamer" / ROLLER_SHUTTER (bridgeIndex=3,serial=53:2A:5D:5A:12:10:1A,position=8FB1)	.

2019-07-14 12:59:25.654 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - velux Bridge is online, now.

my items file,

// 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]”
Rollershutter GF_Keuken_Shutter “Keuken [%d]” { velux=“thing=actuator;channel=serial#00:00:00:00:00:00:00” }
Rollershutter F2_Badkamer_Shutter “Badkamer [%d]” { velux=“thing=actuator;channel=serial#53:2A:5D:5A:12:10:1A” }
Rollershutter F2_Slaapkamer_Shutter “Slaapkamer [%d]” { velux=“thing=actuator;channel=serial#53:2A:5D:5A:12:10:3A” }
Rollershutter F3_Zolder_Shutter “Zolder [%d]” { velux=“thing=actuator;channel=serial#53:2A:5D:5A:12:10:3B” }
//
// end-of-items/velux.items

Hi Johnny-b,

I am on OH2, but it may be the same for you. I have the scenes defined in the items file as well and then added to the sitemap accordingly:

// Velux Scene channels

Switch  V_DG_ALL_50   "Velux DG All 50% open"   <blinds>  (gV)         { velux="thing=scene;channel=action#All_50"}
Switch  V_DG_All_Closed "Velux DG All closed"<blinds>  (gV)       { velux="thing=scene;channel=action#All_Closed" }

Hope this helps.

BTW, Thanks Guenther for the “magic” version. I like the ability to have the windows show 0 when they are closed and 100 when open.

Achim

Hi Mikkel,
did you managed to get the a display of the missing bridge items ?
If yes, could you tell me how, because i have the same problem

@gs4711
I’ve increased the timeoutMsecs to 6000 and will check for errors in the future.

How can i check if the ICMP roundtrip works fine? The Logs seem to be fine.

The weird Connection refused error is back again :frowning:

2019-07-16 13:55:14.194 [TRACE] [ng.velux.bridge.VeluxBridgeActuators] - updateOH() called.

2019-07-16 13:55:14.197 [TRACE] [g.velux.things.VeluxExistingProducts] - isDirty() returns false.

2019-07-16 13:55:14.199 [TRACE] [ng.velux.bridge.VeluxBridgeActuators] - updateOH() finished.

2019-07-16 13:55:14.201 [TRACE] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): openHAB items updated.

2019-07-16 13:55:14.203 [TRACE] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): work on refresh.

2019-07-16 13:55:14.205 [TRACE] [internal.VeluxGenericBindingProvider] - getConfigForItemName(V_STATUS) called.

2019-07-16 13:55:14.207 [TRACE] [internal.VeluxGenericBindingProvider] - getConfigForItemName() returns thing=bridge;channel=status.

2019-07-16 13:55:14.208 [TRACE] [binding.velux.internal.VeluxItemType] - isReadable() returns true.

2019-07-16 13:55:14.210 [TRACE] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): refreshing item V_STATUS.

2019-07-16 13:55:14.212 [TRACE] [velux.bridge.VeluxBridgeDeviceStatus] - VeluxBridgeDeviceStatus(constructor) called.

2019-07-16 13:55:14.214 [TRACE] [velux.bridge.VeluxBridgeDeviceStatus] - retrieve() called. About to query device status.

2019-07-16 13:55:14.215 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - bridgeAPI() called.

2019-07-16 13:55:14.217 [TRACE] [hab.binding.velux.bridge.VeluxBridge] - bridgeCommunicate(get device status) called.

2019-07-16 13:55:14.219 [TRACE] [hab.binding.velux.bridge.VeluxBridge] - isAuthenticated() returns true.

2019-07-16 13:55:14.221 [TRACE] [hab.binding.velux.bridge.VeluxBridge] - bridgeCommunicate(get device status,authenticated) called.

2019-07-16 13:55:14.222 [TRACE] [hab.binding.velux.bridge.VeluxBridge] - isAuthenticated() returns true.

2019-07-16 13:55:14.224 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - bridgeAPI() called.

2019-07-16 13:55:14.226 [TRACE] [ding.velux.bridge.json.JsonBridgeAPI] - bridgeDirectCommunicate(org.openhab.binding.velux.bridge.json.JCgetDeviceStatus@cfcf9e,true) called.

2019-07-16 13:55:14.228 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - bridgeDirectCommunicate(get device status,authenticated) called.

2019-07-16 13:55:14.229 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - bridgeCommunicate(): using SAP http://10.3.0.10:80/api/v1/device.

2019-07-16 13:55:14.233 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - io() to http://10.3.0.10:80/api/v1/device using request {"action":"getDeviceStatus","params":{}}.

2019-07-16 13:55:14.243 [ERROR] [org.openhab.io.net.http.HttpUtil    ] - Fatal transport error: java.net.ConnectException: Connection refused (Connection refused)

2019-07-16 13:55:14.245 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - io(): Exception occurred during I/O: transport error.

2019-07-16 13:55:14.247 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - io(): wait time 6000 msecs.

2019-07-16 13:55:20.250 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - io() to http://10.3.0.10:80/api/v1/device using request {"action":"getDeviceStatus","params":{}}.

2019-07-16 13:55:26.261 [ERROR] [org.openhab.io.net.http.HttpUtil    ] - Fatal transport error: java.net.SocketTimeoutException: Read timed out

2019-07-16 13:55:26.263 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - io(): Exception occurred during I/O: transport error.

2019-07-16 13:55:26.265 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - io(): wait time 12000 msecs.

2019-07-16 13:55:38.269 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - io() to http://10.3.0.10:80/api/v1/device using request {"action":"getDeviceStatus","params":{}}.

2019-07-16 13:55:41.447 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - io(): wait time 6000 msecs.

2019-07-16 13:55:47.449 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - io() got response )]}',.{"token":"LlIjXUcUUh/PU0UsHE9SOQ==","result":true,"deviceStatus":"IDLE","data":{},"errors":[]}.

2019-07-16 13:55:47.452 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - io() cleaned response {"token":"LlIjXUcUUh/PU0UsHE9SOQ==","result":true,"deviceStatus":"IDLE","data":{},"errors":[]}.

2019-07-16 13:55:47.456 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - bridgeCommunicate(): communication result is true, returning details.

2019-07-16 13:55:47.458 [TRACE] [ab.binding.velux.things.VeluxGwState] - VeluxGwState() created.

2019-07-16 13:55:47.459 [TRACE] [velux.bridge.VeluxBridgeDeviceStatus] - retrieve() finished successfully with result Gateway mode, with one or more actuator nodes in the system table., Idle state.. 

The error is appearing completely at random tho.

Hello @lukqw,

let’s assume that your network connectivity between the openHAB and the Velux gateway is stable.
The only possible reasons for the error message

Fatal transport error: java.net.SocketTimeoutException: Read timed out

is that the gateway will not respond to any requests of the binding. This will happen if there is anyone accessing the web frontend. This is a limitation of the KLF200 as documented: one connection only (for firmware v1).

There is no one else accessing the web frontend tho. It only occurs in the logs and afterwards works fine again:

2019-07-16 14:20:14.188 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - bridgeAPI() called.

2019-07-16 14:20:14.190 [TRACE] [ding.velux.bridge.json.JsonBridgeAPI] - bridgeDirectCommunicate(org.openhab.binding.velux.bridge.json.JCgetDeviceStatus@cfcf9e,true) called.

2019-07-16 14:20:14.192 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - bridgeDirectCommunicate(get device status,authenticated) called.

2019-07-16 14:20:14.195 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - bridgeCommunicate(): using SAP http://10.3.0.10:80/api/v1/device.

2019-07-16 14:20:14.200 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - io() to http://10.3.0.10:80/api/v1/device using request {"action":"getDeviceStatus","params":{}}.

2019-07-16 14:20:20.214 [ERROR] [org.openhab.io.net.http.HttpUtil    ] - Fatal transport error: java.net.SocketTimeoutException: Read timed out

2019-07-16 14:20:20.216 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - io(): Exception occurred during I/O: transport error.

2019-07-16 14:20:20.220 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - io(): wait time 6000 msecs.

2019-07-16 14:20:26.225 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - io() to http://10.3.0.10:80/api/v1/device using request {"action":"getDeviceStatus","params":{}}.

2019-07-16 14:20:26.247 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - io(): wait time 6000 msecs.

2019-07-16 14:20:32.250 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - io() got response )]}',.{"token":"LlIjXUcUUh/PU0UsHE9SOQ==","result":true,"deviceStatus":"IDLE","data":{},"errors":[]}.

2019-07-16 14:20:32.252 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - io() cleaned response {"token":"LlIjXUcUUh/PU0UsHE9SOQ==","result":true,"deviceStatus":"IDLE","data":{},"errors":[]}.

2019-07-16 14:20:32.257 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - bridgeCommunicate(): communication result is true, returning details.

2019-07-16 14:20:32.259 [TRACE] [ab.binding.velux.things.VeluxGwState] - VeluxGwState() created.

2019-07-16 14:20:32.261 [TRACE] [velux.bridge.VeluxBridgeDeviceStatus] - retrieve() finished successfully with result Gateway mode, with one or more actuator nodes in the system table., Idle state..

Another question: I’ve tried sending the UP command to a rollershutter, but it fails because the scene is not registered?

2019-07-16 14:44:15.973 [ome.event.ItemCommandEvent] - Item 'RS2' received command UP

==> /var/log/openhab2/openhab.log <==

2019-07-16 14:44:15.979 [TRACE] [.binding.velux.internal.VeluxBinding] - receiveCommand(RS2,UP) called.

2019-07-16 14:44:15.983 [TRACE] [.binding.velux.internal.VeluxBinding] - internalReceiveCommand(RS2,UP) called.

2019-07-16 14:44:15.987 [TRACE] [internal.VeluxGenericBindingProvider] - getConfigForItemName(RS2) called.

2019-07-16 14:44:15.988 [TRACE] [.binding.velux.internal.VeluxBinding] - internalReceiveUpdate(RS2,UP) called.

2019-07-16 14:44:15.990 [TRACE] [internal.VeluxGenericBindingProvider] - getConfigForItemName() returns 0,V_Shutter_2_000,90,V_Shutter_2_090,100,V_Shutter_2_100.

2019-07-16 14:44:15.992 [TRACE] [binding.velux.internal.VeluxItemType] - isWritable() returns true.

2019-07-16 14:44:15.995 [TRACE] [.binding.velux.internal.VeluxBinding] - internalReceiveCommand() is about to send update to item RS2.

2019-07-16 14:44:15.997 [TRACE] [.binding.velux.internal.VeluxBinding] - internalReceiveCommand() working with VeluxBindingProvider org.openhab.binding.velux.internal.VeluxGenericBindingProvider@a5d6e7.

2019-07-16 14:44:16.000 [DEBUG] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(item=RS2,command=UP,config=org.openhab.binding.velux.internal.VeluxRSBindingConfig@111f3cb,provider=org.openhab.binding.velux.internal.VeluxGenericBindingProvider@a5d6e7) called.

2019-07-16 14:44:16.002 [TRACE] [ng.velux.bridge.VeluxBridgeActuators] - updateOH() called.

2019-07-16 14:44:16.004 [TRACE] [g.velux.things.VeluxExistingProducts] - isDirty() returns false.

2019-07-16 14:44:16.007 [TRACE] [ng.velux.bridge.VeluxBridgeActuators] - updateOH() finished.

2019-07-16 14:44:16.009 [TRACE] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): openHAB items updated.

2019-07-16 14:44:16.011 [TRACE] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): found COMMAND UP.

2019-07-16 14:44:16.014 [TRACE] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): working on virtual rollershutter.

2019-07-16 14:44:16.016 [TRACE] [.velux.internal.VeluxRSBindingConfig] - getLevel() returning 0.

2019-07-16 14:44:16.019 [TRACE] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): current level is 0.

2019-07-16 14:44:16.021 [TRACE] [.velux.internal.VeluxRSBindingConfig] - getNextDescendingLevel() called.

2019-07-16 14:44:16.023 [TRACE] [.velux.internal.VeluxRSBindingConfig] - getNextDescendingLevel() returning 0.

2019-07-16 14:44:16.026 [TRACE] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): next level is 0.

2019-07-16 14:44:16.028 [TRACE] [.velux.internal.VeluxRSBindingConfig] - getSceneName(0) called.

2019-07-16 14:44:16.030 [TRACE] [.velux.internal.VeluxRSBindingConfig] - getSceneName() returning V_Shutter_2_000.

2019-07-16 14:44:16.034 [TRACE] [ing.velux.things.VeluxExistingScenes] - get(V_Shutter_2_000) called.

2019-07-16 14:44:16.038 [TRACE] [.binding.velux.internal.VeluxBinding] - internalReceiveUpdate(RS2,0) called.

2019-07-16 14:44:16.039 [TRACE] [ing.velux.things.VeluxExistingScenes] - isRegistered(V_Shutter_2_000) returns false.

2019-07-16 14:44:16.041 [TRACE] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): execution scene null.

2019-07-16 14:44:16.046 [WARN ] [org.apache.karaf.services.eventadmin] - EventAdmin: Exception during event dispatch [org.osgi.service.event.Event [topic=openhab/command/RS2] {item=RS2, bridgemarker=true, command=UP, timestamp=1563281055974} | {org.osgi.service.cm.ManagedService, org.osgi.service.event.EventHandler}={service.id=361, service.bundleid=233, service.scope=bundle, event.topics=openhab/*, service.pid=org.openhab.velux, component.name=org.openhab.binding.velux.binding, component.id=220} | Bundle(org.openhab.binding.velux_1.14.0.201907092115 [233])]

java.lang.NullPointerException: null

	at org.openhab.binding.velux.handler.VeluxBridgeHandlerOH1.handleCommandOnChannel(VeluxBridgeHandlerOH1.java:547) ~[?:?]

	at org.openhab.binding.velux.internal.VeluxBinding.internalReceiveCommand(VeluxBinding.java:223) ~[?:?]

	at org.openhab.core.binding.AbstractBinding.receiveCommand(AbstractBinding.java:94) ~[?:?]

	at org.openhab.binding.velux.internal.VeluxBinding.receiveCommand(VeluxBinding.java:207) ~[?:?]

	at org.openhab.core.events.AbstractEventSubscriber.handleEvent(AbstractEventSubscriber.java:45) ~[?:?]

	at org.apache.felix.eventadmin.impl.handler.EventHandlerProxy.sendEvent(EventHandlerProxy.java:415) [3:org.apache.karaf.services.eventadmin:4.2.1]

	at org.apache.felix.eventadmin.impl.tasks.HandlerTask.runWithoutBlacklistTiming(HandlerTask.java:82) [3:org.apache.karaf.services.eventadmin:4.2.1]

	at org.apache.felix.eventadmin.impl.tasks.SyncDeliverTasks.execute(SyncDeliverTasks.java:104) [3:org.apache.karaf.services.eventadmin:4.2.1]

	at org.apache.felix.eventadmin.impl.tasks.AsyncDeliverTasks$TaskExecuter.run(AsyncDeliverTasks.java:166) [3:org.apache.karaf.services.eventadmin:4.2.1]

	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]

	at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]

	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]

	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]

	at java.lang.Thread.run(Thread.java:748) [?:?]

With this being my items config

Group:Switch:OR(ON, OFF)    gV  "PushButton"

// Velux Scenes

Switch  V_1_S_OPEN   "Velux Rolladen open"       (gV)    { velux="thing=scene;channel=action#V_Shutter_1_000" }
Switch  V_1_S_SUNNY  "Velux Rolladen sunny"      (gV)    { velux="thing=scene;channel=action#V_Shutter_1_090" }
Switch  V_1_S_CLOSED "Velux Rolladen closed"     (gV)    { velux="thing=scene;channel=action#V_Shutter_1_100" }

Switch  V_2_S_OPEN   "Velux Rolladen open"       (gV)    { velux="thing=scene;channel=action#V_Shutter_2_000" }
Switch  V_2_S_SUNNY  "Velux Rolladen sunny"      (gV)    { velux="thing=scene;channel=action#V_Shutter_2_090" }
Switch  V_2_S_CLOSED "Velux Rolladen closed"     (gV)    { velux="thing=scene;channel=action#V_Shutter_2_100" }

Switch  V_3_S_OPEN   "Velux Rolladen open"       (gV)    { velux="thing=scene;channel=action#V_Shutter_3_000" }
Switch  V_3_S_SUNNY  "Velux Rolladen sunny"      (gV)    { velux="thing=scene;channel=action#V_Shutter_3_090" }
Switch  V_3_S_CLOSED "Velux Rolladen closed"     (gV)    { velux="thing=scene;channel=action#V_Shutter_3_100" }

Switch  V_4_S_OPEN   "Velux Rolladen open"       (gV)    { velux="thing=scene;channel=action#V_Shutter_4_000" }
Switch  V_4_S_SUNNY  "Velux Rolladen sunny"      (gV)    { velux="thing=scene;channel=action#V_Shutter_4_090" }
Switch  V_4_S_CLOSED "Velux Rolladen closed"     (gV)    { velux="thing=scene;channel=action#V_Shutter_4_100" }

Switch  V_5_S_OPEN   "Velux Rolladen open"       (gV)    { velux="thing=scene;channel=action#V_Shutter_5_000" }
Switch  V_5_S_SUNNY  "Velux Rolladen sunny"      (gV)    { velux="thing=scene;channel=action#V_Shutter_5_090" }
Switch  V_5_S_CLOSED "Velux Rolladen closed"     (gV)    { velux="thing=scene;channel=action#V_Shutter_5_100" }

Switch  V_6_S_OPEN   "Velux Rolladen open"       (gV)    { velux="thing=scene;channel=action#V_Shutter_6_000" }
Switch  V_6_S_SUNNY  "Velux Rolladen sunny"      (gV)    { velux="thing=scene;channel=action#V_Shutter_6_090" }
Switch  V_6_S_CLOSED "Velux Rolladen closed"     (gV)    { velux="thing=scene;channel=action#V_Shutter_6_100" }

// Velux Bridge parameters

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 Shutters

Rollershutter RS1  "Velux Rolladen 1 [%d]"   { velux="thing=bridge;channel=shutter#0,V_Shutter_1_000,90,V_Shutter_1_090,100,V_Shutter_1_100"}
Rollershutter RS2  "Velux Rolladen 2 [%d]"   { velux="thing=bridge;channel=shutter#0,V_Shutter_2_000,90,V_Shutter_2_090,100,V_Shutter_2_100"}
Rollershutter RS3  "Velux Rolladen 3 [%d]"   { velux="thing=bridge;channel=shutter#0,V_Shutter_3_000,90,V_Shutter_3_090,100,V_Shutter_3_100"}
Rollershutter RS4  "Velux Rolladen 4 [%d]"   { velux="thing=bridge;channel=shutter#0,V_Shutter_4_000,90,V_Shutter_4_090,100,V_Shutter_4_100"}
Rollershutter RS5  "Velux Rolladen 5 [%d]"   { velux="thing=bridge;channel=shutter#0,V_Shutter_5_000,90,V_Shutter_5_090,100,V_Shutter_5_100"}
Rollershutter RS6  "Velux Rolladen 6 [%d]"   { velux="thing=bridge;channel=shutter#0,V_Shutter_6_000,90,V_Shutter_6_090,100,V_Shutter_6_100"}

The initial lines, which state what scenes are available, would be interesting: Normally the appropriate information looks like:

2019-07-16 15:16:37.033 [INFO ] [.o.b.v.h.VeluxBridgeHandlerOH1] - Found velux scenes:
Scene “V_DG_Shutter_West_100” (index 5) with non-silent mode and 0 actions
Scene “V_DG_Shutter_West_000” (index 4) with non-silent mode and 0 actions
Scene “V_DG_Shutter_Ost_090” (index 10) with non-silent mode and 0 actions
Scene “V_DG_Window_Mitte_005” (index 3) with non-silent mode and 0 actions
Scene “V_DG_Window_Mitte_000” (index 1) with non-silent mode and 0 actions
Scene “V_DG_Window_Mitte_100” (index 2) with non-silent mode and 0 actions
Scene “V_DG_Shutter_West_090” (index 7) with non-silent mode and 0 actions
Scene “V_DG_Window_Mitte_010” (index 0) with non-silent mode and 0 actions
Scene “V_DG_Shutter_Ost_000” (index 8) with non-silent mode and 0 actions
Scene “V_DG_Shutter_Ost_100” (index 9) with non-silent mode and 0 actions

If you’re using the latest release, you can trigger those informations by activating the reload channel of the bridge.

Hi @gs4711,

I have the problem that I can not invert the window state. My item:

Rollershutter VeluxFensterSpeicher_Treppe "Fenster Treppe Speicher [%d %%]"	 <window> (gVelux, gSpeicher)	{ velux="thing=actuator;channel=serial#56:36:13:32:13:0A:04:DE*", channel="knx:device:bridge:control:VeluxFenster_Speicher_Treppe"}

Log after sending an up or down command with basic ui:

2019-07-16 21:12:49.988 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): cannot work on unknown actuator: 56:36:13:32:13:0A:04:DE*.

2019-07-16 21:12:49.989 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): updating of item VeluxFensterSpeicher_Treppe (type ACTUATOR_SERIAL) failed.

Without the “*” after the serial number everything works ok, expected the state value:-)
Can you please give me a hint?

Thank you!

Hello @johannesbonn Johannes,

in fact, the definition

contains some strange trailing information items. What is the purpose of

channel="knx:device:bridge:control:VeluxFenster_Speicher_Treppe"}

?

Best regards, Guenther

I have connected the Velux rollershutter item with a knx thing, so that I can control my windows per knx switch. Since now I had no problems with this constellation.
This is a common way to connect multiple platforms.

Interesting point. Have to check what the compat1x passes in that case to the binding.
It did work well until the introduction of the inverted branch?

Without the * there are no problems.

Hello Johannes,

unfortunatelly I can not reproduce your phenomena; having tried this setup:

Rollershutter V_DG_M_W3 “DG Fenster Bad [%d]” { velux=“thing=actuator;channel=serial#56:23:3E:26:0C:1B:00:10*”,channel=“knx:device:bridge:control:VeluxFenster” }

Using the UI this results in a successful move (towards to the inverted position) of the window:

2019-07-17 10:03:03.095 [DEBUG] [.o.b.v.h.VeluxBridgeHandlerOH1] - handleCommandOnChannel(item=V_DG_M_W3,command=85,config=org.openhab.binding.velux.internal.VeluxBindingConfig@e8841b,provider=org.openhab.binding.velux.internal.VeluxGenericBindingProvider@153f3c3) called.
2019-07-17 10:03:03.099 [TRACE] [.o.b.v.h.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): openHAB items updated.
2019-07-17 10:03:03.100 [TRACE] [.o.b.v.h.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): found COMMAND 85.
2019-07-17 10:03:03.699 [TRACE] [.o.b.v.h.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): there are some existing products.
2019-07-17 10:03:03.700 [TRACE] [.o.b.v.h.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): actuatorSerial=56:23:3E:26:0C:1B:00:10*
2019-07-17 10:03:03.700 [TRACE] [.o.b.v.h.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): actuatorSerial=56:23:3E:26:0C:1B:00:10
2019-07-17 10:03:03.701 [TRACE] [.o.b.v.h.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): fetching product for 56:23:3E:26:0C:1B:00:10.
2019-07-17 10:03:03.701 [TRACE] [.o.b.v.h.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): found product Product “DG_M_Window” / WINDOW_OPENER (bridgeIndex=0,serial=56:23:3E:26:0C:1B:00:10,position=C800).
2019-07-17 10:03:03.702 [TRACE] [.o.b.v.h.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): found command of type PercentType.
2019-07-17 10:03:03.702 [TRACE] [.o.b.v.h.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): found command to set level to 15.
2019-07-17 10:03:03.703 [DEBUG] [.o.b.v.h.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): sending command with target level 15.
2019-07-17 10:03:30.038 [TRACE] [.o.b.v.h.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): The new shutter level will be send through the home monitoring events.
2019-07-17 10:03:30.610 [TRACE] [.o.b.v.h.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): position of actuators are updated.
2019-07-17 10:03:30.611 [TRACE] [.o.b.v.h.VeluxBridgeHandlerOH1] - handleCommandOnChannel() done.

Do you see a difference in my trial configuration? Could you pls. send in appropriate logging lines?

Regards, Guenther

Hi @gs4711
I have been thinking about this question for quite a few months now, but always seem to forget it :slight_smile:

My setup is fairly simple. I got 8 Velux topline windows. I use scenes at most. (I can control control them individually with the firmware 2, which is working great).

However - I have notice, when my rule for opening the windows fire, (my rule opens all 8 windows at the same time, depending on the temperature inside), then it seems like everything else in openhab stops, untill the windows have moved into possition.
I often use the tail log to see whats going on. And I can see, that even the tail log stops, untill all the windows have finished moving… Like the SLIP somehow locks up all other communication while the windows are on the move.
The time it stops it depends on how many windows moving at the same time. But since I use a scene to control all 8 at the same time, this behaviour can last aprox 10-15 seconds.
If I switch off the automatic control (my rule), and then move only a small group (still a scene), then this time is shorter.

Is there a specific reason for this behaviour?

Hi @Kim_Andersen,

thank you for your question - hopefully it was not overlooked. Currently the implemenation forces a completion of the ongoing command sequence before returning control to the user/rules/a.s.o.

Of course, this could be changed - but has especially consequences in the areas of sequences of commands. For example due to mechanics it is wise to move shutters only on windows which are closed. Therefore the correct sequence is close window, move shutters to the desired position, reopen windows.

With the current semantic it is easy to place those commands in one sequence (with taking no care about the success of the operation). The other approach leads to amore complicated szenario: the rule has to:

  1. send the closure command to the window,

  2. loop with check and wait for the intended closure state of the window,

  3. send the move command to the shutter,

  4. loop with check and wait for the intended state of the shutter,

  5. send the open command to the window.

Technically both implementation methods are possible and make sense to me …

Here are some logs from a fresh install of the velux binding (moving it out and back into the /addons folder.

openhab.log (196.0 KB)

As you can see starting at line 1543, I got 10 scenes which I crosschecked with my .items file and adjusted it accordingly:

Group:Switch:OR(ON, OFF)    gV  "PushButton"

// Velux Scenes

Switch  V_2_S_OPEN   "Velux Rolladen open"       (gV)    { velux="thing=scene;channel=action#V_Shutter_2_0" }
Switch  V_2_S_CLOSED "Velux Rolladen closed"     (gV)    { velux="thing=scene;channel=action#V_Shutter_2_100" }

Switch  V_3_S_OPEN   "Velux Rolladen open"       (gV)    { velux="thing=scene;channel=action#V_Shutter_3_0" }
Switch  V_3_S_CLOSED "Velux Rolladen closed"     (gV)    { velux="thing=scene;channel=action#V_Shutter_3_100" }

Switch  V_4_S_OPEN   "Velux Rolladen open"       (gV)    { velux="thing=scene;channel=action#V_Shutter_4_0" }
Switch  V_4_S_CLOSED "Velux Rolladen closed"     (gV)    { velux="thing=scene;channel=action#V_Shutter_4_100" }

Switch  V_5_S_OPEN   "Velux Rolladen open"       (gV)    { velux="thing=scene;channel=action#V_Shutter_5_0" }
Switch  V_5_S_CLOSED "Velux Rolladen closed"     (gV)    { velux="thing=scene;channel=action#V_Shutter_5_100" }

Switch  V_6_S_OPEN   "Velux Rolladen open"       (gV)    { velux="thing=scene;channel=action#V_Shutter_6_0" }
Switch  V_6_S_CLOSED "Velux Rolladen closed"     (gV)    { velux="thing=scene;channel=action#V_Shutter_6_100" }

// Velux Bridge parameters

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 Shutters

Rollershutter RS2  "Velux Rolladen 2 [%d]"   { velux="thing=bridge;channel=shutter#0,V_Shutter_2_0,100,V_Shutter_2_100"}
Rollershutter RS3  "Velux Rolladen 3 [%d]"   { velux="thing=bridge;channel=shutter#0,V_Shutter_3_0,100,V_Shutter_3_100"}
Rollershutter RS4  "Velux Rolladen 4 [%d]"   { velux="thing=bridge;channel=shutter#0,V_Shutter_4_0,100,V_Shutter_4_100"}
Rollershutter RS5  "Velux Rolladen 5 [%d]"   { velux="thing=bridge;channel=shutter#0,V_Shutter_5_0,100,V_Shutter_5_100"}
Rollershutter RS6  "Velux Rolladen 6 [%d]"   { velux="thing=bridge;channel=shutter#0,V_Shutter_6_0,100,V_Shutter_6_100"}

Controlling the Shutters is still not working tho. At line 2737 I tried to send rollershutter 2 DOWN, but on line 2861 it want’s to execute scene null. Got any ideas here?