Groups vs Scenes

I'm a little confused as to when to use a group and when to use a scene.

For example, I'd like to set an input to "bed time" which will run a scene to set most of the lights to a 0 level (I assume this is sound practice?) At the same time though I'd like it to "enable" 5753 multi sensor so that if there is movement at night it brings up some strategic lights.

Herein lies my confusion: As far as I can fathom, if I sent the Virtual Key to "PIR Night Move" then I can only control a Group and not a Scene. When I define a logic group of these lights they come on to 100% and I'd like them to come on to 40% (so and not to dazzle my sleepy eyes) but to so that would entail a scene right? How then, do I assign a scene to one of the sensors Virtual Key's to be triggered by Movement & Night?

 

Yep, that is a good way to go and will work fine.

The Multisensor can only control groups in response to movement, it cannot trigger a local scene. The only way to trigger a scene from a Multisensor in response to movement is to store the scene in some other unit, set the primary application of the Multisensor to Trigger Control and remotely trigger the scene in the other unit. Scenes are included in the Multisensor because they can be triggered either remotely or via the IR remote control.

Fortunately you can achieve what you want without needing to use a Scene though. You can do this one of 2 ways.

1. Define a logic group in your output unit so that when the logic group is on then the output won't go above 40%.
2. Change the Dark + Movement key function so that the Short Press function is Recall 1 instead of Onkey. You can then set your 40% level on the blocks tab of the UI.

Option 2 is probably the quickest and easiest so I'd recommend that option. It also allows manual control of the same load to set any level you like.

 

Newman, thanks for the prompt and informative response. I'll try storing the scene in a DLT first as this may give me an easy way to trigger the scene from other locations too (PC, etc) at a later stage.

While I'm at it, I'm guessing the "Sunset" event will be triggered when the lux level hits my lower limit and then not re-trigger before the upper limit has been hit after that?

 

As far as I know Sunset is calculated, based on location, that is Longitude and Latitude.

 

The Sunset function (by default) turns on a Group and starts a timer when the light level drops below the threshold. If the timer expires the Group turns Off. If the light level rises back above the threshold the Group turns Off.

If you edit the key microfunctions to make the Retrigger Timer Long Press function Idle then the Group will simply turn on when the light level drops below the thresold and turn off when the light level rises back above the threshold.

 

OK, still a little confused. I set the primary application to trigger control, and copied the groups across from the Lighting application.

When creating scenes with my DLT, I created a TriggerGroup called "SceneList" and then I assigned a scene (scene 3) to a key (key 8). The ramp rate is instant and the "Trigger Group Action Selector" is 2 and named NightMovement

Now I can assign "PIR Day Move" to trigger a TriggerGroup, so I assign it to "SceneList" but how do I assign it to trigger the Group Action Selector number 2 (or named NightMovement)?

Did I get my understanding of TriggerGroups and Action Selectors wrong somewhere? The other docs desribe them as a "list of scenes" and the Action Selector as the scene in that list to trigger.

 

Nearly there!

Trigger Groups and Action Selectors are analogous to a C-Bus Group Address and Level. So, an Action selector of 2 corresponds to a Level of 1% (there are 255 action selectors but only 100 whole percentages).

To make the Multisensor set the Trigger Group to 1% (Action Selector 2) is change the key functions in the Multisensor from OnKey to Recall 1. Then set the Recall 1 level to 1%

That should sort you out.

 

Inches away now.

One more question please sensei.

I have too many individual outputs to create a "Bedtime" scene (max 10 as far as I can fathom).

I understand the solution is to form logical groups and then set levels for these. But I can't quite get my head around the logical AND and OR setting on the relay or the "min" & "max" settings on the dimmer units.

I seem to find myself in a situation where is a unit was off before I switch it off, then I can't switch it back on, and vice versa.

Am I barking up the wrong horse here?

 

Not really a solution to your question, however, try to find a solution without using logics. With logics, you have to plan clearly and draw up the diagram to tell yourself what you are doing. e.g. "AND" in relays gives you master off, but not ON, "AND" in dimmers gives you a Lower level of the address involved, so in fact it could give your user a sense of "malfunction" when your sensor locked up the master address level and your wall key for individual address doesn't seem to have any effect.

If you are lucky enough to have more than one DLT to trigger the same scene, you can store the level of individual group address in different DLTs. For example, DLT01's scene 1 controls Group 01, 02, 03, 04, 05. DLT02's scene 1 controls Group 06, 07, 08, 09, 10. Assign the same trigger group and tag level to both scenes. So, when you press DLT01's scene 1, it'll trigger DLT02's scene 1 as well. The more the switch for the same scene, the more addresses you can handle without using logics.

If you just have one DLT for each scene and must use logic, draw a switch-logic plan (as in the manual, draw switches in series (AND) or in llel (OR) )for the set-up and think twice if there is any side effect. You must be clear about what logic means, of course.

 

wanricky, thanks for this, it's a big help. I was running into just the issue you mentioned with a sensor preventing a wall key from operating as expected.

I like the idea of using multiple DLT's. Is there a more elegant and scalable solution if I don't have 2 DLT's though? Would a PAC help my campaign here if I intended to do some more progamming later?

Or will my sensor broadcast light leves to C-Gate that I can pick up and then send some commands out to manipulate my own "scene" - this is assuming a C-Gate command reference emerges soon of course

 

PAC is a great product to me. If you have one, always store the scene there. There is much less memory constrant with PAC. With multiple DLTs, there is a risk that one disconnected DLT in the future could distory your whole scene setting. I used this method with NEOs at sites without PAC. It is a pain to open a few switches to edit one scene, but at least it was a solution with the hardware at site.

For scenes, PAC will do a great job itself. Even if you need complicated logics to trigger the scene, PAC will do as well. For example, in different time period of the day, the same trigger group and action selector could trigger different scenes. (again you need to try some time to see if the logic engine is stopped under certain conditions) With everything in the same unit, it is always easier to maintain. Even if it breaks down after how many years, it is must simpler to have one set-up file to be downloaded to a new single unit.

As far as logic is concerned, honestly I still have not come up a case that I should use it without causing problems. It seems there will be priority between switches when I use logics.

 

I'm getting very swayed towards buying a PAC. I was just thinking about making my own with a combination of PCI and C-Gate and a spot of PERL (my PERL is better than my PASCAL). I know I have the threat of the PC connected to the PCI going pear-shaped and having limited functionality, but then I do own the PC and the PCI right now (albeit still struggling to get the PCI to work in Linux) so those are sunk costs.

You have confirmed that I can store scenes on the PAC though. I was worried that I would still have to store assored scenes on the DLT and only have the PAC trigger them.

 

I've got the serial PC interface connected to an 8-port Lantronix terminal server (along with various other things, weather station, energy controller, security system, genset and other things) - and I have written an application in C (you could use Perl) that simply opens a socket to the appropriate port on the lantronics and can read and write bytes as if it were on the local RS232 port. Difference is, I can have it on virtually any PC in the world (latency to be considered of course). This way, my very reliable Unix machines can do the work (and could failover to another machine if the main one lost connectivity or died). Might be an answer for you?

RossW

 

Public Release Protocol

Hi,

I don't understand why you guys bother with the Public Release Protocol. Who cares about the bits n bytes when you can use a nice, clean dll?
http://www3.clipsal.com/cis/CBusDriver.php3

This should also give you Trigger Control, which might be helpfull if you're interested in scenes...

Cheers,
MvdB

 

Fortunately, the world does NOT revolve around microslops.

I've had to (suffer) with products with zero support OUTSIDE the .dll (thermographic cameras for one) and I would never buy another product which was exclusively tied to that platform.

If it's hard and a lot of stuffing about isn't really a major problem if there is at least the OPTION of writing your own code on a platform of your choice.

 

Not all computing platforms are a PC. A dll does nothing for an embedded controller.