Guy Lavoie

Ah, using the Custom Configuration Parameter worked. Now back in business! I kind of prefer things that are spelled out instead of having automatic discovery, which can be finicky. Thanks!

I'm giving this plugin a try. It was working well for about 2 weeks. Now not seeing the thermostats (I have two). Looking at the log file, It seemed to be trying to access them at their IP address which seems to have been changed, which is very possible because they were set up with DHCP. So now I set them to fixed IP addresses. Then I tried to rediscover them, restart the plugin, etc. No luck. Even deleted and reinstalled the plugin, but it's not detecting them. Is there something I need to erase to really start afresh? Thanks.

Well I don't think you can pair an Insteon remote with a non-Insteon device. But you should be able to create a program in your ISY controller to look for the remote button press, and then trigger any action that your ISY can do.

Chances are good that you would be able to use the triac out of an old X10 WS467 wall switch. Many of us have a box with several of those laying around, from our early automation days!

Well, that might be a usable workaround, if there is no other way. I'll just have to think about that. This is for the pool water temperature, which is a rather limited range of temperature values during the summer season when I want to know it. Here is the full story: I'm still new to the EISY world (just a few weeks) and I'm enjoying trying everything out. I have Venstar Colortouch thermostats, three of them in fact. One controls my HVAC, another one controls a blower to send heated air into my furnace return when my wood stove is hot enough, and the third one uses an external sensor that I sealed into a tube to measure the pool water temperature. Now Venstar has a nice phone app, online portal (much like UD) and an Alexa skill, and it all works great, but there is an annoying bug... The optional external temperature can be configured in various ways: to display the outside temperature (and use it in some control parameters, such as lock out the heat pump below certain temperatures), as an alternate control source for the thermostat, as an air return temperature reading, etc. The annoying bug is that when you ask Alexa for the current temperature, it always tells you the temperature of the thermostat's internal sensor, even if you configure the thermostat to use the external sensor instead for control, which ignores the internal sensor in that configuration. This is how my pool water temperature one is set up. So the thermostat's screen shows the correct water temperature, but Alexa gives me the useless internal sensor instead. I even reported the bug to Venstar in April, and they acknowledged it. But no fix in sight. Fast forward to today, where I'm trying out the Venstar plugin. Good news: it extracts both the internal and external temperature sensor readings, and sets them both to distinct variables. Now if I can just get Alexa to say the variable...

So close... I'm trying to have Alexa say the value of a variable. The closest I can get is to ask the percentage of the device (if I define it as a device set/lower/raise), which is awkward with you're not looking for percentages, such as a light level, temperature, etc. I tried words like "level", "setting", etc. Any magic way to get this working more intuitively and better?

It looks like what Goose66 is saying is that the program will retrigger (as we'd say about an electronic circuit), so any resulting sequences and timings are started over from the beginning.

It would help to know where you're located.

Has anyone ever replaced the triac on one of these? If so, do you have a triac part number? It looks like a regular TO-220 case. Just good stuff to know in case... It should be straightforward to drill out the rivet, unsolder it, and replace it.

As I often say, the best (mobile phone, browser, operating system, ha platform, etc) is the one you know best. As IndyMike said, check out their + and -, especially as experienced by real users, not vendor literature.

This discussion raises a good question: what happens if you restore a backup to a different ISY994i that doesn't have a module that the original had? Does the restore fail? For example, if I had the X10 module and I try to restore to a unit that doesn't have it, what happens in the programs?

This question kind of goes along with the ones I've been asking about links. I'll be following this thread.

Thanks for the responses guys. Well, scenes are next on my learning list anyways so I'll certainly check that out.

At worst, you might be able to turn it into a slave switch, if you have an otherwise good switch being used as a slave in a 3 way circuit somewhere else. Swap the switches and cap off the red load wire.

Wrapping up my Insteon link learning for the day, I checked out the links table for my test device and it looks consistent enough. The first link I see is the manual one I made with the 2412N, then the reciprocal links to and from the PLM connected to the ISY994i, followed by the manual link to a second switch (to create a 3 way circuit), then the manual link to the 2245-222 hub, and finally to a mini controller. As per the wiki, the ISY994i responder link is A2 and controller link (some are F2, others E2). The other 4 links, all done manually, appear as AA. So it appears that all manual links to devices other than the PLM are treated as the same, which would be good news. Now when you say that instead of manually linking two switches together to make a virtual 3 way circuit, that I should use the ISY994i, are you saying that there is a way to create actual links between devices (I haven't found where), or that I should be doing that as scenes? Thanks.

If the status on your controller appears to be correct but the load is always on, then that's a good indication that the control electronics survived, but the power triac didn't. That would usually be repairable.

If these devices have triacs in them, they could be blown, which often causes them to be shorted out and appear as being on constantly.

Well I'm not having issues. I'm just figuring out something that's new to me, and the possibilities are looking pretty good so far! I'm able to do what I want it to, once I understand it. Yes, the suggestions are more than welcome, and I think that once I have the ISY994i's link maintenance figured out, I'll be quite happy with it.

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!