Guy Lavoie

This has a happy ending! From reading and searching, I discovered the plugin called "Virtual" which seems to be exactly there for this purpose. This forum reply will also help anyone looking for this functionality in the future. Virtual allows you to create virtual switches (and other devices) which can then be added as responders to scenes. Turn on a scene and the virtual switch turns on too, and same for off. Then you can use the virtual device in a IF statement just like an actual device. Because the device only exists as a responder for the scene, no need to "guess" the status of several devices as suggested earlier. Having this capability helps maintain the optimum failure mode for an Insteon setup, since Insteon is peer to peer. So if the eisy/PLM/whatever ever fails, the generic scene will still function, and only the additional functionality provided by the eisy will be lost. This is different than relying on eisy to launch the scene just because you also want added functionality in a program.

If you have access to the IP command protocol, you should be able to control it using the network module.

Well, just add more non-Insteon functionality when a scene is triggered. For sure, scenes don't have states, but they do have on/off control events, which is what I'd like to be able to test for. The Eisy is in fact executing a hidden program of sorts when it sees the scene control command (both on and off) and controls the zwave device as I mentioned in my test above. I looks like the design philosophy for multiple action events is to have your initial event trigger a program, which can then initiate a scene along with other actions, so it's always possible to work around it that way. It's just that some types of macros (especially those that involve lighting) are more easily thought of in terms of triggering a scene. It might be because I'm just getting familiarized with keypadlincs at the moment!

Yes, if it's a device that's only ever controlled by a scene, as discussed above.

Oh yes, that and other test/troubleshooting features are really handy, like the ability to run the "then" portion of a program by itself. Well thought out. Back to triggering on scenes... I do notice that it's possible to add non-Insteon devices to scenes. I see it for X10 and Zwave devices. I'm only able to add a X10 device as a controller (adding as a responder tries to set it and gives an error). I haven't test it, but this is something we could also already do (trigger a scene command) with a program. More interestingly, if I add a Zwave device to a scene, it allows adding it as a responder, and does respond to the scene on and off commands. We know that Insteon cannot talk to Zwave... so the Eisy is definitely receiving the scene command and is able to do something in response such as control a Zwave device... but not trigger a program. Could this be added as a new feature?

Yes, that's the "guess from responder's status" method, which might be good enough if the devices are only set to those levels by the scene. I'm also thinking of using a few spare lamp modules without loads that are mostly strategically placed as signal repeaters/bridges for that purpose. Enlist one into a scene and look for it's status change as a program trigger. It would still be interesting to know why direct detection of scene commands isn't or can't be done.

I'm a bit surprised that there seems to be no way to detect scene commands as a way to trigger programs. This would be handy to have the controller "participate" in a scene and control additional, non Insteon devices when a scene command is initiated by a device. Is this a limitation of Insteon (ie: can't have the PLM as a responder)? Also, is there a workaround I could reasonably use? One possibility would be to detect the status of a device that is only controlled by a scene, and never as an individual device. But that isn't always the case.

Another victim of "found the solution right after posting on the forum about it". So I'm not alone!

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.

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.