rccoleman

I did the same with acetone-free nail polish remover (drug stores have both kinds, acetone and acetone-free), and it doesn't damage the buttons. It probably takes a little more effort, but I was pretty happy with the result. Add some clear PTouch labels and the buttons look great! Rob

I installed a new Elk keypad yesterday, enrolled it, and it's working fine. Unfortunately, if I go into the ISY admin console and refresh the Elk topology, the new keypad doesn't show up in Elk->Areas->All Areas->Keypads. I only see the two keypads that I had when I first set up Elk in my ISY. I do see the new zones that I've added periodically, so some of the topology is updating. Just not the keypads. It just looks like an informational display with no interactive components, so it's not that big a deal for me. I just thought that I'd mention it. Rob

Done - #8794. Thanks, Rob

I wonder if it's an OS X issue. I've launched the same Java app a bunch of times in a Windows VM under Parallels and the Elk bar has come up every time. If I close it in the VM and open it under OS X, I won't see the bar. When I go back to Windows and re-launch, it shows up. I deleted and reinstalled Java on OS X, but it doesn't seem to have helped. Edit: Nevermind. I have seen a missing Elk bar under Windows. Rob

Me neither. It either shows up when I launch the admin console or it doesn't. Each time I launch the admin console it seems to be random whether I'll get the Elk bar.

I was looking through your wiki and noticed the following on the page that describes the event viewer: The display level corresponds to the Debug level in the ISY Shell. The Event Viewer window displays the same information as is found in the Java Console, but without the necessity of telneting to ISY and using the DBG command in order to set the Debug level. I can tell Java to open enable logging and tracing and also to automatically open the event window. The ISY shell also seems to accept the "DBG" command, even though it's not in the menu. No matter what I do, I still can't get the same output that I see in the event viewer, and instead I get a bunch of Java-related messages. Some examples are: security: Missing Codebase manifest attribute for: http://isy.universal-devices.com/994i/4.4.3/insteon.jar security: Missing Application-Library-Allowable-Codebase manifest attribute for: http://isy.universal-devices.com/994i/4.4.3/insteon.jar security: Validate the certificate chain using CertPath API security: Missing Codebase manifest attribute for: http://isy.universal-devices.com/994i/4.4.3/insteon.jar security: Missing Application-Library-Allowable-Codebase manifest attribute for: http://isy.universal-devices.com/994i/4.4.3/insteon.jar security: Validate the certificate chain using CertPath API security: Missing Codebase manifest attribute for: http://isy.universal-devices.com/994i/4.4.3/insteon.jar security: Missing Application-Library-Allowable-Codebase manifest attribute for: http://isy.universal-devices.com/994i/4.4.3/insteon.jar Is there a way to use the Java console to see the messages that you need to see? I also connected a long Ethernet cable to take the wireless extender out of the picture, but the first few times I launched it, the bar still didn't show up. After quitting and launching a few more times, it eventually showed up. Rob

Yep. No Elk bar, but status for Insteon devices updates in near real time. Rob

No, if it doesn't show up when I first start the admin console, it never does. If I keep quitting and restarting the admin console, eventually it'll show up. Rob

Yeah, I realized that after posting. Is there any way to get to the events via telnet? There doesn't appear to be a "real" shell there, but more of a command processor. Or a way to log them somehow? Or a way to monitor the situation from the Elk? I'm rather new to this system and I'm not sure what options are available. Another potentially relevant point is that I don't have the luxury of an Ethernet connection to my alarm panel and my XEP is connected to a wireless extender. I'm seeing remarkably good throughput and ping times with no apparently packet drops, but I'll try to run a long Ethernet cable and see if it's more reliable. That would only be a temporary solution, though. Rob

I think that's a separate version of the Java app that's compatible with OS X 10.6, but the "mainline" version is compatible with all versions after that. I'm not using admin16.jnlp, but just admin.jnlp. Michel, feel free to correct me if I'm wrong. Rob

I'm running OS X 10.11.4 and I'm using the standalone java app and not launching it from a browser - is that what you mean? Both my UI and app version are the same - 4.4.3 RC. I made sure to update both a few weeks ago. Rob

Thanks, that's an approach that I hadn't considered. The problem is that the Burglar Alarm state and the zone violations may not occur simultaneously and the violation information is lost when the condition is reversed (someone opens and closes a door quickly, for instance). The sequence is always Violation->Entry Delay->Burglar Alarm (if not disarmed), so I think I could do something with your concept. Riffing on your idea, I think I could use one program per zone to set bits or separate zone integer variables, send the result as a notification when a burglar alarm occurs + reset the variables, and reset the variables if the system becomes disarmed. I wouldn't need any delays in this method because I'm just caching the information and regurgitating it later. The zone programs would only set bits (not clear them), so information wouldn't be lost if the condition changes later. This would only store and report zone numbers, and converting those numbers into zone names would require a bunch more programs and customer notifications, I think. Sometimes I feel like I'm swimming upstream In any case, thanks for the advice. For what it's worth, I can upgrade to the 5.0.x beta if this becomes easier there. From the 5.0 wiki page, it's not clear that it does, though. The more I think about it, the more I wonder if the ISY just isn't the best tool for this and I should look into ElkRP rules instead. Rob

Is what I'm asking here clear?

I don't have another PLM and ISY, so I'm not sure how to do that. I looked at the error log again and here's what it says around the time of the failures: Wed 2016/02/17 06:49:19 AM System -170001 [uDSockets] RSub:29 error:6 Wed 2016/02/17 06:49:24 AM System -170001 [uDSockets] RSub:29 error:6 Wed 2016/02/17 06:49:29 AM System -5012 85 Wed 2016/02/17 06:49:40 AM System -10011 n/a Wed 2016/02/17 06:50:09 AM System -170001 [uDSockets] RSub:29 error:6 Wed 2016/02/17 06:50:14 AM System -170001 [uDSockets] RSub:29 error:6 Wed 2016/02/17 06:50:19 AM System -5012 86 Wed 2016/02/17 06:56:40 AM System -170001 [HTTP:0-30-5] 192.168.1.203:54445->80 Wed 2016/02/17 06:56:40 AM System -170001 [HTTP:0-30]: POST[1]-->/services Wed 2016/02/17 06:56:40 AM System -170001 <s:Envelope><s:Body><u:GetReport xmlns:u="urn:u Wed 2016/02/17 07:00:02 AM System -170001 [HTTP:0-30-5] 192.168.1.203:54512->80 Wed 2016/02/17 07:00:02 AM System -170001 [HTTP:0-30]: POST[1]-->/services Wed 2016/02/17 07:00:02 AM System -170001 <s:Envelope><s:Body><u:GetErrorLog xmlns:u="urn Wed 2016/02/17 07:02:09 AM System -170001 [uDSockets] RSub:29 error:6 Wed 2016/02/17 07:02:14 AM System -170001 [uDSockets] RSub:29 error:6 Wed 2016/02/17 07:02:17 AM System -170001 [HTTP:0-30-5] 192.168.1.203:54602->80 Wed 2016/02/17 07:02:17 AM System -170001 [HTTP:0-30]: GET-->/desc Wed 2016/02/17 07:02:19 AM System -170001 [uDSockets] RSub:29 error:6 Wed 2016/02/17 07:02:21 AM System -170001 [HTTP:0-30-5] 192.168.1.203:54605->80 Wed 2016/02/17 07:02:21 AM System -170001 [HTTP:0-30]: GET-->/desc Wed 2016/02/17 07:02:21 AM System -170001 [HTTP:0-30-5] 192.168.1.203:54606->80 Wed 2016/02/17 07:02:21 AM System -170001 [HTTP:0-30]: POST[1]-->/services Wed 2016/02/17 07:02:21 AM System -170001 <s:Envelope><s:Body><u:GetISYConfig xmlns:u="ur Wed 2016/02/17 07:02:24 AM System -170001 UDWriteAll[sock=29:RSub]:Socket inactive = 6 Wed 2016/02/17 07:02:24 AM System -170001 UDWriteAll[sock=29:RSub]:Socket inactive = 6 Wed 2016/02/17 07:02:24 AM System -170001 UDWriteAll[sock=29:RSub]:Socket inactive = 6 Wed 2016/02/17 07:02:24 AM System -5012 87 Wed 2016/02/17 07:02:26 AM System -170001 [HTTP:0-29-5] 192.168.1.203:54610->80 Wed 2016/02/17 07:02:26 AM System -170001 [HTTP:0-29]: POST[1]-->/services Wed 2016/02/17 07:02:26 AM System -170001 <s:Envelope><s:Body><u:Authenticate xmlns:u="ur Wed 2016/02/17 07:02:26 AM System -170001 [HTTP:0-29-5] 192.168.1.203:54611->80 Wed 2016/02/17 07:02:26 AM System -170001 [HTTP:0-29]: POST[1]-->/services Wed 2016/02/17 07:02:26 AM System -170001 <s:Envelope><s:Body><u:GetStartupTime xmlns:u=" Wed 2016/02/17 07:02:26 AM System -170001 [HTTP:0-29-5] 192.168.1.203:54612->80 Wed 2016/02/17 07:02:26 AM System -170001 [HTTP:0-29]: POST[1]-->/services Wed 2016/02/17 07:02:26 AM System -170001 <s:Envelope><s:Body><u:GetNodesConfig xmlns:u=" Wed 2016/02/17 07:02:28 AM System -170001 [HTTP:0-29-5] 192.168.1.203:54613->80 Wed 2016/02/17 07:02:28 AM System -170001 [HTTP:0-29]: POST[1]-->/services Wed 2016/02/17 07:02:28 AM System -170001 <s:Envelope><s:Body><u:GetSystemTime xmlns:u="u Wed 2016/02/17 07:02:28 AM System -170001 [HTTP:0-29-5] 192.168.1.203:54614->80 Wed 2016/02/17 07:02:28 AM System -170001 [HTTP:0-29]: POST[1]-->/services I can't tell whether there's anything meaningful in there. Rob

I just started and quit the admin console a few times and the bar showed up the first 3 times, but didn't show up on the fourth startup. I haven't been able to find a distinct sequence of events that causes it to happen, but it did work fine the first time I launched it this morning. As far as I know, I can only get to the event viewer from the admin console, so by the time I get to the event viewer, it's empty. Is there a way to see past events (other than the log or error log, which show nothing interesting). Thanks, Rob

I just installed my Elk alarm system and I generally love the integration with the ISY. I'm running the 4.4.3 RC release on the ISY and I see that sometimes I get the Elk bar at the top of the admin console (system state, alarm state, buttons to arm the system) and sometimes I don't. I suspect that it has something to do with whether the ISY can connect to the Elk, so I think it's either failing to connect or just timing out when it tries to connect. Along those lines, I initially thought that it was happening only when I had another client connected to the Elk (like ElkRP), but it's definitely happening when nothing else is connected to the Elk or has connected to it in hours (such as when I wake up in the morning). Whether or not the Elk bar shows up seems almost random. I've looked at the log and error log on the ISY and I don't see any obvious Elk messages around the time that I launch the ISY admin console. Is there another way to see what's going on? Rob

I just installed my Elk security system and I've spent some time integrating it with my ISY. I'd like to write a program to handle a particular sequence, but I'm having trouble making it work. Basically, if the alarm trips while armed, I'd like to turn on the downstairs lights and send an email with the violated zone after the entry delay has expired. Taking a cue from the wiki, I can write a program like this that send a notification with the violated zone when it happens: If Elk Zone 'xxx' is Violated Or Elk Zone 'yyy' is Violated ... Then Send Notification to Email 'Prowl' content 'Alarm Zone Violated' where 'Alarm Zone Violated' has the following: "Zone Violated: ${elk.zone.#.name}" That works at the time of the zone violation because zone violation itself caused the program to run, but it also runs when I enter normally and disarm the system within the entry delay time. I can also get the lights to turn on after the entry delay has expired using this: If Elk Area 'House' 'Alarm State' is Burglar Alarm Then Set Scene 'Scenes / Downstairs Lights' On This program works fine and turns the lights on after the entry delay expires. Merging the two programs should work if the zone remains violated (door is left open), but if the zone has become normal (i.e., the door has been closed), I can only rely on the 'Burglar Alarm' state as a trigger (as in the second program) and I can't use the if zone 'xxx' is violated conditions. If I try to send the "Alarm Zone Violated" notification from the second program and the zone has become normal, I get a blank zone name in the notification. I considered trying to cache the zone name when the violation occurs to use it later in the notification, but I don't think that's currently possible. The Elk tells me the zone violation that triggered the alarm when I disarm it, even it's been closed, so it clearly has that information stored. Is there anyway to send a notification from the ISY at a later time that includes the zone that was violated when the alarm was triggered? Hopefully that was reasonably clear, but I'll be happy to clarify anything that's confusing. Thanks, Rob

Put the mini-remote into linking mode (hold down set for a few secs until the LED starts blinking), right-click on the mini-remote and select 'Restore Device'. That should remove all existing links from the mini-remote and repopulate it with what the ISY has in its database. I believe that you can also do it from the 'diagnostics->device links' section by hitting 'compare' to detect differences. If there are differences, you can restore the device to get it back in sync. The most important thing is determining how it happened in the first place. Are you using devices other than the ISY to manage your devices or performing any manual linking at the devices? Both will likely mess up your links.

I see - that makes sense. Thanks very much for the help. Rob

I think I understand. So choosing an ISY scene as the first parameter changes the response when you set/trigger an ISY scene manually from the ISY or through a program. Choosing a device as the first parameter changes the response when a scene is triggered from that device (like flipping a switch, motion sensor detects motion, etc.), or when you send a command directly to the device from the ISY. All correct? I still feel like a wording change would make it more obvious. Maybe changing the prompt to "For scene controller" and naming the ISY scenes "PLM - <scene name>", where it's clearer that you're always choosing a device/scene controller, even when you choose <scene name>. That's really where it threw me off - it's clear that the devices in the list are scene controllers (non-controllers are actually excluded), but the "device" aspect of the scene entries wasn't as clear. Thanks for the quick response - I think I get it now. Rob

Regarding the original issue, I really recommend changing the wording as described by oberkc: I just ran across this as well, and the wording "In scene", coupled with a dropdown list that includes a bunch of scenes, really leads a new user in the wrong direction (to pick a scene). Is there any situation where it's appropriate to select a scene from that dropdown box? If not, it would be a lot more user-friendly to change the wording to "for scene controller" and only list scene controllers. I understand why it doesn't make sense to choose a scene there, but it's definitely not intuitive the way it is now. Rob

Is the process changing in 5.0, perhaps addressing this concern? I'm reluctant to update to the beta considering that I just got everything up and running and it sounds like 5.0 is still a work in progress. I haven't found a definite description of what's changing in 5.0 compared to 4.3.26. Is there anything you can point me to, or is just try it and see? <Edit: Never mind. Found the Wiki page>

Thanks for the clarification, Michel. All I'm really interested in is automatic detection of address to avoid having to read it off of the label and type it in manually, so if that becomes possible in the future, it would make the initial configuration process much more user-friendly. Any thoughts on this? I'm also curious about the third observation in my original post. Is there any way to edit device names as they're being added through Start Linking, or do you just have to take notes (mental or paper) and do it at the end? I suspect that the days of onboarding lots of devices are long past for many of the frequent contributors here, but this is one of the areas that I think could be more polished to get a new user up and running more quickly. Rob

Understood, Michel. This issue came up when I was setting up my devices for the first time and realized that I had to manually enter the address of each battery-operated device. Two 'competing' systems, the Insteon hub and Indigo (which also uses the 2413s PLM) are able to figure out the address automatically, so I was wondering if this was a technical limitation of the ISY (can't be done for some reason) or is a feature that could be added in the future to streamline adding these devices. Is it possible for the ISY to discover the address of battery-operated devices automatically in the future, rather than requiring the user to find and enter them?

Yes, that's the same result that I get. Thanks for following up. Stu, are you seeing different results? I'm also curious about the third observation in my original post. Is there any way to edit device names as they're being added through Start Linking, or do you just have to take notes (mental or paper) and do it at the end? I suspect that the days of onboarding lots of devices are long past for many of the frequent contributors here, but this is one of the areas that I think could be more polished to get a new user up and running more quickly. Rob