I'm learning about Insteon linking. Question about status tracking between controllers

[Guy Lavoie]

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.

[Geddy]

@Guy Lavoie I think that Insteon can only have one controller. When you connected it to a different hub it lost contact to the PLM/ISY994. Can you still control the switch from the admin console of the ISY994? If not then it’s only being controlled by the other device now. 

UD has their portal and Echo Skill that make the Alexa connections, but it’s price has recently increased for ISY994 so might not be for your situation, but it would allow the ISY994 to still be the controller for all Insteon devices and would also continue to keep status in sync with the ISY994. 

 

[Guy Lavoie]

1 hour ago, Geddy said:

@Guy Lavoie I think that Insteon can only have one controller. When you connected it to a different hub it lost contact to the PLM/ISY994. Can you still control the switch from the admin console of the ISY994? If not then it’s only being controlled by the other device now. 

 

 

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.

Edited August 10 by Guy Lavoie

[bpwwer]

Insteon linking can be tricky to understand.     From your descriptions, I believe things are working the way they are supposed to, just not the way you'd like.

There are two ways to "link" what Insteon calls responders (devices that respond to commands) and controllers (devices that sends commands).  

The first type of link is a direct link.  That's where a controller is directly linked to a responder.  This is the type of link you've made between both the ISY's PLM and the 2412n.    With a direct link, the controller sends a command to the responder and the responder acknowledges back to just that controller.  So if the ISY sends a command to the switch, the switch executes the command and responds back to the ISY.  If the 2412n sends a command to the switch, the switch executes the command and responds back to the 2412n.   Neither controller is aware of what the other controller sent.

The second type of link is a group (or scene) link.    With this type of link, the responder has a link table entry that tells it to listen and respond to commands sent to a specific group/scene ID.  Multiple responders can listen for the same group broadcast.   There can be multiple controllers and multiple responders configured for a single group/scene ID.

The ISY will do some magic behind the scenes when creating scenes to make sure everything it knows about is properly linked as it can get pretty complicated.

So if you want the two switches and the ISY to all work together as a group, you'd create a scene with the ISY and add both switches as both responders and controllers.   Then the ISY would update the link tables so that everything works as you'd expect.  Sending a scene command from one switch will go to both the other switch and to the ISY.  Scene commands from the ISY will got to both switches.  In all cases, the ISY should be able to track the status of both switches.

Now the ISY expects to be the only thing that controls those switches.   As you've noticed, adding links to the switches that the ISY doesn't know about, means the ISY doesn't see everything that's happening on the Insteon network and then isn't able to track all the device status.   There's no easy/good way to deal with this.  You can manually add entries to the various link tables and probably get things working the way you want, but the ISY may get confused and may overwrite those entries since they won't match what it thinks the tables should look like.

You're probably better off changing you're application to interact with the ISY via it's API to control devices instead of trying to use a separate PLM.

[mjrush]

I think you need to link the devices by creating a scene with the ISY994.  If you link the devices using the paddles on the devices, the ISY994 doesn't know what is linked.  I hope I got this correct.  I don't know if it's  possible to import links.

[Guy Lavoie]

46 minutes ago, bpwwer said:

1- So if you want the two switches and the ISY to all work together as a group, you'd create a scene with the ISY and add both switches as both responders and controllers. 

2- Now the ISY expects to be the only thing that controls those switches.   

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).

[paulbates]

48 minutes ago, mjrush said:

I think you need to link the devices by creating a scene with the ISY994.  If you link the devices using the paddles on the devices, the ISY994 doesn't know what is linked.  I hope I got this correct.  I don't know if it's  possible to import links.

There's a way to do it, you can ask the isy to look for links and include them, rather than delete links. It will "crawl" the insteon network for devices related to the device you're adding.

My experience trying this across several home automation system migrations is that it's better to start from scratch, adding the devices to the isy and delete existing links. Then build scenes from the isy

[Guy Lavoie]

4 minutes ago, paulbates said:

There's a way to do it, you can ask the isy to look for links and include them, rather than delete links. It will "crawl" the insteon network for devices related to the device you're adding.

 

Interesting. How would I go about launching that?

[paulbates]

When you add an insteon device, you get an option pop-up, to "delete existing links" or (I forget the other terms) include include links, something like that.

Like I tried to say above, that didn't usually work out for me and I rebuilt my insteon from scratch

[bpwwer]

1 hour ago, Guy Lavoie said:

Interesting. How would I go about launching that?

when you add a new device in the ISY you can either clear the device's link table or import the links from the device.

1 hour ago, Guy Lavoie said:

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).

I think the Insteon protocol is capable of doing what you want, the problem isn't the protocol, it's the ISY.  The ISY's software tends to assume that it is the owner of all device link tables so if something else starts modifying those link tables, then you could run into trouble.  

Ideally, you'd add the 2412n to the ISY and then let it manage that link table as well, but (you'll have to verify) I don't think you can add it.  At least last time I checked, you weren't able to add PLM's as devices to the ISY.

[paulbates]

2 hours ago, bpwwer said:

Ideally, you'd add the 2412n to the ISY and then let it manage that link table as well, but (you'll have to verify) I don't think you can add it.  At least last time I checked, you weren't able to add PLM's as devices to the ISY you Thanks that's th

That's correct, you can not / should not add the plm as a device to the isy. Also the 2412n is out of production/support for a number of years and I believe some newer Insteon. devices will not be supported by it. It's not dual band and I don't believe it supports i2 or i2cs Insteon protocols

Edited August 11 by paulbates

[Guy Lavoie]

19 minutes ago, bpwwer said:

1- when you add a new device in the ISY you can either clear the device's link table or import the links from the device.

2- Ideally, you'd add the 2412n to the ISY and then let it manage that link table as well, but (you'll have to verify) I don't think you can add it.  At least last time I checked, you weren't able to add PLM's as devices to the ISY.

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!

Edited August 10 by Guy Lavoie

[Guy Lavoie]

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.
 

[bpwwer]

19 minutes ago, Guy Lavoie said:

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.

If you're going to do that, why not just have your program use a REST command to set the device (switch and/or scene) directly.  No need to involve the 2412n at all.

[Guy Lavoie]

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.

[Brian H]

This may give you some information  on Insteon. http://cache.insteon.com/developer/developer-guide-022009-en.pdf

There  are many archived Insteon information here.  https://github.com/pyinsteon/pyinsteon/commit/2533494a8b13b30b2d0938c9a18afe782b740410

Just be aware that the 2412N has a history of failing.

[Ross]

@Guy Lavoie It seems that everything you want to do can be accomplished with the ISY - including Alexa integration.  I feel you're making things harder on yourself by trying to keep the 2412N in the mix.

Also, the ISY has been deprecated and we now have the EISY.  The ISY still works (that's what I use), but if you're going to "start from scratch", you may just want to start with the EISY.

Good luck,

Ross

[Guy Lavoie]

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.

[Brian H]

Two more papers that may help.

I also started in X10. One point that sometimes makes a difference. Some X10 repeaters. See the end part of an Insteon message as an X10 message. Falsely sending a X10 message back on the power lines.

 

insteoncomparedV2.pdf insteondetailsV2.pdf

Edited August 11 by Brian H
Add something

[Guy Lavoie]

Just now, Brian H said:

Two more papers that may help.

 

insteoncomparedV2.pdf 868.05 kB · 0 downloads insteondetailsV2.pdf 1.52 MB · 0 downloads

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

[bpwwer]

Having all the background helps with understanding what you're trying to do.   Typically, when someone has an ISY, that ISY is the what will be managing all the Insteon devices, that is what it was designed to do.

So manually trying to maintain link tables when you have an ISY seems counter-intuitive without all the background.

I too, messed around with writing my own software to manage Insteon links when it first came out and stopped once I had an ISY to manage them.   My software is still available here: www.bobsplace.com/ilinks/ but good luck getting anything working on a modern system.

Sounds like you now have enough information to move forward.   Keep us updated on your progress, I'd like to know how it all works out.

[Guy Lavoie]

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.

[bpwwer]

You should be able to view the device link tables and the PLM link table from the ISY.  

Right click on a device select "Diagnostics" and then show device link table or show isy link table. the former queries the device and the later shows the ISY's internal copy.

[Brian H]

If you linked the two switches with the Set Button and then added them to the ISY994i. You may have issues. As the ISY994i should always do all the linking. So it has the correct link information in it. Other wise it may cause broken and half links but I believe it maybe possible. I never tried and always used my ISY994i to do everything.

Links done by your 2412N may also not be properly in your ISY994i/2413S PLM setup.

The UDI WIKI has much good information in in. The ISY Cookbook is a big help along with the other helpful information and experienced users here.

https://wiki.universal-devices.com/index.php?title=Main_Page

 

Edited August 12 by Brian H
Add something

[lilyoyo1]

12 hours ago, Guy Lavoie said:

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.

You need to decide on 1 controller and 1 method for that controller otherwise you will continue to face the issues you are having.

It's akin to having multiple bosses at a job that issuing commands but none of the bosses know about each other and what each other are doing. If your software is doing what you need, then you should stick with that and code for everything else that you want. Otherwise, I'd look at the eisy and portal subscription as an investment that allows you to grow your system exactly the way you want it to be.