mrp

We get most of our rainfall one week in the year. It finally rained again today, and FTWR1 should be showing non-zero values for rainfall-rate and max-rainfall rate. Thanks for looking into it! mrp

Yes, rain-rate-max is listed and the regular rain-rate is populated correctly on the Climate tab. The LocationID is FTWR1. I didn't realize it was an unusual stat. Its not important to me--the Admin console just made the information available as part of the "Add Variable" button, and I didn't understand why it didn't work. cheers, mrp

Sorry for omitting that information. Yes, the Admin Console reports fine, and the other WB variables seem to work fine. Here is the content of my Customization: *** Automatic Watering Start *** Time: ${sys.date} ${sys.time24} (sunrise: ${sys.sunrise24}; sunset: ${sys.sunset24}) --- Current Weather --- Current Temperature: ${mod.weather.temp.current} (feels like: ${mod.weather.temp.feelslike}) Temperature Rate: ${mod.weather.temp.rate} (hi: ${mod.weather.temp.high}, low: ${mod.weather.temp.low}) Humidity: ${mod.weather.humidity} (Rate: ${mod.weather.humidity.rate}) Pressure: ${mod.weather.pressure} (Rate: ${mod.weather.pressure.rate}) Windspeed: ${mod.weather.wind.speedavg} avg (${mod.weather.gust.speed} gust) Wind Direction: ${mod.weather.wind.directionavg} avg (${mod.weather.wind.direction} current) Rain Today: ${mod.weather.rain.today} Rain Rate: ${mod.weather.rain.rate} current (${mod.weather.rain.ratemax} max) --- Irrigation Status --- Days since last water: ${var.2.10} Is Automatic Watering Enabled: ${var.2.11} Water Restriction Stage: ${var.2.14} Evapotranspiration: ${mod.weather.irrig.et0} Irrigation Requirement: ${mod.weather.irrig.req} Water Deficit Yesterday: ${mod.weather.irrig.deficit} And here is the content of the email that I receive... *** Automatic Watering Start *** Time: 2012/05/12 02:59:12 (sunrise: 06:29:12; sunset: 20:15:24) --- Current Weather --- Current Temperature: 64.9 °F (feels like: 65 °F) Temperature Rate: 0.2 °F/h (hi: 65 °F, low: 63 °F) Humidity: 91 % (Rate: 0 %/h) Pressure: 29.98 inches (Rate: 0 inches/h) Windspeed: 2 mph avg (5 mph gust) Wind Direction: WNW avg (NW current) Rain Today: 0 inches Rain Rate: 0 inches/h current ( max) --- Irrigation Status --- Days since last water: 6 Is Automatic Watering Enabled: 1 Water Restriction Stage: 0 Evapotranspiration: 0.1158 inches/day Irrigation Requirement: 0.5194 inches Water Deficit Yesterday: -0.0413 inches For this given email, the Max Rain Rate should have been "0.04 inches/hr". Hope this helps & thanks again! mrp P.S. - As a future enhancement, could we have a button on the Emails/Notifications-Customizations page that "sends a test email" for the entry selected? This would make certain that I've got everything the way I want it without having to kludge-run a test program to get the effect. Thanks. Also, some email servers jettison mail with 'empty bodies' as spam. Google is a good example of this. Perhaps a note toward the bottom warning users not to create email with empty bodies (e.g., subject only). It took me a couple of hours to figure out this was the problem (and I'm a techie-type). If I walk away for a few months and come back, I'm likely to forget about this, and spend more hours figuring it out again.

Upgraded to 3.2.6 yesterday, and rewrote all my Irrigation programs (due to other issues--don't ask. ) The only problem I've found so far is that ${mod.weather.rain.ratemax} doesn't appear to produce any output when used with Emails/Notifications Customizations. cheers & thanks for the great work! mrp

I, too, like to see 'false' across the board for programs that are not 'active'. By doing so, one can quickly ascertain the overall state of the ISY just by looking at the status column in the Program Summary tab. I frequently find myself using the following paradigm to solve problems similar to yours. IMHO, the solution is clunky, but serviceable. Most importantly, it fits a well-defined pattern, so you don't have to go fiddling with custom conditionals for each program that differs. Program 'XXX': If Time is 7:00:00AM And Folder 'AWAY' is True Then Send Notification to 'aLf' Run Program 'XXX' (Else Path) Else - No Actions - (To add one, press 'Action') This has the effect of making the program a 'one shot'--when the condition is met, it executes the 'then' action, then immediately sets itself back to 'false'. Just be sure the "Run Program 'XXX' (Else Path)" is *always* the last action in the Then clause; otherwise, anything below it is effectively 'commented out'. cheers, mrp

My understanding of batch-mode (and it works great this way)... [*:hlsd1bed]Turn off the "Automatically Write Changes to Device" icon up at the top (green circle with '11010' in it; its also under File->Write Changes to Devices) [*:hlsd1bed] Make whatever changes to your system you need--adjust scenes, set levels, whatever. [*:hlsd1bed] Turn on the "Automatically Write Changes to Device" icon, and watch the devices get programmed all at once. It certainly makes mass adjustments a lot less time consuming. If it has powers beyond this, I am unaware of them, and would love to learn more. From your wording, I'm a little unclear on what you seek. Perhaps it is "File->Restore Devices" you're looking for. This will visit each one of your devices, and bring them in line with what the ISY thinks they should be. When I use this, it takes 3 - 4 hours to program my system of about 50 devices. The Pro is much more than batch mode though. It adds a boatload more memory which can be used to host complex web pages and such through the Network module. Also the number of scenes and devices it can manage are considerably more than standard, too. cheers

I tried to make it clear I was an Insteon newbie. Apologies for mis-analyzing the duplicate messages. I've no clue as to why they would be happening. Aye, "ISY is not reporting the correct status of the EZIO inputs when queried?" is my complaint. I initially had problems with trying to link the EZIO6I to the ISY99i with the 2.6.x series. But, somewhere in 2.7.x, I merely entered the EZIO6I address, and may have selected EZIO6I in the device list (rather than letting it auto-discover), and things started working. Its been a while, and memory fails. If it helps, here is the link table from my EZIO6I: Figure 5. Link table from EZIO6I (01.70.F0). The PLM is 12.9D.12. thanks for the reply! cheers

As with many here, I use the EZIO6I to monitor the status of my alarm panel. Also, like many I am frustrated by the inability of the ISY99i to successfully query the EZIO6I. My EZIO6I was purchased after 1-Jan-2010, so I assume it is one of the new models. Where we live, we lose power several times a year--sometimes several times a month depending on the season. Most of the time, its a brief flicker, but it is enough to cause us to have to reset a bunch things. The problem for the ISY99i when this happens is that it can't tell if the alarm is armed or not. Thus, it frequently doesn't run the "away from home" programs that it should. Or conversely, we come home and get involved in something, and the lights start changing automatically, because the ISY99i thinks we're still away. This kind of thing makes home automation extremely frustrating. This frustration led me to dig a little into what is going wrong. I am a complete newbie to the Insteon protocol, and started with these documents: [*:s2vvxfe6]Ref 1: ISY-99i/ISY-26 INSTEON:Using the Event Viewer [*:s2vvxfe6]Ref 2: Insteon - The Details [*:s2vvxfe6]Ref 3: EZIOxx Advanced Details and Command SetI was unable to locate any form of message sequence charts for the Insteon protocol. Without them, the protocol spec is incomplete, as it leaves much of the semantic interpretation up to each reader. First, let me start with my configuration, which i believe is typical: Figure 1. Tree view of the EZIO6I As you can see from the image, the ISY99i has been unable to ascertain the status of any of the EZIO6I inputs (via a query). In this picture, the status of the Fire Alarm is known, because my spouse accidentally triggered it, thus causing the status to be explicitly sent to the ISY99i (e.g., not obtained by a 'query' operation.) So to delve into what is going on, we selected the "AP-9:Disarmed/Armed" item in the tree view, and selected the "Query" option. The result of this action yielded the following in the log file: Figure 2. Log file for an ISY99i 'Query' command against the EZIO6I. Using the references listed above, I attempted to parse what is happening. Let me start by saying that I've no clue as to the meaning of the first two bytes immediately after the [action-code] in each logfile entry. Mon 05/03/2010 11:21:05 AM : [iNST-ACK ] 02 62 01.70.F0 0F 4F 02 06 (02) (this is a response from the PLM to the ISY99i indicating that it received a query command--4F 02--from the ISY99i, and has forwarded the request to the Insteon network. For reference, the EZIO6I address is 01.70.F0, and our PLM address is 12.9D.12.) Mon 05/03/2010 11:21:05 AM : [iNST-SRX ] 02 50 01.70.F0 12.9D.12 2B 4F 02 (02) Mon 05/03/2010 11:21:05 AM : [standard-Direct Ack][01.70.F0-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 (this is the reply from the EZIO6I, it appears to be the EZIO6I's Direct Acknowledgment of the query command. Bit5 in the 2B value indicates this is an Acknowledgment command, and the command values simply reflect the original query command of 4F 02. I agree this is not a normal 'acknowledgment' to a query command if you compare it to say a SwitchLinc. However, I could find no place in the protocol specification that indicated this was an -invalid- response. The EZIO6I is simply saying "I'm here and listening" to the query command. Apparently, SimpleHome felt the status that the EZIO did not fit well with the 'normal' query status return (e.g., ST, OL, RR et al). I assume because of this they elected to leave it at "I'm here", and expected the controller to issue subsequent commands for particular pieces of information. I will also admit to being a little confused as to why the ISY99i is identifying this as "Group 0". The issued request from the ISY99i was a direct point-to-point request, and the response was the same.) Mon 05/03/2010 11:21:05 AM : [iNST-SRX ] 02 50 01.70.F0 12.9D.12 2B 4F 02 (02): Process Message: failed Mon 05/03/2010 11:21:05 AM : [standard-Direct Ack][01.70.F0-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 (this appears to be the ISY99i telling us it doesn't know what to do with the acknowledgment.) Mon 05/03/2010 11:21:05 AM : [iNST-ACK ] 02 62 01.70.F0 0F 49 00 06 (00) (this is a response from the PLM to the ISY99i indicating that it received a Read Input Port command--49 00--from the ISY99i, and has forwarded the request to the Insteon network. This is exactly what the SimpleHomeNet utility also does to query the status of the EZIO6I.) Mon 05/03/2010 11:21:05 AM : [iNST-SRX ] 02 50 01.70.F0 12.9D.12 2B 49 01 (01) Mon 05/03/2010 11:21:05 AM : [standard-Direct Ack][01.70.F0-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 (this is the acknowledgement and response from the EZIO6I. In the returned commands--49 01--with the 01, the EZIO is telling us that Input 1 is turned 'on', Input 2 and the rest are 'off'. This is precisely right for the state of the EZIO6I at time I ran the query command.) Mon 05/03/2010 11:21:05 AM : [iNST-SRX ] 02 50 01.70.F0 12.9D.12 2B 49 01 (01): Process Message: failed Mon 05/03/2010 11:21:05 AM : [standard-Direct Ack][01.70.F0-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 (this appears to be the ISY99i telling us it doesn't know what to do with the information returned. If we go back to examine the state of the EZIO6I as the ISY99i understands it, the information in Figure 1 hasn't changed--the Fire alarm is Off (correct), and the rest of the inputs are unknown (incorrect, since the EZIO6I returned its state.) For comparison purposes, I loaded the SimpleHomeNet utility and looked at the EZIO6I... Figure 3. EZIO6I input state after hitting the "Read Inputs" button on the SimpleHomeNet utility. The state shown is what was expected--Input 1 is On, and the rest are Off. And for comparison purposes, we were curious as to the input traffic that generated: Figure 4. Insteon messages sent & received by the SimpleHomeNet utility for EZIO6I "Read Inputs". We note that these are the same commands that the ISY99i issued to obtain the status of the EZIO6I inputs. I love my ISY99i. We also appreciate all the hard work the development team puts into the product, and their diligence on the forums in answering questions. With that said, I hold in my hand two products that claim to be Insteon compatible--the ISY99i and the EZIO6I. Both claim to adhere to the Insteon protocol, yet they only partially talk to each other. I am certain this is due to poor specification in the protocol. But from these tests, it looks like the EZIO6I is performing according to the documentation provided, yet the ISY99i is not processing the information correctly. Could you please put the EZIO6I query option somewhere on the priority list to address? I will be glad to help in any way possible. Just keep in mind that I'm very new to Insteon. I'll even go so far as to make an offer to ship you my EZIO6I if it will help solve the problem for all of us. Thanks again for all your hard work! cheers

Thanks, Rand! In fact, my work-around employs the technique you describe. However, I find it a substandard solution because it requires remembering to use a Repeat in each calling program (Garage Door down, Goodnight, Away, etc). It would be preferable to encapsulate the special handling logic in the subroutine where it belongs. I believe I've made my point in that I feel the Repeat/Wait behavior is broken. I'll be quiet about this topic. cheers, mrp

Illusion, THANK you for the reply! Putting a "Run (If)" inside the same program that is running the If is a programming paradigm I've completely missed. I was going to convert my dodgy solution to this new paradigm, then I realized the two solutions wouldn't be the same. My solution tries three times, then gives up if the door fails to close. Putting the "Run (If)" inside the Repeat creates an infinite loop which will burn out the garage door opening motor if the door fails to close for some reason. Given the "Run (If)" paradigm, I could completely eliminate the Repeat--this should help make it obvious that its an infinite loop if the door fails to close. The "Run (If)" paradigm you proposed is wonderful and certainly opened my eyes to something I've missed. It is appropriate for many ISY programming applications, but I feel it is a bit dangerous to use for mine. But even given this wonderful paradigm, I'm still of the opinion that a program body should not change behavior based on whether it is enabled or disabled. I'm sure we all do, using programs as flags is an excellent way to remember previous state in the absence of variables. It is also a good technique for "reversing" program logic, and keeping the programs readable. *smile* I do too. But, that's what "Run (Then)" and "Run (Else)" is for. Thanks again for the enlightenment!

Setup Assume we've got a pair of KeypadLincs (husband & wife), and a SwitchLinc controlling the Master Bedroom fan. Setting them up in a scene with the ISY yields the following partial device tree... (Yes, the code can be refined by throwing the fan into the same scene, but that's not the point of this example. The example has been dumbed down substantially, and doesn't involve fans. *big smile*) I frequently write programs like the following: Obviously, if one had a lot of switches controlling the same device, the length of devices to check can get long and error-prone to maintain. My question is this... Why can't I use the ISY's view of the scene when programming If conditions? Specifically, I'm looking to do this: or perhaps... If we could do this, then as we add or remove controllers to a scene, no Program Details would have to be changed or maintained. I am certain that when someone points out why, I'm going to blush with embarrassment at missing the obvious. But for right now, I'm just not seeing why, and am frustrated enough to ask.

One of the features of the ISY is the ability to Adjust Scenes. I have a simple question regarding the use of this feature. I would assume in adjusting a scene, the ISY reprograms the device(s) involved. I also assume that the Insteon devices probably store this information in FLASH, or something similar. If so, FLASH has a limited lifespan of writes--something on the order of 10000 to 50000 writes before it fails. Does this mean that excessive use of the ISY's Adjust Scene capability will wear out our switches faster, or am I missing something about the technology and techniques involved in this feature? I have yet to have any problems with this, and am just curious. If it is problematical, is there anything else we should avoid doing to prevent wearing out the switches? thanks!

Hi, Illusion! Thanks for the reply, but I respectfully disagree with your statement: I see a program being 'enabled' as determining whether or not a program will implicitly run as a consequence of the If being evaluated. From my understanding, a program will be started via the If statement under one of the following two conditions: [*:l4bklyx3] the program is 'enabled' (implicitly started through If evaluation) [*:l4bklyx3] another program calls "Run (If)" (explicitly started via If evaluation) It should be noted that there is a very important distinction between evaluating the If statement, and starting the execution of the program. I agree with you that a disabled program should never start program execution through the evaluation of the If statement. This is not what I am asking for. What I'm asking is the Repeat/Wait logic to have the same behavior regardless of whether a program is enabled or disabled. Simply put, changing the behavior of Repeat/Wait based on whether or not the program is enabled just doesn't make sense to me. When a program is disabled, I believe the If condition should be re-evaluated by Repeat/Wait to determine if program execution should continue--just like it does when the same program is enabled. We've already made the decision to start the program--either through an implicit (enabled), or explicit (enabled or disabled) decision to run the program. In an already running program, I just don't see the logic in having Repeat/Wait have one behavior if a program is enabled, and a completely different behavior if the program is disabled. I believe you've missed the point that... evaluating an If before each execution of Repeat/Wait is a time of our choosing according to the ISY documentation. And the ISY is failing to accommodate this when the program is disabled. Once again... I agree that the If shouldn't be used to trigger program execution if the program is disabled; however, once started, the body of a running the program should function the same whether the program is enabled or disabled. This is not what is currently happening. I do not believe what I am asking for would cause anyone to rewrite programs.

I believe there is a problem with program execution with respect to Repeat and Wait, or at least something that should be documented in the wiki. Setup We are running 2.7.13 on the ISY. We started by writing a program to close the garage door if it was open. The hardware is an IOLinc connected to a normally-closed switch, and the relay is connected to the garage door motor, of course. The relay is programmed for Momentary-A. We know that Momentary-C is a common deployment, but that is not the issue here. The program, "Subroutines / Do Garage Close Door", looks like: If Status 'Garage Door / Garage Door-Sensor' is not On Then Repeat 3 times Set 'Garage Door / Garage Door-Relay' On Wait 20 seconds Else - No Actions - (To add one, press 'Action') If the program is "Enabled", it works great. First, it checks that the garage door is not already closed. If the door is closed, the program moves to the else clause immediately. If open, the program makes up to three attempts to close the door. Once the door is down, the sensor changes state and any remaining Repeat attempts are abandoned. We implemented the program with three attempts because our garage doors are frequently opened manually. Sometimes they are partially open. Sometimes, they are partially open, and the next relay closure opens them further, so a second try is needed to get them going in the proper direction. But the program has one problem when 'enabled'. Anytime the garage door is open, this program will close them--not what is desired, as this prevents us from ever opening the garage door. The program was designed to run as a subroutine, so we need to 'disable' the program and call it explicitly from elsewhere to have the desired effect. There are many other activities that could call our new subroutine. For instance, periodic monitoring if the burglar alarm is armed (we're away), or as part of a goodnight sequence, or as a manual control on a KeypadLinc. Here is an example of the latter: If Control 'KPL Den / KPLDen-G:Garage Door' is switched On Or Control 'KPL Husband / KPLH-G:Garage Door' is switched On Or Control 'KPL Wife / KPLW-G:Garage Door' is switched On Then Run Program 'Do Garage Door Close' (If) Else - No Actions - (To add one, press 'Action') As such, we dropped the "Subroutines / Do Garage Close Door" program in our 'Subroutines' folder, and disabled it like we do all of our subroutines. Now the program should only execute when called via an explicit "Run (If)" from another program. The Problem Once setup in the configuration described above, we immediately encountered a problem. The subroutine would run for all three iterations even though we watched the ISY report that the Garage Door-Sensor went On. The expected behavior was for the Repeat statement to execute once, then terminate once it saw the door was down. The subroutine worked when 'enabled', but fails when 'disabled'. We finally chased the problem down to Repeat and Wait apparently failing to re-evaluate the "If" condition prior to each iteration if the program is disabled. Needless to say, this is unexpected behavior. If called via "Run (If)", we expect the program to honor the If condition (for Repeat and Wait statements) regardless of whether the program is enabled or disabled. If not fixed, we feel that this at least deserves some documentation in the wiki (e.g., http://www.universal-devices.com/mwiki/ ... tion_Order). We've managed to work around the problem by controlling the subroutine from other enabled programs. However, this feels incredibly dodgy.