[velux] New OpenHAB2 binding - feedback welcome!

Inversion can be activated on any of the things actuator, window and rollershutter.
Automaticly the inversion will be activated by autodiscovery of a window (paperUI).

Of course, the channels limitationMinimum and limitationMaximum can be set on any device (but switches) so that we need an interpretation whether the minimum should be the real minimum or vice versa.

Found it: The localization of the text unused: {}. causes your problems. Have to review the i18n specs. and will provide a fix, soon.

Let me guess: you have been some scenes which are not used?

No all scenes from the klf200 is configured in my things file as well.

Hello @tstark ,

thank for your message. Let’s try to recap:

(a) The repeated messages in the event logs are ugly but do not disturb the operation. This is fixed in the recent binding jarfile.

(b) The message about unknown channel limitation came by changes during the review process which led to two channels limitationMinimum and channel limitationMaximum instead of the channel limitation. A re-discovery of the bridge thing should eliminate this issue.

(c ) That a pity. Do you have some log informations, what has happened? This would be great.

(d) Is the binding stable and operational, now? Otherwise please replace it by the recent jar-file and restart openHAB (with this snapshot-release a hot-replacement of the binding is working, again :roll_eyes:).

Best regards, Guenther

Hello Ingo,

perhaps a good idea could be if you start with a tiny configuration, i.e. with the definition of the bridge element. This can be done in a separate file for example velux-bridge.things

Bridge velux:klf200:gs28 [ ipAddress="192.168.45.9", tcpPort=51200, password="secret", isProtocolTraceEnabled=true ]

Without any further configuration this should lead to some output within the logfiles, like

08:15:15.108 [INFO ] [del.core.internal.ModelRepositoryImpl] - Loading model ‘velux-bridge.things’
08:15:15.273 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - ‘velux:klf200:gs28’ changed from UNINITIALIZED to INITIALIZING
08:15:15.283 [INFO ] [x.internal.handler.VeluxBridgeHandler] - Initializing Velux Bridge ‘velux:klf200:gs28’.
08:15:15.285 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - ‘velux:klf200:gs28’ changed from INITIALIZING to UNKNOWN
08:15:15.289 [INFO ] [b.binding.velux.internal.VeluxBinding] - veluxConfig[protocol=slip,ipAddress=192.168.45.9,tcpPort=51200,password=**********,timeoutMsecs=500,retries=5,refreshMsecs=10000,isBulkRetrievalEnabled=true,isSequentialEnforced=false,isProtocolTraceEnabled=true]
08:15:15.291 [INFO ] [.internal.bridge.slip.SlipVeluxBridge] - Sending command GW_PASSWORD_ENTER_REQ.
08:15:15.292 [INFO ] [internal.bridge.slip.io.SSLconnection] - Starting velux bridge connection.
08:15:20.200 [INFO ] [.internal.bridge.slip.SlipVeluxBridge] - Received answer GW_PASSWORD_ENTER_CFM.
08:15:20.201 [INFO ] [ng.velux.internal.bridge.slip.SClogin] - velux bridge connection successfully established (login succeeded).
08:15:20.202 [INFO ] [.internal.bridge.slip.SlipVeluxBridge] - Sending command GW_GET_STATE_REQ.
08:15:20.706 [INFO ] [.internal.bridge.slip.SlipVeluxBridge] - Received answer GW_GET_STATE_CFM.
08:15:20.707 [INFO ] [.internal.bridge.slip.SlipVeluxBridge] - Sending command GW_GET_SCENE_LIST_REQ.
08:15:21.211 [INFO ] [.internal.bridge.slip.SlipVeluxBridge] - Received answer GW_GET_SCENE_LIST_CFM.
08:15:21.213 [INFO ] [.internal.bridge.slip.SlipVeluxBridge] - Received answer GW_GET_SCENE_LIST_NTF.
08:15:21.214 [INFO ] [x.internal.handler.VeluxBridgeHandler] - Found velux scenes:
Scene “Window-Close” (index 1) with non-silent mode and 0 actions
Scene “Window-Open” (index 0) with non-silent mode and 0 actions
08:15:21.215 [INFO ] [.internal.bridge.slip.SlipVeluxBridge] - Sending command GW_GET_ALL_NODES_INFORMATION_REQ.
08:15:21.717 [INFO ] [.internal.bridge.slip.SlipVeluxBridge] - Received answer GW_GET_ALL_NODES_INFORMATION_CFM.
08:15:21.718 [INFO ] [.internal.bridge.slip.SlipVeluxBridge] - Received answer GW_GET_ALL_NODES_INFORMATION_NTF.
08:15:21.720 [INFO ] [.internal.bridge.slip.SlipVeluxBridge] - Received answer GW_GET_ALL_NODES_INFORMATION_NTF.
08:15:21.721 [INFO ] [.internal.bridge.slip.SlipVeluxBridge] - Received answer GW_GET_ALL_NODES_INFORMATION_NTF.
08:15:21.722 [INFO ] [.internal.bridge.slip.SlipVeluxBridge] - Received answer GW_GET_ALL_NODES_INFORMATION_NTF.
08:15:21.724 [INFO ] [.internal.bridge.slip.SlipVeluxBridge] - Received answer GW_GET_ALL_NODES_INFORMATION_NTF.
08:15:21.724 [INFO ] [.internal.bridge.slip.SlipVeluxBridge] - Received answer GW_GET_ALL_NODES_INFORMATION_FINISHED_NTF.
08:15:21.724 [INFO ] [x.internal.handler.VeluxBridgeHandler] - Found velux actuators:
Product “#0” / SLIDER_SHUTTER (bridgeIndex=0,serial=56:32:14:5A:12:1C:05:5F,position=0000)
Product “#4” / SWITCH (bridgeIndex=4,serial=#4,position=C800)
Product “.” / SLIDER_SHUTTER (bridgeIndex=1,serial=53:09:40:5A:0C:23:0A:6E,position=0000)
Product “DG-M-Window” / SLIDER_WINDOW (bridgeIndex=3,serial=56:23:3E:26:0C:1B:00:10,position=C800)
Product “#2” / SLIDER_SHUTTER (bridgeIndex=2,serial=53:09:40:5A:0C:2A:05:64,position=0000)
08:15:21.725 [INFO ] [.internal.bridge.slip.SlipVeluxBridge] - Sending command GW_HOUSE_STATUS_MONITOR_ENABLE_REQ.
08:15:22.231 [INFO ] [.internal.bridge.slip.SlipVeluxBridge] - Received answer GW_HOUSE_STATUS_MONITOR_ENABLE_CFM.
08:15:22.231 [INFO ] [x.internal.handler.VeluxBridgeHandler] - velux Bridge is online with 2 scenes and 5 actuators, now.
08:15:22.232 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - ‘velux:klf200:gs28’ changed from UNKNOWN to ONLINE

If you are familiar with the console, you should be able to see the bridge thing:

openhab> smarthome:things list
velux:klf200:gs28 (Type=Bridge, Status=ONLINE, Label=Velux KLF200, Bridge=null)

Bases on this situation you can add different things refering onto that bridge, i.e. a window defined in velux-001.thing (binding=velux, thing type=window, bridge=gs28, name=window001):

Thing velux:window:gs28:window001 (velux:klf200:gs28) [ serial=“53:09:40:5A:0C:2A:05:64” ]

After this, the thing should appear and the log should tell you the same:

08:43:58.682 [INFO ] [del.core.internal.ModelRepositoryImpl] - Refreshing model ‘velux-001.things’
08:43:58.695 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - ‘velux:window:gs28:window001’ changed from UNINITIALIZED to INITIALIZING
08:43:58.707 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - ‘velux:window:gs28:window001’ changed from INITIALIZING to ONLINE

Pleas feel me to comment!

Best regards, Guenther

Thanks Guenther, I will try the next days. I have to go to work again :wink:

Hi Guenther.

Thank you for your fast reply. And sorry for my rather long post also mixing things. But you did very well… not forgetting anything. Lets stick to your recap style. Like it;

c). [any logs available] Unfortunately not. It was during the renewal period before moving in. Lots of stuff broke (especially when testing the two existing velux bindings…) and I had to reinstall OH as well :frowning: tldr no logs, sorry

a)b)d). [reoccurring error messages in the OH-log] You are right. Its just unpleasant. The plugin works without any other issue (as far as I am aware of). I did replace the plugin in the add-ons directory, restarted OH2.5 and readded the bridge thing (minor remark: I did give it the same thing-ID in order to keep my actuator things). But unfortunately the messages reappear every 10 minutes.

Any other idea?!

Best regards Andreas

Hello Andreas,

have I got it right, that the message

still occurs after removal and recreation of the bridge thing?

Could you please post the answer of the command openhab-cli console smarthome:things show ?

Hi,

I run the binding since 2 weeks. It works with the issues, which are discuss here at last. I be aware of an delay up to 40 seconds between command in the sitemap and the real action.

But I have an other question. The documentation is for the 1.x binding, not for the 2.5 binding, so I don’t understand some Items.

One Item called Silentmode and is an switch-item. According to the API-manual from velux there are 3 states default, silent and fast. So why the item is not an number-item, so I can choose al three state? Or: between which state the switch change ON/Off?

The imitation item is rollershutter-item, but I don’t know how to use, because there are two states min and max limitation.

Is there a chance to get all states from the item bridge.status? My sitemap shows “GW_S_GWM/GW_SS_IDLE”, according to the API-Doc it means “Gateway State/Substate Idle”. According to the API-doc there are following states

  • Performing task in Configuration Service handler

  • Performing Scene Configuration

  • Performing Information Service Configuration.

  • Performing Contact input Configuration.

How they are shown in the Binding. Goal is an mapping-file to translate the States, so my wife can read them :wink:

Same Goal with the bridge.check-item which shows “@text/channelValue.check-integrity-ok”, which other states are there?

thanks for the answer

The document is for both versions of the KLF firmware (version 1 and 2).

I dont use limitations at all for my windows. I dont see whats the need of it. The windows already have a max/min build-in.

I have never seen anything else than Idle for this.

Hello together,

The limitation can be helpful if you have some roof windows which should be closed during rain.
And vice versa (as the Velux original equipment takes care for such situations) you can recognize the presence of rain by getting the change event on the limitationMaximum channel.

Hmm but my windows have build-in rainsensor. They will close to Ventilation state, when it´s raining…
So if I understand you correctly, I can get this state from the limitationMaximum channel?

Hello @Cernon,

thanka for this feedback.

Could you please activate either within the bridge configuration isProtocolTraceEnabled=true or within the console the debugging level to trace (log:set trace org.openhab.binding.velux.internal). I’d like to get more information about the cause of this delay as the binding is currently highly parallelized with three different thread pools.

In fact, during 18 months of dealing with this bridge I never have got another status. Yes, it is documented, but the gateway does not provide some other states - hopefully this will be fixed in another release of the firmware.

Hi Guenther.

Sorry for the delay. Holidays and the kids needed attention :wink:. Anyway I did remove all things (bridge and shutter) and recreated them using different thing IDs. Apparently openhab did reuse an old configuration when using the old id. Now I only get that bunch of Thing 'velux:klf200:360b7a8c' has been updated. messages but that is much less disturbing :stuck_out_tongue_winking_eye: … Just in case… here is my current log tail.

2020-01-06 22:12:10.037 [INFO ] [ing.velux.handler.VeluxBridgeHandler] - Initializing Velux veluxBridge handler for 'velux:klf200:360b7a8c'.
2020-01-06 22:12:10.045 [hingStatusInfoChangedEvent] - 'velux:klf200:360b7a8c' changed from ONLINE to UNKNOWN
2020-01-06 22:12:10.055 [INFO ] [.binding.velux.internal.VeluxBinding] - veluxConfig[protocol=slip,ipAddress=192.168.178.53,tcpPort=51200,password=**********,timeoutMsecs=500,retries=5,refreshMsecs=10000,isBulkRetrievalEnabled=true,isSequentialEnforced=false,isProtocolTraceEnabled=false]
2020-01-06 22:12:10.062 [INFO ] [g.velux.bridge.slip.io.SSLconnection] - Starting velux bridge connection.
2020-01-06 22:12:15.249 [INFO ] [ab.binding.velux.bridge.slip.SClogin] - velux bridge connection successfully established (login succeeded).
2020-01-06 22:12:16.269 [INFO ] [ing.velux.handler.VeluxBridgeHandler] - Found velux scenes:
2020-01-06 22:12:16.823 [INFO ] [ing.velux.handler.VeluxBridgeHandler] - Found velux actuators:
2020-01-06 22:12:17.331 [INFO ] [ing.velux.handler.VeluxBridgeHandler] - velux Bridge is online with 0 scenes and 2 actuators, now.
2020-01-06 22:12:17.338 [hingStatusInfoChangedEvent] - 'velux:klf200:360b7a8c' changed from UNKNOWN to ONLINE
2020-01-06 22:12:47.944 [me.event.ThingUpdatedEvent] - Thing 'velux:klf200:360b7a8c' has been updated.
2020-01-06 22:12:47.986 [me.event.ThingUpdatedEvent] - Thing 'velux:klf200:360b7a8c' has been updated.
2020-01-06 22:12:48.544 [me.event.ThingUpdatedEvent] - Thing 'velux:klf200:360b7a8c' has been updated.
2020-01-06 22:12:48.562 [me.event.ThingUpdatedEvent] - Thing 'velux:klf200:360b7a8c' has been updated.
2020-01-06 22:12:49.151 [me.event.ThingUpdatedEvent] - Thing 'velux:klf200:360b7a8c' has been updated.
2020-01-06 22:12:49.173 [me.event.ThingUpdatedEvent] - Thing 'velux:klf200:360b7a8c' has been updated.
2020-01-06 22:13:49.779 [me.event.ThingUpdatedEvent] - Thing 'velux:klf200:360b7a8c' has been updated.
2020-01-06 22:13:49.806 [me.event.ThingUpdatedEvent] - Thing 'velux:klf200:360b7a8c' has been updated.
2020-01-06 22:13:50.342 [me.event.ThingUpdatedEvent] - Thing 'velux:klf200:360b7a8c' has been updated.
2020-01-06 22:13:50.356 [me.event.ThingUpdatedEvent] - Thing 'velux:klf200:360b7a8c' has been updated.
2020-01-06 22:13:50.996 [me.event.ThingUpdatedEvent] - Thing 'velux:klf200:360b7a8c' has been updated.
2020-01-06 22:13:51.007 [me.event.ThingUpdatedEvent] - Thing 'velux:klf200:360b7a8c' has been updated.
2020-01-06 22:14:51.631 [me.event.ThingUpdatedEvent] - Thing 'velux:klf200:360b7a8c' has been updated.
2020-01-06 22:14:51.655 [me.event.ThingUpdatedEvent] - Thing 'velux:klf200:360b7a8c' has been updated.
2020-01-06 22:14:52.196 [me.event.ThingUpdatedEvent] - Thing 'velux:klf200:360b7a8c' has been updated.
2020-01-06 22:14:52.210 [me.event.ThingUpdatedEvent] - Thing 'velux:klf200:360b7a8c' has been updated.
2020-01-06 22:14:52.820 [me.event.ThingUpdatedEvent] - Thing 'velux:klf200:360b7a8c' has been updated.
2020-01-06 22:14:52.834 [me.event.ThingUpdatedEvent] - Thing 'velux:klf200:360b7a8c' has been updated.
2020-01-06 22:15:53.483 [me.event.ThingUpdatedEvent] - Thing 'velux:klf200:360b7a8c' has been updated.
2020-01-06 22:15:53.506 [me.event.ThingUpdatedEvent] - Thing 'velux:klf200:360b7a8c' has been updated.
2020-01-06 22:15:54.059 [me.event.ThingUpdatedEvent] - Thing 'velux:klf200:360b7a8c' has been updated.
2020-01-06 22:15:54.076 [me.event.ThingUpdatedEvent] - Thing 'velux:klf200:360b7a8c' has been updated.
2020-01-06 22:15:54.626 [me.event.ThingUpdatedEvent] - Thing 'velux:klf200:360b7a8c' has been updated.
2020-01-06 22:15:54.637 [me.event.ThingUpdatedEvent] - Thing 'velux:klf200:360b7a8c' has been updated.

If you want more information I will be happy to share but for me its okay as it is now.

Thanks a lot and keep on with your great work. Andreas

Thanks for the answer. I‘m Not a programmer. I Use the 2.5 Binding over Papier UI and than text configuration. Where I should type isProtocolTraceEnabled=true? With the console i have no expierience…

For me the delay is Not so bad because I want to use the Commands in rules. I have 7 rollershutter. When I set the group switch for all rollershutter there is the delay. The rollershutter goes one after the other up or down and Not at the Same time. I‘m Not sure how Long the Delay is for only one rollershutter

Hello,

the configuration can be done via paperUI under the KLF200 configuration page: Please activate the switch Enable Protocol Trace. It should look like:

To move all shutters in parallel, a good idea could be to define such a scene.

I use Window -Motors, and there is a short delay from clincking to Motormovement of about 1s, not much more. And all 5 Motors do move simultaneously.

wow, what a difference.

I Install the newest binding. I had problems and had delete all things an re install them.

But now it works great.

The log ist calm. And there ist no delay. I can count 21,22 and the roller shutter run. When I activate all rollershutter, there ist nearly no delay between the start of the different rollershutter.

@gs4711: great work!! I am happy :slight_smile: I think you don’t need an log, anymore.

Today I paired my 7 new Somfy Oximo IO rollershutters with Velux KLF 200 and afterwards with openHAB2.

I would like to praise this fantastic binding. Everything works flawlessly and straight away. Support of @gs4711 also was excellent. Thanks a lot! :slight_smile:

P.S. Had a little problem with API password at the beginning. It is the same like the Wifi password. But Guenther also helped me immediately.

P.P.S: Integration with Alexa also works.

2 Likes

Note to all current users of this binding. Out of the review process some modifications will occur within the next version of this binding: Some information being present as channel will exist only as property of the bridge furthermore. In fact, that are:

  • “firmware”
  • “ipAddress”
  • “subnetMask”
  • “defaultGW”
  • “DHCP”
  • “WLANSSID”
  • “WLANPassword”
  • “products”
  • “scenes”
  • “check”

Will keep you informed. Rgds, Guenther

1 Like