larryllix

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.

I believe the air gap is a safety thing. You have to be able to shut the power off completely to change a light bulb, standing in water with bare feet, with a shorted filament bulb that's full of gasoline. Trickle currents are not allowed while kids hold onto the outer metal ring screw thread or put their hand palm on the halogen bulb to change a lightbulb.

Yeah the receiver part of the RF would be no problem but you don't start transmitting an RF signal inside a metal box without risking damage to other components with the standing waves created, let alone the output transistors not having their power absorbed. This is a Radio guy's nightmare. My thoughts are SH never even thought about this and the board has the same guts as all the rest. maybe in the spring I should open this one up and take some pics. 'As long as we can put the "dual-band" sticker on it.' EDIT: Ohh! Brian to the rescue...

I run a lot of test programs to try things out. Use a beeper or even a program to indicate the code is being executed. Test Indicator (Not enabled) If -- Then Wait 1 second Run program 'Test Indicator' (else) Else --- Now when you insert the line in your programs Run program 'Test Indicator' (If)' you will see the program icon turn to red and back every time YOUR ISY program passes through that point. When you are sure about your program, remove the test line. NOTE: You have to have your icons colours enabled for this. This is a right click option on the program tree.

Great! Both of them have syntax errors in the wording as doesn't it doesn't match the value implied. If you would have waited the 35 minute for the cycle to repeat you would have seen it happen.

I just got me one of those, them, thar, thin's. (Outdoor Module) I am sitting parallel with the top of Upper Michigan state, in latitude, but Ontario, but haven't experienced much real cold yet this winter. The units has worked flawlessly, so far this winter, at the end of a 30' Christmas light extension cord mounted on a metal lawn chair fed by a GFCI receptacle. It turns my light sequencer on and off about 5-6 times per evening every hour on the half past. The button is encapsulated in rubber and the device seems totally sealed against water penetration. Good hard metal box and almost bullet proof cord and receptacle. OK not so important in Canada but tough plastics with sealed joints. I don't know why this thing would be dual band being in a completely metal box but maybe the cord acts as an antenna.