Comfort  Automation/ Security System Forums Home
Home Search search Menu menu Not logged in - Login | Register

buggy timer behaviour
 Moderated by: admin
 New Topic   Reply   Printer Friendly 
 Rate Topic 
AuthorPost
 Posted: Saturday Jun 1st, 2019 10:22 am
   PM  Quote  Reply 
1st Post
2dp
Member


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? :?



 Posted: Sunday Jun 2nd, 2019 03:32 am
   PM  Quote  Reply 
2nd Post
slychiu
Administrator


Joined: Saturday Apr 29th, 2006
Location: Singapore
Posts: 5493
Status: 
Offline

  back to top

timer logic seems to be cotrrectWhat is your firmware? The wait for timer was a relatively new action so old firmware may not work with it correctly



 Posted: Sunday Jun 2nd, 2019 05:47 pm
   PM  Quote  Reply 
3rd Post
2dp
Member


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

  back to top

Comfort 2Z Ultra
Comfort File System 34
Comfort Version 7.113
Latest Version 7.117
Serial No C089244
Vocabulary No 5
Custom Vocabulary False
System Vocabulary Version 39
User Vocabulary Version 1
LCD Text Version 2
LCD KP Min Version 3

Ethernet UCM01, id 1
Type General
UCM Command Type None
Version 7.098
Latest Version Unknown
Serial Number Unassigned

Keypad ID 1, Name TI8
Type KP04
Version 1.019
Latest Version Unknown
Serial Number Not supported by firmware

Keypad ID 2, Name TI12
Type KP03
Version 1.003
Latest Version Unknown
Serial No Not supported by firmware

RIO ID 1
Version 2.010
Latest Version Unknown
Serial No Not supported by firmware

RIO ID 2
Version 2.010
Latest Version Unknown
Serial No Not supported by firmware

RIO ID 3
Version 2.010
Latest Version Unknown
Serial No Not supported by firmware



 Posted: Sunday Jun 2nd, 2019 05:54 pm
   PM  Quote  Reply 
4th Post
2dp
Member


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

  back to top

It says that the latest versions are:

Controller 7.153
Ethernet UCM 7.110

For other devices, the firmware version is either the latest, or it cannot be checked (the option in the right-click menu is grayed out).

Should I update the firmware? Do I need that special piece of cable for that, or it can be done from Comfigurator over IP connection?



 Posted: Tuesday Jun 4th, 2019 02:08 am
   PM  Quote  Reply 
5th Post
slychiu
Administrator


Joined: Saturday Apr 29th, 2006
Location: Singapore
Posts: 5493
Status: 
Offline

  back to top

Your firmware Ult 7.113 is quite old, around the same time as the Wat action was introduced. I suggest you upgrade the firmware. First for UCM and then ControllerYou do not need to use the UCM firmware programmi9ng cable

see instructions here http://www.comfortforums.com/forum92/3400.html



 Posted: Monday Jun 10th, 2019 10:25 pm
   PM  Quote  Reply 
6th Post
2dp
Member


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

  back to top

Hello again!
I did the firmware update. For a couple of days it seemed OK, but now it's the same as before.
Any other ideas? Is there a debugging tool I could use? Can Comfigurator, or some simple terminal emulator listen on some port and collect status and event information through several days? Or something...? :)
What actually is supposed to happen when a running timer is stopped? I'm guessing, whatever was supposed to happen after it expires - isn't meant to happen at all? When a timer (after being stopped) gets reused again, does it count down from the newly given value or from the value it reached when it was last stopped? Is it possible that all "wait for timer" actions are left waiting on some stack and then pop all up in a (random?) sequence after this timer finally expires?
I'm just throwing ideas at you, because this behaviour looks like that.



 Posted: Tuesday Jun 11th, 2019 02:01 am
   PM  Quote  Reply 
7th Post
slychiu
Administrator


Joined: Saturday Apr 29th, 2006
Location: Singapore
Posts: 5493
Status: 
Offline

  back to top

What actually is supposed to happen when a running timer is stopped? I'm guessing, whatever was supposed to happen after it expires - isn't meant to happen at all? When a timer (after being stopped) gets reused again, does it count down from the newly given value or from the value it reached when it was last stopped?


Corect. When you stop a timer, the event does not get activatedWhen you start a timer it is always with a new value, there is no Restart timer action

Is it possible that all "wait for timer" actions are left waiting on some stack and then pop all up in a (random?) sequence after this timer finally expires?
No, each timer  has its own track ie timer value and Response or next action
Is there a debugging tool I could use? Can Comfigurator, or some simple terminal emulator listen on some port and collect status and event information through several days?
There is a Bus Monitor under Tools that monitors the Bus messages. However Timers do not transmit on the Bus

You can see the status of Timers in the Timers page Press Show Status in Timer Status. This shows the remaining timer value when you press.



You say that it works OK for a few days, and then it does not. That seems to indicate that something external has changed?
What about wgeb you reset. Dioes it start to work?



 Posted: Thursday Jun 13th, 2019 09:01 pm
   PM  Quote  Reply 
8th Post
2dp
Member


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

  back to top

Timer as such works OK (starts when both PIRs turn off, and counts down from 180 seconds, and stops when any of the PIRs lights up).

But the OUTPUT keeps turning off. And, right now, it is as fast as in a split-second after it turns on. The PIR doesn't even get to turn off. I'm walking across the room, the PIR lights up, the light switches on and then immediately off, as I'm walking, PIR is on all the time. Then I need to stop and wait for the PIR to switch off, move again, the PIR lights up again, the light switches on again, and then immediately off (or not always immediately, but in a couple of seconds.). Etc.
I checked the status of the output to make sure it's not a bad connection or something. The output REALLY switches off. Can I use bus monitor to see what triggers the output?

Besides this, the output is turned off by manual pushbutton, and this always works as it should. Also, there is a control in the menu on the Comfort app in iPhone. This also always works fine.
Reset makes no difference. Nether has writing of the changed program.



 Posted: Saturday Jun 15th, 2019 02:09 am
   PM  Quote  Reply 
9th Post
slychiu
Administrator


Joined: Saturday Apr 29th, 2006
Location: Singapore
Posts: 5493
Status: 
Offline

  back to top

The Bus Monitor will show the output turning on and of, but it does not show what causes it. Can you send the cclx file to support@cytech.biz so we can check



 Posted: Sunday Jun 16th, 2019 07:59 pm
   PM  Quote  Reply 
10th Post
2dp
Member


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

  back to top

Hi!I've just emailed you the file, with some additional notes. Thanks!



 Posted: Sunday Aug 4th, 2019 02:17 am
   PM  Quote  Reply 
11th Post
slychiu
Administrator


Joined: Saturday Apr 29th, 2006
Location: Singapore
Posts: 5493
Status: 
Offline

  back to top

Thanks for the Bus Monitor files. These revealed the cause of the problem. Output 4 was set low when Sensor 3 value was received from the TSM temperature sensor.

In Functions > Thermostats, Output 3 was assigned to the thermostat. However there is an undocumentated feature  where the next output is controlled by the thermostat, so that output 4 was affected.
Hence the problem was not due to timers. Timers are working properly.
To work around the problem use another output other than 4 for the light or assign another output for the thermostat in which the next higher output is not used. The next firmware will fix this bug



 Posted: Sunday Aug 4th, 2019 10:05 am
   PM  Quote  Reply 
12th Post
2dp
Member


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

  back to top

Thanks for your patience, persistance and help! :)



 Current time is 07:25 am
Top




UltraBB 1.172 Copyright © 2007-2014 Data 1 Systems