Guy Lavoie

Yes it does. I tested it by adding the virtual switch as a responder to a simple "3 way" circuit scene. I press the slave switch to turn on the light, and the test program looking for the scene "on" command sets a variable. Now you can add anything to an Insteon initiated scene, allowing true macros. Imagine starting up your home theater, lighting and all, from a button on a keypadlinc or a mini remote. It all becomes possible. Or a good night routine that also locks the doors, etc.

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

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.

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.