wrj0

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."

The original battery in my my Rev 1.1, 2420M Motion Sensor, marked "4908" finally died. No Low Battery status was provided by the sensor. Great battery life from the sensor installed Jan-09; just wish the Low Battery status indication worked.

Thought I'd throw in my $0.02: My Rev 1.1, 2420M Motion Sensor, "4908" was installed on 17-Jan-09, with all jumpers at factory default. It's been working fine on the same battery since installation. So, although there's a program set to report the low battery, I don't know if this rev 1.1 motion sensor will report a low battery condition or not...yet.

Hi Michel, I believe that the user ID & PW in the Treo were correct, as I checked that several times over the past few days. I suspect something got corrupted in the Internet Explorer application on the Treo that was corrected during the hard reset. Curiously, though, other https sites would work fine; I tested several during the past couple of days. I'll watch the operation from both the Treo and from a PC for a while to be sure all's well again. Edit: I should add that during this problem period, most of the time when the Treo 750 would try to access to ISY remotely, it would not get to the ISY login page at all. It would show the certificate page, and when that page was acknowledged, the page would go blank with the security lock Open, the status would show “Connecting…†for a few seconds, then “Opening…†for a long period (CWT parameter?), and finally the page would go blank. But, at the end of this process, the security lock would display as Closed as if the page had been properly entered. Gladly, everything is working properly now after the Treo hard reset. Thanks again for the suggestions.

Well...after several attempts at a few different port assignments, and testing with two different routers, I was about at wit's end trying to get port forwarding to work when accessed from the Treo 750. The Treo seemed to open any web page except the ISY when assigned to a port other than 443. Several different router port forwarding tests, multiple soft resets of the Treo, clearing history, cookies, ect. all ended in the same result. Finally, I did a hard reset on the Treo and am finally able to access the ISY without any problem. Who hoo!

Will do. Thanks, Michel. I'm also going to try another router as I'm a bit suspect about port forwarding working properly on the one I've been testing.

Thanks, Michel. Sure enough, changing to Metric, and restarting the Admin console does indeed change the arguments in the program test condition to metric. I had not tried making the change and then restarting the Admin console – thanks for the tip. However, now when I switch back to English, the Rain Today arguments in the program remain in Metric after changing back to English and restarting the Admin console. I found that when making the change from English to Metric also changed the test argument to null when it was in inches before. For example after changing to Metric: If Module 'Climate' Rain Today is null Before the change: If Module 'Climate' Rain Today > 0.1" Not a real problem though as likely the switch would only be performed infrequently. It does seem that regardless of the Configuration, Climate WeatherBug, Unit selection, Rain Today is always presented as Metric even if the Admin console is restarted. Thanks again for a quick response and the great support.

Greetings, Looking for suggestions on what’s needed to enable ISY access via a mobile device on a non-standard port (as recommended by others here for improved remote access security). I’m having a problem getting my Treo 750 to access the ISY on a non-standard port. Port forwarding on the router seems to be OK, as I can remotely access the ISY on port 444 from a PC. When the ISY is set for port 443, the Treo displays the appropriate certificate page, much like the PC based browser, and then allows access to the ISY for control and status. But, nothing I’ve tried allows the Treo access to the ISY when it is set to something other than port 443 (I’ve tried a few different ports). Here’s the results: https://x.x.x.x with ISY set for port 443 works fine from the Treo 750 – works great! https://x.x.x.x with ISY set for port 443 works fine from a PC. https://x.x.x.x:444 with ISY set for port 444 works fine from a PC not on the ISY network. https://x.x.x.x:444 with ISY set for port 444 fails on the Treo 750. The response is a blank page on the Treo. But, if I make a Bluetooth connection from a laptop to the Treo 750 for web access using the Treo as an access point, I can access the ISY at port 444 from the PC, so I’m guessing it’s not something that the service provider (ATT) is blocking. I’d appreciate any suggestions. Thanks. Device Revs: Treo: WM6 ISY-99: 2.6.12

Thanks, Michel. When the Configuration, Climate, WeatherBug Unit is changed from English (F) to Metric ( C), the temperature display in the Climate, Status window does indeed change from F to C. Winds also change from mph to km/h. However, the Rain Today value always seems to be presented in mm. Unless I’m (very likely) missing something, it also appears that the Rain Today argument in a program is always presented in Inches – I don’t see a way to select metric equivalents. While I would prefer to work in English units, since WeatherBug provides the rain value in Metric, it would seem that I could test: If Module 'Climate' Rain Today is 25mm But the program arguments seem to be presented only in Inches: If Module 'Climate' Rain Today is 1 " No big deal, I can certainly do the math to set up the proper test, just wondered how ISY handled the Rain Today value.

Please advise if the weather module in the ISY handles the appropriate units conversion. For example, the current ISY climate module status shows: Rain Today: 0.18 mm but, the conditional test in the ISY is: If Module 'Climate' Rain Today > 0.5 " Is the metric report from WeatherBug converted to inches in the ISY? Thanks.

Problem Solved – thanks to some very good documentation provided in this forum by others who have fought these issues before. Initially, I followed the Factory Restore procedure as described in: http://forum.universal-devices.com/viewtopic.php?t=1765 Unfortunately, my laptop does not have a serial port, so I had to scrounge up an old one for the serial work described in the link above. That resolved the flashing red LED error, until I forced the same problem to happen again as will be described below. Argh. The procedure called for me to launch http://www.universal-devices.com/99i, which I did, but this once again caused the red LED error to occur. Double Argh. Since doing successful updates on the ISY-99i earlier this week, I had changed my antivirus package to AVG 8 and did some digging on this forum to find: http://forum.universal-devices.com/view ... hlight=avg So, I turned off the Web Protection in AVG as described, ran the FR procedure again, was able to re-install 2.6.12, restore my backed up configuration (making sure I cleared the Java cache between each restart of the web page), and am finally back in operation. Whu hoo! It seems that the AVG 8 package that I installed earlier this week did indeed “brick†my ISY just as author gviliunas described in his post. Here’s the sequence of restoration that I followed: Turn off Web Protection in AVG HyperTerminal to ISY serial port Login using my saved username/PW. Issue FR command for factory reset. ISY reboots. Connect to ISY99i via Ethernet Clear Java cache Launch www.universal-devices.com/99i. Login using admin/admin. Re-install 6.2.12. ISY reboots. Clear Java cache Launch www.universal-devices.com/99i Login using previously saved username/PW. Restore backed up ISY configuration (Sure glad I saved that last working config!). ISY reboots. HyperTerminal to ISY serial port Login using my saved username/PW. Issue CT command to restore desired IP settings. ISY reboots. Clear Java cache System is back in operation as before being clobbered due to the AVG setup. I supposed I should have anticipated a problem was about to occur; prior to the ISY erroring out, I had noticed a couple of “funnies†in its operation, such as device notes that would not save, and programs that after the save command was issued, still reflected a not-saved status. Anyway, this ISY-99i is back operation thanks to the info others provided in this forum. Thanks!

Greetings, I recently purchased an ISY-99/IR PRO, successfully upgraded to 2.6.12 earlier this week, and have been adding devices and programs for the past few days testing the operation - things have been working OK up to now. This morning after attempting to save a newly entered program, the ISY lost several existing, previously-saved programs from the display. So, I did a reset by cycling the power. The ISY now boots with three Green LEDs permanently on (PWR, RX & TX), and the red Error LED blinks continuously. Powering down for several minutes and then powering back up results in the same status. No ip communication is available now with the ISY99. Please advise. (Was hoping to get several new programs in operation during the holidays. Argh!) -Bill