Guy Lavoie

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.

Think of it as a wall switch (relay or dimmer) with four extra programmable buttons. It's a nice concept, because it can easily be used to replace an existing regular switch to get the augmented versatility. And yes, whenever you want to use it in less a conventional way (as your All On function), that's exactly where using a program comes in. That's the justification between having a ISY vs just a hub. I have several set up that way.

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.

Assuming you'll get a eISY (the only controller model currently sold by UDI), you can either get a Zooz 700 series USB dongle if you only need Zwave, or the ZMatter dongle if you also want Zigbee and Matter functionality. Matter connectivity is not released yet.

It's a conceptual idea, that I haven't tested. But I can picture that kind of thing possibly working. Devices can both be controllers and responders (like we do with virtual 3 way circuits) or not, like in many scene applications. That's the big advantage with Insteon: the multiple linking concept. You'd be testing for the virtual light getting turned off, during the nighttime, which shouldn't occur according to your description of the way it's supposed to work. I'd test it with a couple of switches.

It depends on what you mean by if they're turned off "by themselves". By someone manually turning one off? One way might be to use the "Virtual" plugin to create a virtual light that gets turned on at the beginning of the night, and then make all these night lights controllers for a scene that turns that virtual light on or off. That way if one of them is turned off, the virtual light also turns off, and you could have a single IF statement looking for the status change to off for that virtual light, during the night time. Just an idea that I haven't tested.

You could possibly add actual repeats of the command if they're being initiated by a program. Such as send the command, wait a few seconds, and then send it again.

Try encoding it in this order: https://admin:admin@my.isy.io:8443/rest/nodes Replace admin:admin with your own username and password, but in plain text, not base 64 encoded. The base 64 encoding works with a multiline http request. I just tested this successfully on my own eisy, from a chrome browser on Windows 10 to turn on an Insteon switch: http://admin:admin@192.168.0.145:8080/rest/nodes/20 88 BE 1/cmd/DON

Well, the "open" and "close" buttons (at the top right) are normally open momentary contact buttons. Are you looking to just control opening and closing, or more than that (like monitoring status, etc)?

Have you tried the reset button inside the unit (not sure if that's the "factory reset" you tried)?

Yes, that's the trick. I migrated from X10 to Insteon that way, doing 3 or 4 devices, then programming them the way I wanted them to work together, to learn the programming at the same. Then a few more. As usual, the first time can be daunting. Yes, there is a learning curve. Not being in a hurry is the best approach.

I had that happen to me 2 days ago. It had been running fine for weeks, then suddenly both my eisy and polisy wouldn't show up. Did the clear cache, full resintall of java, reinstall of launcher...no go. I ended up having to use the "add" button on the launcher to manually tell it where the devices were. Like this: https://192.168.0.145:8443/desc Just write in your own ip address. It worked for both devices. I then did a "save" to make it easier next time. No idea why this suddenly happens.

You need to go into Configuration -> Emails/Notifications. Configure the email server (try it with just the default box checked first), then in Settings/groups, define a recipient group (even if it's just yourself) and then add recipient(s) to the group in the second field. Test...and save. Then you go into Customizations to define a notification type that you'll want to send, and in the second field (content) you compose the actual email with subject and body. Save. Finally, in your programs you can now choose "notify" as an action. You then define the two fields from the select lists. The group you defined earlier as the "to" destination, and the email you defined as "content".

There you go, thanks. Just something to file under "good to know".