I have my kitchen rollershutters connected to a Fibaro FGR222 rollershutter controller.
Depending on sun azimuth and elevation from astro binding and two temperature sensors (one in direct sun light, one always in the shade, difference in temperature detects sunshine) automatic shading is performed.
Each shutter controller is connected to a physical momentary switch with up and down buttons.
Now it comes to the wife acceptance factor: as soon as the shutters are moved with the physical switches the automatic shading should stop.
In my events.log I see, when either button is pressed, a state update:
2016-06-15 10:39:47 - FibFGR222_Kitchen_East state updated to 35
where the value can be anything from 0 (=shutters up) to 100 (=shutters down)
My first idea was using my rrd4j persistence and compare the previousState of the shutters with the current state and if any difference is noted set a boolean variable to disable the automatic shading.
Unfortunately with state changes (trigger on “received update”) there is no previousState. And trigger on “changed” does not work.
Does anybody know how to detect a press on the physical switches and set a boolean variable?
Edit: in contrast to my first test with rule triggers now triggering on “changed” also works, but still there is no chance to get the previousState.
I’m looking for something like: var Number PositionEastPrevious = FibFGR222_Kitchen_East.previousState()
Ha, I’m just busy doing the more or less same thing, albeit we have no turnknobs and I use a light sensor and venetian blinds.
Use a global variable (defined as Number in items file) to store the state on every change (trigger “received update”), that’s your ‘previous state’ to compare to then.
But I believe you should also see a ‘UP’ or ‘DOWN’ event if configured properly.
Verify if your controller is in association group 1 (see Fibaro manual). If that doesn’t work, you could try setting param 50 and catch the SCENE_ACTIVATION commands.
Yes, when I move the shutters with the android app or another UI I see up/stop/down commands and after that the position update.
But when the physical switches are used I only can see the state update.
I will try your suggestions the next days, thanks.
[quote=“sihui, post:1, topic:11622”]
My first idea was using my rrd4j persistence and compare the previousState of the shutters with the current state and if any difference is noted set a boolean variable to disable the automatic shading.Unfortunately with state changes (trigger on “received update”) there is no previousState. [/quote]
will return the item’s state from a minute ago (assuming you’re persisting it). Compare that with current state on a state change. (Unless I’m missing something?)
NOTE: the behavior of this code is subtle and sensitive to timing. I’m not super happy with it but it works.
The main thing is the Weather rule. When Yahoo weather reports a condition code that indicates it is likely cloudy I turn on some lights and turn them off when the condition code indicates it may be sunny. However, if the light is triggered on or off manually I want it to stay that way until evening.
So what I do is I created some Override Switch Items to store whether or not a given light has been overridden. I like to store state in Items where possible as opposed to global vars but you can store the overrides in a global var if that is what you prefer.
I also have an Item named WhoCalled. By default, WhoCalled gets set to “Manual”. However, when a rule triggers to turn on or off the lights it changes WhoCalled to something else (e.g. “Timer”) before sending the commands to the lights and then changes it back to “Manual”. Then I have a rule called “Override Lights” which gets triggered whenever any light gets an update. This rule checks “WhoCalled” and if it is “Manual” we know that the light was manually triggered so we set the Override flag for that light to true (which disables that light in the Weather Rule).
So tl;dr of the setup is:
have a who called Item that gets set to one thing when changing your rollershutters from a rule and something else any other time; this is how we tell the difference beteen a rule triggered change and an manual change
have a rule that triggers for any updates to your rollershutters
in this rule if that who called Item indicates the rollershutter was not changed by a rule, you know that it was manually triggered so set your override flags
make sure to check for overrides in your rules
make sure to reset your override flags for the next day
I tried that before but didn’t work, must have done something wrong. Now it works, thx.
I saw that post before but never catched the idea behind the “who called”.
I will start over with my rollershutter rule from scratch and use your who called item, many thanks.
I’m finally giving up on this
I couldn’t get the “who called” string working, so as a last resort I tried
and bingo, this gives me a nice switch which only gets triggered (state update to ON) when the physical momentary switches are pressed: Switch FibFGR222_Kitchen_East_Manual_UP_1x "Kitchen East Manual UP 1x [%d %%]" {zwave="11:command=SCENE_ACTIVATION,scene=16,state=0"} and Switch FibFGR222_Kitchen_East_Manual_DOWN_1x "Kitchen East Manual DOWN 1x [%d %%]" {zwave="11:command=SCENE_ACTIVATION,scene=26,state=0"}
Now I thought it’s easy to setup some logic rule, but I’m still struggling.
The complete rule can be found here:
The part which doesn’t work as expected is:
rule "shading kitchen east"
when
Item Shading_tempDiff_Proxy received update
then
if (Night_Proxy.state==OFF &&
((Sun_Az.state > 80 && Sun_Az.state < 140) &&
(Sun_El.state > 10 && Sun_El.state < 40)) ) {
if (Shading_Shutter_Proxy.state==ON) {
if (!ShutterOverrideEast) {
if (Shading_tempDiff_Proxy.state >= 15) {
if (ShutterDelayTimerKitchen_East!=null) {
ShutterDelayTimerKitchen_East.cancel
ShutterDelayTimerKitchen_East = null
logInfo("FILE", "Shutter Delay Timer East reset because sunshine was detected, but timer was active")
}
FibFGR222_Kitchen_East.sendCommand(ShadingKitchenEastPosition)
logInfo("FILE", "shading kitchen east active, shutters are down")
}
if (Shading_tempDiff_Proxy.state <= 14) {
logInfo("FILE", "shading kitchen east temporary terminated, starting 30 min timer")
ShutterDelayTimerKitchen_East = createTimer(now.plusMinutes(30)) [|
if (FibFGR222_Kitchen_East.state != UP) {
FibFGR222_Kitchen_East.sendCommand(UP)
logInfo("FILE", "ShutterDelayTimer_East has expired, shutters are up")
}
]
}
}
else if (ShutterOverrideEast) {
logInfo("FILE", "shading kitchen east overridden, starting 3 hour timer")
ShutterOverrideTimerKitchen_East = createTimer(now.plusMinutes(180)) [|
logInfo("FILE", "ShutterOverrideTimer_East has expired, override set to false")
ShutterOverrideEast=false
]
}
}
}
else
logInfo("FILE", "shading kitchen east permanently deactivated, it's night or activation conditions not met")
end
My goal was to have the shutters down when sun is detected, then have a 30 minutes delay if no sun is detected and after the timer has expired the shutters should go up again.
If in the meantime during the 30 minutes timer delay sun is detected again the timer should be cancelled and the shutters should stay down.
In addition to that if a physical switch is pressed, a 3 hours timer should start and after expiration give control back to the “auto” rules.
I tried to do this part by part and then put all pieces together, but the final step (putting all pieces together) is not possible with my programming skills.
If anybody has an idea with which logic I have to start or could take a look at the rule excerpt above to tell me if I am on the wrong track would be very much appreciated.
This will take a good deal of time to analyze. but some first thoughts:
Any time I see a rule that doesn’t fit on the screen, particularly if it is not working, I look for ways to move the logic out of the rule to simplify it. It is easier to debug that way and easier to understand.
Whenever I see that degree of nesting (five nested ifs right off the bat) alarm bells go off. I would create a new proxy Item to determine if it is appropriate to do the shading and move all of those nested ifs into a separate rule. In this rule just check that proxy Item. This will be easier to read and easier to test. Alternatively you could move them into a lambda.
At a high level I would put the sun detected logic in its own rule and create the timer there.
Put the physical button press logic in its own rule and create a different timer there.
You will have to split the interaction between the two between the two rules.
Perhaps this evening when I get home I’ll be able to spend some time on this.
I use a different approach:
While I don’t need to work around your problem (I omitted the switches), I, too, have a virtual switch (Rich calls thems proxy items) ‘auto-shade’. Whenever a trigger fires (I’m using cron, you could use temperature changes or anything, but key is not to trigger on shutter item updates), all calculations are made and shutters/blinds are eventually set accordingly ONLY if that virtual switch auto-shade is ‘ON’.
You could set it to OFF whenever someones manually operates a shutter and set off a timer to reset it to ON (i.e. ‘auto-shade’).
Since I’m using a multitude of input values, different sensors for sides of the house and a two-level shading (blinds just down or fully closed), it used to be a pretty deeply nested if-then-if-then-… thing at first that quickly became very hard to read and debug.
I untangled it by setting boolean variables ‘need for shading’ and ‘need for maximum shading’ at the beginning of each check run to apply the logic there.
The longer I’ve been working on this ruleset, the longer it became.
Remember there’s times of the day where you want to close shutters (nighttime) or don’t want to (obstructed doors) and times of the year where you may want the sun to help heating your room, and others where you want shading to prevent heating.
From the beginning of this thread, I’ve always been wanting to ask about the algorithms you apply. So what’s yours?
I’m comparing current weather binding reported temperature and an outside sensor’s temperature (albeit with a correction factor, as it’s in direct sunlight) to the room’s current target temperature.
Plus, I’m using a brightness sensor with 2 thresholds (either the ‘high’ threshold is superseded or the 15min average supersedes the low threshold), something like 15000/9000 lux seem to be reasonable values, plus UV index with threshold 2 (as my sensors happen to supply that value).
Oh, and time of day, because I want to have the blinds closed at night for safety reasons.
Also, if the door to get obstructed by a shutter is open, I don’t close the blinds in the first place, and if I open such a door, I lift the corresponding shutter.
Eventually, you might want to check wind speed, too. Any other ideas ?
Actually I believe @bob_dickenson came up with the term. I’ve also seen them called virtual Item.
Personally I think of them just as Items without making any sort of distinction between them and any other Item. But having a name for an unbound Item seems to help with explanation so I go with the flow.
Another example of this approach is here. He is using a motion sensor to override the light but it is essentially the same approach.
I really like this sort of approach. I find it really useful to separate things like this or even farther. For example, I might completely separate the logic that determines whether the shades need to be closed or not into a completely separate rule and then drive the actual closing of the blinds off of the results of this rule. This is particularly handy if there is some other thing you may want to do when the blinds should be closed (e.g. turn on a fan, turn off a light, etc.)
Two really successful examples where I’ve applied this is tracking TimeOfDay and sending Notifications.
As for the algorithm, I’ve been thinking about this sort of problem for awhile. It seems like some sort of state machine would be perfect for this. I’ve been waiting until the new Rules engine that supports generic reusable code but maybe doing something sooner would be useful. The problem is any person technical enough to use a state machine would be technical enough to code their rules without it.
Thanks to all contributers, I finally got it working!
Putting all your suggestions together, I untangled the nested if’s, created proxy items and separate rules for them and that did the trick. It’s still a lot of ugly logic code with proxies, boolean variables and timers, but it does what it is supposed to do.
That was the key to my main problem, detecting press on the physical switches. Now I’m (ähh, my wife …) even able to control each shutter manually and with a little scene rule open and close all shutters together with a double click on any single switch.
You will be disappointed: I only use two temperature sensors, one in direct sunlight on top of the roof, one is always in the shade. And because my rule just got finished, I even cannot tell you if that is sufficient.
But hopefully I will be able to answer that question after a couple of days under working conditions.
