wrj0

Seems like a good idea to have a ready-to-go backup SD card on hand. This post indicates up to 16GB SD card can be used in the ISY-99. Is a particular SD Card (or class of card) recommended?

Update to 3.1.5 completed without a hitch a couple of days ago. Irrigation Requirement calculations are now working properly. Thanks Michel and UDI!

Update to 3.1.5 completed without a hitch a couple of days ago. Irrigation Requirement calculations are now working properly. Thanks Michel and UDI!

Thanks for confirming the 1/10th value behavior, Jim. Here's hoping the fix will be an easy one for Michel and company.

No apologies are necessary, Michel. I'm rather amazed you are able to respond to as many inquires as you do so quickly! My Weatherbug module display shows English (F) in the display - I've never selected metric for use in the Weatherbug module. (But like many of us in the U.S. are moving to metric an inch at a time.) The change occurred after I upgraded to 3.1.4. Weatherbug programs that used to test for a desired value in 3.1.3, were changed to display 1/10th of that value after the upgrade to 3.1.4. So, I changed them back to the value I wanted for the test. Using the desired value tests false, but using (desired value)/10 seems to test correctly, at least for the Rain Today value.

Michel, Thanks for your response, but I'm not sure how the link provided answers my initial question. So, I'll try to clarify my previous rambling. With Climate Module actually reporting Rain Today = 0.32, the test for: If Module 'Climate' Rain Today >= 0.2 " And Module 'Climate' Rain Today < 0.5 " Returns False! But, If Module 'Climate' Rain Today >= 0.02 " And Module 'Climate' Rain Today < 0.05 " Returns True with Rain Today value = 0.32. Started in 3.1.4 with the Irr/ETo module. Was testing OK in 3.1.3. Please advise.

Michel,After upgrading to 3.1.4, my test values for Rain Today parameters changed by value/=10. For example my code in 3.1.3 was: If Module 'Climate' Rain Today >= 0.2 " And Module 'Climate' Rain Today < 0.5 " But after the upgrade to 3.1.4 the values were changed to 0.02 and 0.05 respectively. Yesterday, we finally had some rain, and Weatherbug was reporting 0.32†rain, which agreed with my weather station. However my code to test for 0.2†<= Rain Today < 0.5†evaluated false, but I found testing 0.02†<= Rain Today < 0.05†evaluated true with the actual Rain Today of 0.32â€. Please advise. Thanks.

Thanks, Michel. You are correct - the Irr/ETYo module was installed before the upgrade. Per your suggestion, I have submitted a request for reactivation. Once again, I appreciate your help.

Thanks for the new update, Michel. I successfully upgraded from v3.1.3 to v3.1.4. I also purchased the Irrigation/ETo Module – thanks for the discount! After clearing my cache and rebooting the ISY, Help, About shows 3.1.4 is installed, and Help, Purchased Modules shows Irrigation/ETo Module - Installed on 2011-06-27. I also have the WeatherBug Module installed and have been using it for over two years now in several programs. My Help, About screen shows “–Weather Information (21020)†but does not show any indication that the Irrigation/ETo Module is installed. Also, my Configuration, Climate tab status does not show any of the new Irrigation/ETo parameters as shown in your sneak preview screen shot from a few days ago. Also, Irr/ETo parameters are not available for selection in programs under Module, Climate conditions. Seems I may have missed something in upgrading to 3.1.4 and adding the Irrigation/ETo Module. Suggestions please on how to enable the new Irrigation/ETo Module parameters. Thanks.

From: http://weather.weatherbug.com/weatherbu ... er-station Light Intensity: Range: 0 - 100%, Accuracy: +/- n/a

Looks like the low battery report capability from an old motion sensor is not consistent - Rev 1.1, 2420M Motion Sensor, marked "4908." First dead battery did not report the low battery report. Second battery did. Last night I found the third battery was dead, but received no low battery report. Probably time to replace the Rev 1.1 2420M.

I've had the same 2412S PLM V2.9 in operation continuously since Dec 2008 without any noted problems. However, I already had an Intermatic power line surge suppressor installed prior to setting up the PLM/ISY. That may have helped with the longevity of this PLM. Still, it seems a great idea to have a spare PLM on hand.

I also had some problems using Weatherbug data from another location, so purchased and installed a Davis VP2 weather station at home. Sending the VP2 data to Weatherbug allows me to pull it into the ISY from Weatherbug and solved my local rain data problem. But, it turns out that light data from personal weather stations is not published by Weatherbug. So, to address that problem I installed a 2420M Motion Sensor on a north facing window and adjusted it so that Dark & Light level reports from the 2420M are right where I need to turn on/off lights. All of my climate data is now local and I don’t have any issues with a passing cloud or rain storm “over there.†The only thing that would make this work even better is if the ISY could pull weather data directly from the Davis VP2 instead of having to push it to Weatherbug for the ISY to retrieve. This feature has been requested previously, but there just doesn’t seem to be enough of us using Davis VP2 weather stations to warrant the work by ISY developers. But it doesn't hurt to ask.

Thanks. The beep function could be much more useful if it were loud enough to be heard from the next room. I had initially set up a beep alert when the driveway flood light sensor was triggered but it's just not loud enough to be of much use for that purpose.

I'm curious how loud the beeps for SwitchLincs should be. I only have one dual band SL installed, and unless we're right beside it when it beeps, it's hardly noticeable.

Michel, Should both the Light value and Light Rate value be shown as %/h ? Perhaps Light value is just a number and not a percentage.

Updated from 3.1.0 without any issues.

Thank you for your response and suggestions, Michel. I’ve tried both DHCP and static addresses in the ISY, but the DNS problem remains. The Climate module is set to poll for data every 120 seconds, but the DNS failure only occurs 4 hours after resetting the PIX501. I've tried to capture the cause of the failure in the PIX501, but the 4 hour delay before the error occurs is maddening. Taking the PIX out of the network allows the ISY to resolve DNS just fine, so the problem is with the PIX. Curiously though, other local network devices connected to the PIX don't have any DNS resolution problems and it worked fine with the ISY for a couple of years prior to upgrading to 2.8.16. Frustration got the better of me, so I’ve replaced the PIX with another firewall device that does not experience the DNS problem. Thanks again.

Recently my ISY began experiencing DNS resolution problems. DNS resolves properly for four hours after a system reset during which time NTP Time sync, Climate Module data, and ISY outbound email all function properly. However, after four hours of proper operation, the ISY starts reporting DNS Errors for both NTP Time and the climate module, and outbound ISY email ceases. Once the DNS errors start, I can replace the ISY's NTP time server URL with the time server’s ip address and can force the ISY to perform a time sync just fine, so Internet connectivity seems OK. Two other devices on the local network, an ELK and a Wi-Fi router are configured with the same DNS server ip (from the local ISP) that is set in the ISY, and both the ELK and Wi-Fi router resolve DNS properly; just the ISY experiences the DNS resolution error. The problem started after upgrading the ISY from 2.8.7 to 2.8.16 and after enabling ISY-ELK communication (both changes made about the same time - OK, bad move on my part!). So, I removed the ELK parameters from the ISY, and disconnected both the ELK and the Wi-Fi router from the local network to try to isolate the problem, but the ISY continues to show DSN errors around 4 hours after a system restart. I’ve also tried setting CWT=30,000, but that didn’t help. The ISY is connected to a PIX501 that when restarted allows the ISY to properly resolve DNS for 4 hours, then the ISY DNS resolution errors start again until the PIX is once again restarted or reloaded. The ISY is assigned a static ip on the local network and worked fine for a couple of years in this configuration (with the PIX) until I upgraded the ISY and established the ISY-ELK link. Now with only the ISY connected to the PIX, the DNS resolution errors start appearing four hours after restarting the PIX. The ISY Error log shows “System -100 [Network] DNS Server N/A,†but the other devices, if connected, resolve DNS properly. Since I've not changed the PIX configuration, I'm curious if anything may have changed in ISY since 2.8.7 that I need to accommodate in the PIX to eliminate these DNS errors. Suggestions, please? Thanks.

Finally got ISY remote access to work again! Reloaded ISY rev 2.8.13; re-booted cable modem, pix and router; re-established dynamic ip with DYNDNS; deleted all UDI certificates in Java security, and re-installed SSL certificate, and now remote access is working fine again. The SSL reset seems to have been the fix for the problem. mjtyson: thanks for the suggestion.

Sure did, but thanks for the suggestion. Resyncing MobiLinc returns "an SSL error has occurred and a secure connection to the server cannot be made." About the same response from a remote web access attempt.

Upgrading my ISY-99 from rev 2.8.7 to rev 2.8.13 seems to have completed successfully and without any error reports. After the upgrade the ISY appears to operate properly, and local access from my home network continues to work fine. Email reports from the ISY and NTP sync are still working fine, so outgoing access is functional, but I have lost remote access to the ISY, both on PCs from work and from MobiLinc on an iPhone. Other than updating to rev 2.8.13, no other system changes were made. Manual port forwarding in the router remains set just as it was prior to the ISY upgrade. ISY settings including CWP ports seem to be set properly, but remote access continues to fail. Upgrade instructions were followed including clearing cache. Suggestions, please. Thanks.

I've also pondered how to verify that the data provided by Weatherbug is indeed valid, and found that for my local Weatherbug station, certain variables are set to zero when not being properly reported (or received). So, my programs that depend on valid Weatherbug data are in a folder with the conditions shown below. It's worked out well for me since the inital release of Weatherbug support in the ISY. Folder Conditions for 'Weather' If Module 'Climate' Temperature is not 0 °F And Module 'Climate' Temperature High is not 0 °F Then Allow the programs in this folder to run. Both Parameters default to 0 if invalid data.

IndyMike, The 9VDC battery was a cheap one my wife picked up at the local discount store; sorry, I don't remember the make.

Yesterday, I received the first low battery email alert from my ISY-99 Pro. Whu-hoo! The original battery installed did not report the low battery condition before the battery completely died, but the second battery that was installed correctly reported the low battery condition by the ISY-99. No changes were made to the low battery report program. The first battery died with the ISY-99 running 2.7.0; the second low battery condition was reported by rev 2.7.12 just fine yesterday. Rev 1.1, 2420M Motion Sensor, marked "4908."