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
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
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?
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?
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.
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…
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.
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%…
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.
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
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.
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).
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.
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 ??
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]
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< -----------------------------------------------
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
Hhhhm. Sorry guys, perhaps you’re right.
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.
(Just kidding).