Breif Latency on Colour C-Touch?

I've been experiencing slow logic response on the Colour C-Touch whenenabling dimming features to lighting channels

okay here is what i have and might clarify things a little more:

Code:

once (GetLightingState("Bedroom") = ON) and
     ((Time >= "11:00:00 PM") or
     (Time <= sunrise)) then
begin
  SetLightingLevel("Bedroom", 30%, "0s");
end;

So, in theory when "Bedroom" is ON then it should come on at 30% instantly when switched on (hence "0s").

now this code works, however the latency between the C-Touch engine and the key input or sensor causes a weird reaction. What i experience is when i turn on the light it shoots upto 100% most of the time then it dimms down to the level stated in the code.

i've already worked out a quick fix for this, but i just wanted to bring this up if anyone can shed light on the matter

 

From what you describe I assume you have a key input that sets "Bedroom" to on (100%) and an Dimmer unit that has a channel set to follow "Bedroom" . If this is the case then the behaviour you are experiencing is exactly as expected.

The key input units sends a ramp to 100 command for "Bedroom" both the CTC and the Dimmer receive this command almost instantly and both respond. The Dimmer sets the channel to 100% and the CTC starts evaluating it's code. The code then puts a message out saying "Bedroom" go to 30% which the Dimmer then does.

The latency is inevitable.

If you want this sort of feature you need to separate the input group and the output group.

The Key switch needs to control a group "Bedroom Input" and the Dimmer needs to monitor a group "Bedroom Output". The CTC needs to run some code like

Code:

once (GetLightingState("Bedroom Input") = ON) then
begin
  if (Time >= "11:00:00 PM") or
     (Time <= sunrise) then
  begin
    SetLightingLevel("Bedroom Output", 30%, "0s");
  end
  else
  begin
    SetLightingLevel("Bedroom Output", 100%, "0s");
  end;
end;
once (GetLightingState("Bedroom Input") = OFF) then
begin
    SetLightingLevel("Bedroom Output", 0%, "0s");
end;

The above code doesn't handle dimming thou so you will need to smarten it up a bit.

The may be non code ways of doing what you want as well, but I'll let the hardware boys answer that.

 

It could be because you're using the same GA ("Bedroom") as the test condition to get in to the logic block and to set the level of the dimmer output?

I think 'ON' in the logic is 100%/255 or whatever so "Bedroom" has to go to 100% via your key input or whatever before it can get into the logic and be set back to 30%.

You'd probably be better off having a dummy/control GA that is programmed in your key input and then when it's 'ON' the logic will set the level of an output GA depending on the time of day or whatever.

That's probably as clear as mud...but I hope it helps!

 

Oops, Richo replied much more eloquently while I was trying to touch type.

But I meant what he said...

 

Thanks for the prompt reply guys

ok, then if i do implement an "Input" address and a "Output" Address don't i end up losing the dimming functionality at the key input ? the light will then be a basic On/Off... is it possible to retain manual dimming capability when dummy group addresses are implemented ?

I'm being reminded on the good old H-Minder... lol..

 

I'm sure it's possible, but not familar enough with the PAC to know the bets way.

 

I knew there was a better way, thanks for your input nick

 

I can see a different way of solving it...

To get rid of the "flash at 100%" you need to reverse how the levels get set

1) Have the Bedroom key always set the GA to 30%

2) Then use the Logic in the Screen to detect that the GA went to 30% (switched on), then set the level to 100% if the time is OUTSIDE the periods you originally used.

So, just reverse the whole thing - you won't notice the latency and the lamps get a nice "soft-start" in daytime.

Furthermore, because you are using the same GA, all the original dimming functions etc will still work properly.

The only thing I can't answer is : what would happen if the light was already on and you dimmed THRU the 30% point ? How could you stop Logic making it jump up to 100% if it was within daylight hours ?

Perhaps in my step 2) above, instead have the key control 2 GA's - one which is directly controlling the dimmer level, and another that toggles ON or OFF at (say) 1% level of first GA.

Then have the Logic engine ramp UP the levels on the main GA if the time is xxx-yyy and the 2nd GA has just changed from OFF to ON

I could write it in Javascript , but note I haven't played with the PAC to know what is actually possible within that environment.

Cheers, john

 

The idea of using logic in the output unit is by far the simplest.

If you really want to do it in the logic engine, here is some code which will do it. Group 1 is the wall switch and Group 2 controls the load.

Code:

{ variables section }
Group1TargetLevel : integer;
Group2TargetLevel : integer;
Group2CurrentLevel : integer;

{ module code }
Group1TargetLevel := GetCBusTargetLevel("Local", "Lighting", "Group 1");
if ((Time >= "11:00:00PM") or (Time <= Sunrise)) and (Group1TargetLevel > 30%) then
  Group1TargetLevel := 30%;
Group2TargetLevel := GetCBusTargetLevel("Local", "Lighting", "Group 2");
Group2CurrentLevel := GetLightingLevel("Group 2");
if Group1TargetLevel <> Group2CurrentLevel then
begin
  if Group1TargetLevel <> Group2TargetLevel then
  begin
    if Group2CurrentLevel <> Group2TargetLevel then
    begin
      { group is still ramping, so stop group 2 at its current level }
      SetLightingLevel("Group 2", Group2CurrentLevel, 0);
      SetLightingLevel("Group 1", Group2CurrentLevel, 0);
    end
    else
      SetLightingLevel("Group 2", Group1TargetLevel, GetCBusRampRate("Local", "Lighting", "Group 1"));
  end;
end;

 

awesome Darren, almost exactly what my original code looks like ... lol