
justin.cool
Members-
Posts
171 -
Joined
-
Last visited
Everything posted by justin.cool
-
fitzpatri8 1. The outlets in the bathroom are GFCI protected by one GFCI outlet. 2. This could very well be contributing to the problem. As for flitering, here is what i have done to date: - All power stirps are pass through only, no surge suppressors or other stuff - half a dozen X-10 Pro 5A plug in filter modules - 3 20A wired in filters for dedicated branch circuits (AV equipment for example) - 4 five amp universal block filters from leviton - Minimized CFLs 3. It is not feasible to monitor or even track every new electronic device my daughters and wife bring into the house, much less where they plug them in. (However, I do applaud your "not a God-given right" approach). Thus, some amount of noise is just a fact of life. The impact has been isolated to this ONE branch circuit that has way too many outlets and lights on it, but will be a major rewire to fix. (It is on my list of things to do). I don't have a problem with that. However, all that said, I believe a Query type program is a reasonable way to mitigate the impact of the relatively low level of noise I am now experiencing. Thus, my question about the two query types that seem to be behaving differently. As usually happens, it is probably something boneheaded that I am doing that is causing the issue. So, I stand ready for enlightenment by those far more experienced and intelligent than me.
-
Oberkc, As suggested: Part 2 – With more double checking at each step Here are the steps, (with STATUS vs CONTROL in the program IF statement) Scenario 1 • Timer program status = FALSE • Check that is light is off, verify that ISY status is OFF. • Turn light ON via ISY. • Verify that light is ON. • ISY status for light is ON • Timer program status is TRUE, Timer has kicked in as expected. (“Running Thenâ€) • STOP the timer program via the Program Summary window – Status of the program remains TRUE • Run the ELSE statement of the timer program via the Program Summary window – Status of the program goes to FALSE • Verify that the light is ON • ISY status for the light is ON • Perform a manual Query (right click on mouse in admin console window) • ISY status for light is ON • The timer program kicks in as expected, status of timer program = TRUE • Verify that the light is ON Scenario 2: • Timer program status = FALSE • Check that is light is off, verify that ISY status is OFF. • Turn light ON via ISY. • Verify that light is ON. • ISY status for light is ON • Timer program status is TRUE, Timer has kicked in as expected. (“Running Thenâ€) • STOP the timer program via the Program Summary window – Status of the program remains TRUE • Run the ELSE statement of the timer program via the Program Summary window – Status of the program goes to FALSE • Verify that the light is ON • ISY status for the light is ON • Enable the Query program. • Save Changes in the program details window • ISY Status of light = ON • Verify light is ON • Timer program status = FALSE • Run the IF statement of the Query program via the Program Summary window. • Every 15 seconds a query is executed, as well as the Test KPL button A turned on. (Part of my debug in the program). • The timer program does NOT kick in, status remains FALSE. • Verify again ISY status of light = ON • Light is actually ON
-
Oberkc, Thanks for your quick response. Let me answer your questions a bit out of order: 1. CFLs. No CFL's, incandescent only. Have isolated most of the problem to the iHome docking stations my teens have. When I put the iHomes on filters, the communication is a lot more reliable, not perfect but better. However, the constant rearranging my daughters do makes this impractical. As for your question here: Here are the steps, (with STATUS vs CONTROL in the program IF statement) Scenario 1 • Turn light ON via ISY and timer kicks in as expected • STOP the timer program via the Program Summary window – Status of the program remains TRUE • Run the ELSE statement via the Program Summary window – Status of the program goes to FALSE • Perform a manual Query (note light is still ON) • The timer program kicks in as expected, status goes to TRUE and turns light off at end of timer period Scenario 2: • Turn light ON via ISY and timer kicks in as expected • STOP the timer program via the Program Summary window – Status of the program remains TRUE • Run the ELSE statement via the Program Summary window – Status of the program goes to FALSE • Enable the Query program. (Note, the light is still ON). • Run the IF statement of the Query program via the Program Summary window. • Every 15 seconds a query is executed, as well as the Test KPL button A turned on. (Part of my debug in the program). • The timer program does NOT kick in, status remains FALSE. Thus, the difference here is the results I get at the last step of each scenario. As for using Control, instead of Status. That may be more reliable, and will try that going forward, but the difference above is still vexing, or indicates that I really don’t understand what is going on. More likely the latter.
-
Programmed Query vs a Manual Query Another fundamental question that I have been unable to figure out…….and would therefore appreciate some guidance here. There seems to be a difference between a Manual Query, done through the admin console, vs a programmed query, done by an ISY-99 program at regular intervals. Let me explain: I have a bathroom light on a 30 minute timer (kids never seem to turn it off). However, it is on a troublesome circuit with lots of noisy devices, including my daughters cell phone chargers, laptop chargers, and multiple other small transformer powered devices. As a result, the timer program does not always detect the light being turned on and thus the timer will not initiate and be automatically turned off. I have been through filtering attempts, but there are just too many kid driven variables here to make it worthwhile. Thus I wrote a simple query program, right from the ISY-99 users guide, that queries the light every 5 minutes. I tested the concept by manually executing a query when the light was ON but the timer program status was FALSE, ie the timer was not running. When the manual query ran, the timer program kicked off and waited the programmed 30 minutes and then turned off the light as desired. However, under the same conditions, • The light was ON • Timer program status was FALSE I had the query program running, and the timer program status did NOT become TRUE, and thus did not kick off. In addition, it appeared that the ISY-99 was running a query by the dialog box / timer box and “system busy†for a split second. See programs below. What am I missing? Query Program If From 12:05:000 AM For 24 hours Then Repeat Every 15 seconds Set “Upstairs Bthroom Sink Lites†Query Set “Office Test KPL 15.62.7A†On Else - No Actions Timer Program If Status “Upstrs Bathroom Remote Swlinc†is On Or “Upstrs Bthroom Sink Lites†is On Then Wait 30 minutes and 10 seconds Set Scene “Upstrs Sink Lites†Off Else - No Actions 1. Note that the very short query interval of 15 seconds was done for my testing so I didn’t have to wait minutes for the query to take place. 2. The Office Test KPL is a test KPL next to my computer and was there for debug purposes. And it was turned ON every 15 seconds so I knew the program was executing.
-
scene stopped working after addin new insteon devices??
justin.cool replied to reakhavok's topic in ISY994
Dear reakhavok, As for your scene test failures from the ISY-99: I my limited experience, I believe you have to make sure there are no programs running / initiated by the devices under test. Until I disabled all programs I could never get the scene test to pass more than one device in the scene. -
So far, I have had mixed success in getting BEEP to work. See my listing below, not exhaustive by any stretch, but a start. Beep Support Listing Some Beep supported (2876SB) Icon Relay Switch v.39 (B2457D2) LampLinc BiPhy v.3A (2476S) SwitchLinc Relay W/ Sense v.37 No beep support in my configuration (2876DB) Icon Dimmer v.39 (2486S/WH6) KeypadLinc Relay v.33 (2476S) SwitchLinc Relay v.35 (2486DWH8) KeypadLinc Dimmer 8 Button v.2D
-
FAST ON Detection by ISY99 for Icon Dimmer - 2876DB
justin.cool replied to justin.cool's topic in ISY994
Lee, Thanks! Looks like 2.8 is in the not too distant future! Justin -
I have just started programming a number of Switchlinc / Icon dimmers and relays using FAST ON / OFF. However, it appears that with the Icon dimmer, 2876DB, the FAST commands are not detected by the ISY. In other words, when setting up a condition: If Control "Upstairs Hall Lite" is switched Fast On If the device, in this case, the Upstairs Hall Lite, is an Icon Relay (2876SB), or a Switchlinc relay (2476S) the ISY will let me set up this condition. However, if the device is an Icon dimmer, (2876DB), it will not show up in the list of devices when trying to set up a Control based condition. It would appear that this is by design. Can someone tell me if this is true or am I screwing something up as usual? Justin in Dallas
-
Lee, Excellent! Thanks for your effort and having to repeat something that has surely been done before on this forum! Justin in Dallas
-
Michel, Thanks! Justin in Dallas
-
Does anyone know where I can get a reasonably comprehensive guide to the Event Viewer?
-
Illusion, Will do that this evening. But not sure I understand how the button press is executing the desired command to the responder? Is the ISY doing it until it can be updated? Please enlighten me! Thanks! As always....learn something new every day!
-
Yes, I have programmed at least 2 buttons on my Rlinc without pressing the dim / bright buttons. And the scenes work just fine. However, in another string, I am having multiple communication issues trying to get Scene Test to pass. Through this forum I have finally gotten about an 85% pass rate through the following: 1. Turn off all programs while running Scene Test. 2. Disconnect / disable any devices that need updates during Scene Test. This turned out to be the Rlinc that I programmed without pressing the buttons. I had to remove the batteries AND disable it in the network listing in the admin console. 3. Replace two SWL's with V.35 firmware. 4. Fix the humidity reporting problem with the Venstar 1700 thermostat that was sending out bogus humidity updates every few seconds. (Separate thread in the forum on how to short two pins on the PCB on the Thermostat). Bottom Line: The RLinc was at the center of the problem because the system wanted to perform an update, and that hoses up the Scene Test. It is NOT totally clear why it needed an update.....but not pressing the dim/bright buttons may very well be related. Sorry for the long winded, round about answer.......but this was a classic multi-layered onion peeling problem, and I am still not totally done.
-
This has probably been answered before, but if so, I haven't found it in the forum. I noticed here a short while back after going up to s/w 2.7.15 that I no longer have to put my remote linc devices into "linking mode" (by depressing two buttons simultaneously) in order to make a change effecting one of them. Is this a new feature? Or am I missing something?
-
Official Firmware Release: 2.7.15
justin.cool replied to Michel Kohanim's topic in Previous Releases
Michel, Just to make it clear, you mention the dongle for the V2 thermostat. I have upgraded my thermo stat (ie the 2441), to V2, and now my ISY-99I reports the s/w as version v.91. Does that mean I have the dongle? -
Official Firmware Release: 2.7.15
justin.cool replied to Michel Kohanim's topic in Previous Releases
Michel, i ran: http://www.universal-devices.com/99i/2.7.12/admin.jnlp The error description was: "The application has requested a version of the JRE (version 1.6+) that is not installed." Once again, I am running 10.5.8 Mac OSX, with the latest java updates from apple. Here is the Java Exception message I got: JNLPException[category] at com.sun.javaws.Launcher.prepareLaunchFile(Launcher.java:681) at com.sun.javaws.Launcher.prepareToLaunch(Launcher.java:309) at com.sun.javaws.Launcher.prepareToLaunch(Launcher.java:214) at com.sun.javaws.Launcher.launch(Launcher.java:107) at com.sun.javaws.Main.launchApp(Main.java:405) at com.sun.javaws.Main.continueInSecureThread(Main.java:252) at com.sun.javaws.Main$1.run(Main.java:111) at java.lang.Thread.run(Thread.java:613) Just for the heck of it, I ran: http://www.universal-devices.com/99i/2.7.6/admin.jnlp Which was my last fully functional firmware version. (Ie could access admin console directly from home computer, OR from Univ Dev website). I got the same error..... [/u] -
Official Firmware Release: 2.7.15
justin.cool replied to Michel Kohanim's topic in Previous Releases
Michel, That was fast! I will give it a shot. Justin -
Official Firmware Release: 2.7.15
justin.cool replied to Michel Kohanim's topic in Previous Releases
Michel, Thank you very much for the prompt response. I can deal with having to get Snow Leopard, in the not too distant future. However, in the meantime, i cannot access my admin console at all. I assume that when you say that you need java 6 functionality for the admin console, you mean for 2.7.15? As I did not have an admin console problem through Univ Dev website for 2.7.12. Is it possible to fix the problem that prevented me from accessing the admin console directly (not going through the Univ Dev website) in 2.7.12? If that can't be fixed, i will have to go back to 2.7.6, and I have a number of newer devices, like dual band lamp lincs, upgraded thermostats, etc etc that could present a problem. Will all my programs still work if I go back to 2.7.6? But quite frankly, if I can't get to my admin console, I dont believe I have a way to go back to 2.7.6?????? In other words, HELP, please! Justin -
Official Firmware Release: 2.7.15
justin.cool replied to Michel Kohanim's topic in Previous Releases
I am running Mac OS X Leopard 10.5.8 I have downloaded the very latest java updates from Apple. In about the middle of March I upgraded to 2.7.12 from 2.7.6. After the upgrade to 2.7.12, I lost the ability to directly access my admin console, I had to go through the universal-devices support website. I accessed my admin console just this past Monday evening, 3 May, using the Univ-devices website, without any issues. As of the evening of 5 May, I can no longer get to my admin console at all. I get: Applet com.universaldevices.client.ui.UDClientApplet notinited at the bottom of the console window, using Firefox or Safari. I tried following the advice above from "Illusion", and was not successful. I must admit, I do not know how to set "timeout to 25000" so I was not able to follow that part of the instructions. This could all be a coincidence, or related to the new release. Any help would be greatly appreciated. NOTE: My internet connection was both wireless and by cable, with no difference in the result. -
Michel, Given your suggestion of just removing the KPL from the ISY, doesnt that potentially leave a lot of loose links out there in the system? Somewhere I thought I had heard that. If it is a clean operation, I will certainly do if for the remaining 6 KPLs that dont have the s/w version recognized by the ISY. Thanks again!
-
Michel, Excellent results now! The s/w version came back as v.2D with autodetect. Thank you very much. That KPL is now solid as a rock, doing exactly what I expected. Now I have 6 more to go!! However, i must say it took a while to: - Remove all 8 buttons of the KPL from all the scenes - Factory reset the KPL - Auto detect - Add them all back to the scenes, - Get the ramp rates and On Levels from the "Copy Scene Attributes........" With the larger, more complex scenes, there was a lot of idle time. Is there a quicker way to accomplish this process???? Really appreciate your support, it has kept me a believer in this system. Thanks again! Justin
-
Rand, Good to hear from you again, we haven’t spoken for some time now, hope all is well. In response to your question. When I set the Level locally, via the ISY, for the Dining Rm KPL-A (load), to 35%, and I initiate the scene from Dining Rm KPL-H, here is what I get: Device Status Brkfst Rm KPL A Off Brkfst Rm KPL H On Dining Rm Lamp 85 Dng Rm KPL A On Dng Rm KPL H On Kit Bar Lites On Kit KPL A 55 Kit KPL H On If I just turn on the load of Dng KPL A manually by the button, the on level is 35%. When I initiate the scene from the Brkfst KPL H, here is what I get: Device Status Brkfst Rm KPL A On Brkfst Rm KPL H On Dining Rm Lamp 85 Dng Rm KPL A 55 Dng Rm KPL H On Kit Bar Lites On Kit KPL A 55 Kit KPL H On Basically the same results as I posted for Michel above/below. And this is of course the desired result for the Kit and Dng KPL loads. Thanks! Justin Monger
-
Michel, Thanks for the prompt response. Here are the answers to your questions: The ISY-99 reports the following for these KPL devices: Kit Keypad 2486 DWH8 KPL Dimmer 8 button v.00 Brkfst Rm KPL 2486S/WH6 KPL Relay v.00 Dng Rm KPL 2486D KPL Dimmer v.00 The issue is identical with both Din Rm KPL and Kit KPL, in that the KPL H button turns on/off the scene but the local load on that KPL, only comes on at 100% and with a 0 second ramp rate, despite being set to 55% and a 2 second ramp rate. I have summarized the results below in the table, with the status of each case depending in which device was used to initiate the scene. Note that the Brkfst KPL H will not turn Brkfst KPL A load off when it is turned On, and this is consistent with your earlier postings. I can live with this minor quirk. Initiator / Status ISY Brkfst Kit Dng Rm KPL H KPL H KPL H Brkfst Rm KPL A Off On Off Off Brkfst Rm KPL H On On On On Dining Rm Lamp 85 85 85 85 Dng Rm KPL A 55 55 55 On Dng Rm KPL H On On On On Kit Bar Lites On On On On Kit KPL A 55 55 On 55 Kit KPL H On On On On When I do a compare, of the Dining Room KPL link table to the ISY 99 device link table, here is what I get, 10 “Identical†and a bunch of “Extra Recordâ€. Could these extra records be an issue. I have NOT done a factory reset and restore, maybe that should be my next move??? [identical] 0FF8 : A2 36 0F.D5.9D FF 1F 06
-
Michel, I finally had time to upgrade to 2.7.12 per your suggestion. And the problem has changed, but not as I would have expected. Let me describe in more complete detail what I have: • 3 KPLs, two are 8 button (dimmers) and one is a 6 button (relay). o Kit KPL (8 button dimmer) o Dining Rm KPL (8 button dimmer) o Brkfst KPL (6 button relay) • All three KPLs have load/main buttons that are part of the Kitchen Evening Scene (abbrev Kit Even Sc). • Button H on all three KPLs are linked to turn on/off the Kit Even Sc. • All linking in my entire network has been done through my ISY-99. • When the scene is controlled from the ISY-99 admin console, it behaves as expected. • When the scene is controlled from the 6 button KPL, everything behaves as expected. • However, when I turn on /off the scene from either of the other two KPLs, (8 button dimmer types), I get the same, unexpected result. Specifically, when I turn the scene on via the Kit KPL, the main device on that KPL comes on 100%, with a ramp rate of 0 sec, despite being set for 55% and 2 sec ramp rate. (Note, as described in my long winded earlier post, I cannot set the level or ramp rate for this load, with the Kit KPL H button as the controller.) Also note that the Dining Rm KPL device comes on as expected (55% and ramp rate of 2 secs) when the scene is activated by the Kit KPL H button. • Likewise, if I activate the scene from the Dining Rm KPL-H button, the Kit KPL main load comes on 55% and ramp rate 2 secs, but the Dining Rm KPL main load comes on 100%, with a ramp rate of 0 sec, despite being set for 55% and 2 sec ramp rate. Firmware 2.7.12 has allowed me to reliably turn on/off the scene from a sub button and have the main load on that KPL, in that scene, be controlled as well, but the on level and ramp rates are 100% on and 0 secs. Thus, some progress has been made, but still not what I would have expected. Is this the way it is supposed to work? v/r Justin _____________________________________
-
My ISY is running 2.7.6. I recently upgraded, in the last month. And nothing seemed to change with respect to this problem.