I’ve since found out that the remote control I use (“Situo 5 IO Variant” or something like this) has a “Manual/Auto” slider where the “Manual” side basically blocks any non-“user” actions. As soon as I switched it to “Auto” (which really means "let others control the devices as well), the controls continue to work. I’ve not investigated if the lock is lifted after a while or active as long as the slider is switched to “auto” …
So I guess you can consider my feature request revoked
The only slight weirdness/question I have left at the moment is that it seems that commands sent via the OpenHAB UI (Basic UI, for example) are executed sequentially and never in parallel (for example if I want multiple shutters to close, the second one will only start closing once the first one is done).
As far as I can see from the API (which isn’t very far, to be honest) that isn’t required by the API. Is this an intentional/known restriction?
you’re right. The initial approach (supporting both firmware versions and both protocols in parallel) is to limit the parallelism to one: one command after another. If most of the users migrate to OH2, I’d prefer to switch to full parallelism.
Hello Guenther,
thank you for your answer.
You say, the discovery process adds the items to the OH framework - ok, but where can I find the definitions. I would like to assign simpler and shorter names to the items, for example.
Further, I could not find a description of available commands applicable to the roller shutters. Some hints I could find in the openhab logs. Is there no complete list available?
For example, I did not recognize a command for query the shutter position which would be nice to get a feedback for the loxone control.
Do you have any more infos on these questions for me?
Best regards,
Johann
perhaps this real-life example may help: our Velux window in the bathroom will be automaticly closed after a minute being fully opened:
rule "V_DG_M_W_changed"
when
Item V_DG_M_W changed
then
val Number windowState = V_DG_M_W.state as DecimalType
if (windowState == 0) {
logInfo("rules.V_DG_M_W", "Window-Bath changed to fully open.")
var int interval = 1
createTimer(now.plusMinutes(interval)) [|
sendCommand(V_DG_M_W,100)
V_DG_M_W.postUpdate(100)
]
}
}
end
Within this rules you’ll recognize the reaction upon changes of the device state and the possibility to act accordingly.
Hi Guenther,
Thanks so much for this binding. So far I am using simple Velux remotes switched by relays and controlled by OpenHAB. While it is working it is obviously quite limited (no reading of status, cannot set a target percentage for a rollershutter, etc.).
Now I am really keen to use the KLF200 with this binding but wanted to make sure that it can completely replace my current system before I start tinkering. Is there a list of current issues? Would I first include all my Velux windows and rollershutters via the KLF200 interface and then include them in OpenHAB?
I am running OpenHAB 2.5 M3.
Many thanks in advance,
Jonas
To make sure to give a right answer, what are the exact features you`ll expect the binding to address?
Secondly yes, you have to activate the KLF200 bridge into learning mode, to recognize the devices. Then, they are managable by the KLF200 via web interface (or by the physical input lines) and, of course, under control of this binding.
Currently I am simply opening or closing a number of windows and rollershutters (sometimes in groups because of a limited number of remote controls wired to my Raspberry Pi). I can also stop an action in case I don’t want to completely open a window.
With the binding I hope to include all items individually, send more precise instructions (e.g. open 50%), and read the current status of items (if a window closes due to rain I would like to see this). What would be great is if I could switch to silent mode.
I read somewhere that the binding can execute actions only sequentially. Is this correct? Does that mean that it has to wait for one window to close until the second one can start closing?
How does the detection/inclusion of devices by the KLF200 work?
Thanks, this looks great. Regarding the sequential actions, does that mean that when I want to close all windows window #2 starts closing only once window #1 is fully closed? Depending on the number of windows that could take some time for the last window.
Of course, for the time being, you can overcome this limitation by defining a scene with the desired position of all windows - and simply starting this scene.
I don’t have any electronic Velux windows but I’m interested in getting some.
With respect to point 5, it’s a shame that they didn’t add the rain sensor as a separate device. I understand that when the rain sensor detects rain it automatically closes the window. Would this allow for an indirect way of determining if it’s raining? If there have been no requests to close the window but it “closes itself” can we assume that it’s raining?
of course, the windows are automaticly closed and the openHAB is able to react on the incoming close procedure as it is informed via the Velux House Monitoring Service.
But you won’t see a close command coming from the Velux device - you’ll see that someone/something has closed the window. It’s a pity that you cannot distinguish between someone (person by remote control) and something (velux rain sensor).
Scenes in the KLF200 is created from the remote control… Ie KLR200.
You create a screne where one or more devices (group) operate. Like at learning lesson from a IR remote controle if you have ever tried that.
