ad 1) Yes, but you will limit yourself to start an action with neither response nor status update.
ad 2) If you configure the PI correctly, it works as described.
FYI: it is documented in the README on GitHub, where you’ll find the recent comments (hopefully being incorporated into official OH release by PR#5833): please take a look at the recent three sections of this document.
This binding was originated on contact with Velux product mgmt and lateron engineers: they did a great job in documenting their internal APIs. Officially you can choose the Netatmo/Velux solution which IMHO has the caveats of being dependant on their cloud service: I prefer my privacy.
I also prefer the privacy. However, when having a pricky device like me, using the “reference” implementation could help narrow down the problems.
Hi @Nosepull,
thanks for the logfile. Just for your information: the relevant lines had been the following:
04:35:58.301 [TRACE] [ing.velux.bridge.slip.SlipVeluxBridge] - io(): sending packet with 7 bytes: C0 00 03 00 0C 0F C0
04:35:58.303 [TRACE] [ng.velux.bridge.slip.io.SSLconnection] - send() called, writing 7 bytes.
04:35:58.305 [WARN ] [ing.velux.bridge.slip.SlipVeluxBridge] - io(): raised an error during sending: Connection closed by remote host.
04:35:58.307 [TRACE] [ing.velux.bridge.slip.SlipVeluxBridge] - io(): wait time 2000 msecs.
04:36:00.309 [TRACE] [ing.velux.bridge.slip.SlipVeluxBridge] - io(): receiving bytes.
04:36:00.314 [TRACE] [ng.velux.bridge.slip.io.SSLconnection] - receive() called.
04:36:00.318 [WARN ] [ing.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(): method io() raised an error: null.
04:36:15.754 [TRACE] [ing.velux.bridge.slip.SlipVeluxBridge] - io(): sending packet with 7 bytes: C0 00 03 00 0C 0F C0
04:36:15.757 [TRACE] [ng.velux.bridge.slip.io.SSLconnection] - send() called, writing 7 bytes.
04:36:15.761 [WARN ] [ing.velux.bridge.slip.SlipVeluxBridge] - io(): raised an error during sending: Connection closed by remote host.
04:36:15.765 [TRACE] [ing.velux.bridge.slip.SlipVeluxBridge] - io(): wait time 2000 msecs.
04:36:17.769 [TRACE] [ing.velux.bridge.slip.SlipVeluxBridge] - io(): receiving bytes.
04:36:17.776 [TRACE] [ng.velux.bridge.slip.io.SSLconnection] - receive() called.
04:36:17.783 [WARN ] [ing.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(): method io() raised an error: null.
04:36:33.219 [TRACE] [ing.velux.bridge.slip.SlipVeluxBridge] - io(): sending packet with 7 bytes: C0 00 03 00 0C 0F C0
04:36:33.222 [TRACE] [ng.velux.bridge.slip.io.SSLconnection] - send() called, writing 7 bytes.
04:36:33.227 [WARN ] [ing.velux.bridge.slip.SlipVeluxBridge] - io(): raised an error during sending: Connection closed by remote host.
04:36:33.233 [TRACE] [ing.velux.bridge.slip.SlipVeluxBridge] - io(): wait time 2000 msecs.
04:36:35.238 [TRACE] [ing.velux.bridge.slip.SlipVeluxBridge] - io(): receiving bytes.
04:36:35.246 [TRACE] [ng.velux.bridge.slip.io.SSLconnection] - receive() called.
04:36:35.252 [WARN ] [ing.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(): method io() raised an error: null.
In fact, I was able to reproduce this scenario by running more than one separate instance of OH directing requests onto one KLF: in that case, the gateway is responding by dropping the connection. According to the KLF-API spec this should occur with the third connection to be established. Will keep you informed.
I had the same idea, somehow. However, nothing else in my net should access the bridge besides OpenHAB.
However, my problem has slightly changed, doing the factory reset (both by the reset button at the back and with the UI) has f**ked up the box completely: Now I can not even pair my existing actuators any more, the pairing process does not find any products (rollershutter remotes pressed at the settings button, rollershutters move up and down, KLF finds nothing).
Tried to re-update the firmware, too, but that was rejected as “too old”?!
Grrrr! Is there something more I can do? I guess I’ll have to look for a refund,!
Edit: System log shows errors, too
Screenshot_20190712-125602_Bromite|281x500
Your new problem is that your devices (rollershutters etc.) now also have to be factory-reset (and thus reprogrammed) before you can pair them again. See my revious post here: https://community.openhab.org/t/io-homecontrol-velux-somethings-in-the-bush/11413/120.
I feared something like that :-(. Unfortunately neither the Velux WebUI nor the instructions for the KLF200 hint at something like that.
Is the procedure for Velux shutters the same as for Somfy shutters?
However, the error messages in the protocol after the firmware reset (in connection with the problems I had already before the reset) make me tend to be believe that there is something else wrong with the box…
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 
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