shannong

I said "thanks" but will say it again. Thanks!!

I use Mobilinc Pro without the Connect service. I also don't do port forwarding. Both are for the same reason. I don't want the central controller for my house exposed to the internet. Using the Connect service is safer since the ISY software isn't directly accessible from the internet (outbound channel vs always open inbound) but still if the Connect service gets hacked I'm toast. I don't yet have my home security system integrated with my ISY yet but that will happen over the holiday break when I have more time. Definitely wouldn't want my security system compromised via an open channel to the internet. Both Android and iOS have a VPN client built into the phone. I always make sure to buy a router for my house that has VPN capabilities. I can create a secure VPN from my phone to my home router and run the Mobilinc app to avoid the security issues and monthly cost of Connect. I can also do VPN from my laptop from anywhere to access the ISY. I haven't yet had the need to do something at the house while away but I'm sure I will eventually.

Here's a another bump to hopefully get this into the User Guide and Wiki. Too late for me but will be very helpful for new ISY owners. This is a great description to understand the basics of Insteon communications and how the ISY interacts with Insteon network. Previously I had looked for something like this over at Smarthome but was unable to find anything outside of describing the Insteon frame structure. Thanks to Mark James!

At night when I go to bed I don't want ANY LEDs or backlights on including the On/Off buttons. Furthermore, I don't want to turn off the scenes that might be active when the LEDs are shutoff. For example, Scene A is to turn my ceiling fan on High. If I used your approach, when the A button is shutoff so would my ceiling fan but I don't want my ceiling fan turned off. Also, the Off button of the KPL which is quite large would still be lit.

Sweet! And so fast, too!! Thanks. That'll make Xmas more merry for me. And thanks to LeeG. Right now I have HL still running only for the purpose of triggering an event from my MiniRemote4 to turn off the LEDs and turn them back on in the morning. It took quite a bit of tinkering to get working properly since the KPL and MiniRemote are simultaneously managed by two different systems. They both execute programs that include the KPL with the same button press on the remote.The HL instance sees a bunch unrecognized links and it was tricky to avoid overstepping each systems links. Probably would be problematic for me in the long run. Once I can do this from ISY then I'll be decommissioning the HL instance and make my life much simpler.

Agreed. I was operating under the false assumption you implemented all the BASIC and EXTENDED features of a device when you added to ISY. I now know that is not the case. However, On and Off are a universally basic. Varying degrees of on and off (dimming) would fall into the subjective area of "basic". You got the On and dimming yet left out Off. That's basic. Regardless of how many people want it.

Obviously I'm new to HA, Insteon, and ISY. Is this KPL new and is "LEDs Off" a new feature and concept not previously considered such that it would not be included when this device was included in the "supported" list by the ISY994i? It's frustrating for me because it's such a basic concept to consider regardless of device and especially to me knowing this specific device supports it.

Thanks, Bomber for the suggestions with detail. I have several other things to get setup and working that I'll tackle first. If 5.x is still far away at that point, I'll implement the methodology you shared.

One other thought. There are wireless water sensors for security systems. You could use your security system for this and be notified that way. Most security systems are built with their own battery backup. They usually also monitor battery life and provide low battery alerts for wireless sensors. If you're security system is integrated with the ISY (or could be) then you could use a wireless water sensor with the security system and still let the alert and notification flow through your ISY. I'm planning to integrate an Elk M1, although they don't make a wireless water sensor that I've seen. However, you can add a module to it to support GE wireless sensors, and GE makes makes a wireless water sensor among many others. I haven't installed my Elk M1 so do your due diligence.

I was also brainstorming this to address a similar scenario with leak detection. There is now a Zwave module that can be added to your ISY, although in beta still. Then you could use a Zwave leak sensor for this purpose. All your other house stuff would still be Insteon using the dual-band PLM that doesn't need to be plugged into a UPS. Make sure you're using the external power supply connected to a UPS rather than power off the serial connector from the PLM. Probably the easiest route without complexity IMO and not affecting your current setup. Of course to get the notification you'll need connectivity to the outside world which means maintaining external connectivity via a hard wired phone line, GSM gateway, or your internet modem-and/or-router and all components would need to be on a battery backup as well.

I don't really care what HL is doing. I only care about being able to turn off the LEDs with ISY without affecting scenes.

Here's what HL shows with debug logs when turning off the LEDs. It says it's setting it to "0" but I can't decipher the Data field of the message to actually confirm that. 013-12-16 11:40:46,724 [38] INFO - Master LEDs Off: Keypad with Dimmer ON / OFF - Turn LED off 2013-12-16 11:40:46,724 [38] DEBUG - Setting backlight of Keypad with Dimmer 29.4D.2F to 0 ... 2013-12-16 11:40:46,724 [38] DEBUG - Tx: Ext Msg, To: 29.4D.2F, Flag: 1A (Hops: 2/2), C1: 20 (Set Operating Flag), C2: 08, Data: 00 00 00 00 00 00 00 00 00 00 00 00 00 D8 2013-12-16 11:40:46,747 [42] DEBUG - Rx: PLM Ack, 02 62 29 4D 2F 1A 20 08 00 00 00 00 00 00 00 00 00 00 00 00 00 D8 06 2013-12-16 11:40:46,747 [38] WARN - PLMDataProcessorCommand Write timeout of 1500 milliseconds 2013-12-16 11:40:46,747 [38] DEBUG - Calculated wait time: 6523 ms, no retries=False, hops left=2 2013-12-16 11:40:46,747 [38] DEBUG - Starting WaitforReply, wait time: 6523 2013-12-16 11:40:47,195 [42] DEBUG - Rx: Std Ack, From: 29.4D.2F, To: 23.9A.7C, Flag: 26 (Hops: 1/2), C1: 20, C2: 08 2013-12-16 11:40:47,195 [38] DEBUG - WaitforReply, signaled 2013-12-16 11:40:47,195 [38] DEBUG - WaitforReply, returning sendResult.. 2013-12-16 11:40:47,195 [38] INFO - Successfully sent Turn LED off command to ON / OFF. 2013-12-16 11:40:47,195 [38] INFO - Master LEDs Off: Keypad with Dimmer ON / OFF - Turn LED off Success

Oops. Actually that was wrong. HL has Off and then increments from 2% to 100%. I was thinking of zero in a different spot. I wouldn't say I grew up on HL. I only used for two weeks and still don't know what the hell I'm doing.

I disagree. ISY is providing the UI and middleware. ISY should provide an interface that's easy to understand and use. Regardless of the protocol or "supported commands" the UI should abstract that for the end user. That's what HoseLinc did. They provide the UI for the end user to easily select a scale from 0-100% with zero being off and 100% being the brightest or "full on" value. Or you can just pick Off. How that's implemented as commands on the backend is immaterial to the end user. That's what a good UI does.

Obviously zero isn't off in the ISY because it's the default and by default they're not off. But zero SHOULD be off since it's a range of values where the larger the number the brighter the light.

I have tried controlling the "LED Brightness" of the individual device. The behavior is ineffective as the same the programs. The default for ISY is 0/0 (On/Off) from my limited exposure. But that doesn't make sense to me. Zero should mean off, no? Of course, by default they are not off. Perhaps I'm not interpreting the values correctly. I'm assuming that On=0 means when the particular device is "On" it's brightness level is zero and thus the lights should be off. And when a device's "Off" brightness is zero it should be off also when the button is not active. Anything greater than zero would be some level of light variable up to the max. The ISY values are non-intuitive though perhaps technically accurate for all I know. Zero, seven, and fifteen. Zero makes sense. Seven and fifteen both represent a range of values that fall within even bit boundaries . But why that? In HL, they were based on percentages starting with 2% up to 100%. I'd be happy to capture traffic from HL if you give me the specifics of what you're looking for. I'm only slightly less new to HL than ISY. I can capture the event logs but let me know if you're looking for something else.

Minor nuisance. Not having the non-auto option or opening the GUI more than once to regain the feature isn't important at this point.

I upgraded to 4.1.1 today (and cleared the cache so I also have 4.1.1 UI) and am still seeing the same behavior as before. Sometimes when I open the console I have both options, sometimes just the option for battery devices, and sometimes neither. Just to be clear, I was seeing the issue with 4.0.5 using both the 4.0.5 and 4.0.11 UI.

If you open and close the admin console do they consistently return?

My goal is to turn off ALL the LEDs on the KPL without affecting that status of the scenes buttons. I have a program written to set the backlight level of the KPL for On/Off to 0/0. The LEDs would be enabled by a program that runs at sunrise. The program does not turn off the LEDs when I use a Run(Then). With the On backlight brightness set to zero the active scene buttons should not light. With the Off backlight set to zero the local Off button on the KPL should also go dark. They are not.

Yes.

I updated to 1.7.0_b45 and the same behavior is exhibited. Sometimes the automatic write options are available and sometimes not.

For sometime? A whole two months? I hate Java. It's slow, a resource hog, and the version conflicts with various apps gets tricky. I gotta say I wasn't happy to discover ISY used a Java applet for configuration. I'll update and see if that helps. Hopefully none of my other apps are too picky.

I was wrong about this. It's not a factor of loading the console from portal vs local or even the version of the UI. Sometimes the options are there when I launch and sometimes not. Sometimes I only have the disable updates option for battery. It varies as I open and close the console repeatedly and I haven't detected a pattern. The toolbar buttons are also gone when the File menu options are not available. Same for when I have the "battery only" option. My JRE is 1.7.0_40.

Turn off LEDS. Simple right? Insteon supports that. ISY has a value to set for LEDs when "on" and "off". Great.... I set "on" to zero (default): it's some brightness (but not off!) . I set it to one: it's some brightness that's dimmer than zero!! Why the heck have a value of zero that's brighter than one? I set it to two hundred (which shouldn't be allowed), nothing changes. It's silently ignored. The "off" value for brightness is also zero. The "Off" button of the KPL is lit up like Xmas when the KPL is off. Wha!?!? Why have a variable that does nothing in the ISY? In HouseLinc, I had an "event" that turned off the LEDs at night by schedule or when I turned on a scene for bedtime since there are two KPLs in my bedroom. All the LEDs went completely off. Nothing. The associated devices/scene was still on. Perfect. I also have several switch dimmers in the bedroom. Less of a nuisance than the KPLs, but if I'm writing a program to turn LEDs off why not include them also. Hmm... No option for "off" LEDs for those nodes. I write a program to set "backlight level" as zero. No affect on those either. Also they were simple to turn off in HouseLinc. This is starting to frustrate me. What was simple, obvious, and easy with HouseLinc for free is either convoluted or not possible with ISY. I'm new to ISY so I'm hoping this is a blundering mistake on my part but this thread seems to prove what I've experienced in practice. The brightness values are not actually functional in ISY.