I have new windows with blinds. These are controlled by two inputs (up/down) and find their endposition automagically.
I am controlling these currently with some rules:
rule "OG_BA_SW_Rollade_auf (direction up)"
when
Item OG_BA_SW_Rollade_auf received command
then
switch(OG_BA_SW_Rollade_auf.state)
{
case ON : { postUpdate(OG_BA_OUT_Rollade_ab_Relais, 0)
postUpdate(OG_BA_OUT_Rollade_auf_Relais, 1)
createTimer(now.plusSeconds(150)) [| postUpdate(OG_BA_OUT_Rollade_auf_Relais, 0) ]}
case OFF : { postUpdate(OG_BA_OUT_Rollade_ab_Relais, 0)
postUpdate(OG_BA_OUT_Rollade_auf_Relais, 0) }
}
end
rule "OG_BA_SW_Rollade_ab (direction down)"
when
Item OG_BA_SW_Rollade_ab received command
then
switch(OG_BA_SW_Rollade_ab.state)
{
case ON : { postUpdate(OG_BA_OUT_Rollade_auf_Relais, 0)
postUpdate(OG_BA_OUT_Rollade_ab_Relais, 1)
createTimer(now.plusSeconds(150)) [| postUpdate(OG_BA_OUT_Rollade_ab_Relais, 0) ]}
case OFF : { postUpdate(OG_BA_OUT_Rollade_ab_Relais, 0)
postUpdate(OG_BA_OUT_Rollade_auf_Relais, 0) }
}
end
Which works.
But I would like to be able to control the opening/closing height. For this I can time how much the blinds need from 0% to 100% and use this to determine where the blinds are.
Sadly I can only tell you what I would like to have, but my Java programming skills lack the possibility to create it.
Inputs:
total time for one cycle
start signal (i.e. the normal switches in the wall)
stop signal (i.e. the normal switches in the wall)
goto position x signal
outputs:
move up as seen above
move down as seen above
I can wrap everything else around this (f.ex. window is opened and blinds are between 80 and 100%, open to 75%).
Does anyone have already written some code for this?
that works very well. But probably not the way the original poster expected.
It only works if you start at an endpoint. there is no memory where the shutter is. So eg. if you define, that it shall close 80% and the rule fires from 0 position, then you are where you want it to be. if you controlled it manually and it is already closed by 30%, then it will be 100% closed and not 80% what you wanted to have.
There are too many variables, status etc. needed in order to get it done via software.
For me, it is sufficient.
So for example, if the outside temperature is above a certain value and the sun is shining into the room for more than X minutes and reaching a threshold, the shutter is moving about 80% down. If somebody is home or coming home, it will move them up for a bit to have more light into the room. If nobody is home, it will be darker.
As @parachutesj indicates, this will only work if no one ever manually touches the blinds since you have no feedback to OH and therefore have no way to know the current percentage if someone has messed with the blinds.
One way to get around this though could be to reset the blinds (e.g. issue a command to close or open them all the way) before doing the timing based percentage open. It is a little hacky and your blinds will do a lot more movement for each setting but at least you will be able to know where they are so the percentage works correctly.
The code for this would be something like (just typed this in, very likely errors)
val int blindsTotalMsec = 123456
rule "Goto position x"
when
Item BlindsPercent received command
then
val totalMsec = blindsTotalMsec * ((blindsPercent.state as DecimalType) / 100)
// reset the blinds
BlindsDown.sendCommand(ON)
Thread::sleep(blindsTotalMsec)
// Go to percentage
BlindsUp.sendCommand(ON)
Thread::sleep(totalMsec)
BlindsUp.sendCommand(OFF)
end
I was thinking that every action (Button press or automatic control) triggers an action, which saves the recent time. While the action is running, the time naturally increases. if now the action was “goto 80%” the stop command is coming from the time needed for going to 80% (create.timer(xyz)). if the stop action is triggered by a button press, the recent time is compared to the start time and by that, one can calculate the new position.
The idea with the reset run is good. But since our blinds are normally used by automatic actions, I would think that an action “Goto 0% or 100%” would also mean doing a reset run (the created timer is unneccesary long to make sure the blinds will go into their autoshutdown and by that are at 0% or 100%).
The problem is without feedback from the blinds and the ability to control the blinds manually you can never be sure of what position the blinds are in. Therefore you need to cover the case where the blinds are ar 0% and wait long enough for them to get to 100%. Otherwise you hit the following scenario:
Blinds are set to be open 50%.
User manually adjusts the blinds to 25%. This manual adjustment does not get transmitted to OH so OH still thinks it is at 50%.
User wants to set the blinds to 10% though OH. OH sends the blinds down 50% which it thinks is closed but because it didn’t know it was actually at 25% the blinds only go down to 75%. Now when it sends the blinds to what it thinks is 10% the blinds end up fully open. This is the scenario @parachutesj is describing.
So, assuming that all manual adjustments get communicated back to OH (something not adequately described in your original Inputs and Outputs posting) you can keep a better track of what the position of the blinds is in and perhaps know how long to wait to reset.
However, then you have the problem that the timing of these commands will not be all that precise. Over time the actual percentage of the blinds will drift due to the build up of latency in the communications between OH and the devices. This is less of a problem but it will eventually lead to, for example, OH thinking “100% closed” actually being several percent open. This will get more and more off as time goes on, though a simple once a day cycle from 0% to 110% and back would clear that up.
Generally speaking, expect this to not work well even if you get it to work. openHAB and most transmission systems don’t guarantee for real time. As others note, too, there will be transmission losses or delays at times (particularly if you use radio such as ZWave or Somfy RTS) and there can be processing delays in OH, too.
This can easily get your blinds’ state out of sync with the state openHAB believes they’re in.
You didn’t mention the control hardware you’re using, did you? Not sure if it’s an option for you to change your HW, but I’m using Fibaro FGRM ZWave actuators to control my blinds, and they are intelligent in that you can tell them a percentage to drive to. Timing is handled locally inside the actuator.
I am using shutter controls based on MySensors. They indeed send stop, up and down movement controls when the manual buttons are pressed to OH. So in principle there would be possibilities to handle this via software/rule in OH but not sure if it is really worth it.
There is even an implementation within the shutter control available. The shutter is opening completely and then calculating the time. You could send the state to the shutter (from OH) and it would make exactly what you like.
I have explained that before somewhere (maybe at mysensors?) that I wanted to have it simple as the shutters on some windows need more time than on others, doors are different and the shades as well and the same hardware is also driving windows, which of course need different time to open and close. It would take me ages to get that sorted out and being perfect.
If I need a shutter to be at ~50% by rule, I assume it is dependent on the rules/states open or closed and just drive it for X seconds, pause the thread and then send a stop. If it is wrong, so what… there are much more important things to get running. I see it like a navigational system. It gets you most of the time where you want to be. Sometimes it takes a re-route and one could take a better and faster way but at the end the sum ok.
If I think about the shutters in my office building which are all going down in case there is just one ray from sun coming in the morning even the sun is on the other side of the building, and going back up when the sun is behind a cloud my implementation is 1000x times better and I can live with little flaws.
I do understand that my implementation is far from being a true real-time evironment. Here is how it is connected:
Classic installation blind switches in the wall connected to my RoomClient hardware (see my other threads).
RoomClient vie MQTT over ethernet-cable to OH
Blind motor via classic eletrical wirering to Relais
Relais actuated by the RoomClient
Again RoomClient vie MQTT over ethernet-cable to OH
So it is relatively lag free, or more precise: the lag is nearly the same all the time
Our typical behavior is to fully open the blinds in the morning and then seldom change the state over the day. So I would have one reset run every morning, perfectly defining 0%. I do understand that with every movement of the blinds the accuracy of the target % gets less and I can live with this.
To try this out, maybe you can give me some coding hints:
How do I have to work with actualtime, time comparison and time in general in the rules?
How can I stop a running timer without triggering the code executed at its end?
I will then fiddle with the rules and tell you how it went
I have a same problem with my “non-intelligent” blinds and going to start writing scenario for exact positioning. Unfortunately the rule most likely will be not in OpenHAB, as it’s rule engine can not handle timing quite well. And this is essential for accurate positioning. The command binding is in opposite working quite acurately - I have something like 40ms delay all the time.
The Idea is simple:
The full closing and opening times need to be recorded. It should be mentioned, that opening and closing times are little different due to different load to the motor.
Rules:
At 0% or 100% closed blinds the motor relay should stay on to make sure, that blinds reach final position in any case. Thus these positions become self-calibrating.
The current position of the blinds is calculated based on the latest end-point position (0% or 100%) and by counting durations of issued up and down commands to the motor (e.g current command duration divided by total opening/closing time). For this you need precise timer. The current position must be reported every time it changed.
Thus this rule becomes a virtual “position sensor”
Finally you need to have a setpoint - for example 85%. This point is compared with position sensor above, and if they are different - appropriate up or down command should be issued to motor, until desired position is reached.
These three rules should run concurrently to make the whole thing work. The benefit of “position sensor” rule is that it will handle blind position change from manual commands, if they are reported to OH.
I fully agree and this is what I was thinking, only that you put it in more clear words
I have never worked with the command binding. Do you have any tips/hints?
So I created the rule, which works like I explained above. It works fine, calculating and updating the position on the base of motor commands and travelling blinds to selected position. The problem is that roller-shutter item in OpenHAB has only up, down and stop buttons, and I would like to have buttons for some intermediate positions - like move to 25% and 75%. How to make it in item file without defining special mapping in sitemap?
Second problem is that rule updates position dynamically, as blinds move up and down. This is shown pretty nice by the rollershutter icon on sitemap, but first time, when user pushes the button, the icon is flashing to fully open or closed state and then returns to actual state, as rule starts to update the position. How to avoid this? Autoupdate feature disabling doesn’t help here.
I’m on my phone so can’t really provide real examples. The built in now variable is a Joda DateTime object representing the actual current time. It has methods like plusSeconds, minusMinutes, isBefore, isAfter, etc which let you do most time calculations fairly easily. You can also get the millis to do your own math.
Save the timer to a global var and when you want to cancel the Timer call timerVar.cancel. It will not execute the body of the timer.
You probably want to use a Dimmer Item and a Slider on the sitemap.
I don’t think this can be avoided. I at heart know if no way.
Yes, but this allows only manual position selection and I wanted to have buttons for fixed positions - e.g. 25% closed, 75% closed etc.
Actually I found my mistake - I was sending feedback over MQTT as command, while I had to send it as status topic. And Autoupdate needs to be disabled. Now this works correctly.
