larryllix

If you like to have things YOUR WAY then you made the right purchase! ISY forever!

If the SwitchLinc that is not the dimmer is connected to the load then there will never be any dimming. The electronics are not capable of dimming.

I run Win 10 32 bit and Win 10 64 bit as, well. When 64 bit java was released, I switched to it during beta version releases, and have never loaded a 32 bit version since. You could try rebooting ISY after a power down for 10-20 seconds. I have received that "java 2 required" message some time back, but not for the last 4-5 months. That would seem to be some derelict code in ISY hanging about.

Lots of pvc tape over connections and a box or waterproof bag around the whole connection point. Just keep snow, rain and running water out of it and they work fine. I have mine plugged into a X10 appliance module suspended in the air under my porch overhang. Not a problem if the wet doesn't get in.

Yeah. Looking at a handful of my two wire, three wire, with and without neutral connections, all load wires are blue, same as your picture. Funny to see two wires out of some, a black and a blue wire only.

Here is a pic of one of the pairs I have. The load wire is blue and the traveller is red. The remote doesn't have any wire colours.

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.