markens

The issue is AC power theory vs DC power theory. For DC, your understanding is correct that P=VI. AC power calculation is somewhat more complicated because of its frequency component. A power factor of 1.0 means the load is purely resistive (incandescent light bulb, heater element, etc), and the current flowing is exactly in phase with the voltage frequency. Power factor goes towards 0.0 as the load's reactive elements increase (motor winding, capacitor coupling) and the current flowing shifts away in phase from the voltage. Watts is the measure of real power (in phase with the voltage), and is what residential electric meters measure. The VA (volt-amp) is a measure of apparent power, which is what the wires must actually carry. Generally you'll see appliances such as heaters (PF=1) rated in Watts and those with motors (PF<1) rated in VA. Wikipedia has a good article with more info about power factor. --Mark

It's very simple, but not what you think: A program's status is simply the result of what happened the last time it ran. If the THEN ran, then program status is TRUE. If the ELSE ran, then it's FALSE. Nothing more complicated than that. It has nothing to do with what actions are taken within the THEN or ELSE parts. In your example of a single time condition ("If time is 11:00:00pm Then ..."), the IF is automatically evaluated only at that time: the IF evaluates to TRUE, the THEN runs, and program status is TRUE. If you manually do a Run(If) some other time, then the IF evaluates to FALSE, the ELSE runs (empty in this case), and the program status is FALSE. In a "From-To" time condition, it's evaluated automatically twice: at the start time (evaluates TRUE) and the end time (evaluates FALSE). But the resulting program status still depends on whether the THEN or ELSE was run, based on the logic of all the IF conditions. --Mark

Did you ever configure an X10 code for these devices? They don't get cleared via link rewriting.

This is fascinating. In retrospect, it does make sense that these devices have measurable current draw with such low PFs when off given the capacitance coupling. I dug out my Kill-a-Watt and tested a bunch of relatively recent devices (both dimmer and relay), using a 60W incandescent light bulb as the load. I saw stable readings for all dim values I tested (0/22/44/50/65/87/100%), so the Kill-a-Watt did not seem confused by dimmers with an incandescent load. I didn't try a CFL load. My results mirror what others have posted WRT OFF values. --Mark

I received a KPL-8 with ivory button caps a year or so ago which exhibited the same brightness inconsistencies you describe. The differences stayed with the buttons when I moved them to different positions on the KPL, clearly indicating button cap problems. My solution was to have Smarthome send me an ivory button kit, which solved the problem. The KPL itself was fine (at least in my case). --Mark

Each time you generate a new certificate, it simply replaces the previous one. The remote browser will warn you again since it is a new certificate, but otherwise there is no problem there either. --Mark

For most situations that you'll encounter (including the ISY), this is exactly the case: the server's SSL certificate enables private (non-snoopable) communication between arbitrary clients and the server. It also allows the client to verify the identity of the server (very useful, for example, when talking to your bank's server). It does not enable the server to verify the identity of the client, which is why login passwords are still required. The SSL framework does allow client authentication (with signed client certificates), but it requires more administration in the client and is used mainly in enterprise environments. I would consider the user ID/password to be critical information. If disclosed, it would allow anyone to connect to your ISY and have their will with your lights. Probably not as sensitive as bank or credit card info, but personally I don't want my ISY vulnerable and this is reason enough to use https connections. The UDI crew will have to answer this. But I seem to remember seeing warnings somewhere that SSL management in the ISY must be performed locally for security reasons. One would think an error would be displayed if this was the case and you tried it remotely. --Mark

A workable solution! But there is another gotcha which you may care about. Consider this situation: the nightlight sequence has been activated (light at 30%) and program 'Light Dim Off ' is running its wait, counting down to turning the light off. During this interval, someone changes their mind and turns the light on with the switch. The light goes on, but the running program is unaffected. When the wait completes, the program will turn off the light as previously initiated, leaving a surprised person in the dark. There is probably a more elegant solution, but a quick fix with your existing two programs is to add a third: If Control 'Room Light' is switched On Then Stop Program 'Light Dim Off' Else - No Actions - --Mark

It's very useful to understand why this is the case, and how these "little" logic issues can come back to bite you when it seems all should work as expected. The example program turns out to be more complex than initially apparent. Let's walk through the the logic: If Status 'Master Bedroom Light' is Off And Control 'Master Bedroom Light' is switched Off Then Set 'Master Bedroom Light' 20% Else Wait 5 seconds Set Scene 'Slow Master Bedroom Light' Off It works fine for the intended situation; that is, if the light is already off and the control is turned off, the IF is true and the THEN executes, turning the light on to 20%. This causes a status change, which causes the IF to be evaluated again. Since the status has changed and is no longer OFF, the IF is false and the ELSE executes: delay 5 seconds, followed by triggering the scene which results in light being off. Note that the status of the light changes yet again (to OFF), causing the IF to be evaluated one more time. The IF is FALSE (doesn't matter what the light status is; the Control was not activated, so it is FALSE) and the ELSE executes again. The program waits another 5 seconds and turns off the light again (no net effect this time since it's already off, but there is insteon traffic). The program finally stops. The unintended effects happen when the light is off and is turned on. The light turns on, which causes a status change from OFF to ON. Which causes the IF of this program to be evaluated. The IF evaluates to FALSE due to the Status clause. Which means the ELSE executes. The program waits, and then turns the light back off via the Scene command. Not what you want. Moral: if you have anything in a program's ELSE, you must be extra careful about unintended effects due to logic inherent in how the IF is constructed. --Mark

Since you're currently accessing remotely, this implies your router is successfully set up to forward WAN traffic to your ISY. Do you currently use http (port 80) or https (port 443, SSL using default generic certificate) for that remote access? If you're using https, then you're almost there already. Generating a self-signed certificate simply replaces the existing generic one, using your specific address information. If you're using http, the first thing to check is that port 443 is forwarded through your router to the ISY's port 443, which is required for SSL access. (This is independent of port 80, which you can close on your router once you verify https access is working.) Yes, you specify the same IP address or hostname you use in your remote browser to access the ISY. For example, if you access remotely via http://1.2.3.4/admin, then enter 1.2.3.4 when generating the certificate. Similarly for a hostname. Note there are ways to use a hostname with dynamic IP addresses, using sites such as dyndns.org. This allows remote access even when your WAN IP address changes. The ISY setup is done. I would try the "remote" access while you're still at home setting things up. Simply access the ISY from your home browser using the WAN address you use remotely. One caveat: your router must support "loopback" access for this to work. The exact wording of this option depends on the router, but it might be called "NAT Loopback" or similar function. Access remotely as before, using https instead of http. The browser will warn you that the site's certificate is not trusted because it is self signed, and give you a way to save the exception permanently. Once you do this, the browser won't warn you again. No access differences after that. Should work the same way, although someone else with Droid experience may have something to add. --Mark

Only one scene is required: An OFF sent to any scene will cause all members of that scene to turn off using each device's ramp rate for that scene. Similarly, a FAST OFF will cause all member devices to turn off immediately. --Mark

Hi Michel, Paranoia about security is a good thing. Thanks for the explanation. The big disconnect in my mind was the different behavior of saving self-signed cert vs CA-signed cert. And it only mattered to me because of the issue I had a few weeks ago when I lost the ability in 2.7.7 to generate a new cert. Most likely not going to be a problem going forward. Sounds like a good resolution. Thanks! --Mark

This is XP. The file save dialog was for the specific folder I wanted to save in, and I hit ok. Afterward (when I saw the file was not there), I did a search of the entire disk to see if it actually was saved somewhere else, and it was not found. And the file save via the SSL utility worked fine (to this same folder) when I saved the key file generated for self-signed cert. The workaround is to retrieve the key from the ISY backup, so I'm not too worried about this. But the behavior is pretty strange and does seem buggy to me (especially with no error that file could not be saved where specified). --Mark

Now that I'm up to 2.7.12, I used the SSL utility to generate a CSR and install the signed cert from my CA. It all worked fine, and my new cert was installed and is active on the ISY. Very nice, thanks. One glitch: After I pasted the signed cert into the popup window to be received and hit OK, that popup went away and I was prompted to save UD.DCF. That appeared to work ok. But UD.DCF did not seem to be actually written to the specified location. I can retrieve it from ISY backup, but something seems amiss here. --Mark

Wow, that was fast even for you guys! I tested the jnlp url (http://www.universal-devices.com/99i/2.7.12/admin.jnlp'>http://www.universal-devices.com/99i/2.7.12/admin.jnlp) a bunch of times this morning, and did not see it hang a single time. Accessed the ISY in between via other methods, as yesterday. So it appears to work so far! I'll keep using it and let you know if I see any problems. The other URL you listed (http://www.universal-devices.com/99i) loads the browser-based console. But it appears to be down-rev, since none of my folders are displayed and devices/scenes are shown the old way. So I didn't continue testing this version. BTW, I noticed a java exception when closing the browser-based console loaded from the ISY (//isy/admin); details attached. The console still closed okay, and didn't seem to affect anything afterwards either. --Mark Exceptions when closing //isy/admin (2.7.12) Java Plug-in 1.6.0_18 Using JRE version 1.6.0_18-b07 Java HotSpot(TM) Client VM ---------------------------------------------------- Exception in thread "AWT-EventQueue-2" java.util.NoSuchElementException at java.util.LinkedList.getFirst(Unknown Source) at java.awt.SequencedEvent.getFirst(Unknown Source) at java.awt.SequencedEvent.dispatch(Unknown Source) at java.awt.EventQueue.dispatchEvent(Unknown Source) at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.run(Unknown Source) Disposal was interrupted: java.lang.InterruptedException at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:485) at java.awt.EventQueue.invokeAndWait(Unknown Source) at java.awt.Window.doDispose(Unknown Source) at java.awt.Window.dispose(Unknown Source) at com.universaldevices.common.ui.GUISystem.Stop(Unknown Source) at com.universaldevices.ui.UPnPClientApplet.stop(Unknown Source) at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source) at java.lang.Thread.run(Unknown Source)

The KPL button backlight values can be adjusted independently for button ON brightness ('ON 15' above) and button OFF brightness ('OFF 7'). All buttons in a KPL use the same values; writing to any of the buttons sets the values for the KPL as a whole. The OFF values are 0 (off) to 7 (bright). The ON values are 0 (dimmer) to 15 (brighter), and is relative to OFF brightness such that the dimmest ON value is always brighter than the specified OFF value. (ON=0 and ON=1 may actually be the same as ON=15 in some cases; ON=2 is generally reliable as the dimmest value for a given OFF brightness.) So the pulldown menu simply lets you select the combination of values that you want. You can use the LED Brightness button on the device page itself (in My Lighting) to experiment and see what it looks like on the specific device in question. Lots more technical details in other threads. Start here and wind your way back through the references: http://forum.universal-devices.com/viewtopic.php?p=28079 --Mark

I don't know the specs for these values. But experimental observation in my own network yields these values: On level FF = 100% bright A8 = 66% 8C = 55% 72 = 45% Ramp rate 1F = .1 sec 1C = .5 sec Based on this, I imagine that On Level takes values between 00-FF (0% - 100%) and Ramp Rate between 00-1F (9min - .1 sec). Edit to add: Note that level/ramp values are only meaningful for responder links. --Mark

I have seen this intermittent console startup hang as well, initially in 2.7.6 and 2.7.7. I've now upgraded to 2.7.12, and see it just as often. I just spent some time doing detailed debugging, and here's what I found: My environment: ISY99i/2.7.12; Windows XP sp3; java 1.6.0_18-b07; no firewall running on XP other than default Windows internal firewall. Java cache purged before loading any 2.7.12 java apps. Symptoms: About half the time when starting jnlp console (initially loaded via //isy/admin.jnlp), the console hangs after entering username/password and displaying what appears to be complete main My Lighting page. Cursor is hourglass, and nothing works when clicked in the console. When console is hung like this, access via html works fine (//isy/devices, //isy/scenes) -- ISY receives and executes these commands ok. Hung console closed by clicking window-close X button. Much of the time, simply restarting the console by double-clicking the "Administrative Console" jnlp icon on desktop works fine. If hung the second time, it almost always works the third time and thereafter. The hung console startup seems to happen about 100% of the time after the ISY was accessed in some other manner (browser-based admin console, html-based commands.). I've only seen the hang in the jnlp console (//isy/admin.jnlp), and never with the browser-based console (//isy/admin). I was able to capture java stack traces for both normal and hung startups, attached below. Included are all the UDI threads; the non-UDI threads all appear to be the same in each case. I hope this helps! --Mark Threads from hung startup: 2010-03-06 12:30:09 Full thread dump Java HotSpot(TM) Client VM (16.0-b13 mixed mode, sharing): "Thread-12" prio=10 tid=0x03490400 nid=0xe80 runnable [0x045df000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.SocketDispatcher.read0(Native Method) at sun.nio.ch.SocketDispatcher.read(Unknown Source) at sun.nio.ch.IOUtil.readIntoNativeBuffer(Unknown Source) at sun.nio.ch.IOUtil.read(Unknown Source) at sun.nio.ch.SocketChannelImpl.read(Unknown Source) - locked <0x23340080> (a java.lang.Object) at sun.nio.ch.SocketAdaptor$SocketInputStream.read(Unknown Source) - locked <0x233400f8> (a java.lang.Object) at sun.nio.ch.ChannelInputStream.read(Unknown Source) - locked <0x23340100> (a sun.nio.ch.SocketAdaptor$SocketInputStream) at java.io.InputStream.read(Unknown Source) at sun.nio.ch.ChannelInputStream.read(Unknown Source) - locked <0x23340100> (a sun.nio.ch.SocketAdaptor$SocketInputStream) at com.universaldevices.upnp.UDProxyDevice$EventsHandler.run(Unknown Source) "Thread-10" prio=6 tid=0x03518c00 nid=0x89c waiting on condition [0x0449f000] java.lang.Thread.State: TIMED_WAITING (sleeping) at java.lang.Thread.sleep(Native Method) at com.universaldevices.ui.views.SystemConfigurationView$ClockUpdater.run(Unknown Source) "Thread-9" prio=6 tid=0x0352e400 nid=0xda0 waiting on condition [0x0444f000] java.lang.Thread.State: TIMED_WAITING (sleeping) at java.lang.Thread.sleep(Native Method) at com.universaldevices.ui.SystemStatusMonitor.run(Unknown Source) "Thread-6" prio=6 tid=0x0344f800 nid=0xa38 in Object.wait() [0x03b9f000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x27f0f020> (a java.lang.Boolean) at java.lang.Object.wait(Object.java:485) at com.universaldevices.upnp.UDProxyDevice.subscribeToEvents(Unknown Source) - locked <0x27f0f020> (a java.lang.Boolean) at com.universaldevices.ui.UPnPClientApplet.prepareAuthenticatedSession(Unknown Source) at com.universaldevices.ui.UPnPClientApplet.authenticate(Unknown Source) at com.universaldevices.ui.UPnPClientApplet.onDeviceOnLine(Unknown Source) at com.universaldevices.upnp.UDControlPoint.onLine(Unknown Source) - locked <0x28284d88> (a com.universaldevices.upnp.UDControlPoint) at com.universaldevices.upnp.UDControlPoint.updateDeviceInfo(Unknown Source) - locked <0x28284d88> (a com.universaldevices.upnp.UDControlPoint) at com.universaldevices.upnp.UDControlPoint.addDevices(Unknown Source) at com.universaldevices.ui.UPnPClientApplet.start(Unknown Source) at com.universaldevices.ui.UPnPClientApplet$7.run(Unknown Source) Threads from normal startup: 2010-03-06 12:25:56 Full thread dump Java HotSpot(TM) Client VM (16.0-b13 mixed mode, sharing): "Thread-8" prio=6 tid=0x02cb7800 nid=0xd20 waiting on condition [0x03ccf000] java.lang.Thread.State: TIMED_WAITING (sleeping) at java.lang.Thread.sleep(Native Method) at com.universaldevices.upnp.UDControlPoint$DeviceLifeMonitor.run(Unknown Source) "Thread-7" prio=6 tid=0x02cb7000 nid=0x254 runnable [0x03c7f000] java.lang.Thread.State: RUNNABLE at java.net.PlainDatagramSocketImpl.peekData(Native Method) - locked <0x28d3d7c0> (a java.net.PlainDatagramSocketImpl) at java.net.DatagramSocket.receive(Unknown Source) - locked <0x22c0e6c8> (a java.net.DatagramPacket) - locked <0x28d3d508> (a java.net.MulticastSocket) at com.universaldevices.upnp.SSDPClient.run(Unknown Source) "Thread-12" prio=10 tid=0x02cc5400 nid=0x718 runnable [0x03bdf000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.SocketDispatcher.read0(Native Method) at sun.nio.ch.SocketDispatcher.read(Unknown Source) at sun.nio.ch.IOUtil.readIntoNativeBuffer(Unknown Source) at sun.nio.ch.IOUtil.read(Unknown Source) at sun.nio.ch.SocketChannelImpl.read(Unknown Source) - locked <0x28ccb1e8> (a java.lang.Object) at sun.nio.ch.SocketAdaptor$SocketInputStream.read(Unknown Source) - locked <0x28ccb1e0> (a java.lang.Object) at sun.nio.ch.ChannelInputStream.read(Unknown Source) - locked <0x28ccee68> (a sun.nio.ch.SocketAdaptor$SocketInputStream) at java.io.InputStream.read(Unknown Source) at sun.nio.ch.ChannelInputStream.read(Unknown Source) - locked <0x28ccee68> (a sun.nio.ch.SocketAdaptor$SocketInputStream) at com.universaldevices.upnp.UDProxyDevice$EventsHandler.run(Unknown Source) "Thread-10" prio=6 tid=0x03d39400 nid=0xf2c waiting on condition [0x0454f000] java.lang.Thread.State: TIMED_WAITING (sleeping) at java.lang.Thread.sleep(Native Method) at com.universaldevices.ui.views.SystemConfigurationView$ClockUpdater.run(Unknown Source) "Thread-9" prio=6 tid=0x03d9f400 nid=0x448 in Object.wait() [0x044ff000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x28b5ba00> (a java.lang.Boolean) at java.lang.Object.wait(Object.java:485) at com.universaldevices.common.UDClientStatus.waitNotBusy(Unknown Source) - locked <0x28b5ba00> (a java.lang.Boolean) at com.universaldevices.ui.SystemStatusMonitor.run(Unknown Source)

The wiki page which defines the fields is here: http://www.universal-devices.com/mwiki/index.php?title=ISY-99i/ISY-26_INSTEON:Tools_Menu#Show_Links_Table_Database For a KPL, each button is its own group, and will have links accordingly. Remember there are also two links for each group for the PLM (one responder, one controller) which are created when the device is added to ISY. Plus more PLM links for additional ISY scenes that device is a member of. --Mark

One easy way would be to have a program trigger on KPL button on/off control events and enable/disable your other program. Something like this: If Control 'KPL-A' is On And Control 'KPL-A' is not Off Then Enable Program 'whatever' Else Disable Program 'whatever' Another way would be to add a check for status of the KPL button in your existing program, which would require no additional triggers on the KPL: If A9 ON is received And Status 'KPL-A' is On Then ... (edit to add second suggestion) --Mark

Yup, your series of four programs removed the wait/reevaluate problem of the original program. Note that changing the light's status manually will cause any of these executing program to terminate, and evaluate conditions again (which is probably what you want anyway). For example, the light is at 50% and someone turns it full on again. Your step-down sequence will start over. --Mark

MarkJames made some excellent suggestions. But it's useful to understand why your original program doesn't work as you expected: When the "set 'light' 75%" executes in your program, it causes the status of 'light' to change (assuming the original level was not 75% when turned on). And since this program looks at that status in its conditions, the wait terminates and the program restarts, evaluating its conditions again. The first "wait 10" executes, along with "set 'light' 75%" again. But the light is already at 75% this time, so this command doesn't change the light's status in the ISY and the program continues. Now the change to 50% triggers this sequence over again. And next time the 75% changes status, resulting in cycling between 75% and 50% indefinitely. So, here's what I believe your original program will do if allowed to continue: (light on) : wait 10 : light 75% : wait 20 : light 50% : wait 10 : light 75% : ... --Mark

Got it. All is clear (!) now. Thanks for the additional clarifications. --Mark

The parentheses in my example are important, and are not present in your latest code. The underlying problem is that AND is higher precedence than OR, and so the logic is incorrect without the parens. As you write it, "Control 'Living Rm Keypad Button A'" is tested only during the time periods, but "Control 'Dining Rm Entrance'" is always effective. Your two programs battle it out on this event, and it's indeterminate who wins. Put the parens in and see if that fixes it. --Mark

Michel, I'm simply trying to get clarification on that earlier statement you made, which does not seem to me to be consistent with itself. Perhaps we're using terminology differently. Just to make sure I understand this... So, any devices that currently reside in My Lighting on the ISY should have links present in the PLM. And restore PLM writes all those links (and effectively deletes all other links). Correct? This seems the important concept here. This is what I don't understand. I don't want "all" my devices to be removed, only some of them. Is this what you actually mean here? I.e., that devices I intended to be removed have actually been removed, as opposed to the devices that I want to stay? How is one absolutely certain (as you say) of this? In my case, there was no indication of the devices in My Lighting, so they appeared to have been removed. I didn't know there was a problem until I dumped the PLM links table. Is this how to make certain? Or, pay more attention to the event log to notice the "incomplete" error message, and assume errant links in this case? Thanks, --Mark