larryllix

Forget looking at the status of the MS. I use little programs, like this, to show what is happening. Watch the program icons instead, If Control 'Deck Motion Detector-Sensor' is Switched On Then Wait 2 seconds Run 'ThisProgram (else)' Else ----

Agreed. If Insteon stopped this capability they would have to redefine the whole Insteon protocol so that most devices wouldn't work. IIRC, the X10 3way system was a special switch at the load end anyway. There was an extra wire for the remote dummy to input a 120vac pulse and switch the master load switch. The master cost more and the remote cost less. This would be no different for Insteon. A special load end switch would need to be created with an extra terminal/wire for the remote input. A special controller only switch could be created without the triac but with all other hardware the same the special PCB without the triac included would cost more as a smaller production quantity item. Almost always stopping the routine production to remove a part from being installed on a PCB costs extra. I think I still have a few 3way X10 switches in my junk box. I do remember the wire colours included an extra blue wire and were scrambled to electrician standard types, causing confusion. If you didn't have the instructions they were hard to figure out every time you got one of the junk box. There was no Internet manuals and I don't think SmartypantsHome had dial up at 300 baud either.

Except for one thing. You need to have three wire wiring in your walls to make the three wire extension work. A feature of the Insteon method is that 3-wire prewiring is not necessary to add a 3-wire switching scheme. From what I can remember the 3-way extension unit was not much cheaper anyway. Currently I have a 3-way setup between two switches at opposite ends of my house where I have a deck, with entrance and switch, and a front porch with entrance and switch, and respective lights for each. I am not currently using a scene to make this happen but rather a program in order to maintain individual control of each bank of lights. The Fast On/Off commands on either switch can operate them both, from either switch, if desired.

Since the chime is a brand new product ISY will not have it in it's database for proper operation. You will have to wait for a future IS version release. I recommend you search for Request new features and voice in that thread. UDI listens.

I have to assume the kitchen lights are operating then and this is assumed to be the Kitchen 2 program run from Kitchen 1. View the event viewer for excessive Insteon traffic. If that isn't the case I would try power cycling your ISY with a few seconds shut down.

The first program Then clause should only trigger on a signal from the MS and only at the exact instant of the On signal. The MS status isn't being checked with the "switched ON" parameter. This shouldn't be possible unless your MS is sending out continuous signals. Have a look at your event viewer to see Insteon traffic.

Enabling a program should NOT make it run and doesn't on my ISY. What is your indicator that causes you to think it is running?

I got my new bulbs for Costco.ca today and replaced my flicking unit. It was the bulb purchased last year and another Cree bulb starting to flicker (not 60 Hz). This makes me angry as I paid about $40 for this CREE BR40 bulb. This is about the 5th or 6th CREE bulb that has worked fine for a few months only to start flickering, or in this case flicking out briefly, on a random basis. No dimmer or Insteon involved. I think the new bulb performance proves it to not be supply related. I am told, I think at HD, that CREE has a service number to call that will attempt to make it right. No receipts around any more but this bulb has only existed for less than two years. We'll find out.

Right click on the suspect program and select Find/Replace. In that box you will find methods to select programs, variables, scenes, devices. Select program, pulldown the menu and select the offending program and click find several times. ISY will take you through every occurrence of the program name. Hopefully you will find usage of your program somewhere else that is causing your problem.

That shouldn't be happening unless you have another program calling it as a subroutine. The find option can find this.

Yup. The statements posted by Stu from the wiki article are out of their context and only an example used in the context of the section. The point I made was the example was only specific to the program under discussion but in reality any program, device, rest input, or variable change, wherever the change originates from, can change the progression of the program in question from False to True or vice versa. The example, being out of context, implies only the program can change it's own course of execution from false to True or vice versa.. This is not correct and is causing confusion for users.

Here is an If with two ANDed controls that works. Just to confuse you but you seem to have good handle on real time event/triggers and statuses already. If control of wallswitch is switched On AND control of wallswitch is NOT switched Off Then switched On code Else NOT switched Off code

Well welcome! Diggers welcome!

Nice. But it still has holes in it causing confusion "What this means [wrt/Wait or Repeat] is that if anything a program's Then clause changes a condition which causes the program's overall condition to become false while the program's Then then clause is running (or if anything the program's Else clause changes a condition which causes the program's overall condition to become true, while the program's False clause is running), the current atomic statement group will complete, and at that point execution will transfer from the Then clause (or the Else clause) to the Else clause (or the Then clause)."

LOL. Confusion here. You are discussing the condition affecting the Wait line while I am discussing the Wait affecting condition lines.

Out of context. The whole phrase was " allows (the OS to do it's system homework and evaluate ALL triggers)" Parenthesise were implied. English! If none of the trigger elements change there is nothing to run. A program needs to be executing a wait or repeat, or no programs are running (system at rest) for ISY to even evaluate this. I believe if we write a program with 1000 lines of code and no Wait or Repeat included no other triggers or programs could run during this code running time. possibly no Insteon signals would be sent or received ones processed either.

I don't think UDI has ever disclosed the algorithm for running programs and that also keeps the process open for changes if another algorithm is developed to make it more efficient or any other reason. Users cannot depend on programs operating in any particular order. If we did, and UDI changes the technique, the order of execution might change and critical timing would not work. I believe this has happened with v5, as it seems they have changed the internal engine workings and sped it up, too. Dealing with a previous realtime event based system I discovered it's inner workings. I questioned Michel about the event trigger evaluation list/table but he denied it's existence, so the engine may be really busy evaluating every trigger possibility, every chance it gets. Yeah I would like to understand this also.

My understanding is that a Wait allows the OS to do it's system homework and evaluate ALL triggers if another event has happened. IOW: Wait and Repeat is a program's way of giving up it's time slice for a finite amount of time. If no Wait or Repeat is encountered that program hogs the PLC part of the CPU time. Nobody else get a chance to run until it is done.

These things are very important before automating your garage door. A little reading, some thinking, and elbow grease can do this for you. Or like Teken suggested hire a pro to do it, even as a routine checkup for a better off-season price. The Force Detection setting is the most important. People will tell you need to monitor the opening with a cam but this still no substitute for a person standing by with their hand on the button. But who actually does that, right? You slap the button and go into the house. When the toddler next door crawls under the door as it is closing your response through a delayed webcam signal, and through the further delay of a remote control HA system with you panicking, is not going to be in time. For dogs and cats? They aren't gonna to drag you through court to get support for their paraplegic child for the rest of their life, let alone your nightmares. Yeah, it can get serious real fast. As Teken stated above the Force Detection setting is the most critical system, and after that your "Beams" are working and placed correctly. Most "beams" are failsafe these days anyway and service attention is demanded if they are not functioning.

You have to imagine yourself as the computer walking through the instructions and doing each line, one at a time, in order. When you get to the Wait 1 minute, what are you waiting for? There is nothing else to do after that. With only one line per section it's about efficient as it can get for the ISY CPU.

Don't worry about ISY being CPU bound. The pro can have 1000 programs and it's the same firmware and CPU Are you having some problem with it working? Main Bedroom Humidifier - [iD 0002][Parent 000C] If From 9:00:00PM To 9:00:00AM (next day) Then Set 'Main Bedroom / Bedroom Humidifier' 100% Wait 1 minute <----- this line has no program function Else Set 'Main Bedroom / Bedroom Humidifier' Off Wait 1 minute <---- this line has no program function

Any of the brands a few years back were problems as they tried to make them too cheap. I have Cree units that started to flicker after about 3-4 months of perfect service. @Stu, this is not 120Hz flicker I am seeing. I have that on some when dimmed, especially my expensive Cree bulbs, now they are getting older. This is the occasional brilliance dip that seems to go completely out and then come back on full brilliance. A rough guess is the dip lasts 1-2 cycles only. For the longest time I thought I might have blinked my eyes but now this is happening more frequently and we can actually zoom in on the bulb that is doing it. hmmmmm... I was just thinking this bulb, over kitchen sink, is backed up by an inverter. Maybe contacts are getting dirty etc... I have had many problems with Occupancy sensor in this switch position, like 5 of them went back as keep retriggering after no motion. Insteon is not involved in this one at all. Maybe I will crawl up there and swap that bulb with another on another circuit nd switch. Thanks for making me think about it. Need to get proactive as I just ordered replacements for the lineup over the counter, 5K, 27W BR40's. Better work surface colour than the 2700K I have now.

"So this is giving me issues still. Not 100% perfect. My problem is IF I invoke my sunset scene before the MS declares it "dark" then turn off the lights - the MS will change to dark and then run sunset. Sometimes being in Seattle a dark grey day I may turn the sunset scene on earlier in the day. Any thoughts how to fix this? " I guess I missed the part where you ever turned the scene ON manually and assumed it was only the manual Off that caused the restrike from the MS.dark. My apologies. So you want once this scene has been run auto or manual for it to never be activated automatically again that day? So... - if you operate the scene On/Off manually at any time, that is OK = no conditions - if you operate the scene Off manually within an evening time frame the MS.auto On should be ignored for the rest of the evening. hmmmm.. let me think about that quirk and I'll try to get back to you.

Maybe the poor soul is a victim of the All On bug and thought it was due to power failure return.

You were close. The changes to your programs are highlighted in Red. The programs should operate as a "Once and Only Once" scheme each day.