 |
Hello!
I have a problem (it has been present since the first commissioning of the system, but it\'s a system in my own office, so it has low priority  ) with timed auto-switch-off of a light.
I have one of the lights in the main room controlled over an output from the main panel of the Comfort system.
The output is controlled manually and/or automatically.
Manually, the state of the output is toggled by two pushbuttons (one is connected to a zone on the main panel, another to a RIO input) and key \"8\" on the secondary keypad. Also from a control on the Comfort app for iPhone. The app also controls the state of the flag that turns automatic control on or off.
If the automatic control flag is on, the light is also controlled automatically. There are two PIR (motion detection zones) on the main panel that call the same ON Response for automatic switch on:
Code: If Flag Night_time <> 0 And Flag AutoAllowed <> 0 Then
Output MainLight On
End If
Stop Timer MainLightT
That is - the same two PIR zones call the same OFF Response for automatic switch off:
Code: If Input PIR1 = 0 And Input PIR2 = 0 And Flag AutoAllowed <> 0 And Output MainLight <> 0 And NightTime <> 0 Then
Wait 180 Seconds MainLightT
If Input PIR1 = 0 And Input PIR2 = 0 And Flag AutoAllowed <> 0 And Output MainLight <> 0 Then
Output MainLight Off
End If
End If
If any of the PIR zones goes to off, check if the other one is off as well, and, if automatic control is allowed and it\'s night time, then activate the timer and wait for 3 minutes. After 3 minutes, check all the conditions AGAIN, and if all of them are STILL valid, switch the light off.
Meanwhile, if any of the PIR zones goes back to ON, the timer will be stopped (beacuse of the ON response) and the \"wait for 180 seconds\" part of the OFF response will never be completed, so the light will remain on.
Eventually, the movement in this area will stop (everybody will leave somewhere, but not necessarily arm the alarm, because they may be in the other surrounding rooms, so the alarm cannot be armed yet), and then the \"wait for 180 seconds\" part of the OFF response will complete, all the conditions will still check out, and the light will turn off.
The same timer is also stopped whenever a manual command to switch on or off is issued, or the AutoAllowed flag is toggled either way, so there should be no remaining auto-switch-offs queued for delayed execution after a manual action.
This is how I imagined it will work. Part of the time it actually does work like that. But sometimes it consistently - doesn\'t.
For instance - it\'s dark inside, you enter, PIR detector sees you, light turns on immediately. And then it turns off a couple of seconds later (the PIR detector is actually ON all the time!). Then, the detector turns off, you move again, light turns on again, and turns off again after a few seconds. Etc. Nobody touches the AutoAllowed flag. :?
Another problem - we have a meeting in that room. I switch the light on manually and switch off the AutoAllowed flag. But the light STILL GETS automatically switched off after some time! :X And this is something that is persistent. I can\'t keep this light on all the time. I can switch it on and off manually, but I can\'t stop it from getting switched off by itself (when the PIRs turn off).
When the AutoAllowed flag is off, the light doesn\'t turn on automatically. Ever. This is OK.
So, to summarize, the switching on works fine, both manual and automatic. But the switching off doesn\'t.
Is it a problem of me not understanding the way timers (or responses) work, or is it a bug in Comfort? I looked for a way to not only stop the timer, but somehow \"reset\" all the actions that depend on it, but I haven\'t found it. It occured to me that maybe Comfort internally puts all the \"wait for timer\" requests to a stack (sort of) and doesn\'t delete them when a timer is programmatically stopped before the given time elapses. And so, when, eventually this specific timer actually DOES elapse, then a whole bunch of \"wait for timer\" stuff pops out and executes in an erratic sequence. But I suppose there would be a warning of such behaviour somewhere in the manual, wouldn\'t it? :?
|
