jtara92101

No firewall software. I did a manual download to my Linux box, and did the upgrade from there. The only thing between the isy99 and the Linux box is a Gig-E switch, and no firewall on the Linux box. I do have a tap port set-up on the switch, so I could take a look with Wireshark if need be. Not sure what you mean by "use https". I'm doing a local upgrade, it prompts for the file location. Should I attempt automatic upgrade? Yes, it's a pretty old unit. There's no physical serial # on the unit. Can you tell from the UUID? File System Status says total 125MB, used 14MB, bad 0B, free 79MB. Any thing else I should look at?

Said installed several files, got to 8%, then: Upgrade Failed: Failed uploading file (reported written size is invalid) Socket Timeout Error

OK, what I wound up doing was creating 3 new scenes: LR A LED Mutuals, LR B LED Mutuals, LR C LED Mutuals. I made the LEDs that have to be turned off when a given scene is turned on responders in the corresponding scene. So, LR A LED Mutuals has the B and C switches as responders, etc. In Roomie Remote, I turn the Theater scene (corresponding to the A button) on, and the LR A LED Mutuals scene off. (I could just as well have created a program to do this, and have Roomie run the program.) The three LEDs come on briefly, then the two unwanted ones go out. BTW, I am not setting mutual exclusion using "Buttons Grouping" because when you press that button, the ISY pops up a dire warning that it's a bad idea, and that you should accomplish button groups through scenes by adjusting respective on levels. But when you do that, you can't set the on level of the LED in the scene itself - only in the attributes for the buttons. That is, for the LR Theater scene, buttons B and C do NOT appear in the scene. But if you look at the LR A Theater button under the LR Theater scene, you see all of the responders to the scene (which you would typically "copy scene attributes from LR Theater") and AS WELL you will see the B and C LEDs as responders. If you set the levels to 0, then they will be off when the A button is on. But it only works when you push the button. It's terribly confusing, but from what I gather, not UDI's fault. At least I have a work-around.

(Sorry, I should have posted this in questions and answers. Moderator: please feel free to move.) ??? When I press one of A, B, and C to turn ON the corresponding scene, it DOES turn OFF the other two LEDs. This is because I have set the levels to 0 in the links from the button. The other LEDs only appear in the links for the button, though, NOT in the scene itself. So, for A, you do not see B and C in the scene itself. However, when you go down to button A, you will see B and see as responders, and set the levels to 0 there. However, if I turn ON the SAME scene from the isy- either manually from the console or from a program - (not from the button itself), the the other LEDs do NOT turn off. I need to know how to turn the other LEDs off when I set the scene on from the ISY, not from the button. It's a similar situation to a 3-day circuit, right? A 3-way circuit works as you would expect when you use the buttons, but it gets complicated if you want to turn the scene on or off from a program.

I once knew the answer to this question, but I'm afraid it's been quite a while since I last had to do this, and I wasn't able to find the answer here or in the documentation. I have a keypad in my living room where the A, B, and C buttons are assiged as follows: A: Theatre B. Snack C. Mood The A, B, C buttons are mutually-exclusive. I've made them mutually-exclusive as recommended by making the "other" buttons responders to each scene. (e.g. B and C are responders to A.) I know there is some Insteon issue where the B and C buttons won't appear in the attributes for the scene itself - only for the A button. You have to set the levels for B and C to 0 on the list of responders for the A button. etc. This all works fine - when I use the buttons. But I also want to activate scenes from my Roomie Remote on my iPad. This activates a scene on the isy99. e.g. it's the same as me going in on the console and activating the scene. When I do this, the LED status lights do not update properly. The scenes activate correctly, (lamps) but the LED status lights don't. How do I make the LED lights update when I activate the scene from the ISY? Do I need a program?

Roomie is fairly new. I think it was released in the past couple of months. I tried to make sense of iRule. After a couple of days of noodling, I finally managed to turn a light on and off. And people were reporting in forums that it "only took a week" to set-up their systems. I had Roomie up and running for my system in a couple of hours. It doesn't have the layout flexibility of iRule. You can add your own buttons, but you can't add your own images, define the exact layout, etc. I suspect that will be coming eventually. It's more like a Logitech remote than iRule. And that's fortunately easy to correct. Just turn it on/off manually to sync the state back. Wouldn't work for the cable box, since it's a DVR model. So, it might power-up to record a show. (Though the remote power state is still OFF...) I've read a lot of comments online recommending just leaving it on all the time, saying there isn't much difference in consumption between on and off. I think you still save significant power turning it off. If you're recording, of course, you aren't saving any more than some front panel lights and the HDMI driver. However, that might be a solution for my Samsung Bluray, which also doesn't have discrete on/off commands. Back when I was in college, somebody rigged-up a sensor taped to a lamp on an IBM 360 mainframe console. I forget what was hooked-up to the sensor, but they wanted to know when a certain light came on... Does Insteon have a light sensor module? Or some combo of sensor and input module that could be used to detect if a front-panel light is on or off?

This is a duplicate, sorry. Can an admin please delete? Thanks.

Apparently I was wrong: programs do NOT have to be in the root folder to run them from the REST API. I just moved them back into the A/V folder, and they still work. You do need to use the recursive option to LIST them, however. I was looking at the Wiki documentation. I was unaware that there was any additional documentation. The Wiki documentation on REST is very thin. Where do I get the WSDK?

Some IR-controlled devices (notoriously, Scientific-Atlanta cable boxes) only have a power toggle. They do not have "discrete" on and off commands. This wrecks havoc when using activity-based remotes. (I'm using Roomie Remote on my iPad). Remote control solutions that use a central server can keep track of this on the server for multiple remotes. Single remote solutions can/could track power state, assuming they are the only remote used, but often don't or don't in all circumstances. I've seen solutions involving a little server running on a PC, but when you have an isy99, that seems overkill, doesn't it? My configuration: iTach ip2IR (Ethernet to IR adapter) with an emitter on my Scientific-Atlanta 8240HDC cable box. isy99 also on my Ethernet. Roomie Remote on my iPad. Network Module installed on the isy99. First, I created a network resource to toggle the 8240 power, 8240HDC.Toggle: TCP, (host address), Port 4998, Timeout 500mSec, C Escaped. The body is my IR command to the IP2IR: sendir,1:2,1,58000,1,1,192,192,48,145,48,145,48,48,48,145,48,145,48,145,48,145,48,145,48,48,48,48, 48,48,48,48,48,48,48,145,48,48,48,48,48,48,48,48,48,48,48,145,48,145,48,145,48,2146\r\n This sends the power toggle code for the 8240. Of course, you should substitute this with the correct code if you have a different device. Then, I set-up three disabled programs. They have to be disabled, you only want them to run when they are explicitly executed. 8240.On? is an empty program. It's used to keep track of the state of the cable box. It's poorly documented, but running the "then" of a program sets it's state to true, running the "else" sets it's state to false. So, you can use an empty program to track an on/off state. 8240.On If Program '8240.On?' is False Then Run Program '8240.On? (Then Path) Resource '8240HDC.Toggle' Else - No Actions 8240.Off If Program '8240.On? is True Then Run Program '8240.On? (Else Path) Resource '8240HDC.Toggle' Else - No Actions Now you have discrete On/Off commands for the cable box! 8240On first checks to see if the cable box is already on (state of 8240On? is true). If it is, it does nothing. If it's off, then it sends a toggle. 8240Off does vice-versa. To integrate this into my remote (Roomie Remote on iPad) I used URL commands in the remote: http://userid:password@10.0.1.5/rest/pr ... 002e/runIf (for on) (substitute your ISY address for 10.0.1.5) You first have to lookup the hex codes for the programs using: http://10.0.1.5/rest/programs In my case 002e is 8240.On, and 002f is 8240.Off. http://10.0.1.5 Edit: the 8240.On and 8240.Off programs MUST be in the root folder of your programs, or they will not be seen by the REST interface!

Some IR-controlled devices (notoriously, Scientific-Atlanta cable boxes) only have a power toggle. They do not have "discrete" on and off commands. This wrecks havoc when using activity-based remotes. (I'm using Roomie Remote on my iPad). Remote control solutions that use a central server can keep track of this on the server for multiple remotes. Single remote solutions can/could track power state, assuming they are the only remote used, but often don't or don't in all circumstances. I've seen solutions involving a little server running on a PC, but when you have an isy99, that seems overkill, doesn't it? My configuration: iTach ip2IR (Ethernet to IR adapter) with an emitter on my Scientific-Atlanta 8240HDC cable box. isy99 also on my Ethernet. Roomie Remote on my iPad. Network Module installed on the isy99. First, I created a network resource to toggle the 8240 power, 8240HDC.Toggle: TCP, (host address), Port 4998, Timeout 500mSec, C Escaped. The body is my IR command to the IP2IR: sendir,1:2,1,58000,1,1,192,192,48,145,48,145,48,48,48,145,48,145,48,145,48,145,48,145,48,48,48,48, 48,48,48,48,48,48,48,145,48,48,48,48,48,48,48,48,48,48,48,145,48,145,48,145,48,2146\r\n This sends the power toggle code for the 8240. Of course, you should substitute this with the correct code if you have a different device. Then, I set-up three disabled programs. They have to be disabled, you only want them to run when they are explicitly executed. 8240.On? is an empty program. It's used to keep track of the state of the cable box. It's poorly documented, but running the "then" of a program sets it's state to true, running the "else" sets it's state to false. So, you can use an empty program to track an on/off state. 8240.On If Program '8240.On?' is False Then Run Program '8240.On? (Then Path) Resource '8240HDC.Toggle' Else - No Actions 8240.Off If Program '8240.On? is True Then Run Program '8240.On? (Else Path) Resource '8240HDC.Toggle' Else - No Actions Now you have discrete On/Off commands for the cable box! 8240On first checks to see if the cable box is already on (state of 8240On? is true). If it is, it does nothing. If it's off, then it sends a toggle. 8240Off does vice-versa. To integrate this into my remote (Roomie Remote on iPad) I used URL commands in the remote: http://userid:password@10.0.1.5/rest/pr ... 002e/runIf (for on) (substitute your ISY address for 10.0.1.5) You first have to lookup the hex codes for the programs using: http://10.0.1.5/rest/programs In my case 002e is 8240.On, and 002f is 8240.Off. http://10.0.1.5

How do I do that? Edit: OK, figured it out. I need this: http://userid:password@10.0.1.5/rest/pr ... 002e/runIf I programed it into my Roomie Remote on my iPad, and it works great! No more shutting off the cable box as a side-effect of starting the TV activity when the cable box is already on. (As when Roomie has been closed - I don't know why it doesn't remember state when it closes - it's reasonable to assume that if the remote closes, that everything is still the same when you start it back up...) Ah, I discovered another undocumented or poorly documented "feature" of the REST interface: apparently programs MUST be at the root level of the program folders, or they are not seen by the REST interface. If you list programs with REST, it only shows the programs in the root. Amazing how this stuff goes for years with no documentation...

I can't seem to run a program through the REST interface? What might I be doing wrong? I've written and tested a little set of programs to essentially create a discrete on/off for my cable box, which only has a power toggle. It uses the networking module to send a command to an iTach Ip2IR which has an emitter on the cable box. I've tested this on the administrative console, and it works as expected. My problem is that the REST interface just returns this: 404 My command is: http://10.0.1.5/rest/programs/8240On/runIf I am able to use the REST interface to get status, etc. I know I've used it in the past to do simple things like turn lights on and off. Clearly, I'm missing some detail on running programs. BTW, the program is in a folder (A/V), but that shouldn't matter, right? Because when you run programs from within a program, it doesn't need the folder path. Maybe I need to include the path if I'm calling it from REST? (No, that doesn't seem to be the case, because I just moved the program out of the folder, and I still have the same problem.) Edit: Apparently, you need to refer to programs using a hex code? I'm just guessing here. I listed my programs using the REST interface, and each has a hex ID. This seems to match the (sparing) documentation. This is horribly documented!

Don't you think, though, that you should at least document the fact that they shouldn't be touched?! Maybe just something like "don't change this parameter unless you have been instructed-to by tech support?" Could you please answer my question, and tell me what the default value is for Delay? I think I may have altered this in the past, but since I don't know the default value, I have no way to know if I have changed it or what the default value is that I should change it back to if I have changed it. I was having a great deal of communication problems, and I may have changed this in desperation. I moved an RF link, and that seems to have largely solved the problems, and now I want to set all the parameters back to defaults. I changed retries back to the default of 2, but I need to make sure everything else is back to default values.

The Configure Delay command in the Telnet console is undocumented in both the Wiki and the PDF manual. (As well, this documentation is out of date in that it includes settings that are no longer supported.) As well, the console doesn't show what the default is. (It does for some commands, but not for CD and some others.) So, if you've changed the delay, you'd have no idea what to set it back to to go back to default. What is the default value? Can the software be updated at some point to show the default value? Can somebody get the Wiki and PDF updated? Thanks.

Thanks. I think something happened with the PLM. Not sure just what, but unplugging and replugging the PLM seems to be what fixed the problem. Coincidently, I had stacked-up error messages on the Admin Console, probably as a result of the PLM problem.

Over the past couple of days, the reliability of my Insteon network slowly degraded. First, I noticed the bathroom fans weren't working (they work off an isy program). Then, some scenes stopped working reliably. It got to the point where my HOME and AWAY scenes would only turn on/off 1 or 2 lights.... and then there were none! I went to the admin console, which I'd left open, since I've been making some changes recently. I had to dismiss several error messages. Things were hinky with the admin console, so I decided to reset the ISY. When I reset it, I couldn't get back into the admin console. (no connection). I was able to ping the ISY, but couldn't get the web interface or the admin console. Finally, I unplugged and re-plugged the PLM and reset the ISY again. I was finally able to get in, and - magically - everything worked again on the network. I think what happened is that at some point some error occurred that the admin console wanted to notify me about. That produced a dialog box that requires user interaction (press OK). I can only speculate that this blocked ISY programs somehow, and/or perhaps commands stacked-up in a queue in the ISY until they overflowed, creating chaos. What I can't explain is how this interfered with my large HOME/AWAY scenes. While I have programs that run when the HOME or AWAY buttons are pushed, the major lifting is done by scenes. That is, for example, the AWAY button is linked to a scene that shuts off every light in the house. Additionally there is a program that does things that can't be done with that scene. So, the BASIC functionality of the HOME/AWAY buttons (turn off the lights leaving, turn on an entry path arriving) should work with or without the ISY. I can only speculate that whatever confuzzled state the ISY was in created a flood of messages on the Insteon network. Unfortunately, I didn't think to glance at the activity lights on the ISY or RF bridges. (Edit: thinking now that this is because the devices were trying to communicate with the PLM, creating a lot of congestion. Perhaps the ISY blockage somehow messed-up the PLM. This is consistent with the need to reset the PLM to get the network working again.) "heads-up" to others that it may not be a good idea to leave an Admin console open for an extended period of time. Perhaps UD can consider an alternative to these blocking message boxes and/or do some troubleshooting to see if they can be made more benign if not responded-to by an absent admin.

In English, please? Since I'm an engineer, I think I can guess, given other symptoms I've seen. Would the Admin console be a "subscriber"? See my separate post about leaving the Admin console open...

What does this mean? [-5011] Change of state failed: SID not found [uuid]

I am having the same problem as the original poster. I think others have misunderstood just what he is reporting. I have an expired certificate. When I attempted to create a new one, I get a new browser window. The title of the window is "My ISY Certificate Manager". The problem is that the Java applet never opens. I get a screen that says "Universal Devices" "Please keep this window Open". There's a gray box, and the status bar says "Start: applet not initialized". It just sits there forever with the gray box. Note that I'm running the stand-alone desktop Java application, admin.jnlp. So, I'm kinda surprised that it opened a browser window. I am NOT accessing it remotely, but from my local LAN. The problem is that the certificate manager never starts.

Not sure just when you want it to query the thermostat. I'll experiment, but not sure where to put the Query. After setting Program Auto? The problem is not GETTING set-points from the thermostat. It's that when it is switched into PROGRAM AUTO mode by the isy, it doesn't recall the stored set-points. It just keeps any set-points that were previously set by the isy. That is, the problem is NOT that the ISY is seeing the wrong set-points - it's that they are never recalled from the stored settings when going to PROGRAM AUTO. When switching to PROGRAM AUTO manually, the set-points are recalled correctly. EDIT: A Query after switching to PROGRAM AUTO using an ISY program returns the set-points previously set by the isy - NOT the set-points programmed for the time period. If I manually cycle through the modes using the MODE button, the correct set-points are restored, and in fact the correct set-points appear in the admin console, without a need to query. I'm guessing the problem here is the Smarthome adapter. It simply does not do the same thing when selecting the mode through the interface as when you actually hit the MODE button.

Unfortunately, using a scene isn't going to help anything. There's actually NO WAY to switch to PROGRAM AUTO mode with a scene WITHOUT setting a heat and cool setpoint! It looks like there might be a fundamental disconnect between how the thermostat works (in PROGRAM AUTO) and the isy interface. PROGRAM AUTO and settings setpoints = DOES NOT COMPUTE!

The problem is that when I use an isy program to change the thermostat to AUTO PROGRAM mode, after previously having changed the setpoints while in AUTO, HEAT, or COOL modes, it does not switch to the programmed setpoints. The display shows that it is in AUTO PROGRAM, and shows the current time period (morning, day, evening, night). But the setpoints are those that were previously set by the program. In order to recall the setpoints, I have to manually cycle through the modes using the MODE button until it is in AUTO PROGRAM again. Then, it will recall the correct setpoints. The isy mode change is obviously NOT doing exactly the same thing as using the MODE button! I just checked to see if the thermostat exhibits this behavior when being controlled manually: it does not. If it put it in AUTO and bump the setpoint a few degrees, then hit the MODE button to change it to AUTO PROGRAM, it does get the correct set-point that was previously programmed into the current time period. I had read that on this forum. So, I put 2 second delays in-between each setting, but that didn't help. I will try the "scene" technique, though - thanks! Now, there is an obvious work-around: I would need to duplicate the schedule in an isy program, and change the setpoints to those for the current schedule. I guess that should not be done if it's say, less than 10 minutes to a schedule change (because the clocks won't be perfectly in sync. So, if less than 10 minutes, just let the pending time-period change handle the set-point change.) I could also use a similar program to "advance" to the next time period. That is, let's say it is evening, and I am going to bed early. I could have the "goodnight" program change the setpoints to the "night" settings. Eventually, the "night" program will come along and take over (with the same set-points). I think this bug has probably been missed because most people are managing the thermostat completely from the isy, and not using AUTO PROGRAM.

I'm having a problem using a Venstar T-1800 with "home" and "away" programs. I want to use the Venstar's built-in "Program Auto" mode when I am NOT away. Rather than setting a daily schedule to set-back the thermostat during the day (I work at home) I've set it up for "comfort". A bit warmer in the morning for waking/shower, etc. But set-back for non-occupancy is handled by the "away" program. The away part works fine. The program switches the thermostat to AUTO mode, then sets the cool setpoint to 90 and heat setpoint to 50. Home is where I have the problem. I've tried every possible order and delays, and the setpoint is "sticky" when setting the mode to Program Auto. First, I thought I ought to reset the default AUTO temperature. That is, I don't want to leave it at 50/90, in case I might want to manually switch to AUTO mode at the thermostat, I'd want a reasonable default value for setpoints. (So, restore AUTO to the previously-programmed setting.) So, I tried going to AUTO (in case it was changed manually), change the setpoints to 68/78, then switch to PROGRAM AUTO. But the setpoints remain 68/78, not the appropriate PROGRAM AUTO setpoints! If I DON'T reprogram the setpoints to 68/78, then it's even worse - they will remain 50/90, even though the thermostat DOES change to PROGRAM AUTO mode, and shows the correct time period. Manually hitting the MODE button on the thermostat so that it cycles back around to PROGRAM AUTO corrects the problem - it changes the setpoints to those for the current time period. I tried cycling the mode through OFF in the program (AUTO, change setpoints to 68/78 to reset the AUTO setpoints, OFF, PROGRAM AUTO) and that still doesn't fix it - the setpoints remain 68/78. The only way I can get it to go to PROGRAM AUTO with the correct setpoints from the thermostat's program is to manually use the MODE button.

Thanks - I was able to replace all of my V35 Switchlincs. It didn't help that the Wiki was down when I started this (it seems to be down often lately). Sure wish they would just document everything in the manual! I think as BrianH suggested, the problem might have been the remaining V.35 devices making it difficult to communicate. Probably a good idea to disable all them when you start the process. What happened on the first one is that the Administrator got "stuck" with the little 101010 tags pending and it never did reboot itself. But it was OK after a manual reboot. It seems it DID do the replacement, but somehow got out of sync with the Administrator application.

Thanks - I was able to replace all of my V35 Switchlincs. It didn't help that the Wiki was down when I started this (it seems to be down often lately). Sure wish they would just document everything in the manual! I think as BrianH suggested, the problem might have been the remaining V.35 devices making it difficult to communicate. Probably a good idea to disable all them when you start the process. What happened on the first one is that the Administrator got "stuck" with the little 101010 tags pending and it never did reboot itself. But it was OK after a manual reboot. It seems it DID do the replacement, but somehow got out of sync with the Administrator application.