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.

For my garage door, I changed from a 2450 I/O linc after one too many "all On" events. I use a Fibaro FGBS-222 "implant" unit, coupled with a 12V brick supply and an external relay. The Implant uses a FET output, which may not handle spikes properly. So I use the implant to fire a transistor driven relay contact closure.

Yes, timing is important! Read twice, execute once.

I'll add that the password can be reset to the known default admin/admin without doing a full factory reset on the ISY. Procedure here: https://wiki.universal-devices.com/index.php?title=ISY-99i/ISY-26_INSTEON:Resetting_Your_Userid/Password I'd do the following: - Download launcher and locate the ISY on their network. If an issue with wifi use a direct Ethernet cable from the ISY to the router or the laptop to connect initially. - See if previous owner set the user/password to admin/admin. Reset password if they did not. - Log into the Admin Console and make a backup of the system - Then start working with the system to determine how/what needs to be changed.

I know that Smarthome has removed the ALL ON command from their firmware for units shipped in the last couple of years, but some of us have older modules that still respond to an ALL ON command. For those modules, ALL ON commands can still cause issues. Tonight I may have discovered another possible source for ALL ON commands I have an older 2456S3 - date code 1152 - that was beginning to fail by intermittently not responding to ON/OFF commands in the last two-three months. I just hadn't got around to replacing it. I'm assuming the power supply is failing due to old caps that are failing. I've had two ALL ON events in the last month, after having none for several years. I have no Insteon wireless devices (one possible source of interference-caused ALL ON events) in my system, having replaced all of them with Zwave wireless devices a few years back. I believe the failing Power Supply in the 2456S3 module may have caused it to send or created the conditions that made the 2 recent ALL ON events happen. I've replaced the failing module, and will see if that ends the random ALL ON events. Just something to keep in mind if you still have older modules and are getting random ALL ON events.

I've had decent results with the Fibaro FGFS-101-EN Its reliable, and the only thing that's odd is that the temperature is only available in degrees Celsius. Battery is CR123A and life is over a year.

To answer some of your other questions: You can run Polyglot locally currently on a Raspberry Pi or on a Polisy box or in the cloud (which I understand you are not interested in cloud-based integrations) with a cloud ploy setup. To run a local polyglot server linked to your ISY, you need either of a ISY Portal account, or the Networking module for your ISY. Either opens up the access to the ISY's nodes for on-network reading/writing to the ISY. If you aren't interested in portal integrations (Alexa, etc.) then the network module will allow you to use Polyglot without any third-party Internet access to your system. To upgrade to versions 5.1.0 or later, if you are using Zwave, you also need to upgrade the Zwave hardware in the ISY to the 500 series Zwave module. Carefully read the release notes for 5.3.0 in this thread: https://forum.universal-devices.com/topic/30939-release-530-is-now-available/ as it covers all the items you need to know to update from 4.7.x to 5.1.0 or later. Version 5 introduces vastly different and improved handling of Zwave devices, and adds support for Polyglot node servers. Because it is a major change, depending on your programs, you may need to do some work to get them fully functional after the upgrade if you have Zwave devices.

Upgraded from 5.1.0 to 5.3.3 yesterday. No issues. Both older Schlage locks (BE369 and BE599) work fine after a Zwave/Synchronize Polyglot nodes work fine after restarting the nodes in Polyglot server.

Installing a Zwave module requires two steps: 1. Installing the physical zwave board 2. activating the zwave module. Go to Help/About in your Admin Console. If your About does not show a zwave module, you need activate your zwave. From the wiki at: https://wiki.universal-devices.com/index.php?title=Z-Wave:_Ordering/Assembly_Instructions Hope that helps.

I upgraded from 5.0.16C to 5.2.0 Everything went well, and all devices are working after Zwave Synchronize. However, a Schlage BE599 door lock is showing a Write Changes pending icon in the device list. If I enable write changes, it will repeatedly attempt to write changes, trying about once every few minutes. Synchronize, Update Neighbors and Repair Links did not clear the issue. The only error I see in the Event Log is: Fri 10/02/2020 12:05:50 : [ZW-TX-FAILED] enc=Ok uid=2.0 cmd=0x85.02 ASSOCIATION It appears to be trying to set an association that can't be set? Other than the Write Changes issue, the lock is working properly and appears to be communicating with the ISY. Status updates correctly in the UI, I can write user codes to the lock, and unlock/lock from the Admin Console UI. Full event log attached. Zwave Dongle Version info: 6.81.00 ISY-Events-Log.v5.2.0_10927-1_Fri 2020.10.02 12.06.42E.txt

Or maybe have an option for a combo Zwave/Zigbee stick like this: https://gatehousesupplies.com/husbzb-1-gocontrol-quickstick-combo/?cmp_id=159600245&adg_id=8992267205&kwd=&device=c&gclid=EAIaIQobChMIzuCXpdK36wIVkIbACh2yFA_9EAYYASABEgK2t_D_BwE

I'll try to help. I believe that the bootloader is no longer necessary. If you are running the latest UI version, it is no longer listed. For Weather data, if only temps are needed, there is a NOAA nodeserver in the nodeserver store that can be pointed to a nearby NOAA site (also has data for some major international airports) to capture temperature data. For Polyglot, I was able to get it up and running on a Rasberry Pi very easily, rather than subscribe to the portal. However, you will need to add the Networking Module to the ISY to use a Rasberry Pi (Rpi) based polyglot nodeserver. Look in the Polyglot section of this forum for more info, it will point you in the correct direction. If you install Polyglot on a Rpi and a nodeserver that accesses local weather data, you won't need a portal subscription. However, if you wish to integrate voice control or other features that require the portal, then that is the obvious choice. A Portal subscription includes access to the Network Module while the subscription remains valid. If the Honeywell thermostat supports Zwave, and you have installed the 4.55 version or later of the Zwave firmware on your Zwave accessory within the ISY you should be able to include the thermostat to the ISY. Zwave inclusion instructions vary for the device. On the ISY, you choose Zwave/Add a Zwave device and then do the inclusion on the device. Many devices require the ISY to be very close (<1.5M or 5 ft) to successfully include. I used an extension cord on the ISY to get some of my Zwave devices included after they were mounted. Since you say your thermostat and ISY are within that range, you should be able to include the thermostat without too much trouble. When the ISY is in Zwave include mode, and the thermostat has signaled it wants to join, there is activity on the ISY UI to show the inclusion. The Event Viewer on mode 3 will show all communicaiton between ISY and the Zwave device. For Sunrise, there is a setting in the program interface to set that up, and you can include an offset to sunrise/sunset if you desire. I've attached a screen shot as a guide. The KPL buttons grouping button is on the far right when you are looking at the primary device of the KPL. You may have to make your UI full-screen to see it. Things in the UI that have changed (mostly just moved) do take some poking around to find. Some new features, such as being able to set the font size are handy. If you are on an older version of the UI than your ISY firmware, strange behaviors will be expected. You can use the ISY Launcher (see thread on that) to insure you always load the correct UI. Very handy if you have multiple ISY units on different versions. When registering your ISY in the portal, use your UUID rather than the older Serial number that may be on your unit. EDIT: Re-reading your info about the alarm panel and thermostat. If the alarm is the primary Zwave controller, then you can join the ISY to the existing Zwave network and have it be a secondary controller. You can add the ISY to your existing Zwave controller by including theISY to the alarm panel's Zwave controller - read the manual pages for both devices, but you generally will put your alarm panel Zwave controller in to incude mode, then put ISY into Zwave include mode so they see each other. After the alarm panel controller enrolls the ISY, you can put the ISY in "Learn" mode and it will ingest the topology of the Zwave system from the other controller. The ISy will then monitor the Zwave network, and will be able to see the data from the thermostat and send commands to it.

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 did miss the note about having to press the button after making the parameter change to cause transmission to the device. Thanks for pointing it out. However, when starting the Admin console, the status for the 2441V thermostat adapter does not show actual status of the adapter until I click on one of the buttons (one of the Setpoints, Mode, Fan Mode). Also, the parameter settings are not accurate as to current mode settings until I click on one of the buttons. Clicking Query doesn't seem to update device status in the UI.

I upgraded to 5.1.0 last week. I noticed last night that with device 2441V - Insteon Thermostat Adapter V.92 and also with device 2441ZTH Insteon Wireless Thermostat (Both are HVAC control interfaces): Changing setting for mode, Setpoints, or Fan in the Admin console do not result in changes on the target devices. The status in the admin console also does not change - and is blank However, having a program send the same mode change command to the device DOES result in the device changng mode, and updates status on the Admin console. In 5.0.16 I had noticed that status in the Admin console did not always auto-update, and I had to query the status to get accurate temperature readings. In 5.1.0 it appears that the UI in the admin console is not generally operative. The Event viewer shows communications between device and ISY when Query is triggered from UI, but results do not display. ISY is on v5.1.0. Admin Console UI is v5.1.0 started with the Launcher. ISY-Events-Log.v5.1.0__Wed 2020.08.12 07.00.13.txt

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.