[velux] New OpenHAB2 binding - feedback welcome!

[Kim_Andersen]

@spiff42

You don’t need to be sarcastic - it just makes it appear like you didn’t understand what I wrote

Just a joke, not sarcastic.

@spiff42

I don’t know what you mean by the default state.

Default state = Before they get activated to their purpose. This goes for anything, even relays etc.
For rollershutters and blinds thy´re open by default - the purpose is to close.
Windows are closed by default - the purpose is to open.
Lights are off by default - Their purpose is to lit.

From what I can understand, you agree with this?

So, for windows it´s not natural to have a closed state of 100%, as we, (humans) normally count up, from 0 to 100, exactly like lights (ie how much is a ligt lit etc). If this should make sense, it wouldn´t be asking how much a light is lit, insted one would be asking, how less… I believe the very same goes for rollershutters and blinds… It isn´t just a question of words… It´s words creating a meaning which is natural and understandable…

@spiff42

What I was referring to when I wrote “it makes sense” is that the Item in OpenHAB is a “Rollershutter”, and the sitemap icons for rollershutters show them fully closed at 100% and fully open at 0%.

Which in my opinion makes perfect sense. open is default - default state should be 0%, and then count up how much they should be closed. The only different from windows is, rollershutter is open by default and windows are closed by default. But controlling should be the same.

@spiff42

In fact I think that the problem is to a wide extent related to the limited number of item types in OpenHAB, and not really a problem with the binding.

Agree. It would be alot easier to comprehend, if we have an item type for each. But in a technical manner, they´re controlled exactly like a dimmer. Thats why it´s highly important to threat them from their default state and their purpose. Otherweise we get the scenary we see today - Window closed but reporting state is 100%…

@spiff42

And secondly, the reason why I think the “reversing” needs to be configurable is exactly because of my awning blinds. To me it seems most logical that 0% is that the blinds are open (I can look out the window), and 100% is closed (limits the heating from the sun), and that is exactly how it is working now.

Which is how all blinds/Rollershutters should be controlled.
If there were a configuration option, it would make it possible if someone has a need of doing the opposit, (I cant figure why though). So a simple “inverted” option through the binding would fix this.But the controle is still 0% to 100%.
In the IHC binding there is such an option “inverted” through the binding, which makes the controlling works opposit. I believe this is the best way to threat this issue, which also makes it flexible.

[spiff42 (Mikkel Holm Olsen)]

It seems to me that we agree on what is the most logical direction of control for windows, blinds, dimmers, etc.

I actually think you are saying exactly the same as I am. I just got confused because when I first stated that it makes sense because we are controlling a rollershutter item you wrote: “To me it doesnt really make any sense at all”, and when I tried to explain it again you wrote: “Which in my opinion makes perfect sense”.

In any case, as long as we have only a rollershutter item in OpenHab, I believe it would be nice with an option to invert it, because the I/O homecontrol protocol can be used to control a lot of different things, and apparently the “direction” of different products is not always logical. And since the KLF200 should even be able to support products that are not from Velux, I think there is little chance of getting the binding to auto detect this. Of course we can make proxy items and rules converting back an forth to achieve this, but it is just very complicated.

There really ought to be a more generic item type such as LinearPosition, which would go from 0% to 100%. But in addition, I think OpenHAB also has some confusion regarding whether an item is input, output or both. For instance we could have a window position sensor in percent or in degrees (angle), but without an actuator. It is the same confusion that occurs with the switch and contact, where it is even more confusing that a switch is on/off and a contact is open/closed, and if your contact is inverted you need to make a mapping. For instance a contact monitoring a window is not necessarily wired such that contact open means window open. I guess this discussion should be moved to another thread, as it does not have much to do with the velux binding

Cheers

[Kim_Andersen]

@spiff42

It seems to me that we agree on what is the most logical direction of control for windows, blinds, dimmers, etc.

I actually think you are saying exactly the same as I am.

We do agree, and yes, we actually say the same. I misunderstood cause I thought you meant that it makes sense the way it is now… It doesnt.

@spiff42

In any case, as long as we have only a rollershutter item in OpenHab, I believe it would be nice with an option to invert it, because the I/O homecontrol protocol can be used to control a lot of different things, and apparently the “direction” of different products is not always logical

There really ought to be a more generic item type such as LinearPosition, which would go from 0% to 100%.

Like I said in previous message…
It doesnt really matter if we have more generic item types. They´re all “dimmers” in a principal matter, like:
Rollershutter - Dimmer
Blinds - Dimmer
Windows - Dimmers
At least as long as they can be controle with a value of 0-100%
Dimmers is just a technical type covering it all. It sends commands of value 0 to 100. And thats whats needed to controle anything which accept this value.
Technical there isn´t any need of anything else. BUT, it makes it alot more easy to comprehend, if we had Windows type for windows, like we have Rollershutter for Rollershutters etc… I agree on this. There are also gates, garagedoors etc which can be controled of a value from 0-100. Equal to all of them - They´re all motors one way or another. So perhaps “motor” type definition would be suitable (Just kidding).

@spiff42

It is the same confusion that occurs with the switch and contact, where it is even more confusing that a switch is on/off and a contact is open/closed, and if your contact is inverted you need to make a mapping. For instance a contact monitoring a window is not necessarily wired such that contact open means window open.

There is a technical reason why a switch isn´t a contact. The problem is, in openhab, some switches should have been contacts, like door/window sensors, and they should report open/closed. Switches is on/off.

[AndrewFG (Andrew Fiddian-Green)]

Personally I think there are two possible solutions…

a) The Thing offers two Channels – namely Window_Position and Roller_Shutter_Position; where Window_Position = 100% - Roller_Shutter_Position. In this case the user can choose which channel they want to use.

b) The Thing offers a Configuration parameter “Window_Mode”; where if this value is true the Position channel is (Window Closed=0% … Window Open=100%) and if false the Position channel is (Roller Shutter Open=0% … Roller Shutter Closed=100%)

Either way, I think it is rather simple to implement – it should need only a handful of lines of extra code. Or ??

[Kim_Andersen]

I agree to both, though I like a) most, as it´s more userfriendly.

[gs4711 (Guenther Schreiner)]

Personally I vote for choice (a) as is be easier to implement in common code for OH1 and OH2.

[Kim_Andersen]

Do you know when an update will be avialble?

[gs4711 (Guenther Schreiner)]

Unofficially (without review by the maintainers) up to the end of this week. Sign-off somewhere in the summer ;-(

[Kim_Andersen]

Okay, look forward for the next uofficial release then

[lilalinux]

Hi all,

I’m using latest v1 FW with the latest jar with openhab2.4.0 release and configured services/velux.cfg like that:
bridgeIPAddress=192.168.12.95
bridgeProtocol=http
bridgeTCPPort=80
bridgePassword=velux123
timeoutMsecs=2000
retries=6

However, I get a connection refused:
------------------------- 8< -----------------------------------------------
2019-06-05 13:51:15.997 [INFO ] [inding.velux.internal.VeluxActivator] - velux binding has been started.
2019-06-05 13:51:16.187 [INFO ] [.binding.velux.internal.VeluxBinding] - Active items are: [].
2019-06-05 13:51:16.192 [INFO ] [.binding.velux.internal.VeluxBinding] - velux refresh interval set to 15000 milliseconds.
2019-06-05 13:51:16.197 [INFO ] [.binding.velux.internal.VeluxBinding] - veluxConfig[bridgeProtocol=http,bridgeIPAddress=192.168.12.95,bridgeTCPPort=80,bridgePassword=********,timeoutMsecs=2000,retries=6,refreshMsecs=15000,isBulkRetrievalEnabled=true]
2019-06-05 13:51:16.202 [INFO ] [b.core.service.AbstractActiveService] - velux Refresh Service has been started
2019-06-05 13:51:20.268 [ERROR] [b.core.service.AbstractActiveService] - Error while executing background thread velux Refresh Service
java.lang.NullPointerException: null
at org.openhab.binding.velux.bridge.json.JCgetDeviceStatus$Response.access$0(JCgetDeviceStatus.java:89) ~[?:?]
at org.openhab.binding.velux.bridge.json.JCgetDeviceStatus.isCommunicationSuccessful(JCgetDeviceStatus.java:143) ~[?:?]
at org.openhab.binding.velux.bridge.json.JsonVeluxBridge.bridgeDirectCommunicate(JsonVeluxBridge.java:252) ~[?:?]
at org.openhab.binding.velux.bridge.json.JsonBridgeAPI.bridgeDirectCommunicate(JsonBridgeAPI.java:83) ~[?:?]
at org.openhab.binding.velux.bridge.VeluxBridge.bridgeCommunicate(VeluxBridge.java:197) ~[?:?]
at org.openhab.binding.velux.bridge.VeluxBridge.bridgeCommunicate(VeluxBridge.java:216) ~[?:?]
at org.openhab.binding.velux.bridge.VeluxBridgeDeviceStatus.retrieve(VeluxBridgeDeviceStatus.java:88) ~[?:?]
at org.openhab.binding.velux.handler.VeluxBridgeHandlerOH1.bridgeParamsUpdated(VeluxBridgeHandlerOH1.java:244) ~[?:?]
at org.openhab.binding.velux.handler.VeluxBridgeHandlerOH1.handleCommandOnChannel(VeluxBridgeHandlerOH1.java:298) ~[?:?]
at org.openhab.binding.velux.internal.VeluxBinding.execute(VeluxBinding.java:181) ~[?:?]
at org.openhab.core.binding.AbstractActiveBinding$BindingActiveService.execute(AbstractActiveBinding.java:144) ~[196:org.openhab.core.compat1x:2.4.0]
at org.openhab.core.service.AbstractActiveService$RefreshThread.run(AbstractActiveService.java:166) [196:org.openhab.core.compat1x:2.4.0]
2019-06-05 13:51:39.332 [ERROR] [b.core.service.AbstractActiveService] - Error while executing background thread velux Refresh Service
java.lang.NullPointerException: null
at org.openhab.binding.velux.bridge.json.JCgetDeviceStatus$Response.access$0(JCgetDeviceStatus.java:89) ~[?:?]
at org.openhab.binding.velux.bridge.json.JCgetDeviceStatus.isCommunicationSuccessful(JCgetDeviceStatus.java:143) ~[?:?]
at org.openhab.binding.velux.bridge.json.JsonVeluxBridge.bridgeDirectCommunicate(JsonVeluxBridge.java:252) ~[?:?]
at org.openhab.binding.velux.bridge.json.JsonBridgeAPI.bridgeDirectCommunicate(JsonBridgeAPI.java:83) ~[?:?]
at org.openhab.binding.velux.bridge.VeluxBridge.bridgeCommunicate(VeluxBridge.java:197) ~[?:?]
at org.openhab.binding.velux.bridge.VeluxBridge.bridgeCommunicate(VeluxBridge.java:216) ~[?:?]
at org.openhab.binding.velux.bridge.VeluxBridgeDeviceStatus.retrieve(VeluxBridgeDeviceStatus.java:88) ~[?:?]
at org.openhab.binding.velux.handler.VeluxBridgeHandlerOH1.bridgeParamsUpdated(VeluxBridgeHandlerOH1.java:244) ~[?:?]
at org.openhab.binding.velux.handler.VeluxBridgeHandlerOH1.handleCommandOnChannel(VeluxBridgeHandlerOH1.java:298) ~[?:?]
at org.openhab.binding.velux.internal.VeluxBinding.execute(VeluxBinding.java:181) ~[?:?]
at org.openhab.core.binding.AbstractActiveBinding$BindingActiveService.execute(AbstractActiveBinding.java:144) ~[196:org.openhab.core.compat1x:2.4.0]
at org.openhab.core.service.AbstractActiveService$RefreshThread.run(AbstractActiveService.java:166) [196:org.openhab.core.compat1x:2.4.0]

2019-06-05 13:51:54.361 [ERROR] [org.openhab.io.net.http.HttpUtil ] - Fatal transport error: java.net.ConnectException: Verbindungsaufbau abgelehnt (Connection refused)
------------------------- 8< -----------------------------------------------

The box is reachable via nmap:
------------------------- 8< -----------------------------------------------
nmap 192.168.12.95
Starting Nmap 7.40 ( https://nmap.org ) at 2019-06-05 14:01 CEST
Nmap scan report for VELUX_KLF_1A50 (192.168.12.95)
Host is up (0.000074s latency).
Not shown: 999 closed ports
PORT STATE SERVICE
80/tcp open http
MAC Address: 64:61:84:00:1A:50 (Velux)
Nmap done: 1 IP address (1 host up) scanned in 1.72 seconds
------------------------- 8< -----------------------------------------------

[lilalinux]

It looks like the velux box is generally quite unresponsive. Is there some ridiculous connection limit?

[acfischer42 (Achim)]

There is a limit (at least with FW 1) of one connection. Make sure that you are not logged on with the web frontend into the KLF. It would still react to ping (and I guess nmap), but not letting you log in.
hope this helps

[lilalinux]

Thank you. I power-cycled the device and even pushed the reset button twice (to logout), but the binding still couldn’t connect.
Anyway, As v1 seems to be braindead I’m in the process of installing v2 now.

[lilalinux]

2019-06-05 15:55:26.170 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - velux Bridge is online, now.

[johannesbonn (Johannes)]

Hi guenther @gs4711 ,

Thank you for this nice binding. I have one more question. I am using the 2.x firmware on my KLF200 and I need help to define a switch for the silent mode. Do I have to define a switch for every rollershutter? Please can you give me an example for my item file.

Thank you!

[antares2001]

Hello @gs4711 ,

I’m having some trouble with the binding, after I finally managed to install it (it should definitely be pointed out much clearer, that you should use the Wifi password and not velux123 - especially when that default password is in the docs as example it caused confusion to me).

Now - I have 3 Somfy items and they are recognized by the KLF200. So far so good - but the binding only shows me the garage door item. I suppose it’s due to the fact that all get the same serial 00:00:00…:00. Do you have a clue what the reason is and can I refer in the items file to the index (it’s different for each io-device)?

2019-06-23 00:39:06.054 [DEBUG] [ng.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(): working on response GW_GET_ALL_NODES_INFORMATION_FINISHED_NTF with 0 bytes of data.
2019-06-23 00:39:06.054 [TRACE] [ng.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(): passes back command 0x205 and data .
2019-06-23 00:39:06.054 [DEBUG] [ding.velux.bridge.slip.SCgetProducts] - setResponse(GW_GET_ALL_NODES_INFORMATION_FINISHED_NTF with 0 bytes of data) called.
2019-06-23 00:39:06.054 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): handling response GW_GET_ALL_NODES_INFORMATION_FINISHED_NTF (0x205).
2019-06-23 00:39:06.054 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): finished-packet received.
2019-06-23 00:39:06.054 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - setResponse(): finished=true,success=true.
2019-06-23 00:39:06.055 [DEBUG] [ng.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(GW_GET_ALL_NODES_INFORMATION_REQ) returns success.
2019-06-23 00:39:06.055 [TRACE] [ding.velux.bridge.slip.SCgetProducts] - getProducts(): returning array of 3 products.
2019-06-23 00:39:06.055 [TRACE] [ng.velux.bridge.VeluxBridgeActuators] - getProducts() found product Garagentor (type UNDEFTYPE).
2019-06-23 00:39:06.055 [TRACE] [g.velux.things.VeluxExistingProducts] - isRegistered(VeluxProduct Product "Garagentor" / UNDEFTYPE (bridgeIndex=0,serial=00:00:00:00:00:00:00:00,position=C800)) called.
2019-06-23 00:39:06.055 [TRACE] [g.velux.things.VeluxExistingProducts] - isRegistered(String 00:00:00:00:00:00:00:00) returns false.
2019-06-23 00:39:06.055 [DEBUG] [ng.velux.bridge.VeluxBridgeActuators] - getProducts() storing new product Product "Garagentor" / UNDEFTYPE (bridgeIndex=0,serial=00:00:00:00:00:00:00:00,position=C800).
2019-06-23 00:39:06.056 [TRACE] [g.velux.things.VeluxExistingProducts] - register(Product "Garagentor" / UNDEFTYPE (bridgeIndex=0,serial=00:00:00:00:00:00:00:00,position=C800)) called.
2019-06-23 00:39:06.056 [TRACE] [g.velux.things.VeluxExistingProducts] - isRegistered(VeluxProduct Product "Garagentor" / UNDEFTYPE (bridgeIndex=0,serial=00:00:00:00:00:00:00:00,position=C800)) called.
2019-06-23 00:39:06.056 [TRACE] [g.velux.things.VeluxExistingProducts] - isRegistered(String 00:00:00:00:00:00:00:00) returns false.
2019-06-23 00:39:06.056 [TRACE] [g.velux.things.VeluxExistingProducts] - register() registering new product Product "Garagentor" / UNDEFTYPE (bridgeIndex=0,serial=00:00:00:00:00:00:00:00,position=C800).
2019-06-23 00:39:06.056 [TRACE] [g.velux.things.VeluxExistingProducts] - register() registering by UniqueIndex 00:00:00:00:00:00:00:00
2019-06-23 00:39:06.056 [TRACE] [g.velux.things.VeluxExistingProducts] - register() registering by ProductBridgeIndex 0
2019-06-23 00:39:06.057 [TRACE] [g.velux.things.VeluxExistingProducts] - register() registering set of modifications by UniqueIndex 00:00:00:00:00:00:00:00
2019-06-23 00:39:06.057 [TRACE] [ng.velux.bridge.VeluxBridgeActuators] - getProducts() found product Arbeitszimmer (type ROLLER_SHUTTER).
2019-06-23 00:39:06.057 [TRACE] [g.velux.things.VeluxExistingProducts] - isRegistered(VeluxProduct Product "Arbeitszimmer" / ROLLER_SHUTTER (bridgeIndex=1,serial=00:00:00:00:00:00:00:00,position=A443)) called.
2019-06-23 00:39:06.057 [TRACE] [g.velux.things.VeluxExistingProducts] - isRegistered(String 00:00:00:00:00:00:00:00) returns true.
2019-06-23 00:39:06.057 [DEBUG] [ng.velux.bridge.VeluxBridgeActuators] - getProducts() storing updates for product Product "Arbeitszimmer" / ROLLER_SHUTTER (bridgeIndex=1,serial=00:00:00:00:00:00:00:00,position=A443).
2019-06-23 00:39:06.057 [TRACE] [g.velux.things.VeluxExistingProducts] - update(currentProduct=Product "Arbeitszimmer" / ROLLER_SHUTTER (bridgeIndex=1,serial=00:00:00:00:00:00:00:00,position=A443)) called.
2019-06-23 00:39:06.057 [DEBUG] [g.velux.things.VeluxExistingProducts] - update(bridgeProductIndex=1,productState=5,productPosition=42051,productTarget=42051) called.
2019-06-23 00:39:06.058 [TRACE] [g.velux.things.VeluxExistingProducts] - isRegisteredProductBridgeIndex org.openhab.binding.velux.things.VeluxProduct$ProductBridgeIndex@6b514627) called.
2019-06-23 00:39:06.058 [WARN ] [g.velux.things.VeluxExistingProducts] - update() failed as actuator (with index 1) is not registered.
2019-06-23 00:39:06.058 [TRACE] [ng.velux.bridge.VeluxBridgeActuators] - getProducts() found product Ankleidezimmer (type ROLLER_SHUTTER).
2019-06-23 00:39:06.058 [TRACE] [g.velux.things.VeluxExistingProducts] - isRegistered(VeluxProduct Product "Ankleidezimmer" / ROLLER_SHUTTER (bridgeIndex=2,serial=00:00:00:00:00:00:00:00,position=B059)) called.
2019-06-23 00:39:06.058 [TRACE] [g.velux.things.VeluxExistingProducts] - isRegistered(String 00:00:00:00:00:00:00:00) returns true.
2019-06-23 00:39:06.058 [DEBUG] [ng.velux.bridge.VeluxBridgeActuators] - getProducts() storing updates for product Product "Ankleidezimmer" / ROLLER_SHUTTER (bridgeIndex=2,serial=00:00:00:00:00:00:00:00,position=B059).
2019-06-23 00:39:06.058 [TRACE] [g.velux.things.VeluxExistingProducts] - update(currentProduct=Product "Ankleidezimmer" / ROLLER_SHUTTER (bridgeIndex=2,serial=00:00:00:00:00:00:00:00,position=B059)) called.
2019-06-23 00:39:06.059 [DEBUG] [g.velux.things.VeluxExistingProducts] - update(bridgeProductIndex=2,productState=5,productPosition=45145,productTarget=45145) called.
2019-06-23 00:39:06.059 [TRACE] [g.velux.things.VeluxExistingProducts] - isRegisteredProductBridgeIndex org.openhab.binding.velux.things.VeluxProduct$ProductBridgeIndex@1cfbb953) called.
2019-06-23 00:39:06.059 [WARN ] [g.velux.things.VeluxExistingProducts] - update() failed as actuator (with index 2) is not registered.

There you see they are all 00:00:00:00…:00.

I appreciate any help and thank you for your hard and great work to make us able to use io-homecontrol devices with KLF200.

[antares2001]

Some additional info to my previous post. When downloading the demo for the firmware v2 API, I get the scenes and can call them with ActivateScene.py, but the Velux binding doesn’t show them up on OpenHAB.

[lukqw]

Hi I’m running into a weird problem. This is in my logs continuously:

2019-06-27 15:04:44.947 [INFO ] [g.velux.bridge.slip.io.SSLconnection] - Starting velux bridge connection.

2019-06-27 15:04:44.971 [WARN ] [ng.velux.bridge.slip.SlipVeluxBridge] - io(): raised an error during connection setup: SSL V2.0 servers are not supported..

2019-06-27 15:04:44.975 [INFO ] [g.velux.bridge.slip.io.SSLconnection] - Starting velux bridge connection.

2019-06-27 15:04:44.999 [WARN ] [ng.velux.bridge.slip.SlipVeluxBridge] - io(): raised an error during connection setup: SSL V2.0 servers are not supported..

2019-06-27 15:04:45.003 [INFO ] [g.velux.bridge.slip.io.SSLconnection] - Starting velux bridge connection.

2019-06-27 15:04:45.027 [WARN ] [ng.velux.bridge.slip.SlipVeluxBridge] - io(): raised an error during connection setup: SSL V2.0 servers are not supported..

2019-06-27 15:04:45.032 [INFO ] [g.velux.bridge.slip.io.SSLconnection] - Starting velux bridge connection.

2019-06-27 15:04:45.056 [WARN ] [ng.velux.bridge.slip.SlipVeluxBridge] - io(): raised an error during connection setup: SSL V2.0 servers are not supported..

2019-06-27 15:04:45.059 [INFO ] [g.velux.bridge.slip.io.SSLconnection] - Starting velux bridge connection.

2019-06-27 15:04:45.073 [WARN ] [ng.velux.bridge.slip.SlipVeluxBridge] - io(): raised an error during connection setup: SSL V2.0 servers are not supported..

2019-06-27 15:04:45.075 [INFO ] [g.velux.bridge.slip.io.SSLconnection] - Starting velux bridge connection.

2019-06-27 15:04:45.088 [WARN ] [ng.velux.bridge.slip.SlipVeluxBridge] - io(): raised an error during connection setup: SSL V2.0 servers are not supported..

2019-06-27 15:04:45.090 [INFO ] [ng.velux.bridge.slip.SlipVeluxBridge] - io(): socket I/O failed 5 times.

2019-06-27 15:04:45.092 [WARN ] [ng.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(): method io() raised an error: null.

2019-06-27 15:04:45.093 [WARN ] [.velux.handler.VeluxBridgeHandlerOH1] - velux bridge login sequence failed; expecting bridge is OFFLINE.

So far I have put the jar from https://github.com/gs4711/org.openhab.binding.velux in /usr/share/openhab2/addons.
Created services/velux.cfg with

bridgeIPAddress=xxxxxx

Created items/velux.items

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" }

// 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"}

Can someone help me out here on what to do?

Edit: velux firmware is 0.1.1.0.41.0

Edit 2: maybe pinging @gs4711 helps

[lukqw]

I figured it out:
If you are not using the newest velux klf 200 firmware, you have to set the protocol to http. Password for connecting was velux123 and Port 80.

I ran into a new problem though, because a lot of times the binding sends an empty request:

2019-06-28 14:14:05.925 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - io() to http://10.3.0.26:80/api/v1/device using request null.

2019-06-28 14:14:05.938 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - io(): wait time 2000 msecs.

2019-06-28 14:14:07.942 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - io() got response )]}',.{"token":"LlIjXUcUUh/PU0UsHE9SOQ==","result":false,"deviceStatus":"IDLE","data":{},"errors":[999]}.

2019-06-28 14:14:07.945 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - io() cleaned response {"token":"LlIjXUcUUh/PU0UsHE9SOQ==","result":false,"deviceStatus":"IDLE","data":{},"errors":[999]}.

2019-06-28 14:14:07.952 [ERROR] [b.core.service.AbstractActiveService] - Error while executing background thread velux Refresh Service

java.lang.NullPointerException: null

This leads to the velux refusing a connection later on because of the repeated requests (or at least I think that’s what happens)

2019-06-28 14:14:42.274 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - io() to http://10.3.0.26:80/api/v1/auth using request {"action":"login","params":{"password":"velux123"}}.

2019-06-28 14:14:42.284 [ERROR] [org.openhab.io.net.http.HttpUtil    ] - Fatal transport error: java.net.ConnectException: Connection refused (Connection refused)

2019-06-28 14:14:42.286 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - io(): Exception occurred during I/O: transport error.

2019-06-28 14:14:42.289 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - io(): wait time 2000 msecs.

Why are empty requests even being sent? And how can I fix this? @gs4711

[tinusv (Martijn)]

I got the binding running, but it cannot find any actuators, while there are 2 visible in the Web interface of the klf200. Anybody a suggestion? Here the log entries:

13:41:07.630 [INFO ] [b.binding.velux.internal.VeluxBinding] - velux refresh interval set to 15000 milliseconds.
13:41:07.635 [INFO ] [ab.core.service.AbstractActiveService] - velux Refresh Service has been started
13:41:07.635 [INFO ] [b.binding.velux.internal.VeluxBinding] - veluxConfig[bridgeProtocol=slip,bridgeIPAddress=192.168.178.57,bridgeTCPPort=51200,bridgePassword=**********,timeoutMsecs=15000,retries=15,refreshMsecs=15000,isBulkRetrievalEnabled=true]
13:41:22.696 [INFO ] [ng.velux.bridge.slip.io.SSLconnection] - Starting velux bridge connection.
13:41:42.657 [INFO ] [hab.binding.velux.bridge.slip.SClogin] - velux bridge connection successfully established (login succeeded).
13:42:12.715 [INFO ] [g.velux.handler.VeluxBridgeHandlerOH1] - Found velux scenes:
13:42:27.846 [INFO ] [g.velux.handler.VeluxBridgeHandlerOH1] - Found velux actuators:
13:42:42.880 [INFO ] [g.velux.handler.VeluxBridgeHandlerOH1] - velux Bridge is online, now.