Guy Lavoie

Yup, count me among the healed! A big thanks to Michel for such a quick fix, and over a weekend too.

The rising body count indicates that this is a pretty fundamental issue, and should (I said should...) bring a quick fix.

Was an IoX update installed a few days ago? Look at these forum threads:

Looks like our exclusive 5.8.4_1 club is growing.

Given that you upgraded on Oct 3rd, I'm just wondering if you're getting the same problem I'm having, after an update notification appeared and I installed it, at around noon on Oct 3rd. Run this command: https://eisy.local:8443/WEB/sysconfig.txt And scroll down to the isy version. Are you seeing 5.8.4 or 5.8.4_1 ? I had it go from 5.8.4 to 5.8.4_1 and have been having several problems since.

Ok just tried all that. Cleared java cache, reinstalled launcher. Same problem. If I try to turn on a X10 device, I get a window that says: Socket Open Failed java.net.ConnectException: Connection refused: no further information Then about a minute later, another window pops up asking me to log into admin again, asking for user id and password. Looks like I'm really stuck. The origin of that 5.8.4_1 update is really mysterious. It popped up as a "needed update" when I launched UD mobile on Thursday, at the time you see the update. I'm guessing that this is the probable source of my problems, and I wonder why I'm the only one who got this update. Is there a provision to roll back updates? I haven't found anything.

If you can construct multiline URLs, the better way is to encode the username and password as a base 64 value, and include it as a parameter. Browsers do this internally. It looks like this: GET /rest/programs/0009/runThen HTTP/1.0 Host: 192.168.160.31:8080 Authorization: YWRtaW46YWRtaW4= That authorization value is the result of encoding "admin:admin" You can encode your own userid:password here https://www.base64encode.net/

You can encode the username and password into the http GET string, like this: http://admin:<password>@192.168.160.31:8080/rest/programs/0009/runThen replace <password> with the actual password

Thanks guys. I'm getting these numbers: UDX 3.5.8 Version : 5.8.4_1 Installed on : Thu Oct 3 12:52:59 2024 EDT (it's the "_1" that caught my eye when the upgrade notification appeared, glad it wasn't just my imagination...) Pg3X 3.2.27 If I just leave the admin console running and go away, it's frozen when I return an hour later. I have to kill it using the windows task manager.

After a while, the admin console just logs me out, saying IoX restarted. Any hints?

This is a strange problem that showed up yesterday evening. I can't say if it's related to the minor IoX update that was also released and installed yesterday. So far it appears like this: 1- I get a java socket connection error if I try to send on/off commands to a X10 device. Only the first time. Then it just seems to ignore the commands. But commands to Insteon devices works fine. 2- After the above problem occurs, the following admin console top level choices no longer work: Link Management, Tools, and Help. 3- If I click on Network or IoX from the Main menu, the device list is blank. But I can still view individual devices ok. As part of troubleshooting this, I installed the latest Java update, and replaced the PLM (following the eisy power off first procedure, etc). That all worked fine, but the problem remains the same. It all seems ok until I try to send a X10 command. Closing the admin console and logging back in "fixes" items 2 and 3 above, as long as I don't try to send a X10 command. The same thing seems to happen if I try to send a X10 command by a program (by setting a test variable to trigger it).

Quick question: do Polisy and Eisy run the same version of unix? Would the plugin development environment, paths, etc be the same?

Well as discussed by myself and others, scene "status" is a bit of a fuzzy thing. A scene is a macro command, setting one or more devices to a list of preprogrammed conditions. Nothing prevents these devices from then being individually controlled after that. UD mobile has an interesting take on scenes, displaying the "level" of a scene based on the percentage of how many of the devices are on. If you really want to track the individual devices, then you can always do it with a program, as some have been doing. But I think that for most of us, we see scenes as control events, not statuses.

Go into Polyglot, select the Virtual plugin, then click on "Configuration". Scroll to the bottom, where you can enter parameters. I used the example given, entering "78" for the key, and "switch" for the value. You can create several (click on "add custom parameter"). Save changes and you're done. As explained in the instructions at the top, you might need to log out of the admin console and then back in to see the new virtual devices.

When you defined the virtual device(s) (key and value) in the custom configuration parameters, what did you enter as a value? I used "switch".

If you're at the main device list and you press on the + sign at the top right, do you see a "New Folder" option?

Well I prefer to see scenes as a control event (trigger), not as a status. ie: launching a macro. Homes aren't static environments. In fact the program editor would need to offer conditional scene commands only under the "control" condition. Having it available in programs just allows more possibilities, some of which could also involve wait statements, such as stepping through a sequence of IR commands to turn on a home theater. Arming an alarm system could also be a scene, that includes shutting off or disabling things. Lots of possibilities.

Well one workaround is if you have otherwise unused physical modules. For example I have two Lamplincs (that I obtained when buying a lot of used devices) with nothing plugged into them. They're placed to act as signal boosters/bridges. You can add those to a scene just so that your ISY994 can track their status as triggers. That's the thing with Insteon, you need to turn on "something" by establishing a scene link. The aptly named "Virtual" plugin just makes that easier if you have no spare devices.

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.