Guy Lavoie

Now that's almost (I said almost...) worrying So you're saying that the instructions that come with every Insteon device about linking should be ignored, and that the ISY994i becomes the alternate way of creating links. I'll have to read up on that, including the cookbook. I thought the ISY was adding itself to the links, as a controller and/or responder for different devices. It's when I see comments like "You may have issues" that makes me wonder how well linking is understood, and makes me want to learn the specifics. I appreciate the feedback guys! In other experimentation I've been doing (hah, now I'll get spanked) I also got a factory reset 2245-222 Insteon hub responding to http commands. It's not even registered to an Insteon account. Strictly local control stuff. Like the 2412N, I manually link it to a device, and I can then turn it on and off with http commands. Also, even though officially it no longer supports X10, the embedded PLM still does. Good to know. Remember, I'm doing all this on a test setup to learn. I don't have a single Insteon device installed in my home, other than that 2414N presently doing Alexa duty. This way, I can factory reset devices and start over easily, such as for examining how linking tables change at each experiment step.

I don't want to start managing links manually. But I want to be able to do things like look at the link table for a device and understand what it's telling me. And what a "normally" linked device should look like, etc. For example, take two factory reset switches, link one to the other (3 way in one direction), then add them as devices in the ISY994i and import the link tables and view them. I think I should see them linked together, and also pointing to the ISY994i's PLM. That kind of thing. Seeing what it looks like when working normally is great when troubleshooting later. So far, I'm catching on slowly but surely, the way I like it.

Thanks! Whitepapers are often handy in understanding the design philosophy of a protocol.

Well, I've been an X10 user for 25 years, with a system that still works very well for me. I designed and built a standalone alarm system that communicates with X10 too. I have had the same ADI Ocelot running things for all that time without a hiccup. Most of my wall switches are Switchlinc 2384, which were well regarded at the time. I repaired a few (bad buttons) but they've been good. I was heavily involved with the Ocelot and ADI, and even wrote the 150 page manual for them when CMax 2.0 was developed. I added my Alexa project (using HA-bridge, and a program of my own making to drive a CM11A) about 2 years ago. That's been working great ever since. Way back around 2005 when Insteon first came out I had bought a Powerlinc 2414S PLC and a couple of Icon switches, and played around with that a bit. I had joined a developer's forum. Got the Ocelot to turn on the switches through the 2414S. But nothing else became of it. Then a few months ago an opportunity came up to get a used ISY994i for $20. So something new to play with and since it supports X10, also possibly add some functionality to my setup. Then bought a small lot of Insteon items on marketplace, including this 2412N that I initially thought was just an appliance module. Digging up stuff on the internet, I found out it was essentially a PLM with a web server built in. Basically an early hub. That's when the project of adapting my Alexa program to use that instead of the CM11A came about. Got that to work just fine. Cool. Faster, network connection instead of serial, and supports both X10 and Insteon. Now I've gotten around to exploring the ISY994i itself. Interesting little unit, and possibly handy for some of my projects, though the programming language isn't as "raw" as the Ocelot (I love ladder logic, Assembly language, etc). I had so much success with the Ocelot that I figured I'd take a similar approach with the ISY994i: learning the actual way it does things, and the way Insteon works, esp with links (hence the discussions in the preceeding posts). One poster replied with something like "The ISY then does it's magic..." concerning maintaining links, but I like to know precisely what this means. From experimenting, I can see that it keeps track of links between devices, and establishes new links with itself (well, the PLM). I'm still learning, and that's ok. Slowly but surely works well for me. Now we come to the idea that I should use the ISY994i to implement my Alexa functionality. Well, the one I have doesn't have the portal module, seems you can't add it anymore anyways, and getting the new EISY would cost me over $430 Canadian (I'm in Canada) plus I'd have to pay an annual subscription, just to be able to do what I'm already doing for free with the 2412N that cost me basically nothing. Not very appealing. Look guys, this is mainly a hobby for me, and I had a lot of fun developing that program to use Alexa (and learned a lot about Insteon in the process). Now I'm learning about links, and status, and learned a lot just from this thread! Importing the links when adding a device makes logical sense now.

Well, I like the speed and independence of the Alexa app, especially through the 2412N. My former app used a CM11A and wasn't as fast, and only did X10. Plus it does macros, like A1,A2,A3,AOn, and they're easy to edit. The faster speed turned out to be a bonus. I was just going for the added Insteon functionality. Going through an extra controller and extra programming is the kind of thing I try to avoid. This way, even if I'm working on the rest of my system or the ISY994i is out of commission for some reason, Alexa still works (kind of important for the missus). Again, I was mostly trying to learn how status tracking worked, more than for a specific need at this time.

I'm getting the hang of adding devices. I factory reset both switches and deleted them in the ISY994i, and started over. I first created the link between switch 2 and switch 1 to make it a 3 way, and also did the link thing with the 2412N towards switch 1 (the switch really beeps like a link is extablished). Then I created the two switches in the ISY994i, this time importing the existing links too. It now lists the devices that the switch is either a controller and/or responder to, and does show that it's a responder to switch 2. But doesn't show the link to the 2412N... I guess that confirms it doesn't do it. Now at least I'm getting the status of switch 1 updated whether it's turned on locally or by switch 2, which is better. Also, I think I've found a workaround for those few cases where knowing the status of a device turned on or off by my Alexa setup is important. I could have my program set a variable in the ISY994i using a REST command, and then that variable gets changed to a value, send query requests to the device(s) that I need a status update for. I just tested it and it works.

1- I'll check that out. 2- Well...when I click on Add device and choose from the device types, the PLMs are there (2413S, 2413U, 2412S, 2412U...but not the 2412N). When I do add it, it says "unsupported device type". I would have thought that at the PLM level, they were all treated the same for a given model number. However I also notice that the Insteon hubs aren't listed either, and the 2412N is considered to be one of the early hubs. I guess I'm guilty of wishful thinking!

Interesting. How would I go about launching that?

1- Ok, now we're on to something. In my crusty old X10 mind scenes were simply macros, things that you wanted to happen together. I guess Insteon scenes are a bit more involved, in having the devices keeps tabs on each other. I'll read up on scenes for my next homework. 2- Well, I just want to have the 2412n seen as just another switch sending on and off commands, not having another application administering links, etc. If you mean more by "only thing that controls those switches" then that would need to be explained. In my mind, controllers (of any kind) can send commands to responders (switches, keypads, even hubs).

Yes, I can still control the switch from either the hub or from the ISY994i. That makes sense because you can also have other switches or keypads controlling a switch. I thought the whole advantage with Insteon was the ability to always track status. So it makes a difference on where the control signal comes from, as far as tracking status goes. Before posting this reply, I added a second switch, and linked it to the initial switch (let's call it switch 1). Switch 2 can control it fine, like a 3 way circuit, as expected. But once again, the status of switch 1 isn't updated in the ISY994i. The status only updates if it's turned on manually, or by a command from the ISY994i itself. That can't be right... Please note that I'm learning here, and I'm probably missing a step to have all this work the way I think it should.

Hi all. I'm still new to Insteon and I'm learning with a test setup. I have the ISY994i as the main controller, and also a 2412n "central controller" that's used independently by an application of my own creation for Alexa, allowing it to control X10 and Insteon lights. My test device is a 2477S on/off switch. I first added the switch to the ISY994i and it works fine: turning it on and off, and updating the status if I operate the switch manually. As expected. I then established a controller to responder link from the 2412n to the switch, and now my Alexa setup can control the switch. As expected. However the ISY994i isn't showing the status change. I tried establishing a controller to responder link from the 2412n to the PLM, thinking that maybe it needs to send updates to the PLM, but that doesn't change anything. Is there a way to have the ISY994i track the status of the switch no matter how it's turned on or by what? Thanks for any hints about this.

Yes, with the Ocelot the "Skip to" command that was added in C-Max 2.0 allowed that kind of nested programming, where a logic test allowed you to skip over one or more logic tests. It really came a full ladder logic machine with that. I had asked Dan Smith at ADI to add that, along with the modulo math operator. Good memories of those days! With that, it became possible to script programs like the C language: If (condition) { If (other tests) Then.... } As I told some C programmers at the time, the "Skip to" command translates to a "{" in C (that skips to the matching "}" ) if the logic test is false. The complier hides that from you!

Yes I know (from using X10 for 25 years now...) that most devices like switches don't send their status when manually activated. But that's secondary right now, because I was mostly trying to understand the programming model for the ISY994i. The same logic rules will apply to switch status, variables, etc. The thing I've determined is that all the logic tests (IF/AND/OR) within programs test static conditions, or single events like a control message being received, but if the whole resulting logic test of the program transitions from false to true, the THEN clauses are run, and if it transitions from true to false, the ELSE statements are run. That was the goal.

Thanks for the responses. Well I finally got around to writing a test program. It turns out that the status test is a bit of both: a test of static condition and also of a status change. I wrote a simple two line program that tests the status of two X10 addresses, with an AND statement, and increments a variable if both are On, like this: If A1 Status is On AND A2 Status is ON THEN variable1 =+1 The way it behaves is that if either device is on and I turn on the other one (changes from off to on), the variable increments. In that sense, the device that is already on is being tested for it's static condition only. But if both are on and the test would be strictly about the static condition, then the variable would be incrementing wildly and continuously as long as that's true. As I mentioned in my first post, the language seems to be designed with "idiot proofing" in mind, and more specifically, it's the status of the WHOLE program that needs to transition to true to trigger the THEN statement(s), and transition to false to trigger the ELSEs. It's the status TRANSITION of the WHOLE program that makes it single triggering. Now I also see how the current static condition of the whole program can also be tested in other programs, with the IF Program... statement. Now it's clear!

Agreed. I'll post about any findings that don't appear to be clear.

Ok, that's great if this is the case. It simply appears that the text in the cookbook is poorly written and seems to imply that a CHANGE in status is needed to have a status test true and trigger. Thanks!

Thanks Techman. That's the way I see the meaning of "Status". It's just that it seems to be contrary to what the cookbook says: Unlike control, a "status" condition will trigger an evaluation only after a CHANGE in status According to that quote, if the door light was already on, then the IF statement will test false because no status change occurred. IF (false) AND (true) = false, and won't trigger... Unless "trigger an evaluation" actually means "trigger an action" if the whole logic test (IF/AND/OR...) is true. It just might be the wording. In my experience with Programmable Logic Controllers, logic tests are ALWAYS evaluated, and actions (THEN...) are only taken if the resulting test is true, and any ELSE if false.

Thanks, but that doesn't answer my question... Let me rephrase it. Here is a quote from page 127 of the cookbook: 8.2.14 Using ‘If Control’ versus ‘If Status’ in Programs16 The reason to use control condition is that a control will trigger a program evaluation upon EACH receipt of the anticipated command. Unlike control, a "status" condition will trigger an evaluation only after a CHANGE in status. If a device status is off, and you turn it off again, the status has not changed and no program evaluation will take place. I understand that to mean that "control" will trigger the program every time the activating command is actually received, like getting a X10 "A/1 On" command pair, regardless of the fact that it might have been already turned on. "Status" means it triggers if the internal status table for that device changes from off to on because this is the first time a X10 "A/1 On" command pair is received since it was last turned off. But what if I only want to check if the status is currently on or off? Just the static condition of the internal status table (no received commands at this time)? In my example above I'd like to trigger if the status of the hall light goes from off to on (it's status changes) AND the door light is already on.

One question comes to mind. The same options appear for a device status, whether it's a IF statement or AND statement. For example: IF Hall light Status is On AND Door light Status is On Knowing that the IF statement is actually looking for a status change, does this mean that the AND statement is also looking for a status change (and not just the current, static status)? This would be impossible to do because they cannot really change status simultaneously. Is there a way to check just the current status? A workaround would be to have a separate program look for the door light status change and set a variable value, then have the above code AND with the variable. That would be rather clumsy. Seems it would make more sense for IF statements to show "Status changes to" instead of just "Status", and let AND statements check current status. Maybe I'm just not seeing it correctly either... That's the kind of thing I'm trying to learn.

Hi Paul. Oh yes, my days of participating and moderating the ADI forum will always remain as great memories, as the number of people I've exchanged with. My Ocelot is still running strong and isn't going anywhere, especially with the expansion modules. I sort of happened upon the ISY box my chance, and because it supports X10 too, I thought it was interesting and worthwhile to check out. It seems to be what a next generation Ocelot could have been. The used one I bought has the X10 and Networking modules in it, which perfectly fits the bill for me. It also has a "Open ADR" module, for which I can find configuration documentation, but nothing about what it actually does. The networking module is of interest to me, because I could integrate it to my current setup of the Ocelot and HA bridge, which provides Alexa functionality. I created my own HA bridge to X10 bridge program using VB and a CM11A, but maybe the ISY could now do that. What I'm doing at this time is simply familiarizing myself with the ISY programming model. Like the Ocelot, it's a PLC style language, using ladder logic (which is what drew me to the Ocelot in the first place). However it seems to be trying to look like a somewhat higher level language, breaking up the long loop into separate "programs", and from what I can see so far, tries to "idiot proof" the user by allowing only single triggering events for IF statements. If it was me, I'd replace "Is On" by "Turns On" to reflect triggering on the status change. Minor stuff really, and doesn't take anything away from the functionality, and that I'll quickly get used to. I've already solved the missing timers issue! So I'm looking forward to figuring out and trying things...and exchanging with other users!

I just tested it, and works perfectly. I created a state variable called Timer1, and created a standalone program that tests if it's greater than zero (which will always test true as long as it isn't reset to 0), waits one second, and increments the variable by 1. I now have a timer and can be used in a composite conditional situation, such as if a trigger occurs, and another trigger occurs within a time interval. I've used this on the Ocelot for that double tap function I mentioned in my first post. Another use is for a bathroom fan timer. You might want to turn on a bathroom fan that will automatically turn off after so many minutes. Using "wait" confines you to a fixed value, while using a timer like this allows you to add time by retriggering the same or a different event. Here is the logic, in pseudo code: IF turn_on_bathroom_fan trigger AND Timer = 0 (if fan first turned on) THEN fan_ON action THEN fan_time = 600 (default of 600 seconds) THEN set Timer to 1 (start the timer) IF turn_on_bathroom_fan trigger AND Timer > 0 (if fan is already running) THEN fan_time = fan_time + 120 (add 120 seconds to run time) If Timer > fan_time THEN fan_OFF action (turn off the fan) THEN Timer = 0 (stop timer)

Interesting, thanks for the pointers. I like to learn by writing and testing small examples. I do see a "wait" action. I suppose a timer could be implemented by setting a variable to a non-zero value, and have a separate program that as long as the variable is non-zero, waits one second (or whatever granularity you want) and increments the variable by one. I just might test that as one of my first experiments.

Hello. I'm just getting started with a ISY994i and PLC that I bought used for almost nothing. I'm a long time ADI Ocelot user and some will recognize my name if you remember the ADI forum. I got the ISY994i because it was such a bargain, and thought it would be a fun thing to try out, and possibly add functionality to my Ocelot based X10 system. They might complement each other nicely since the ISY994i has networking features. Anyways, I'm just trying to get a sense of how the if/then programming works, compared to the Ocelot. In particular, how tests for single events vs static statuses works, and which ones it supports. The Ocelot is particularly versatile in that regard, and allowed triggering on raw X10, command pairs, status change, and existing status. For example: If X10 A/1 is received... (if raw X10 address or command is received) If X10 A/1 ON command pair (if a command pair is received) If X10 A/1 Turns ON (if the status for that X10 address changes from Off to On) If X10 A/1 Is ON (if the status is currently On, often used with AND statements) This is very versatile, but also allows for mistakes, such as if you use "Is ON" instead of "Turns ON" to then send other commands: it sends continuously because the test is that of a static condition. From the bit of exploration I've done with the ISY994i, a statement such as "If A/1 Status is ON", it actually means if the status "becomes" ON, not a static condition. I'm deducing thing from the fact that the programming allows a THEN statement to send commands, and also a ELSE statement to do that. Similarly, the ELSE statement seems to imply the opposite status of the same test becoming true (so it's not an ELSE IF, just ELSE). I also don't see any timers, or haven't found an equivalent yet. For example, with the Ocelot I could look for a X10 command pair, and start a timer (that increments every second). Then have another program section look for reception of that same command pair while the timer is running, and finally a third program section stop the timer if it reached a certain value, say 5 seconds. This allows me to look for the reception of a X10 command pair, and if I receive it again within the time interval (by double tapping a X10 transmitter), then trigger a second action. I use this to turn off all the kitchen lights if the switch is tapped twice. Can the ISY994i do this kind of thing? Thanks!