Using Bright in Program

[ergodic]

I have a light ("X") that is controlled from three places, so like most of my devices, there's a scene for it ("Multiway: X").

 

Since you can't set the dim level of a scene directly, I tried using a disabled program like this to keep the 3 controllers in sync:

 

Program X25 (always set disabled)

 

If Status "X" < 25"

Then

Set "Multiway: X" Bright

Run Program "X25" (If Part)

 

The problem is that this takes the light full on. And the ISY console shows it at a status of 77% when the program is done, not something around 25%. (A manual query on the device then updates it to the triue value of 100%.)

 

If I add a 1 second wait after the bright, then the light inches up to 54% with the console showing it at 25%. Again, a manual query updates it to 54%. If I change the wait to a query on the device it still overshoots.

 

If I change it to the actual device instead of the scene, it gets much closer. It overshoots to 32% with the console showing it at 28%.

 

So my basic question is why the ISY gets out of sync on the light status with the scene it's controlling, and is there a way to do this?

[fitzpatri8]

I have a light ("X") that is controlled from three places, so like most of my devices, there's a scene for it ("Multiway: X").

So you have a scene called Multiway: X with three devices in it, all as Controllers?

 

Since you can't set the dim level of a scene directly, I tried using a disabled program like this to keep the 3 controllers in sync:

Don't use a program, use a scene. Simply create another scene with that dim level. Create a new scene (Multiway: X 20%), add all three devices, then set the dim level for all devices to 20%. The ISY will recognize that they are already controllers of scene Multiway: X, so it will have you add them to the second scene as Responders only.

 

When adjusting the scene by holding the On or Off paddle on any of the three controllers in the scene, they should all adjust in sync. If you just tap the On button of a switch when it is already on, it will activate the local bright feature that puts just that dimmer at 100%, but you should be able to create a program to watch for that condition (an On when the device is already On) and respond by re-sending the On command to the scene. Just make sure you don't send any commands directly to one device in the scene--make any bright/dim/on/off commands to the scene, not to any one of the individual devices, or you'll put them out of sync.

[oberkc]

Since you can't set the dim level of a scene directly

 

??!!

 

I am not sure I understand this statement. One can set on levels and ramp rates for devices within scenes. One can even set different on levels and ramp rates for a scene devices, dependent on which controller activates the scene.

 

I have a light ("X") that is controlled from three places, so like most of my devices, there's a scene for it ("Multiway: X").

 

I am a little confused. What insteon device actually powers light "X"? What are the three insteon devices used to contol light "X"? Does the scene include all four (or is it three? Five?) devices?

 

If you, from the admin panel, my lighting, choose the scene, what are the on levels and ramp rates for each of the included devices? If you select each of the devices within that scene, are the ramp rates and on level different?

 

The problem is that this takes the light full on.

 

It looks to me as if your program potentially causes itself to enter an infinite loop. Your last "else" statement causes the program to restart, which runs the "else" which restarts the program, which,.... My gut suspects it has something to do with the content of your "multiway-X" scene.

[ergodic]

My understanding is there is no way to set a scene to x%; I would need to define a scene for each dim level, yes? I kind of remember the capability was proposed on the forum some time ago but I don't remember if anything more was done.

 

It is a simple multiway switch setup. Three dimmers, one of them connected to the load. The scene defines all three as controllers. Ramp rate is 0.5sec, on level for all is 100%.

 

Not sure why you'd expect the program to loop. The else clause does nothing and remember that the program itself is disabled so the only way it executes is if something explicitly calls it. It just doesn't stop at the right place. Not clear why.

[fitzpatri8]

My understanding is there is no way to set a scene to x%; I would need to define a scene for each dim level, yes? I kind of remember the capability was proposed on the forum some time ago but I don't remember if anything more was done.

 

It is a simple multiway switch setup. Three dimmers, one of them connected to the load. The scene defines all three as controllers. Ramp rate is 0.5sec, on level for all is 100%.

 

Not sure why you'd expect the program to loop. The else clause does nothing and remember that the program itself is disabled so the only way it executes is if something explicitly calls it. It just doesn't stop at the right place. Not clear why.

 

Insteon devices don't compute a % of a %, that's correct. Most Insteon devices can be members of 400+ scenes, so you can set up multiple scenes for multiple levels.

 

Maybe we're misunderstanding what you are trying to do. When you hold one of the buttons on one of the three controllers, all three should react in sync. If you brighten or dim the scene using the ISY's admin console, they should all respond in sync. What are you pressing or clicking that is reacting differently than you expect?

[oberkc]

It is a simple multiway switch setup. Three dimmers, one of them connected to the load. The scene defines all three as controllers. Ramp rate is 0.5sec, on level for all is 100%.

 

Is this the same ramp rate and on level for scene level and for each of the three devices? If you select one of the devices within the scene, does it show these same levels? Is it possible that you have different on level for the three devices?

 

Not sure why you'd expect the program to loop.

 

When your program is called and is evaluated true, the "then" statement runs, which first calls for a bright command (Set "Multiway: X" Bright ) , then calls to run itself at the "if part" (Run Program "X25" (If Part)) . If it is, again, evaluated as true, it will send a bright command, the call itself to run again, and continue this indefinitely, so long as it is evaluated as true. That is why I was concerned about the program looping.

[ergodic]

The program is disabled. Events, including it's own, can not trigger it to run. It is effectively an if-then-else. It doesn't execute unless you explicitly call it from another program or the console.

[LeeG]

Ergodic

 

The Program is running faster than the device is responding. By the time the “status†has been updated to 25% or higher several more Program Action statements have been executed and the I/O queued for execution. The Program stops issuing Action statements when the If becomes false but that does not stop the queued I/O commands from executing causing the device to effectively over run the desired stop point. This type of programming would require a new ISY Insteon Action variant that waits for the Insteon command to complete execution and post the results before continuing with the next Action statement.

 

Scenes can be defined to set each Responder to a specific On level. The On Level can be dynamically changed for each Responder with a Adjust Scene but this is changing the stored On Level value in the Responder link record, not actually changing the On Level. To see the effect of an Adjust Scene the Scene would have to be commanded On again. This is not a fast process as a few commands are required to change the data in the responder link record before issuing the Scene On which is another command in itself.

 

What cannot be done at the Scene level is to dynamically specify the On Level when the Scene On is specified. The Insteon Scene command has no placeholder for an On Level for every possible Responder that could exist in the Scene.

 

The Bright and Dim commands alter the On Level across 32 steps so from an Off status a Dim Action can be executed 9 times to reach a status above 25%.

 

Perhaps if you can explain the objective there are other alternatives.

 

Lee

[ergodic]

Makes sense. But it was a bit of a puzzle why the issue is so much worse when controlling a scene than when controlling the device itself (where it actually works reasonably well).

 

I was also assuming an intervening "query" following the "bright" on the device to have queued up a command and thus cause any pending bright commands to get flushed through before coming back, but it doesn't appear things work that way.

 

The purpose as explained is simply to keep the slave controllers sync'ed to the actual status of the device, which doesn't happen if you control the device directly. In this case there are only two of these programs (25% and 50%), so I can just define a couple of more scenes.

[LeeG]

ergodic

 

The Scene command runs faster (executes more commands) because there is no device ACK associated with a Group Broadcast message.

 

I'm still unclear on the objective versus method. I understand the desire to keep the status LEDs in sync. I think what is confusing me is that the point of using a Direct device command is to change its state/status without affecting other devices that might be in a Scene with that device. If the objective is to keep the three devices in sync then a Scene is the method of choice. If a Direct command is the mechanism of choice for whatever reason then send a Direct command for 25% On to each device individually. The devices respond sequentially rather than simultaneously but they will be in sync.

 

Perhaps knowing why a Direct command is preferred over a Scene.

 

Sorry if I am missing the obvious. I am a little sleep deprived.

 

Lee

[oberkc]

The program is disabled. Events, including it's own, can not trigger it to run. It is effectively an if-then-else. It doesn't execute unless you explicitly call it from another program or the console.

 

I guess, then, I am missing the purpose of the statement in your ProgramX25:

 

Run Program "X25" (If Part)

 

If this statement has no effect due to the program being disabled, why is it there?

 

Perhaps I, too, am not grasping what it is you are trying to accomplish and why a simple scene is not working for you.

[LeeG]

oberkc

 

I coded the Program and ran it with Event Trace to see what was actually occurring command wise. The "Run Program X25 (If Clause)" Action causes the Program to repeat starting at the If. Run is not affected by the fact that the Program is Disabled. The Disable does stop the ISY from independently dispatching the Program when the status of "X" changes.

 

Lee

[oberkc]

I coded the Program and ran it with Event Trace to see what was actually occurring command wise. The "Run Program X25 (If Clause)" Action causes the Program to repeat starting at the If. Run is not affected by the fact that the Program is Disabled. The Disable does stop the ISY from independently dispatching the Program when the status of "X" changes.

 

It just goes to show that you go to much greater lengths to be helpful.

 

This is how I suspected it would perform, but I have never actually tried such a program construct, where a program calls itself. I understood the disable function would stop the inherent program triggering conditions, but does not prevent another program (or, apparently, itself) from triggering the evaluation through an if or else statement.

 

So...am I getting stupid, or is there at least some potential (so long as X < 25%) for a program loop here?

[LeeG]

oberkc

 

I'm always amazed at what I learn every time I try something new. A loop is a possibility as I created one by mistake. Coded a Dim rather than a Bright so the status never exceeded 25%. Changed the Program statement while it is was running and it eventually came out of the loop.

 

This technique is actually very interesting. It in essence provides the function of a While loop as the If is executed at the beginning of each loop interation. As with all While statements an unending loop can be the result if the Program is not coded correctly.

 

Now that I look at this with benefit of some sleep the status updates associated with Scene execution are what is running behind rather than unexecuted Scene commands being stacked. Does not change the end result.

 

Lee

[oberkc]

This technique is actually very interesting.

 

I must admit that my initial reaction was of interest, as well. In my mind, I was wondering if this technique (as applied here) was an attempt to cause the light to come up to 25% through a continuous (looping) bright command. I then began to wonder if this technique, along with some variables, could be used as a method to add defined steps to a dimmer-controlled circuit.

 

Regarding the orginal question....initially, I was unsure what device controlled the light "X" and whether it was part of the "MultiwayX" scene. Not knowing, I thought there was a chance that the scene bright command had no effect on the device "X", which meant that the device "X" status could remain below 25% indefinitely (a loop).

 

Unlike you, my curiosity ended at the pondering stage.