Simplifying Programming

[PB11]

Hi All

trying to build a program that reduces all the backlight LED's in the house. 

I've been selective on the devices, but still have 30 or 40 to add to both "then" and "else".

On top of that I've been advised to add a 5 second delay between each action.

This is an arduous task, and I'm wondering if I'm missing methods of easing this type of program building.

Are there any drop and drag, cut and past, copy features in the admin console?

On that note, is there anyway to completely turn off the backlight? When set to 0% I'm still having some level of light.

Thanks

 

[lilyoyo1]

1 hour ago, PeterBarker11 said:

Hi All

trying to build a program that reduces all the backlight LED's in the house. 

I've been selective on the devices, but still have 30 or 40 to add to both "then" and "else".

On top of that I've been advised to add a 5 second delay between each action.

This is an arduous task, and I'm wondering if I'm missing methods of easing this type of program building.

Are there any drop and drag, cut and past, copy features in the admin console?

On that note, is there anyway to completely turn off the backlight? When set to 0% I'm still having some level of light.

Thanks

 

There's a copy feature once a program is setup. Then you can copy it if you want the same stuff but different parameters for something else. 

Unfortunately since the isy doesn't know what you want, there's no short cut to these types of tasks. One thing I do (doesn't help you now) is plan out before an install what I'm trying to do. This way, I can add my stuff to large programs and scenes while I'm adding devices. That way, it's being done 1 at a time vs 100 at 1 time. Same amount of work but since it's done early on it feels less daunting. 

I would recommend making sure your changes are happening when the system is less likely to be used. Doing this at busy times will kill your network until it's over. 

I'd also think about what you are adding to make these changes. For example. If no one is in the laundry room at night, does it really matter if it's set to zero or 100? Same thing with other rooms such as the kitchen. If someone goes in there in the middle of the night, they're already up. Being able to see the buttons helps then more than anything. 

Thinking of how the lights effect people can cut down on how many devices you need to change (vs all) which makes things easier. 

[Goose66]

 

Also, for sanity's sake, I think I would divided these up in separate programs, maybe per room, and run them at different intervals off of the trigger event, e.g., Sunset + 5 minutes for one and Sunset + 7 minutes for another. This will make maintenance easier and spread out some of the Insteon traffic. 

Since these are direct commands w/ no follow up cleanup messaging like you would have in scenes, the 5 second delay between each command is probably not necessary.

[Geddy]

As for the 5 second line - you can add a bunch of them to the Then or Else area and then move them to where you need them. Just keep hitting "add to then" and they'll be there. Then you can go move them up/down as needed. But, as @Goose66 mentioned you might not need since you're not dealing with scenes/cleanup. The 5 seconds just cuts down on network communication and risk of too many signals going out to make the system sluggish. Maybe every few devices put in a slight pause, but not each one if you have a lot. 

Also, having them all in the same program might impact any future control of the LED lights that you might want. I would think breaking them up by room would be a good idea. And as @lilyoyo1points out some rooms might not be in use, but if in middle of the night it would be better to have at least some light on the button/switch to be able to find in the dark. 

I did similar with select switches/keypads in bedrooms to lower the brightness, but not all the way off as sometimes they are needed in the middle of the night. But lights in unused rooms and hallways are left at 100% because they don't bother while sleeping. 

 

[larryllix]

Non-scene Insteon signals require confirmation ACKs to be received by the PLM or they will be re-sent up to 3 times. This will really start to big your sytem down by planning to insert a comm clogging program into your system. Scenes do not do this, as reception is assumed by the PLM. Aways insert lots of Waits in between your program lines when flooding your comm protocol system.

You can prove this by eliminating all Waits for a trial run. While the program is running Then or Else manually, try to send any other Insteon signal to see what happens. Try a MS to Lamp combo or miniRemote and lamp. Then if you have any bad comm areas in your system you may find your Insteon system doing things or responding to events up to 90-120 seconds later, while Insteon buffers clean themselves out. Mine will only stack about 3 items behind until operations are missed and never happen.

Any time you don't have time critical operations it is always a good idea to insert lots of Wait 2-5 second delays. If you don't you may pay for it at any unexpected time in the future when lights don't respond.

As posted above I don't dim everything in my house, only eyesore devices that shine in my eyes at night. The erst don't matter enough to clog up my protocol that much. Then, each device has it's own program that are all spaced out or random for sanity sake.

[Goose66]

@larryllix We'll just have to agree to disagree on this one. The PLM will receive the auto-generated ACK from a direct command within about 15ms of the command. I doubt the ISY has the next command in a long string of commands queued up for the PLM in 15 ms. Yes, there is no ACK for scene commands, but after the scene command the PLM follows with cleanup commands to each device in the scene to ensure the command and status are correct. This can take up to a second (or more) for a large scene. You can see it in the acknowledgment blink of the LED on, e.g., a KPL when you initiate a large scene. It can take a long time for the blink to occur.

In my (12+ years, 60+ Insteon devices) experience, when you send a command for a large scene, sending another command during the cleanup messaging has unpredictable results, and you should place a WAIT after the scene command. When sending a long string of direct device commands, it seems to work OK without the WAITs. Of course, the WAITs don't hurt, outside of the effort to add them to a program.

I also agree that dividing these up into separate programs running at different times is a good idea so you are not creating a long period of heavy Insteon traffic for no good (timing) reason.