View single post by 2dp
 Posted: Saturday Jun 1st, 2019 10:22 am
 PM  Quote  Reply  Full Topic 
2dp



Joined: Wednesday Jun 6th, 2018
Location: Rijeka, Croatia
Posts: 19
Status: 
Offline

  back to top

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:
If Flag Night_time <> 0 And Flag AutoAllowed <> 0 Then
    Output MainLight On
End If
Stop Timer MainLightT

The last line is supposed to (if I understood correctly how timers in Comfort are supposed to work?) "kill" the last auto-switch-off delay that started counting when these same PIR zones both became inactive.
That is - the same two PIR zones call the same OFF Response for automatic switch off:
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

So (in my head), this should mean:
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? :?

 Close Window