[velux] New OpenHAB2 binding - feedback welcome!

gs4711 · April 23, 2019, 3:53pm

This issue is fixed within PR#5843 . Hope that it will be incorporated soon.

Kim_Andersen · April 23, 2019, 4:29pm

Nope, I always use items files, because I have had troubble with paperUI items before… Never again… So the last year or more, I have been using items files only.

Kim_Andersen · April 23, 2019, 5:53pm

Is this also an issue… I just setup my scenes as well, which I use in a rule… But when the scene activates, this happen:

2019-04-23 19:48:41.297 [ome.event.ItemCommandEvent] - Item 'VeluxAlleAaben100' received command ON
2019-04-23 19:48:41.302 [vent.ItemStateChangedEvent] - VeluxAlleAaben100 changed from NULL to ON
2019-04-23 19:48:41.308 [GroupItemStateChangedEvent] - gV changed from NULL to ON through VeluxAlleAaben100
2019-04-23 19:48:42.055 [ome.event.ItemCommandEvent] - Item 'VeluxAlleAaben100' received command OFF

2019-04-23 19:48:43.321 [WARN ] [binding.velux.bridge.slip.SCrunScene] - setResponse(): received GW_COMMAND_RUN_STATUS_NTF, continuing.
2019-04-23 19:48:43.332 [WARN ] [binding.velux.bridge.slip.SCrunScene] - setResponse(): received GW_COMMAND_RUN_STATUS_NTF, continuing.
2019-04-23 19:48:43.341 [WARN ] [binding.velux.bridge.slip.SCrunScene] - setResponse(): received GW_COMMAND_RUN_STATUS_NTF, continuing.
2019-04-23 19:48:43.352 [WARN ] [binding.velux.bridge.slip.SCrunScene] - setResponse(): received GW_COMMAND_RUN_STATUS_NTF, continuing.
2019-04-23 19:48:43.362 [WARN ] [binding.velux.bridge.slip.SCrunScene] - setResponse(): received GW_COMMAND_RUN_STATUS_NTF, continuing.
2019-04-23 19:48:43.374 [WARN ] [binding.velux.bridge.slip.SCrunScene] - setResponse(): received GW_COMMAND_RUN_STATUS_NTF, continuing.
2019-04-23 19:48:43.385 [WARN ] [binding.velux.bridge.slip.SCrunScene] - setResponse(): received GW_COMMAND_RUN_STATUS_NTF, continuing.
2019-04-23 19:48:43.393 [WARN ] [binding.velux.bridge.slip.SCrunScene] - setResponse(): received GW_COMMAND_RUN_STATUS_NTF, continuing.
2019-04-23 19:48:43.398 [WARN ] [binding.velux.bridge.slip.SCrunScene] - setResponse(): received GW_COMMAND_REMAINING_TIME_NTF, continuing.
2019-04-23 19:48:43.403 [WARN ] [binding.velux.bridge.slip.SCrunScene] - setResponse(): received GW_COMMAND_REMAINING_TIME_NTF, continuing.
2019-04-23 19:48:43.408 [WARN ] [binding.velux.bridge.slip.SCrunScene] - setResponse(): received GW_COMMAND_REMAINING_TIME_NTF, continuing.
2019-04-23 19:48:43.413 [WARN ] [binding.velux.bridge.slip.SCrunScene] - setResponse(): received GW_COMMAND_REMAINING_TIME_NTF, continuing.
2019-04-23 19:48:43.418 [WARN ] [binding.velux.bridge.slip.SCrunScene] - setResponse(): received GW_COMMAND_REMAINING_TIME_NTF, continuing.
2019-04-23 19:48:43.423 [WARN ] [binding.velux.bridge.slip.SCrunScene] - setResponse(): received GW_COMMAND_REMAINING_TIME_NTF, continuing.
2019-04-23 19:48:43.428 [WARN ] [binding.velux.bridge.slip.SCrunScene] - setResponse(): received GW_COMMAND_REMAINING_TIME_NTF, continuing.
2019-04-23 19:48:43.433 [WARN ] [binding.velux.bridge.slip.SCrunScene] - setResponse(): received GW_COMMAND_REMAINING_TIME_NTF, continuing.
2019-04-23 19:49:08.449 [WARN ] [binding.velux.bridge.slip.SCrunScene] - setResponse(): received GW_COMMAND_RUN_STATUS_NTF, continuing.
2019-04-23 19:49:09.425 [WARN ] [binding.velux.bridge.slip.SCrunScene] - setResponse(): received GW_COMMAND_RUN_STATUS_NTF, continuing.
2019-04-23 19:49:10.439 [WARN ] [binding.velux.bridge.slip.SCrunScene] - setResponse(): received GW_COMMAND_RUN_STATUS_NTF, continuing.
2019-04-23 19:49:11.423 [WARN ] [binding.velux.bridge.slip.SCrunScene] - setResponse(): received GW_COMMAND_RUN_STATUS_NTF, continuing.
2019-04-23 19:49:12.422 [WARN ] [binding.velux.bridge.slip.SCrunScene] - setResponse(): received GW_COMMAND_RUN_STATUS_NTF, continuing.
2019-04-23 19:49:13.422 [WARN ] [binding.velux.bridge.slip.SCrunScene] - setResponse(): received GW_COMMAND_RUN_STATUS_NTF, continuing.
2019-04-23 19:49:14.474 [WARN ] [binding.velux.bridge.slip.SCrunScene] - setResponse(): received GW_COMMAND_RUN_STATUS_NTF, continuing.
2019-04-23 19:49:15.462 [WARN ] [binding.velux.bridge.slip.SCrunScene] - setResponse(): received GW_COMMAND_RUN_STATUS_NTF, continuing.
2019-04-23 19:49:15.466 [WARN ] [binding.velux.bridge.slip.SCrunScene] - setResponse(): received GW_SESSION_FINISHED_NTF.
2019-04-23 19:49:15.468 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): updating of item VeluxAlleAaben100 (type SCENE_ACTION) failed.

All the windows do open fine though…

This is my items file:

/* Velux Bridge and Devices */

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

Rollershutter Vindue01 "Vindue stue syd-øst 1 [%d]"    { velux="thing=actuator;channel=serial#56:08:1D:26:06:29:06:C7" }
Rollershutter Vindue02 "Vindue spisestue øst 2 [%d]"   { velux="thing=actuator;channel=serial#56:08:1D:26:06:30:0A:CD" }
Rollershutter Vindue03 "Vindue stue nord-øst 3 [%d]"   { velux="thing=actuator;channel=serial#56:08:1D:26:06:29:12:03" }
Rollershutter Vindue04 "Vindue køkken syd-øst 4 [%d]"  { velux="thing=actuator;channel=serial#56:08:1D:26:06:29:08:7B" }
Rollershutter Vindue05 "Vindue stue syd-vest 5 [%d]"   { velux="thing=actuator;channel=serial#56:08:1D:26:06:29:14:5B" }
Rollershutter Vindue06 "Vindue spisestue vest 6 [%d]"  { velux="thing=actuator;channel=serial#56:08:1D:26:06:30:0C:A1" }
Rollershutter Vindue07 "Vindue køkken nord-øst 7 [%d]" { velux="thing=actuator;channel=serial#56:08:1D:26:06:29:0D:0D" }
Rollershutter Vindue08 "Vindue stue nord-vest 8 [%d]"  { velux="thing=actuator;channel=serial#56:08:1D:26:06:29:14:5C" }

// Velux Scene channels

Switch  VeluxAlleLuk       "Luk alle vinduer"                  <window>	(gV)     { velux="thing=scene;channel=action#AlleVinduerLuk" }
Switch  VeluxAlleAaben50   "Åben alle vinduer 50%"             <window>	(gV)     { velux="thing=scene;channel=action#AlleVinduer50" }
Switch  VeluxAlleAaben75   "Åben alle vinduer 75%"             <window>	(gV)     { velux="thing=scene;channel=action#AlleVinduer75" }
Switch  VeluxAlleAaben100  "Åben alle vinduer 100%"            <window>	(gV)     { velux="thing=scene;channel=action#AlleVinduer100" }
Switch  VeluxAlleVent      "Sæt alle vinduer på ventilation"   <window> (gV)     { velux="thing=scene;channel=action#AlleVinduerVent" }

// Køkken
Switch  VeluxKoekAlleLuk   "Køkken Luk alle"                   <window>	(gV)     { velux="thing=scene;channel=action#KoekkenLuk" }
Switch  VeluxKoekAlleVent  "Køkken vent alle"                  <window>	(gV)     { velux="thing=scene;channel=action#KoekkenVent" }
Switch  VeluxKoekAlle50    "Køkken åben alle 50%"              <window>	(gV)     { velux="thing=scene;channel=action#Koekken50" }
Switch  VeluxKoekAlle75    "Køkken åben alle 75%"              <window>	(gV)     { velux="thing=scene;channel=action#Koekken75" }
Switch  VeluxKoekAlle100   "Køkken åben alle 100%"             <window>	(gV)     { velux="thing=scene;channel=action#Koekken100" }

// Spisestuen
Switch  VeluxSpisAlleLuk   "Spisestue luk alle"                <window>	(gV)     { velux="thing=scene;channel=action#SpisestueLuk" }
Switch  VeluxSpisAlleVent  "Spisestue vent alle"               <window>	(gV)     { velux="thing=scene;channel=action#SpisestueVent" }
Switch  VeluxSpisAlle50    "Spisestue åben alle 50%"           <window>	(gV)     { velux="thing=scene;channel=action#Spisestue50" }
Switch  VeluxSpisAlle75    "Spisestue åben alle 75%"           <window>	(gV)     { velux="thing=scene;channel=action#Spisestue75" }
Switch  VeluxSpisAlle100   "Spisestue åben alle 100%"          <window>	(gV)     { velux="thing=scene;channel=action#Spisestue100" }

// Stuen
Switch  VeluxStueAlleLuk   "Stuen luk alle"                    <window>	(gV)     { velux="thing=scene;channel=action#StueLuk" }
Switch  VeluxStueAlleVent  "Stuen vent alle"                   <window>	(gV)     { velux="thing=scene;channel=action#StueVent" }
Switch  VeluxStueAlle50    "Stuen åben alle 50%"               <window>	(gV)     { velux="thing=scene;channel=action#Stue50" }
Switch  VeluxStueAlle75    "Stuen åben alle 75%"               <window>	(gV)     { velux="thing=scene;channel=action#Stue75" }
Switch  VeluxStueAlle100   "Stuen åben alle 100%"              <window>	(gV)     { velux="thing=scene;channel=action#Stue100" }

AndrewFG · May 10, 2019, 3:31pm

Based on Guenther’s recommendation I bought a KLF200…

… but unfortunately now I can’t see the binding available for download into OpenHab 2 (i.e. its not in the legacy 1.14 list of bindings of PaperUI …

… so where can I get it please?

gs4711 · May 10, 2019, 7:16pm

Hello @AndrewFG,

the binding should be within the 1.14 distribution… or you can find the jar-file within gs4711@github.

Regards, Guenther

AndrewFG · May 11, 2019, 4:27pm

Thanks Guenther. I will start working with it. At the moment, it seems that the only available OpenHab runtime for testing purposes is v2.4. So is it correct that your plugin will work if I drop the JAR file into the OpenHab addons folder (and create respective .config. and .items files)? Or do I need to do something else?

gs4711 · May 11, 2019, 4:55pm

Correct: just create the config files and put the jarfile into the additional folder. If it does not work from the beginning, try to increase the loglevel which will lead to tons of addtional informations.

Regards, Guenther

gs4711 · May 15, 2019, 10:05am

@AndrewFG,

as a matter of interest: is your Velux environment working fine, now?

Regards, Guenther

AndrewFG · May 15, 2019, 10:23am

Hi Guenther, I have been away from home, so have not made any progress. But I will let you know.

AndrewFG · May 15, 2019, 6:15pm

Hi Guenther,

Ok, I tried your binding just now, and I do get “something” but actually it is all errors – see below…

( note: it is a brand new KLF200 unit, with v2.x firmware in it, and with the default password etc. )

2019-05-15 19:00:16.664 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'home.sitemap'
2019-05-15 19:00:26.661 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'velux.items'
2019-05-15 19:00:27.726 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'velux.items'
2019-05-15 19:01:18.141 [INFO ] [inding.velux.internal.VeluxActivator] - velux binding has been started.
2019-05-15 19:01:18.666 [INFO ] [.binding.velux.internal.VeluxBinding] - Active items are: [V_FIRMWARE, V_CHECK, V_STATUS].
2019-05-15 19:01:18.684 [INFO ] [.binding.velux.internal.VeluxBinding] - velux refresh interval set to 15000 milliseconds.
2019-05-15 19:01:18.689 [INFO ] [.binding.velux.internal.VeluxBinding] - veluxConfig[bridgeProtocol=slip,bridgeIPAddress=192.168.1.142,bridgeTCPPort=51200,bridgePassword=********,timeoutMsecs=1000,retries=5,refreshMsecs=15000,isBulkRetrievalEnabled=true]
2019-05-15 19:01:18.704 [INFO ] [b.core.service.AbstractActiveService] - velux Refresh Service has been started
2019-05-15 19:01:18.756 [INFO ] [g.velux.bridge.slip.io.SSLconnection] - Starting velux bridge connection.
2019-05-15 19:01:24.806 [WARN ] [.velux.handler.VeluxBridgeHandlerOH1] - velux bridge login sequence failed; expecting bridge is OFFLINE.
2019-05-15 19:01:25.848 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): updating of item V_STATUS (type BRIDGE_STATUS) failed.
2019-05-15 19:01:26.900 [WARN ] [.velux.handler.VeluxBridgeHandlerOH1] - velux bridge login sequence failed; expecting bridge is OFFLINE.
2019-05-15 19:01:27.924 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): updating of item V_STATUS (type BRIDGE_STATUS) failed.
2019-05-15 19:01:43.940 [WARN ] [.velux.handler.VeluxBridgeHandlerOH1] - velux bridge login sequence failed; expecting bridge is OFFLINE.
2019-05-15 19:01:44.957 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): updating of item V_STATUS (type BRIDGE_STATUS) failed.
2019-05-15 19:02:00.972 [WARN ] [.velux.handler.VeluxBridgeHandlerOH1] - velux bridge login sequence failed; expecting bridge is OFFLINE.
2019-05-15 19:02:01.988 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): updating of item V_STATUS (type BRIDGE_STATUS) failed.
2019-05-15 19:02:18.126 [WARN ] [.velux.handler.VeluxBridgeHandlerOH1] - velux bridge login sequence failed; expecting bridge is OFFLINE.
2019-05-15 19:02:19.169 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): updating of item V_STATUS (type BRIDGE_STATUS) failed.
2019-05-15 19:02:35.184 [WARN ] [.velux.handler.VeluxBridgeHandlerOH1] - velux bridge login sequence failed; expecting bridge is OFFLINE.
2019-05-15 19:02:36.203 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): updating of item V_STATUS (type BRIDGE_STATUS) failed.
2019-05-15 19:02:52.225 [WARN ] [.velux.handler.VeluxBridgeHandlerOH1] - velux bridge login sequence failed; expecting bridge is OFFLINE.
2019-05-15 19:02:53.239 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): updating of item V_STATUS (type BRIDGE_STATUS) failed.
2019-05-15 19:03:09.250 [WARN ] [.velux.handler.VeluxBridgeHandlerOH1] - velux bridge login sequence failed; expecting bridge is OFFLINE.
2019-05-15 19:03:10.261 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): updating of item V_STATUS (type BRIDGE_STATUS) failed.
2019-05-15 19:03:26.271 [WARN ] [.velux.handler.VeluxBridgeHandlerOH1] - velux bridge login sequence failed; expecting bridge is OFFLINE.
2019-05-15 19:03:27.286 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): updating of item V_STATUS (type BRIDGE_STATUS) failed.
2019-05-15 19:03:43.296 [WARN ] [.velux.handler.VeluxBridgeHandlerOH1] - velux bridge login sequence failed; expecting bridge is OFFLINE.
2019-05-15 19:03:44.310 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): updating of item V_STATUS (type BRIDGE_STATUS) failed.
2019-05-15 19:04:00.325 [WARN ] [.velux.handler.VeluxBridgeHandlerOH1] - velux bridge login sequence failed; expecting bridge is OFFLINE.
2019-05-15 19:04:01.341 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): updating of item V_STATUS (type BRIDGE_STATUS) failed.
2019-05-15 19:04:17.354 [WARN ] [.velux.handler.VeluxBridgeHandlerOH1] - velux bridge login sequence failed; expecting bridge is OFFLINE.
2019-05-15 19:04:18.368 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): updating of item V_STATUS (type BRIDGE_STATUS) failed.
2019-05-15 19:04:34.386 [WARN ] [.velux.handler.VeluxBridgeHandlerOH1] - velux bridge login sequence failed; expecting bridge is OFFLINE.
2019-05-15 19:04:35.399 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): updating of item V_STATUS (type BRIDGE_STATUS) failed.
2019-05-15 19:04:51.408 [WARN ] [.velux.handler.VeluxBridgeHandlerOH1] - velux bridge login sequence failed; expecting bridge is OFFLINE.
2019-05-15 19:04:52.419 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): updating of item V_STATUS (type BRIDGE_STATUS) failed.
2019-05-15 19:05:08.440 [WARN ] [.velux.handler.VeluxBridgeHandlerOH1] - velux bridge login sequence failed; expecting bridge is OFFLINE.
2019-05-15 19:05:09.447 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): updating of item V_STATUS (type BRIDGE_STATUS) failed.
2019-05-15 19:05:25.458 [WARN ] [.velux.handler.VeluxBridgeHandlerOH1] - velux bridge login sequence failed; expecting bridge is OFFLINE.
2019-05-15 19:05:26.472 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): updating of item V_STATUS (type BRIDGE_STATUS) failed.
2019-05-15 19:05:41.476 [DEBUG] [.binding.velux.internal.VeluxBinding] - execute() called.
2019-05-15 19:05:41.480 [DEBUG] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(item=V_STATUS,command=null,config=org.openhab.binding.velux.internal.VeluxBindingConfig@1ff6dd2,provider=org.openhab.binding.velux.internal.VeluxGenericBindingProvider@1389c1d) called.
2019-05-15 19:05:41.483 [DEBUG] [.velux.handler.VeluxBridgeHandlerOH1] - bridgeParamsUpdated() called.
2019-05-15 19:05:41.486 [DEBUG] [.velux.handler.VeluxBridgeHandlerOH1] - bridgeParamsUpdated(): choosing SLIP as communication method.
2019-05-15 19:05:41.492 [DEBUG] [ng.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(GW_PASSWORD_ENTER_REQ,unauthenticated) called.
2019-05-15 19:05:41.495 [DEBUG] [ng.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(): working on request GW_PASSWORD_ENTER_REQ with 32 bytes of data.
2019-05-15 19:05:41.506 [DEBUG] [ng.velux.bridge.slip.SlipVeluxBridge] - io(): sending packet of size 39.
2019-05-15 19:05:42.511 [DEBUG] [ng.velux.bridge.slip.SlipVeluxBridge] - io(): received packet with 8 bytes.
2019-05-15 19:05:42.517 [DEBUG] [ng.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(): working on response GW_PASSWORD_ENTER_CFM with 1 bytes of data.
2019-05-15 19:05:42.521 [DEBUG] [ab.binding.velux.bridge.slip.SClogin] - setResponse(GW_PASSWORD_ENTER_CFM with 1 bytes of data) called.
2019-05-15 19:05:42.524 [DEBUG] [ab.binding.velux.bridge.slip.SClogin] - setResponse(): returned status: The request failed.
2019-05-15 19:05:42.528 [DEBUG] [ng.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(GW_PASSWORD_ENTER_REQ) returns failure.
2019-05-15 19:05:42.532 [WARN ] [.velux.handler.VeluxBridgeHandlerOH1] - velux bridge login sequence failed; expecting bridge is OFFLINE.
2019-05-15 19:05:42.536 [DEBUG] [ng.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(GW_PASSWORD_ENTER_REQ,unauthenticated) called.
2019-05-15 19:05:42.540 [DEBUG] [ng.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(): working on request GW_PASSWORD_ENTER_REQ with 32 bytes of data.
2019-05-15 19:05:42.551 [DEBUG] [ng.velux.bridge.slip.SlipVeluxBridge] - io(): sending packet of size 39.
2019-05-15 19:05:43.555 [DEBUG] [ng.velux.bridge.slip.SlipVeluxBridge] - io(): received packet with 8 bytes.
2019-05-15 19:05:43.565 [DEBUG] [ng.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(): working on response GW_PASSWORD_ENTER_CFM with 1 bytes of data.
2019-05-15 19:05:43.567 [DEBUG] [ab.binding.velux.bridge.slip.SClogin] - setResponse(GW_PASSWORD_ENTER_CFM with 1 bytes of data) called.
2019-05-15 19:05:43.570 [DEBUG] [ab.binding.velux.bridge.slip.SClogin] - setResponse(): returned status: The request failed.
2019-05-15 19:05:43.573 [DEBUG] [ng.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(GW_PASSWORD_ENTER_REQ) returns failure.
2019-05-15 19:05:43.575 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): updating of item V_STATUS (type BRIDGE_STATUS) failed.
2019-05-15 19:05:43.580 [DEBUG] [.binding.velux.internal.VeluxBinding] - execute() done.
2019-05-15 19:05:58.584 [DEBUG] [.binding.velux.internal.VeluxBinding] - execute() called.

gs4711 · May 15, 2019, 7:39pm

Hello,

thanks for this part of the log. In fact, you’re only a minor step away from a well-working config:

You have already a well-functioning connectivity to the KLF200 bridge - but you’re simply using a wrong password. Please try the default password.

Greetings, Guenther

AndrewFG · May 16, 2019, 10:42am

Hi Guenther,

Many thanks, I got it working now.

However I do have already a few feedbacks as follows…

In the documentation you refer to the hub configuration file as “openhab.cfg” and you should change this in the documentation to “velux.cfg”
You should make it more explicit in the documentation that the password to use in the velux.cfg file is label on the back of the KLF called “Password” (wifi password) and not the Web logon “password” (velux123)
The position status scale of the velux windows is very confusing – it shows 100% when the window is closed, and 0% when it is open. I think you should reverse the scale.
When one issues a manual command to set a new position of the window, one has to wait for the Refresh Interval before the actual new status is indicated. It would be better to have a fast feedback indication that the command has been received. One idea would be to do it like a thermostat where there are two datapoints - namely “Set Position” and “Actual Position”; the Set Position is what is sent to the hub as a command (SET_STATE), and the Actual Position is what you get back when you query its status (GET_STATE). It could also be helpful if the Refresh Interval would be temporarily shortened after any manual Set Position commands are sent.
The hub variables “firmware” and “check” do not work. However the variable “status” does seem to work Ok.

EDIT: regarding item 4. above, when I issue a manual command from openHAB basic UI to open the window to 50%, I see the following series of events. I suppose the first “100 to 50” event is the initial manual command; all of the subsequent “50 to 100” and “100 to 50” events are spurious…

2019-05-16 16:47:55.163 [vent.ItemStateChangedEvent] - V_LOFT changed from 100 to 50
2019-05-16 16:47:55.182 [vent.ItemStateChangedEvent] - V_LOFT changed from 50 to 100
2019-05-16 16:47:55.201 [vent.ItemStateChangedEvent] - V_LOFT changed from 100 to 50
2019-05-16 16:48:11.078 [vent.ItemStateChangedEvent] - V_LOFT changed from 50 to 100
2019-05-16 16:51:42.127 [vent.ItemStateChangedEvent] - V_LOFT changed from 100 to 50

Madvillain · May 17, 2019, 2:46pm

First of all, thank you @gs4711 for this great binding! I used the version for the firmware version One for a while now and upgraded my KLF 200 to the new firmware - really glad that the windows can be controlled directly now and I can leave behind the scene fiddling.

That being said, I can confirm what @AndrewFG already described: When I set a new window position the item changes back to the previous state after the window movement is complete. But again, after some minutes, it changes again to the position that I actually set. In the following case, the window was closed and I set the item to “48% closed”. For this operation, for events have been logged:

2019-05-17 16:26:05.549 [ome.event.ItemCommandEvent] - Item 'Fenster_Buero' received command 48
2019-05-17 16:26:05.566 [vent.ItemStateChangedEvent] - Fenster_Buero changed from 100 to 48
2019-05-17 16:26:31.046 [vent.ItemStateChangedEvent] - Fenster_Buero changed from 48 to 100
2019-05-17 16:29:13.293 [vent.ItemStateChangedEvent] - Fenster_Buero changed from 100 to 48

gs4711 · May 17, 2019, 3:09pm

Thanks for the feedback. Which version of the binding are you using? Should have been fixed with PR#5843.

Madvillain · May 17, 2019, 4:00pm

This might be an embarrassing question - but how/where can I download the most recent version?

The one I downloaded and use is the one you linked to here:

Kim_Andersen · May 17, 2019, 4:32pm

That is the latest .jar file as far as I can see. I use the same, and ofcouse have the exact same issues.
@gs4711 I guess there is a need to an updated jar

gs4711 · May 17, 2019, 7:30pm

Hhhhm. Sorry guys, perhaps you’re right.

I have to check the mentioned build against the two not yet merged open PRs.

spiff42 · May 28, 2019, 9:19am

I don’t know what makes the difference, but on my KLF200 the WIFI password did not work, I had to use velux123, which took me some time to find out I have not changed any passwords on the KLF200. So the documentation should probably state to try both, since apparently it depends on HW revision.

I think this should be somehow configurable, because although it seems confusing with the window it makes sense when considering we are controlling a “rollershutter” item (the icon shows the rollershutter fully closed when at 100%, and fully open when at 0%).

I also have a couple of MML awning blinds, which show 100% when the blinds are closed and 0% when they are open. That seems logical for awning blinds (and probably some other items).

Also, for the windows, there is the “ventilation” position, where the window is closed, but you still get some fresh air. Does this map to a special setting on the item? I guess if the position status scale is reversed so 0% is closed and 100% is fully open, then 1% would make some sense for the ventilation position?

Cheers

Kim_Andersen · May 28, 2019, 9:39am

To me it doesnt really make any sense at all.
0 (zero) should have the meaning of the default state. If you believe your rullershutter, blinds, etc has the default state of beeing closed, then yes, zero makes sense. But I honestly dont think this is a normal opinion.
As for windows, default state is closed. So for this to get any sense, anything else than closed should be open. And then, how much it´s open, (ie something between 1 - 100).
I wonder what sense you´ll give ligthing (dimmer) then? 0 = full light?
Again, default state is it´s turned off. It doesn´t make sense this beeing reported as 100%.

I sure wish we could get this changed to what would be correct for the most.
Rollershutter and blinds are open by default, and can be controlled closed from 1 to 100%.
Windows, lights etc are OFF by default. And can be controlled lit from 1 to 100%.

I could live with an option of setting an inverted default state through the binding though. But we have to have the correct way to controle these things, from 1 - 100%. And not the other way around.
Then it doesnt matter, if you through the binding set your rollershutter to be closed state as default. You´ll still use 1 to 100% to open it.

I dont know if Guenther (@gs4711) have had any thoughts about this?

spiff42 · May 28, 2019, 10:19am

You don’t need to be sarcastic - it just makes it appear like you didn’t understand what I wrote. I’m not suggesting changing the meaning of light dimmers (unless you get the darkness-bulbs the make the room darker when you turn them on; they are much more environmentally friendly )

I don’t know what you mean by the default state. In my opinion the most logical for windows would be 0%=closed and 100%=fully open. 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%. 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. This is a window, not a rollershutter, but still the best OpenHAB item type currently available is a rollershutter.

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. I mentioned it because maybe Guenther does not have such blinds, so he would not be aware that just reversing the direction of all items is not a good idea.

Cheers