Guy Lavoie

The eisy isn't considered a "hub" in that sense. You can't just walk into a chain store and buy an eisy as a shrink wrapped product. Chances are that the product will work just fine, since zwave devices are designed around a common chipset.

What device models are they? My garage thermostat example is an insteon 2441TH, and the dimmer is a 2477D insteon switch.

For your first question, did you do a "synchronize" in UD Mobile after adding the new device(s)? From the main screen, click on the three vertical dots at the upper right corner, and click on synchronize.

I just verified on mine (eisy running 5.8.4), and I have access to the other thermostat, and dimming settings.

Yes I've done a downgrade from 5.3.4 to 5.0.16c, and it worked.

Having a spare PLM on hand is always a good idea.

The easiest (and cheapest) way to couple powerline phases for Insteon is probably by installing a dual band lamplinc module on each phase of your breaker panel, and in somewhat close proximity to each other (ideally in the same room). They're plug in modules, so easy to move around. However if you have lots of other dual band devices, such as wall switches, then this will often be sufficient too. A setup with just a few devices is less reliable than one with many, as is the case with other mesh network topologies. Yes, the 2477S is dual band (has both powerline and rf communications). The dual band technology is a big part of Insteon's reliability. If the only Insteon device(s) you have are wall switches, then trying things like moving it closer to the PLM will be difficult. Tell us what you have exactly, and how they're laid out. I have a mid size setup (about 35 to 40 Insteon devices) and is a mix of dual band and powerline only devices (I bought several lots of used devices). I'd say about 2/3rds of them are dual band. I consciously set them up to have dual band switches in at least every part of the house. Some devices are also rf only, such as the battery powered Triggerlinc magentic door detectors, mini remotes, and the thermostats.

The 1181 is definitely not Insteon. It is one of Smarthome's very first X10 compatible switches. Then came the 2384, etc. Then came Insteon. On the 2477S, you should see a label with an address formatted such as 47.F2.E0 That's the device address, and what you should try entering when adding a Insteon device manually (though "Start Linking" should also work). But just start with that. The fact that the admin console says the PLM is connected is already a good start.

Have you tried manually entering the device address? Under "Link Management", click on "New INSTEON/A10/X10 Device" and enter the device address. Try this first with a 2477S or other dual band device. Also, where is your PLM plugged in? Have your existing Insteon devices worked there before?

Update what? IoX? Current version is 5.8.4

Thanks for that. I'll read it over a couple of times to make sure I grasp everything discussed. Interesting that 13 years ago apostolaskisi asked the same question, did similar tests, and is still around!

Is that discussion still on here, somewhere? I'd like to view it if possible.

I've had the odd Alexa device mix up, where it activates the wrong device. I'd delete it from the Alexa app and rediscover it. But that was with Hue lights being controlled through HA bridge. Insert "Alexa is blonde" joke here... but stuff happens. You geographic restriction thing is really odd. It could be (hopefully) something temporary.

It's possible that the actual occurrence of some output events might appear to happen out of order. For example you might have programmed a zwave command followed by an Insteon command, and the zwave propagation delay might make that device appear to respond after the Insteon device. But that would be due to output queueing and communication speed. The program would still have initiated the commands in programmed order.

There you go. That's why I'm always weary of updates.

Have another computer you could try it from?

I did see a "java update available" go by just a couple of days ago, but I always wait a bit, just in case. The version I have now is 431 build 1.8.0_431-b09 I'm also running Windows 10 64 bit.

Sounds like a admin console problem, not the controller. Any recent java updates? Tried a reboot of your computer?

That's odd. Do you have existing programs with a schedule? If so, try copying that program to create a new one, and edit the new one. Just something to try.

Well how do you think it detects triggers? It doesn't have a hardware interrupt for every device and program... It has to look for events by scanning through the programs looking for a condition that warrants executing the IF or ELSE statements. It might be optimized to skip some of the tests that can only test true when something external like an Insteon/X10/Zwave/whatever command or update happens, but for some others like a variable, time of day, etc, it needs to revisit any programs containing tests on those values if one of them changes (and time constantly changes). That might explain the reason why the execution order is deemed unpredictable. Certainly, things can be optimized to skip unneeded tests. That's also very likely the reason why there are "state" variables; because these need to be in a hit list for event testing, but no need to test integer variables. For sure, the IF/THEN statements within a program will be executed in order.

The next time you fire up the launcher and see your eisy ok, click on "save" to save the configuration. Then if you can't see it at a future time, click on "load" to get back the link.

The number of lines doesn't really have to anything to do with it. No two programs can ever be executed "at the same time". A program like IoX loops through the conditional statements at high speed, looking for any tests that are true to execute the Then statements, or false to execute the Else portion. This type of program model is often called a state machine and is used in PLCs (Programmable Logic Controllers). The main characteristic is that it can never stop and spend any time in a particular routine. All actions are usually put in output queues and dealt out as part of the entire scanning routine. ie: sending an Insteon command looks for the PLM to be idle, initiates sending the command, and sets a flag that looks for the PLM to have completed sending the command, but otherwise keeps looping the program. Same with input conditions. Similarly, a Wait statement will set a flag to look for the system clock to have reached the time for the wait to have elapsed, and immediately gets back to the rest of the loop. The closest you can get two programs to seeing something happening seemingly simultaneously is when you can get them to test true in the same evaluation loop, which is what I was testing here by having them all look for the same X10 command. The two main characteristics of a looping program controller are usually the known execution order, and timing of any triggering events in relation to the loop. That's how full predictability is achieved. For example, the good ole Ocelot home automation controller would queue incoming events, and a new event would be read off the queue and always become testable between two program scan loops. That, and programs would all be written as continuous series of If/Then lines, each one with line numbers. It would loop by starting at line 0 and loop through consecutive incrementing line numbers. That way, you were certain that program segments at lower line numbers would always be the first to see and test a new input condition. Without knowing that, how can you write program segments that reliably communicate with each other through variables? Here is what my three test programs would look like in the Ocelot: 0 IF X10 A/1 On is received 1 THEN $test_1 += 1 2 IF X10 A/1 On is received 3 THEN $test_2 += 1 4 IF X10 A/1 On is received 5 THEN $test_1 = 13 You can have up to 2048 lines. Now no matter when the X10 A/1 On was actually received while the loop was executing, it would become available for testing just before executing line 0 of the following pass and be true for one full pass through the loop. Now I was certain that the Then statement at line 1 would be executed before line 3, and that before line 5. That's the information we're missing about IoX.

Just to deepen my understanding of how IoX works, I thought I'd look into the order that IoX executes programs, especially when they interact with each other through variables as flags. I started by searching the wiki, which does have a section on evaluation precedence within a program, but as for the order of execution of programs themselves, came across this ominous statement: "In all cases, the order in which the programs run is determined by ISY's internal algorithms, and is not user predictable". Whoa...that's not the language of a control system! It might also explain many of the glitches that people come across in getting unexplained behavior. I thought I'd start off with a few experiments, using a Polisy that I have as a test system. I started off with a blank system, no programs. To keep things simple, I use an old X10 minicrontroller to generate events (no need to set up links, etc). I defined two state variables (test_1 and test2), then I created two programs. I use the same trigger for each program to keep them all becoming true at the same time. Program AAA is: IF X10 A/1 On is received THEN $test_1 += 1 and Program BBB is: IF X10 A/1 On is received THEN $test_2 += 1 as expected, both variables increment by 1 with each received X10 command Second test: modify AAA to add a statement: IF X10 A/1 On is received THEN $test_1 += 1 THEN$test_2 = 0 so now if Program AAA executes before BBB, test_1 should increment with every X10 command, but test_2 should always end up with a value of 1 (Program AAA sets it to zero, and BBB then increments it by 1). But that's not what happens...test_2 is always at zero! So it would appear that BBB gets executed before AAA, even though it was created after. Just for fun I tried having it set test_2 to other values (eg: 42, the meaning of life, the universe, everything...) and sure enough, it always ends up with 42, so program AAA is always getting the last word. Execution is in reverse creation order? Well, what's "order" anyways...there is no clear indication of the order of a program in relation to other programs in the program editor, and copying, deleting programs will make you lose track of "creation order" quickly enough, as will the automatic listing of programs in ASCII name order. Start looking around... Ahh, when you click on "Summary" you get a list of programs, and the last field is an ID field! So programs do have ID's, like everything else in IoX. The first program you create gets ID 0002, and then IDs increment with new programs. So AAA is ID 0002 and BBB is ID 0003. You need to click on the ID heading to have them sorted by increasing ID. Ok test 3 to see if the reverse order thing seems to be true: add Program CCC IF X10 A/1 On is received THEN $test_1 = 13 As expected, program CCC gets ID 0004, and sure enough, test_1 ends up with a value of 14 (initiated to 13 by CCC and incremented by one by AAA), and test_2 keeps the final value that AAA sets it to, unaltered by BBB. Am I on to something? A lot more tests would need to be done to know for sure. The rules really needs to be clear for the controller to be reliable.

Well, the port for the 2413S is a RJ45 connector, but is not ethernet. It's serial.