
IndyMike
Members-
Posts
1632 -
Joined
-
Last visited
Everything posted by IndyMike
-
Improper Programm Behavior Since Firmware Update.
IndyMike replied to apostolakisl's topic in ISY994
Hello Lou, Yes - I believe that in a RF coupled system, A device that transmits from the opposite phase will be heard by the PLM on the 1st hop. Here's a bit better chart - A dual band PLM could conceivably hear a RF transmitter during the original transmit (HOP 0). This wouldn't buy you anything in terms of system response since no commands are transmitted with a hop count less than 1 (that I'm aware of). The PLM must wait until the HOP count expires before it can respond to the transmission. I also do not know what the PLM (or any RF device) will do if confronted with RF and Powerline information that doesn't agree. Hope that helps, IM -
Improper Programm Behavior Since Firmware Update.
IndyMike replied to apostolakisl's topic in ISY994
Hi Lou, I believe it requires 1 Hop for the Insteon RF couple. Using the chart below: 1) Initial transmit requires 5 zero crossings of the 60 Hz AC. 2) Between the Initial transmit and the 1st hop transmit there is one "open" zero crossing. The RF devices communicate during this half cycle. 3) RF devices will then transceive the RF info onto the powerline during the 1st HOP. -
Improper Programm Behavior Since Firmware Update.
IndyMike replied to apostolakisl's topic in ISY994
Hi Lou, As Lee indicated, the InsteonDetails guide gives you the formatting and bit structure of the messages transmitted over the powerline. The information displayed in the Event Viewer is actually Modem responses back to the ISY. The ISY tries to add descriptors of the information being received. The transmitted/received messages are preceded with codes like: "02 62": modem acknowledging a standard message from the ISY. ISY tags with the [iNST-ACK] "02 50": standard message received from a device. ISY tags with the [iNST-SRX] Thu 09/29/2011 08:24:14 PM : [iNST-ACK ] 02 62 0A.DB.0B 0F 2B 05 06 PEEK (05) Thu 09/29/2011 08:24:14 PM : [iNST-SRX ] 02 50 0A.DB.0B 13.22.F9 2B 2B 00 PEEK (00) Some of these codes are included in the modem developers guide: http://www.smarthome.com/manuals/2412sdevguide.pdf The Insteondetails paper defines the formatting of the remainder of the message. It does not give the actual command1 and command2 codes. Some of these are included in the Insteon command tables document: http://www.insteon.net/pdf/INSTEON_Command_Tables_20070925a.pdf From the example presented above, command1 is 0x2B which indicates that this is a peek operation - reading a device link table (tagged that way by the ISY). Command2 is 0x05 which is address that location that is being requested (again indicated by the ISY. Clear as mud, right? Unfortunately there is no single guide for this. You need to understand the protocol, modem commands, and device commands/responses as one package. Sorry but that's about the best I can do. I'm not proficient at reading this stuff either. Lee is - when he speaks, I listen and try to learn. I have learned from this thread. If Lee convened a course on the topic, I'd attend. IM -
Improper Programm Behavior Since Firmware Update.
IndyMike replied to apostolakisl's topic in ISY994
Hi Lou, I tried your program and am sorry to report that I receive the same results as reported by Tim. I tried multiple ramp rates, on/off/fast on combination's - worked correctly every time (100+ attempts). Is it possible that you're getting a "double bounce" via RF? I have only one accesspoint installed. Not sure whether "many" AP's could produce a bounce that the ISY would read as a second press on the switch. If Status 'Basement / BSMT Fam Cans' is Off And Control 'Basement / BSMT Fam Cans' is switched Off Then Set 'Basement / BSMT Fam Cans' 25% Else - No Actions - (To add one, press 'Action') -
J0dan, Chris, Michel, Lou, and anyone else who's time I wasted with my post - My apologies - it was a complete cluster... I was attempting to show a program variable used as a latch - I butchered it. For what it's worth, the following is what I should have posted. Lou's approach using variables is superior. On Program with Latch If ( Status '1st Floor / Bar Cans' > Off Or Status '1st Floor / Bar Lamp' is On Or Status '1st Floor / Dinnette SWL' is On Or Status '1st Floor / Fam Room / Fam Fan' is On Or Status '1st Floor / Fam Room / Family Room LampLinc' > Off Or Status '1st Floor / Fam Room / Family Room Lamplinc' > Off Or Status '1st Floor / Fam Room / Fireplace Spots' > Off Or Status '1st Floor / Foyer' > Off Or Status '1st Floor / Fam Room / Fam KPL 1 - Wall' > Off ) And Program '1st Floor Status On Latch' is False Then Run Program '1st Floor Status On Latch' (Then Path) Set Scene 'SC 1st Floor Status On' On Else - No Actions - (To add one, press 'Action') Status off Program with Latch If ( Status '1st Floor / Bar Cans' is Off And Status '1st Floor / Bar Lamp' is Off And Status '1st Floor / Dinnette SWL' is Off And Status '1st Floor / Fam Room / Fam Fan' is Off And Status '1st Floor / Fam Room / Family Room LampLinc' is Off And Status '1st Floor / Fam Room / Family Room Lamplinc' is Off And Status '1st Floor / Fam Room / Fireplace Spots' is Off And Status '1st Floor / Foyer' is Off And Status '1st Floor / Fam Room / Fam KPL 1 - Wall' is Off ) And Program '1st Floor Status On Latch' is True Then Run Program '1st Floor Status On Latch' (Else Path) Set Scene 'SC 1st Floor Status On' Off Else - No Actions - (To add one, press 'Action') Program Latch If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then - No Actions - (To add one, press 'Action') Else - No Actions - (To add one, press 'Action')
-
Michel, I tested the above code in a few "status" programs that I use. Curiously, the program summary shows the Program executing the "Then" statement even though the condition Program state is shown as "true". Watching the event viewer, I can see that the Then clause is not being executed - but the program summary page indicates that it is. Am I setting up a transient condition that is confusing the ISY?
-
Hello j0dan, If you are issuing the LED command from within the Then statement, the following "Lockout" should work. The program will execute the Then statement when the first lamp is turned on and the Program status will become "True". Turning on subsequent lamps will not execute the Then statement since the program is already "True".
-
Release 3.1.7 (Beta) Is Now Available
IndyMike replied to Michel Kohanim's topic in Previous Releases
Upgrade went smoothly (V3.1.6 to V3.1.7). Some good results, some not so good - 1) Verified that the irrigation calculation persists through ISY resets - thank you. 2) Verified that Generic X10 Devices (non-queryable) are not interrogated during "my lighting" query - thank you again. 3) Lost the "batch write control" capability that was a feature of the PRO version. The control buttons are missing in the GUI and I do not see a method of activating things through the menu system. I really hope this feature hasn't been eliminated - I used it constantly. IM -
Hello ELA, It's probably very naive on my part, but I don't normally think of a refrigerator (motor load) as being a problem device for Insteon. I say naive because manufacturers are constantly adding new bells and whistles to appliances. It's very possible that the new generation refrigerators do appear capacitive as opposed to my 25 year old Kenmore. I'll find out soon enough - my better half is keen to replace the Kenmore. Beyond the above, I don't doubt for an instant what you are seeing. I'm simply questioning whether a true resonant condition can exist for any significant period of time with other loads being activated. While I'm sure that it can and does happen, I've never been able the capture this condition "in the act". Looking forward to your conclusion when you get to moving the refrigerator (not a task I take lightly). IM
-
EDIT: I've just re-read your post and am not sure whether your outlets are on the same breaker (branch) or different breakers. If the outlets are on different breakers it's also possible that you are measuring different phases. Voltage differences across the phases are not uncommon when there is a load imbalance (one phase heavily loaded, the other lightly). If your comfortable with it, try measuring the voltage at the load panel for each phase. If you have no loads installed on your outlets, the voltage at the panel should be the same as the outlet voltage. If it is not, you either have a very bad connection or a device drawing significant current. The resonances that ELA and I were referring to apply at the Insteon frequencies of 130 KHz. They do not apply to the 60 Hz power distribution within your home. Original message below- Mark, I am very much hoping that you simply had a bad connection to your voltmeter when you measured the 114V. Assuming that there was no load on the outlet at the time, a 3 volt drop (117 to 114) would qualify as an extremely bad connection. Your meter should be high impedance and therefor be drawing an insignificant amount of current and no noticeable voltage drop. Please inspect/tighten the connections to this outlet and retest. If the drop is occurring at the wire attachment, it will generate heat (i.e. dangerous). It's possible that the receptacle "prongs" were simply oxidized and not allowing your meter to make a good connection. The acid test would be to apply a light load (60 watt incandescent) and monitor for a voltage drop. Again, a 60W load should be insignificant. If you measure a drop with the load installed, replace the outlet and re-test. IM
-
Hello Mark, Let me start by saying that I like your description of the PLM communicating into the load panel. Assuming that PLM is close coupled to the panel, it will attempt to drive the loading at that point to the full 3.2 Vp-p. The load at the panel is a complex composite of all of the loads in your home reflected back to the panel. I say attempt because it's possible that the signal loading at the panel is high enough that the PLM can't drive it to full level. The signal will then fan out across the branch connections on that phase. Signal degradation on a given branch can usually be viewed on a branch by branch basis. If you have a passive coupler that the panel, the PLM signal will be coupled in phase at a lower level and also fan out on that phase. If you are using a RF coupler, the PLM signal will be coupled on the next hop, but again at whatever level the RF coupler can drive into the load it "sees" (presumably 3.2Vp-p). ELA is exactly correct that the signal propagation through the branch circuits can be an extremely complex "transmission" with resonances and nodes as the R-L-C characteristics interact. That said, ELA and I share similar backgrounds and tend to think in these terms (EMI/EMC background - other engineers consider us to be "geeks"). Not speaking for ELA, but I sometimes drift off into complex theories of what might happen rather than gathering all the facts and focusing on what is happening. For most installations, you can consider the powerline as a simple resistive divider circuit. The longer the line, the more series resistance. The more loads installed, the lower the resistance to return (more signal degradation). This resonance condition was exactly what I was thinking of when you described the following: Since your SWL responded well to an off command, I was theorizing that you had a long transmission line and the added Inductive load of the transformer(s) was changing the powerline impedance and effectively killing a resonance at that point. I had hoped that you would install a incandescent lamp at the IOLinc location (not at the switchlinc) and thereby change the R-L-C loading for both the On and Off cases. Although you mis-interpreted the intent, you may have provided enough information to disprove this theory: 1) Your Switchlinc is close coupled to your media center and both are close coupled to the panel (18 inches - not a long line). 2) Your PLM is close coupled to the panel. 3) Is your PLM on the same phase as the SWL, or at least bridged at the panel? If your PLM is on the same phase (or coupled at the panel), your distances should be too short to set up a resonant condition (low line impedance). Adding an incandescent load would not have accomplished anything. A more likely scenario would be - 1) Your media center components are significant "signal suckers". Since these are close to the panel, they could be degrading signals from distant transmitters. 2) You have some noise on this circuit. The combination of noise and "signal suck" are degrading the inbound PLM signal to the point where it is marginal. When the SWL is turned on, you are adding the inductive load of the transformer and effectively filtering some of the noise at the SWL location. This allows the device to hear to the "off" command. Since your media center does appear to be a source of loading/noise (and it's close to the panel), I would agree with the others that filtering this circuit would be wise to prevent possible problems at the PLM. I am also curious whether you swapped to the opposite phase when you reconnected your SWL. In regard to your last comment: What ELA stated is absolutely true in a very strict controlled environment. Resonances will happen, particularly on long lines. In the home, this is normally a "transient" condition since the impedance of our home powerlines are constantly changing (every time we switch on or plug in a device we change the impedance). While I've been able to setup and measure resonances under controlled conditions, I have never observed one in the home. I have witnessed 2 instances of "global signal damagers": 1) The Boosterlinc - these devices actively interfere with insteon signals. The newer "Insteon blessed" devices are better than the old models, but still interfere with low level Insteon signals (unless there is a Rev 3.0 out there). 2) Oscillating power devices - These can be triac dimmer outputs that are "unhappy" with the load (CFL) or other power outputs that are on their last legs. While oscillating, these devices can draw significant power and radiate long distances (lower frequency than Insteon). Noise produced by these devices can activate the Automatic Gain Control (AGC) on Insteon devices and render them "deaf" to valid transmissions. Not sure whether this helps or simply confuses things further... IM
-
Hi Mark, I've been watching from a distance and have not had anything to add because Lee's diagnosis has (as usual) been excellent. You're last post indicated that the "off command" may be working properly, while the "on command" shows the delay. This is rather odd unless the powerline is interacting with the installed devices on this circuit. [*:14x3knq3]Is this a GFCI or AFCI circuit? [*:14x3knq3]If turning on the LED transformer does improve communications, it could be performing the function of a line terminator. Could you try plugging in a Incandescent lamp in the IOlinc location?
-
Release 3.1.6 (Beta) Is Now Available
IndyMike replied to Michel Kohanim's topic in Previous Releases
Hello Michel, The Icon is fully functional when used in the "Automatic" messaging mode which the ISY defaults to. Issues only arise when the user manually switches to the "Device reported mode". I completely agree with your assessment of the priority. I noted the addition of I2 support for the Icon in the release notes and wanted to give feedback. Sincerely, IM -
Release 3.1.6 (Beta) Is Now Available
IndyMike replied to Michel Kohanim's topic in Previous Releases
Hi Michel, Great idea - I had forgotten about the manual scan. The manual scan works like a charm using a start address of 0x00F8. Sun 08/14/2011 08:43:02 PM : [14 78 3B 1 ] Using engine version i2 for 'BSMT Bed' Sun 08/14/2011 08:43:02 PM : [iNST-ACK ] 02 62 14.78.3B 1F 2F 00 00 00 00 FF 01 00 00 00 00 00 00 00 00 00 06 (00) Sun 08/14/2011 08:43:02 PM : [iNST-SRX ] 02 50 14.78.3B 13.22.F9 2B 2F 00 (00) Sun 08/14/2011 08:43:02 PM : [standard-Direct Ack][14.78.3B-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Sun 08/14/2011 08:43:02 PM : [iNST-ERX ] 02 51 14 78 3B 13 22 F9 11 2F 00 01 01 00 FF 01 A2 00 13 22 F9 FF 1F 00 00 Sun 08/14/2011 08:43:02 PM : [Extended-Direct][14.78.3B-->ISY/PLM Group=0] Max Hops=1, Hops Left=0 Sun 08/14/2011 08:43:03 PM : [iNST-ACK ] 02 62 14.78.3B 1F 2F 00 00 00 00 F7 01 00 00 00 00 00 00 00 00 00 06 (00) Sun 08/14/2011 08:43:03 PM : [iNST-SRX ] 02 50 14.78.3B 13.22.F9 2B 2F 00 (00) Sun 08/14/2011 08:43:03 PM : [standard-Direct Ack][14.78.3B-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Sun 08/14/2011 08:43:04 PM : [iNST-ERX ] 02 51 14 78 3B 13 22 F9 11 2F 00 01 01 00 F7 01 A2 10 13 22 F9 FF 1F 00 00 Sun 08/14/2011 08:43:04 PM : [Extended-Direct][14.78.3B-->ISY/PLM Group=0] Max Hops=1, Hops Left=0 Sun 08/14/2011 08:43:04 PM : [All ] Writing 0 bytes to devices -
Release 3.1.6 (Beta) Is Now Available
IndyMike replied to Michel Kohanim's topic in Previous Releases
Hello Michel, I1 (peak/poke) operations work fine with the Icon. It's the I2 read/write operations that present a problem. As expected, I2 restore operations fail for the same reason as the link read operation. Honestly, not that big a deal with the Icon since it doesn't have that many links. Just need to make sure that "Automatic messaging" is checked in the ISY options to enable the I1 mode. If this were a KPL, I'd be whining a bit more. Thanks for the prompt reply, IM -
Release 3.1.6 (Beta) Is Now Available
IndyMike replied to Michel Kohanim's topic in Previous Releases
Revision 3.1.6 downloaded and installed without issue. Attempted a link table read from my 2876SB Icon V.39 using I2 protocol - no go. There is some upside. Previous revisions of the ISY firmware really wouldn't communicate much at all with this device in I2 mode. With rev 3.1.6 things are a bit more clear. The ISY appears to be reading from start address 0FFF while the device is responding with start address 00FF. The ISY rejects the response and then "errors out" after 3 attempts (log below). The data reported by the Icon is correct for the first link record. I believe this is due to the smaller link table in the more recent versions of the Icon switch (verified by LeeG some time ago). Not sure that I can call this a bug. Just another difference in the module configuration (exception) that needs to be accounted for in the ISY. Sorry guys, I've lost track of the number of "exceptions" and "workarounds" that you've already implemented. This may be another one for the list. IM Sat 08/13/2011 12:29:33 PM : [14 78 3B 1 ] Querying engine version Sat 08/13/2011 12:29:33 PM : [iNST-ACK ] 02 62 14.78.3B 0F 0D 00 06 (00) Sat 08/13/2011 12:29:33 PM : [iNST-SRX ] 02 50 14.78.3B 13.22.F9 2B 0D 01 (01) Sat 08/13/2011 12:29:33 PM : [standard-Direct Ack][14.78.3B-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Sat 08/13/2011 12:29:33 PM : [14 78 3B 1 ] Retrieved engine version is i2 Sat 08/13/2011 12:29:34 PM : [14 78 3B 1 ] Using engine version i2 for 'BSMT Bed' Sat 08/13/2011 12:29:34 PM : [iNST-ACK ] 02 62 14.78.3B 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 00 06 (00) {isy requesting data from address 0F FF} Sat 08/13/2011 12:29:34 PM : [iNST-SRX ] 02 50 14.78.3B 13.22.F9 2B 2F 00 (00) Sat 08/13/2011 12:29:34 PM : [standard-Direct Ack][14.78.3B-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Sat 08/13/2011 12:29:34 PM : [iNST-ERX ] 02 51 14 78 3B 13 22 F9 11 2F 00 01 01 00 FF 01 A2 00 13 22 F9 FF 1F 00 00 {icon responding with data from address 00 FF} Sat 08/13/2011 12:29:34 PM : [Extended-Direct][14.78.3B-->ISY/PLM Group=0] Max Hops=1, Hops Left=0 Sat 08/13/2011 12:29:34 PM : [Ext. Msg. Handler] Unexpected Response (i.e. DB range): ignored {response rejected due to invalid address range} Sat 08/13/2011 12:29:43 PM : [iNST-ACK ] 02 62 14.78.3B 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 00 06 (00) {read attempt #2} Sat 08/13/2011 12:29:44 PM : [iNST-SRX ] 02 50 14.78.3B 13.22.F9 2B 2F 00 (00) Sat 08/13/2011 12:29:44 PM : [standard-Direct Ack][14.78.3B-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Sat 08/13/2011 12:29:44 PM : [iNST-ERX ] 02 51 14 78 3B 13 22 F9 11 2F 00 01 01 00 FF 01 A2 00 13 22 F9 FF 1F 00 00 Sat 08/13/2011 12:29:44 PM : [Extended-Direct][14.78.3B-->ISY/PLM Group=0] Max Hops=1, Hops Left=0 Sat 08/13/2011 12:29:44 PM : [Ext. Msg. Handler] Unexpected Response (i.e. DB range): ignored Sat 08/13/2011 12:29:53 PM : [iNST-ACK ] 02 62 14.78.3B 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 00 06 (00) {read attempt #3} Sat 08/13/2011 12:29:54 PM : [iNST-SRX ] 02 50 14.78.3B 13.22.F9 2B 2F 00 (00) Sat 08/13/2011 12:29:54 PM : [standard-Direct Ack][14.78.3B-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Sat 08/13/2011 12:29:54 PM : [iNST-ERX ] 02 51 14 78 3B 13 22 F9 11 2F 00 01 01 00 FF 01 A2 00 13 22 F9 FF 1F 00 00 Sat 08/13/2011 12:29:54 PM : [Extended-Direct][14.78.3B-->ISY/PLM Group=0] Max Hops=1, Hops Left=0 Sat 08/13/2011 12:29:54 PM : [Ext. Msg. Handler] Unexpected Response (i.e. DB range): ignored Sat 08/13/2011 12:29:58 PM : [All ] Writing 0 bytes to devices -
Michel, Fix verified with V3.1.5.
-
Release 3.1.5 (Beta) Is Now Available
IndyMike replied to Michel Kohanim's topic in Previous Releases
Hello ryarber, I've had problems communicating with my 2876sb Icon (V.39) when using I2 mode. Check to make sure that the ISY is set to use the "Automatic" communication mode (menu item: "Link Management/Advanced Options/Automatic"). I can communicate with my 2876DB with V3.1.5 when using I1 mode. I2 mode is a no-response (same with previous revisions of the ISY firmware). -
30 minute turnaround on a bug fix? I'd be willing to wager that's a new benchmark. I've become accustomed to excellent service from the UDI team, but will try not to hold you to this standard for future releases. Confirmed proper triggering with V3.1.5. Using a .6281 Irrigation requirement, the ISY correctly evaluated a true (> .62) and a false (>.63) condition. Thanks again for excellent support of an already outstanding product, IM
-
Hello Michel, In a word - Yes. I do see the correct status after termination of the Progress Bar. After the initial query (first 30 - 40 seconds), I can actually change linked devices and watch them update in the Admin console (progress bar continues for an additional ~ 5 minutes).
-
Hi Michel, I had the same thought - no Joy. I checked the "Irrigation Complete" Email and the Irrigation Requirement value had not changed. Unfortunately, this Email was generated immediately after I had issued the "cycle complete" command. The ISY had apparently not had time to update the value. I was also logging data at 1 hour intervals. The interval prior to irrigation shows the "requirement" at .2644 inches. The interval after irrigation shows 0 inches (reset by the cycle complete command). 3 AM Log (Prior to Irrigation) Date,Time,ET,Current_Temp,High_Temp,Low_Temp,Humidity,Wind_Speed_AVG,Wind_Speed,Pressure,Light,Rain_today,Dew Point, Irrigation Requirement, Water deficit 2011/07/14,03:00:25,0.1229 inches/day,62.2 °F,64 °F,62 °F,78 %,2 mph,3 mph,30.08 inches,0 %,0 inches, 55 °F, 0.2644 inches, 0.2644 inches 8 AM Log (After Irrigation - Irrigation requirement set to 0) Date,Time,ET,Current_Temp,High_Temp,Low_Temp,Humidity,Wind_Speed_AVG,Wind_Speed,Pressure,Light,Rain_today,Dew Point, Irrigation Requirement, Water deficit 2011/07/14,08:00:25,0.1691 inches/day,62.7 °F,64 °F,61 °F,59 %,5 mph,4 mph,30.09 inches,7.4 %,0 inches, 48 °F, 0 inches, 0.2644 inches I've been playing with test programs varying the "irrigation requirement" trigger. I had thought there might be a factor of 10 error somewhere. Again no joy. The following program still triggers with the irrigation requirement of .2612 as shown below. The irrigation requirement qualifier is limited to 20 inches - I can't test a factor of 100 (26.12 inches). If I'm doing something wrong, I sure can't see it. Update: I rearranged the condition to test for Irrigation Requirement < 20.00 Inches - the program does not run. Do we have a factor of 100 error here? Thanks, IM If Time is 3:36:00PM And Module 'Climate' Irrigation Requirement > 20.00 Then Send Notification to 'Yahoo' content 'Irrigation Start' Wait 30 seconds Send Notification to 'Yahoo' content 'Irrigation End' Else - No Actions - (To add one, press 'Action')
-
My irrigation program triggered today and logged the values to Email. Obviously, there's something I don't "get". The logged values indicate that my irrigation requirement was at 0.2644 inches while my trigger was set at >= 0.35 inches. The program ran and completed (logged the irrigation end Email) despite the trigger value. What am I missing? Do I need to copy the Irrigation requirement in order to use it as a condition? Thank you, IM Program If Time is 4:00:00AM And Module 'Climate' Irrigation Requirement >= 0.35 Then Set 'Sprinkler-Relay' On Send Notification to 'Yahoo' content 'Irrigation Start' Wait 3 hours Set 'Sprinkler-Relay' Off Irrigation - Cycle Complete Send Notification to 'Yahoo' content 'Irrigation End' Else - No Actions - (To add one, press 'Action') Values logged at program start: Date, Time, Deficit, ET0, Requirement 2011/07/14, 04:00:01, 0.2644 inches, 0.119 inches/day, 0.2644 inches
-
Hello Michel, Answers below - Correct - with the programs disabled, the progress bar terminates is roughly 40 seconds. Not in this test - the above program was the only one enabled. ...BTW - I wouldn't call this a "tardy reply". We users may be demanding, but we do recognize that you need to sleep at times. Thanks again, IM
-
Hello Michel, Absolutely - The program is extremely simple - it monitors my second floor devices and updates KPL buttons to indicate the ON/OFF status of the second floor. There are 3 KPL's in the "2nd Floor Status" scene spread throughout the house. I have a number of "status" programs that will produce the same effect, this was the simplest. Enabling this program by itself will cause a "several minute" progress bar if I query My Lighting. Curiously, if I query the Scene that contains all of my Insteon wired devices ( No 2420's or remotelincs) the progress bar responds properly and terminates after roughly 30 seconds. The scene contains all of the devices listed in the program (program is run during the query). As always, thank you for the support IM If ( Status '2nd Floor / David Switch' is Off And Status '2nd Floor / Kath Icon' is Off And Status '2nd Floor / Master Fan' is Off And Status '2nd Floor / Master KPL 1 - Master Overhea' is Off And Status '2nd Floor / Matt Inline' is Off ) Then Set Scene 'SC 2nd Floor Status' Off Else - No Actions - (To add one, press 'Action')
-
Hello backinthelab, My Hunter controller is actually the Grandfather of the Pro-C (it's a 10 year old SRC controller). The connections on the Pro-C are a bit different, but should still work. Have a look at page 8 of this link: http://www.hunterindustries.com/Resources/PDFs/Owners_Manuals/Domestic/lit329w.pdf. The IOlink will wire in the location for the rain sensor. I connected the NO (normally open) and common terminals of the IOLink to the sense terminals of the Hunter. Polarity doesn't matter - you're using the IOlink as a switch input to the Hunter. When connected to the NO/COM terminals, the Hunter will be enabled when the IOLink is ON (relay closed).