Hello Jonas @sloth0815,
there is already a snapshot version at GitHub which provides asynchronous command execution.
Regards, Guenther
Hi Guenther.
What exactly does asynchronous command execution mean? (I know that the words means, but in regarding to controling Velux devices, I fail to understand).
Multiple commands being processing asychronously in parallel: i.e. STOP during an ongoing DOWN command.
Ahh okay I see..
Thanks for all your work Guenther!
not finally happy with it ā¦ the bridge status is filled with some strange information during the command/scene processing ;-(
I dont know if itĀ“s releated, but I wish the scene processing could be optimized so it doesnt halt the openhab system, while running a scene. I can live with it, but sometimes it interfere with other stuff..
Like if my windows are opening or closing (from a scene), then itĀ“s a bad idea telling Google to turn on the light at the same time, cause it takes several seconds for Google to react, (and sometimes it fails).
Other than that, IĀ“m highly pleased with the binding. I use it to automaticly run all my windows (8 windows) from a openhab rule based on the inside temperature. And itĀ“s working great!
till finalization of PR#2531 Iād like to stay on the sequential processing so that both (openHAB1 and openHAB2) bindings offer the same user experience. For ambious beta tester, a parallel processing of scene and positioning commands is available, but it (currently) introduces some strange results in the actuator values as the intermediate positioning informations seem to irritate the openHAB event busā¦ especially the paperUI does not show the actual values (even if they occur within the event log).
With the recently published jarfile, no delay in processing after starting a scene or positioning of a windows should be noticable.
Regards, Guenther
I understand, though I dont care about openhab1 to be honest. I know itĀ“s still in use 
I might give the latest version a shot in the weekend.
1 Like
So which version should I use if I donāt want any strange results? Anything but the snapshot or can I use the snapshot but avoid asynchronous command execution?
I have gone ahead and copied the Velux configuaration from my remote to the KLF200, installed the 1.14 binding via PaperUI (OpenHAB 2.5 M3), and edited the automatically generated velux.cfg file to reflect my configuration (tried both the ārandomā and the velux123 passwords):
bridgeIPAddress=192.168.100.29
bridgeProtocol=slip
bridgeTCPPort=51200
bridgePassword=velux123
timeoutMsecs=1000
retries=5
refreshSecs=15000
However, there seems to be an issue because I see the following in the log:
2019-09-15 19:10:27.758 [DEBUG] [.binding.velux.internal.VeluxBinding] - There is no existing Velux binding configuration => refresh cycle aborted!
2019-09-15 19:10:35.052 [DEBUG] [.binding.velux.internal.VeluxBinding] - updated() called with 11 dictionary entries.
2019-09-15 19:10:35.061 [DEBUG] [.binding.velux.internal.VeluxBinding] - updated(): adapted BRIDGE_IPADDRESS to 192.168.100.29.
2019-09-15 19:10:35.069 [DEBUG] [.binding.velux.internal.VeluxBinding] - updated(): adapted BRIDGE_PASSWORD to 84RVTWSgVS.
2019-09-15 19:10:35.079 [DEBUG] [.binding.velux.internal.VeluxBinding] - updated(): adapted BRIDGE_PROTOCOL to slip.
2019-09-15 19:10:35.088 [DEBUG] [.binding.velux.internal.VeluxBinding] - updated(): adapted BRIDGE_TCPPORT to 51200.
2019-09-15 19:10:35.097 [DEBUG] [.binding.velux.internal.VeluxBinding] - updated(): adapted BRIDGE_IS_BULK_RETRIEVAL_ENABLED to false.
2019-09-15 19:10:35.105 [WARN ] [.binding.velux.internal.VeluxBinding] - updated(): unknown configuration entry refresh:=300000.0.
2019-09-15 19:10:35.113 [DEBUG] [.binding.velux.internal.VeluxBinding] - updated(): adapted BRIDGE_REFRESH_MSECS to 15000.
2019-09-15 19:10:35.121 [WARN ] [.binding.velux.internal.VeluxBinding] - updated(): unknown configuration entry refreshSecs:=15000.0.
2019-09-15 19:10:35.129 [DEBUG] [.binding.velux.internal.VeluxBinding] - updated(): adapted BRIDGE_RETRIES to 5.
2019-09-15 19:10:35.136 [WARN ] [.binding.velux.internal.VeluxBinding] - updated(): unknown configuration entry service.pid:=org.openhab.velux.
2019-09-15 19:10:35.144 [DEBUG] [.binding.velux.internal.VeluxBinding] - updated(): adapted BRIDGE_TIMEOUT_MSECS to 1000.
2019-09-15 19:10:35.151 [INFO ] [.binding.velux.internal.VeluxBinding] - veluxConfig[bridgeProtocol=slip,bridgeIPAddress=192.168.100.29,bridgeTCPPort=51200,bridgePassword=**********,timeoutMsecs=1000,retries=5,refreshMsecs=15000,isBulkRetrievalEnabled=false]
2019-09-15 19:10:35.158 [DEBUG] [.binding.velux.internal.VeluxBinding] - execute() called.
2019-09-15 19:10:35.163 [DEBUG] [.binding.velux.internal.VeluxBinding] - There is no existing Velux binding configuration => refresh cycle aborted!
2019-09-15 19:10:42.765 [DEBUG] [.binding.velux.internal.VeluxBinding] - execute() called.
Any ideas?
Best,
Jonas
Hello Jonas,
1st of all: please use the openHAB2 binding for the openHAB2 environment.
The message just tells you, that there is no Velux item defined so that no refresh takes place.
Regards, Guenther
Ok, I have now installed the OpenHAB2 Snapshot binding by copying the .jar file into the addons folder. The binding is starting and scanning but cannot find the bridge. I guess this has to be defined somewhere. I have created this .things file:
Bridge velux:klf200:home [ ipAddress="192.168.100.29", bridgeTCPPort=51200, bridgePassword="velux123" ]
I tried both passwords and get a bunch of TRACE logs and
09:07:42.168 [WARN ] [ding.velux.handler.VeluxBridgeHandler] - velux bridge login sequence failed; expecting bridge is OFFLINE.
I have also power-cycled the bridge without success.
I am assuming that in case of a successful configuration I will get the addresses of my windows and rollershutters in the log but obviously I am still doing something wrong.
@sloth0815,
thanks for feedback. Please note, as described in the README, the bridge cannot be found by the binding. Therefore, your approach by defining the bridge is alright!
Could you please share them?
BTW for your convenience, if you use the paperUI, the following step should lead to success:
- Select
Inbox, - choose Plus-Symbol,
- select
Velux Binding, - continue with
Thing not listed? Add manually, - select
Velux KLF200 Bridge, - Enter Configuration Parameters: IP Address, Password.
After 15 seconds, the Bridge will appear online.
Thanks for your help. Here are the logs:
I have removed the .things file and added the bridge via the PaperUI as you described, changed the password to the ārandomā one printed on the back of the device and now it works. I got my list of addresses and will create items tonight.
Thanks again (will probably be back, I guess).
Jonas
1 Like
where ?
Hello again, Guenther,
after some further reading I realized that I was using the old OpenHAB1 bindings and have since switched over to the snapshot of the oh2 bindings that you provided.
Unfortunately it works roughly as well as the previous one, i.e it successfully connects to my bridge, detects the actuators, shows the position but almost always fails to actually move the shutters.
(These are the āserial-lessā somfy shutters, in case this matters).
On issue that I find repeatedly is that apprently multiple pieces of code try to communicate with the bridge and get confused with the answers.
For example this recent log:
12:49:41.893 [DEBUG] [ing.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(): working on response GW_SESSION_FINISHED_NTF with 2 bytes of data.
12:49:41.897 [DEBUG] [ing.velux.bridge.slip.SlipVeluxBridge] - io(): received packet with 7 bytes.
12:49:41.902 [DEBUG] [ing.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(): working on response GW_ACTIVATION_LOG_UPDATED_NTF with 0 bytes of data.
12:49:41.906 [WARN ] [nding.velux.bridge.slip.SCgetProducts] - Gateway response GW_ACTIVATION_LOG_UPDATED_NTF (1286) cannot be handled at this point of interaction.
12:49:41.912 [DEBUG] [ing.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(GW_GET_ALL_NODES_INFORMATION_REQ) returns failure.
12:49:48.236 [DEBUG] [ing.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(GW_OPENHAB_RECEIVEONLY,authenticated) called.
12:49:48.242 [DEBUG] [ing.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(GW_OPENHAB_RECEIVEONLY) returns failure.
12:49:48.256 [DEBUG] [ing.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(GW_GET_STATE_REQ,authenticated) called.
12:49:48.266 [DEBUG] [ing.velux.bridge.slip.SlipVeluxBridge] - io(): sending packet of size 7.
12:49:49.270 [DEBUG] [ing.velux.bridge.slip.SlipVeluxBridge] - io(): received packet with 9 bytes.
12:49:49.279 [DEBUG] [ing.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(): working on response GW_GET_ALL_NODES_INFORMATION_CFM with 2 bytes of data.
12:49:49.286 [WARN ] [g.velux.bridge.slip.SCgetDeviceStatus] - Gateway response GW_GET_ALL_NODES_INFORMATION_CFM (515) cannot be handled at this point of interaction.
12:49:49.312 [DEBUG] [ing.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(GW_GET_STATE_REQ) returns failure.
12:49:49.317 [INFO ] [ding.velux.handler.VeluxBridgeHandler] - handleCommand(): updating of item velux:klf200:home:status (type velux:klf200/status) failed.
12:49:49.322 [DEBUG] [ing.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(GW_GET_ALL_NODES_INFORMATION_REQ,authenticated) called.
12:49:49.328 [DEBUG] [ing.velux.bridge.slip.SlipVeluxBridge] - io(): sending packet of size 7.
12:49:50.335 [DEBUG] [ing.velux.bridge.slip.SlipVeluxBridge] - io(): received packet with 131 bytes.
12:49:50.369 [DEBUG] [ing.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(): working on response GW_GET_ALL_NODES_INFORMATION_NTF with 124 bytes of data.
12:49:50.383 [WARN ] [ding.velux.handler.VeluxBridgeHandler] - Exception occurred during activated refresh scheduler: 12, java.lang.ArrayIndexOutOfBoundsException: 12
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)
at org.openhab.binding.velux.bridge.VeluxBridge.bridgeCommunicate(VeluxBridge.java:219)
at org.openhab.binding.velux.bridge.VeluxBridge.bridgeCommunicate(VeluxBridge.java:238)
at org.openhab.binding.velux.bridge.VeluxBridgeActuators.getProducts(VeluxBridgeActuators.java:140)
at org.openhab.binding.velux.bridge.VeluxBridgeActuators.autoRefresh(VeluxBridgeActuators.java:170)
at org.openhab.binding.velux.handler.VeluxBridgeHandler.handleCommand(VeluxBridgeHandler.java:786)
at org.openhab.binding.velux.handler.VeluxBridgeHandler.execute(VeluxBridgeHandler.java:364)
at org.openhab.binding.velux.handler.VeluxBridgeHandler.lambda$1(VeluxBridgeHandler.java:393)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
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)
From what I gather thereās both a SCgetProducts and a SCgetDeviceStatus running and the first one gets the GW_ACTIVATION_LOG_UPDATED_NTF response while the latter is given the GW_GET_ALL_NODES_INFORMATION_CFM response and as far as I can tell itās expected to be exactly the other way around.
Iāll try experimenting with enforcing sequential operation (maybe that helps) and Iāve also noticed that the getProducts seems to be called A LOT (i.e. multiple times per second), even though the refresh Msecs is at its default value of 10000.
Sorry, forgot to delete that part. As it is working now I did not want to crowd the thread with the log. Let me know in case you would like to see it.
Thanks for your logfile. In your case
Iām very dependant on you as I have no test scenario for it. In fact, Velux has confirmed that other io-homecontrol devices might return no serial numbers ā¦ so the binding should have to deal with it separately. To focus on the errorous code, Iād like to ask you to switch Enforce Sequential Mode on. Afterwards, the gateway and binding avoid parallel exchange of messages (which leads to more easy-to-interpret log files). Thanks in advance, Guenther
Iāve modified my velux.things to define the bridge like this (no, thatās not the actual password):
Bridge velux:klf200:home [ ipAddress="192.168.0.12", password="hunter2", isSequentialEnforced="true", refreshMsecs="100000" ]
While doing so I also noticed that typos in the config just seem to silently be ignored (I used āisSequentialEnforcesā previously), so Iām not 100% sure that any/all of those parameters are used (except for IP/password).
And Iāve since collected this log (which includes trying to control one of the shutters at about 14:16):
openhab.log (126.2 KB)
Yes, and I have not found a solution for this OH2-specific behaviour! You can spend several hours in debugging in vainā¦
1 Like