Craigb

I don't think this is a universal occurrence. I've run my ISY 99, ISY 994, and Polisy boxes on UPS power since 2010 while the PLM is always plugged into the house wiring with no power backup. In the more than a decade of use, and many short or long power outages, I've never had the communications between the ISY/Polisy and PLM become locked up due to a power failure. I'm not sure what's different about our respective installations, but serial comms lockup is not an expected result of a power failure to the PLM while the ISY stays powered.

You can't "remove" a button from the KPL in the Admin Console. You can remove it from all scenes which will make the button non-functional (it will light on-off, but won't do anything else) - but it is always part of the KPL. After removing it from any/all scenes it was part of, then just right-click on the button in the admin console and rename it to "D". Unused buttons on included KPL's still show in the Admin console - always. Just name them somethign so you know they are unused.

@tazman, Thanks! That worked.

I'm trying to add my Polisy to my UD Mobile app on Ios 15.7 as a local network connection - not via portal. I DO NOT use the ISY Portal, I only use Local Network access (I use a VPN when away from home) When I try to add the Polisy local IP address (https://192.168.x.xx and port 8443) and test, I get an error that the IP address must begin with HTTP, not HTTPS. When I enter the IP address as HTTP://192.168.x.xx and port 8443, I get an error that the "App transport Security Policy requires use of a secure connection" Using various related URL's such as http://polisy.<privatedomain.pvt>, adding /desc at the end of the URL, and/or adding port to URL or not, letting UD Mobile try to connect to Polisy on Port 80 as http - all result in one of the same two errors. Anyone have a way around this seemingly Catch-22 issue? Polisy is running Ver 5.4.4 UD Mobile version for Ios is Ver 0.9.2 Again - I do not use the portal. All connections are via local network only. Note: UD mobile works fine in this config with my ISY's - but not in secure transport - as HTTP only.

Ordered!

Many devices with noise/surge supression will kill off powerline X10 and Insteon signals. One solution I've found is to take a 14 gauge 3-wire extension cord about 6 feet long (the flat ones used for window air conditioners or appliances are good), and coil it into a coil with about a 6 to 8 inch (15-20 CM) diameter, using cable ties to secure it. The coil acts as a choke to isolate the powerline control signal from the filter in the surge/noise supressor, and then nearby X10/Insteon devices will again work. Note: powerline control devices (neither X10, Insteon nor anything else) will not work correctly when plugged into the output side of any power conditioning device (surge protector, UPS, etc.) that filters the power line noise.

I see a different screen layout in Ver 5.4.4: You may be on an earlier version.

Wow, thanks!

I'm searching for a weather node server that can scrape data from NOAA's XML data feeds. Example: https://w1.weather.gov/xml/current_obs/KMDW.xml These provide basic metar type data, and other links based on observation site can provide 3 day history as well. Is it possible to configure WeatherPoly to retrieve the data from NOAA? I couldn't figure out how to get WeatherPoly to poll the website.

I have a door sensor on the front door that turns on the hall light for 5 minutes when the door opens. Using the switch or the keypad will disable the automatic on-off from the sensor. The sensor sets a variable, as does the switch. The Switch, KPL and micro dimmer module that controls the light are all linked in scene "Entry Light". Then 4 programs are used to control behavior. ($Daytime is a variable that is 1 during times the sun is up, and $ExitDelay prevents the light from going on for 2 minutes when I open the door after turning off the light manually The bedroom control referenced in the program turns on all lights in the house when used). Note: the AND in "EntryLgtManON" IF section should be OR.

EDIT: I was unaware of JLOB's programs in the wiki, but I apparently accomplished essentially the same thing. He combined all the month checks into a single program. I've been doing this exact action (lights off on Haloween if I'm away) for years. Since earlier versions did not expose dates, I wrote a set of 7 programs that increment day, week, month, and year variables. I also track the weekday, week of year, and weekday of the first of the month for determining holidays. The Holiday program tests for things like the last Monday in May for Memorial Day or 4th of July or Thanksgiving and alters the routine of the house on holidays. Then I have a program that checks for the date of Halloween and takes a number of actions. The Halloween Off runs after 11PM and resets things back to normal operations. The second Front lights off is there because other programs may trigger the front light between 1hr and 15 min before sunset. In my case, I use $Away_State to determine if the house is in Away mode or not. If I'm home, I'll handle the Trick or Treaters, if I'm traveling for work, the house is in away mode and the front lights will be off. Since I have dates as variables, I also set a season variable (1 to 4) incrementing it on June 15, September 15, and December 15. On March 15, it resets to 1. This is done by the Summer Set and Winter Set programs, based on the date.

Follow up on my post earlier this week concerning 2856S3 and 2856S3B not communicating with ISY after update to 5.0.16C First: I rolled back to 5.0.16B. No change to behavior of the 2856S3, and now the 2856S3B was now also flagged by the ISY as being not in communication. Both units were still fully controlled by both dual-band and power-line only KPL's. The non-dual-band KPL is plugged into the same outlet as the PLM. I moved both units to the same plug (using a cube tap) as the PLM. No Change. Attempts to restore these devices from ISY AC results in "0 bytes written to device" in the event viewer. Next: I removed the devices from ISY, factory reset them, and re-included them to the ISY. They now work correctly. So: I re-updated to 5.0.16C. The 2856S3 and 2856S3B appear to be working properly, although the ISY intermittently reports losing communication with them. This PLM (v9B) has been updated with the power supply fix from 2014 at the link below. It doesn't appear to be failing, but perhaps I'll swap it out later. I can only guess that the PLM tables for these device became corrupt at some point, because all KPL's (both dual band and power-line only) were able to control these units (prior to the reset) via the scenes each were enrolled in.

I'm aware that these are power line only. The ApplianceLink is plugged into the same circuit as the PLM, in the next outlet box on the wiring chain. If it were any closer to the PLM, it would have to be on a cube tap with the PLM. I'll give that a try, and when I get a moment I'll pull all PLM links, but I don't expect that anything in the PLM changed as part of the upgrade. I didn't get more time to work on this tonight, so I'll get more time to troubleshoot this coming weekend.

I installed 5.0.16C (previously was on 5.0.16B) Upon first login into the AC (using Launcher, and it showed correct version) I received a "Can not communicate with <device> "which is an Insteon ApplianceLink 2456S3 - v.42. This is the only unit of this model in my system - all the rest are of newer vintage. This device was seen properly for status by the ISY/PLM immediately before the upgrade. The Appliance Link still responds to the KPL button it's scene is controlled by. I cannot control device from device page of ISY or from scene page of ISY - however the scene on-off commands do change the state of the KPL button. The device and scene pages show no status for the ApplianceLink. I tried a Write Updates to Device. - it runs a progress box but doesn't write anything to the ApplianceLink I tried a Restore Device - The event viewer shows: But there is no writing of restore data. I've not seen this behavior before. I also have a 2456S3B v.39 ApplianceLink, which continues to work properly with the ISY/PLM. Each restart of AC gives the same "can not communicate with" message, and the device does not respond to AC commands for scene or device. All other powered Insteon devices (Appliance, Dimmer modules, Dimmer switches, KPL's, Fan controllers) appear to be working with AC/ISY/PLM correctly. Not sure if this is due to the Upgrade or something else. Its getting late here, I'll poke at it again tomorrow, as this device isn't scheduled in any programs tonight.

Update since moving to 5.0.16B: The communication between ISY and Schlage BE569 seems to be working better. However, the Admin Console Device UI was not showing current status (lock was LOCKED, status was UNLOCKED User 1 from when I arrived home an hour previously). I used the Query button (more than once) which caused communication with the lock, but did not update UI. I then clicked on Options, and after two tries (System Busy message box - no content, just header), the UI updated, and the Options panel opened. Event viewer snip: