odd delay in responding, plus timer questions

[John W]

Hi.
I am not quite sure how to categorise this, because to be honest I\'m not quite sure what is going on.

Our topology is not very complex:
- comfort 2 main, outputs driving relay boards
- A remotely located RIO (connected via main panel) for controlling some lights and inputs from sensors in the drive and front of house
- A Slave module for outbuildings
- An IRIO (connected via the SEM) for controlling lights and inputs from sensors in the garden

For all things on control menu I have flags associated with them for the status to be shown on the app (IRIO requires flags to control it too, and I just did the menu the same way for the RIO, the differences are in the responses).

I am using timers in some responses to turn the lights on in sequence when a sensor is triggered. I have disabled these sensors by disconnecting them from RIO, so they shouldnt happen at present.


The problem (if it is one):
I notice the following when I use the comfort app (doesnt matter if its on iphone, samsung phone, or samsung tablet)

When I select Control, and then the specific section, the on/off status of the things controlled by the RIO initially say \'Wait\', and after a number of seconds appear.
This doesnt happen for any of the other things. I am unclear why there would be a delay in getting status for some flags over others.

Second problem:
when I switch one of them on/off it seems to take ages to action sometimes. For example, if I switch on 1 output via the app for the first time today, it might happen straight away, or it might take a couple of minutes.
Its not simply the app not updating, as I can see the light doesnt come on until roughly the same time the app status updates.

When I use the control menu it uses different responses to turn the lights on/off in one go by setting/clearing the flag, turn the outputs on/off, and stop the timers.

Have I somehow created a dependancy on the timers ?
I have set a bunch of \'Do response after x seconds using timery\' in the responses that sequence the lights. In the others they do \'stop timery\' for all the timers used.

When I run a response (say to turn lights on), if I trigger another response does it get queued up on the stack, or done in parallel ?
Just wondering if I have one response waiting on a timer and another stops the timer...

Is there any way to see what response comfort is currently doing, or what is in its stack of responses ?

I also see this same behaviour if I monitor the output using comfigurator, and action responses from it.

Any thoughts ?

Cheers,
   John.
p.s. slychiu, I uploaded the config file recently to put on my phone, so if you keep a record of these you have the file already

[slychiu]

We do not have access to the files you upload so please send details the cclx to support@cytech.biz thanks

[John W]

ok, will do this evening.

[slychiu]

I have not received your cclx file but these are my comments

When I select Control, and then the specific section, the on/off status of the things controlled by the RIO initially say \'Wait\', and after a number of seconds appear. This doesnt happen for any of the other things. I am unclear why there would be a delay in getting status for some flags over others.

The app has to get the initial status of the control menu items. It is normally very fast, but perhaps your control menu is very extensive?

Second problem: when I switch one of them on/off it seems to take ages to action sometimes. For example, if I switch on 1 output via the app for the first time today, it might happen straight away, or it might take a couple of minutes. Its not simply the app not updating, as I can see the light doesnt come on until roughly the same time the app status updates.

This could be due to the timers and condtions you have programmed.
Try executing the Response directly from Comfigurator and check if there is a similar delay

When I use the control menu it uses different responses to turn the lights on/off in one go by setting/clearing the flag, turn the outputs on/off, and stop the timers. Have I somehow created a dependancy on the timers ?

Probably

I have set a bunch of \'Do response after x seconds using timery\' in the responses that sequence the lights. In the others they do \'stop timery\' for all the timers used. When I run a response (say to turn lights on), if I trigger another response does it get queued up on the stack, or done in parallel ? Just wondering if I have one response waiting on a timer and another stops the timer...

\"Do Response after timer \" does not make other responses wait in line. It starts a new thread with the timer and goes to the next action/response. The timer response activates after the timer

Is there any way to see what response comfort is currently doing, or what is in its stack of responses ?

Not really

[John W]

Hi,
I will email it again when I get home.

I have filled up all of the available control menus, so I guess that makes it extensive.

I did a bit more testing over the weekend.

The RIO entries definitely take longer to initially get their status, but the outputs which are simply on/off without using timers activate pretty much straight away (comfort panels outputs are straight away, IRIO and RIO non timed are a shade longer - long enough to notice but only because I was checking, certainly not a problem).

It seems it is only the one on/off entry in the control menu that has a long (or rather, variable) delay, and only when done from the app.
Activating the response from Comfigurator that the control menu item uses sees the output switch on/off straight away.

I am going to take the timers out of the responses for now and see if that fixes it. If it doesnt, god knows what is going on.

Another thought. Can I get a response to add an entry into the event list ?
I could use that to debug if / when the responses are triggered to some extent. At least I could see when or if the response gets actioned from the app.

Its real odd that having pressed the slider to turn on/off this item, I can switch other things on and off that happens straight away while this one still doesnt happen straight off.

This isnt a show stopper, just frustrating that we cant turn the drive lights on when we want for someone to walk down it. These same responses are used to turn them on at dusk and off at midnight, and appear to work just fine, as do the sequenced responses when a car is detected.

Cheers,
John.

[slychiu]

I still have not received the cclx file, in case you have sent it again
support@cytech.biz is the email address

[John W]

I will try from a different email account later.

The behaviour has changed slightly, although I haven\'t uploaded any changes to the panel or my devices.
Now it takes ages to turn off but turns on straight away.

Very bizarre.