LeeG

I do not have the documentation to evaluate the Query information. A battery device cannot be added to the ISY with Start Linking. As soon as the Set button is pressed the device links with the PLM which is in linking mode from selecting Start Linking. Once the devices have exchanged messages and linked to each other the battery device goes to sleep making further ISY communication with the device impossible. Suggest a factory reset of the 2441ZTH and add it using New INSTEON Device. Have the event trace at LEVEL 3 running during the New INSTEON Device to determine the device response that generates the error of not able to determine engine.

You should be able to put the 2441ZTH into manual linking mode like any other battery operated device. Use New INSTEON Device with Auto Discover to add the device. I do not have 1.3

What does Help | About display for Firmware and UI?

I am looking for messages the 2441ZTH is generating itself such as the following which is reporting a change in temp Fri 05/03/2013 09:08:00 AM : [iNST-SRX ] 02 50 1F.0F.B4 22.80.0B 01 6E 2B (2B) Fri 05/03/2013 09:08:00 AM : [std-Direct ] 1F.0F.B4-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Fri 05/03/2013 09:08:00 AM : [ 1F F B4 1] ST 43 Being a battery powered device Query is not something that counted on to obtain information. With the newest thermostat showing v.00 firmware it looks like the device was not added with auto discover.

I assume it is a 2441ZTH since batteries are being discussed. Are you seeing temperature reporting messages (cmd1=6E) in the event trace? Fri 05/03/2013 09:05:58 AM : [iNST-SRX ] 02 50 1F.0F.B4 22.80.0B 01 6F 34 (34) Fri 05/03/2013 09:05:58 AM : [std-Direct ] 1F.0F.B4-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Fri 05/03/2013 09:05:58 AM : [ 1F F B4 1] CLIHUM 52 Fri 05/03/2013 09:06:59 AM : [iNST-SRX ] 02 50 1F.0F.B4 22.80.0B 01 6E 2A (2A) Fri 05/03/2013 09:06:59 AM : [std-Direct ] 1F.0F.B4-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Fri 05/03/2013 09:06:59 AM : [ 1F F B4 1] ST 42 Fri 05/03/2013 09:08:00 AM : [iNST-SRX ] 02 50 1F.0F.B4 22.80.0B 01 6E 2B (2B) Fri 05/03/2013 09:08:00 AM : [std-Direct ] 1F.0F.B4-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Fri 05/03/2013 09:08:00 AM : [ 1F F B4 1] ST 43 Fri 05/03/2013 09:08:00 AM : [iNST-SRX ] 02 50 1F.0F.B4 22.80.0B 02 6E 2B (2B) Fri 05/03/2013 09:08:00 AM : [std-Direct ] 1F.0F.B4-->ISY/PLM Group=0, Max Hops=2, Hops Left=0 Fri 05/03/2013 09:08:01 AM : [iNST-SRX ] 02 50 1F.0F.B4 22.80.0B 01 6F 31 (31) Fri 05/03/2013 09:08:01 AM : [std-Direct ] 1F.0F.B4-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Fri 05/03/2013 09:08:01 AM : [ 1F F B4 1] CLIHUM 49 Fri 05/03/2013 09:08:01 AM : [iNST-SRX ] 02 50 1F.0F.B4 22.80.0B 0B 6F 31 (31) Fri 05/03/2013 09:08:01 AM : [std-Direct ] 1F.0F.B4-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 05/03/2013 09:08:59 AM : [iNST-SRX ] 02 50 1F.0F.B4 22.80.0B 01 6F 2E (2E) Fri 05/03/2013 09:08:59 AM : [std-Direct ] 1F.0F.B4-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Fri 05/03/2013 09:08:59 AM : [ 1F F B4 1] CLIHUM 46 Fri 05/03/2013 09:10:01 AM : [iNST-SRX ] 02 50 1F.0F.B4 22.80.0B 01 6F 2D (2D) Fri 05/03/2013 09:10:01 AM : [std-Direct ] 1F.0F.B4-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Fri 05/03/2013 09:10:01 AM : [ 1F F B4 1] CLIHUM 45 Fri 05/03/2013 09:11:01 AM : [iNST-SRX ] 02 50 1F.0F.B4 22.80.0B 01 6E 2D (2D) Fri 05/03/2013 09:11:01 AM : [std-Direct ] 1F.0F.B4-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Fri 05/03/2013 09:11:01 AM : [ 1F F B4 1] ST 45 Fri 05/03/2013 09:11:03 AM : [iNST-SRX ] 02 50 1F.0F.B4 22.80.0B 01 6F 2C (2C) Fri 05/03/2013 09:11:03 AM : [std-Direct ] 1F.0F.B4-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Fri 05/03/2013 09:11:03 AM : [ 1F F B4 1] CLIHUM 44 This 2441ZTH is operating in Celsius so the numbers are small.

nowandthen A PLM with v.98 firmware is not new. I had a v.99 running for a long time with v.9B installed now. Check the Insteon address of the new PLM versus what Show PLM Info/Status is displaying. I don't think the ISY is aware of the new PLM.

Robin Will you eventually get around to identifying the security system you are pushing?

No.

Did the Restore Modem (PLM) run to completion? What does Tools | Diagnostics | Show PLM Info/Status list for PLM address and connect status? Was the ISY rebooted after the new PLM was connected to the ISY? It should not require deleting and readding devices. Something in the process of switching to the new PLM did not execute or did not run to completion. I did not have to do anything with the devices when I installed the new PLM with v.9B firmware.

In case you go back to the single Program that turns the Load Controller On, Waits, then turns the Load Controller Off, when the If section of the Program checks the Status of the Load Controller, when the Status changes to On and a Wait is encountered, the If section is reevaluated which is likely False at that point so the Else clause is executed. This means that the Action statement after the Wait to turn the Load Controller Off is never executed. The simple solution is to remove the Load Controller Status check from the If section. The activity is being driven based on Time so it does not matter if the Load Controller is On or Off at the point where the Program is turning the Load Controller On.

If the Program that turns the Load Controller Off is in the posted Folder the Folder Condition prevents the Off Program from running. The Off Program is only allowed to run if the Load Controller is already Off. That Folder condition seems odd for what the Programs are doing. One Program is checking the same thing the Folder is checking. I suggest dropping the Folder altogether.

gatchel Variables are backed up and restored. The OP wants to develop Programs and Variables independently and install them on three different ISY systems in three different houses.

"Question: If I do a restore with the new PLM will it likely be OK? This assumes the original problem is with the old PLM and the new one will fix the issues described above." Yes, assuming your assumption is correct. Unless you have some reason to believe the integrity of the ISY information is in question a Restore ISY is not needed. A Backup should be taken before changing PLMs. Remember that every device reference to the PLM has to be changed from the old to new PLM Insteon address so the Restore Modem (PLM) may run awhile.

Yes to the items mentioned. (program, variables, config, notifications, all module settings). The Insteon specifics, Device definitions (which includes the Insteon addresses, firmware levels, device types), the Scene definitions including all the link information between devices and between the PLM and devices are part of the Backup. The ISY Restore brings back the information contained in the ISY which it created. Web server files which you create and store on your own are not part of the ISY Backup. I do not agree that installing ISY A Backup on ISY B and ISY C will save time. All the device information, firmware levels, Insteon addresses, links are all wrong. Perhaps the Program Export /Import can be used for Programs. Also hard to see how the Insteon devices installed in house A will match the pattern in house B and house C.

In my opinion that is not practical. Even if the devices are mirrored in terms of numbers, Types and Names you will very likely have different device firmware levels in the devices even for the same device type. The ISY has links in all the devices that point back to what will have to be three different PLMs each with its own Insteon address. It means that anytime a backup is restored to an ISY from which it did not come all the links in all the devices will have to be rewritten to correct the PLM address in the ISY information. Plus the only way to adjust the device firmware level the ISY knows about is to delete and add the device back. Whatever you think you will save in having a few common Programs and Variable definitions will be far outweighed by the efforts to correct all the ISY information anytime a Restore ISY is done for other than the ISY from which the backup came.

barkster I'm pretty sure Robin is using the forum for commercial purposes. There are a few posts from that ID which look very commercial oriented.

A KeypadLinc button defined for non-toggle Off mode will never have an On Status from pressing the button. In fact using 'If Status" for a non-toggle mode button is not appropriate as the button always presents On or Off Status but does not change status which is a requirement for 'If Status' to trigger a Program. Change the Program to If Control 'Key_Pad_G' is switched Off This statement looks for a specific command to be issued by the device which is what happens each time the button is pressed in non-toggle Off mode. Also it is better to put the I/O Linc into one of the Momentary modes and set the timeout interval to 2 seconds. That way the I/O Linc Relay is assured of being On only for two seconds. The I/O Linc Relay is sent an On command to turn it On. The I/O Linc Relay will turn Off automatically after 2 seconds.

A Secondary KeypadLinc button cannot be controlled with Insteon Direct commands. Direct commands have no means for indicating which Secondary button to control. Assign the KeypadLinc Secondary button to an ISY Scene as a Responder. Turn the ISY Scene On/Off to turn the Secondary button On/Off. Note: I just verified that a Relay KeypadLinc does present On/Off options for Secondary KPL buttons. These will not work. As indicated above, Insteon Direct commands cannot identify specific KeypadLinc Secondary buttons. When an Action statement is coded in a Program to turn a Relay Secondary button On/Off no actual Insteon command is issued. This is a UI issue which UDI will have to address.

My thanks to the folks that have sent email, PMs and comments on this topic. My experience with the supplier over many years may well be different than others and is certainly no reason to stop using Insteon unless you have similar issues. I like Insteon and would continue to use if I could. I have a very old inventory if Insteon devices going back to when Insteon first started. That presents some unique problems that many will never see. Fortunately those old devices have been very reliable and actually still are in their own old environment. However, now that I need to upgrade some it is necessary to replace almost all of them. Unfortunately the new devices do not match the color of my cover plates and other electrical devices. I cannot stay where I am because of network reliability problems and I cannot move forward (as much as I dislike SwitchLincs versus ICON) because nothing new matches. Combine that with years of other issues not related to Insteon reliability I am moving on. I hope one would not abandon Insteon based on someone else’s experience. You would be doing yourself a disservice. If you have issues the supplier will not address the situation is different. Then either live with it or move on. Complaining about it over and over may lower the frustration for a short time but does nothing to solve the problem. I did not take my action because I thought it would make a difference as I know it will not. I simply took an action that solved by problem. I will be around for awhile. My test bed of Insteon devices is pretty extensive which I use to work on symptoms that are reported. Way too much fun to throw away the test bed. Unfortunately the test bed will age quickly with its usefulness diminishing quickly over time. I will still be around for awhile. My test bed of Insteon devices is pretty extensive which I use to work on symtpoms that are reported. Way too much fun to throw away the test bed. Unfortunately the test bed will age quickly with its usefulness diminishing quickly over time.

Not sure what is being questioned. Fast On/Off can result in the device reacting faster. A device with a Ramp Rate of 10 seconds takes 10 seconds to go from full Off to full On with an On command. Fast On ignores the device Ramp Rate and moves the device to full On in something like .2 seconds (?). That timing should be explained in the device user guide. As far as the ISY side a Fast On/Off is executed the same way with the same Insteon message as an On/Off. Only the command code in the Insteon message is different. There is no difference in speed on the ISY side to issue an On command versus a Fast On command.

You can isolate the wired Insteon devices by pulling the air gap switch which removes power and requires no electrical knowledge. However, I think you want to look at other items first. The more Insteon devices that are repeating messages generally the better the network works. The PLM should be plugged into an outlet that is central to the electrical system. In other words it should not be out on the end of a long electrical run. Other electronics should be isolated from the PLM with a FilterLinc. It is common for devices such as UPS, PC power supply, other electronics to absorb some of the Insteon signal making it difficult to impossible to reach other devices. No surge suppressors on the circuit containing the PLM that are not isolated with a FilterLinc. Insure that phase coupling is installed and working. Run the 4 tap Set button test described in the device user guide to insure there are Dual Band devices in good RF range of each other and on opposite 120v legs. Unplug appliances. Turning them Off does not remove them from the power line. Then see what kind of reliability exists in the various locations. Run Tools | Diagnostics | Event Viewer at LEVEL 3. Using the Admin Console turn On/Off various devices watching the Hops Left=x count. With Max Hops=3 Hops Left=2 is the best, Hops Left=1 is okay if the count is consistent, Hops Left=0 is as poor as it gets and still work. By issuing On/Off commands to various devices a pattern of what is reliable and what is not can generally be determined. DO NOT start moving the PLM around to solve problems. That may be necessary but first see what is causing issues on particularly unreliable circuits. Simple moving the PLM around often fixes on issue and causes another because the underlying problem is not PLM placement but some sort of interference or lack of good phase coupling. It can be a slow and frustrating process to identify and resolve powerline issues but well worth the effort. Once a good Insteon Mesh network is established you will like the results.

Thank you hbsh01. Appreciate your comments. I still have my Insteon test bed of devices and an ISY that manages those devices. I have always enjoyed problem analysis and problem solving. Started with main frame hardware maintenance in the 60's, software maintenance when operating systems became the norm and then program development for a few decades. I hope to continue to make some small contribution to Insteon and ISY for years to come. Helps keep an old mind from turning into mush. Just could no longer deal with that company any more.

iostream212 “and Smarthome is one of the worst companies to deal with. They couldn't care less about their customers and support is non-existent.†I did not start the discuss in this thread about Smarthome as a company. I added my views on the subject. It is a shame as they were very different back in 2006. One of their representatives called me at home to determine how I would use Insteon. You think that would happen today? I do not require the individual attention UDI pays its customers but I do require a business to respond when they have issues. Perhaps I should have been more tactful and said “I no longer find Smarthome a company responsive to my needs and have removed their equipment that has been installed since Insteon startedâ€. As a user I can accept the situation or reject it. The problem cannot be fixed in my opinion so I did the only thing I could do. I stopped doing business with Smarthome.

iostream212 Well I guess I should apologize for posting information you do not want to read. If you find Smarthome a good company to deal with that is great. I have been dealing with them for many more years than you have and find their business practices so unacceptable that I DUMPED their technology even though I am happy with Insteon itself. If that was not something that should be shared with the Insteon community than we will have to agree to disagree. Come back in 7-8 years and we will see if you are still satisfied. Let’s hope so.

When removing power does not restore device function that is generally an indication of a device that is near the end of its life cycle. The only other thing I would try before replacing it when a power cycle does not bring it back to life is the Factory Reset. Must do a Restore Device after that to bring back the link database. Of course there could be wiring issues if this is an n-way device where the wires had to be retasked when the device was initially installed. If the travelers were not retasked correctly the physical On/Off state of another switch location that was originally part of the standard n-way hookup could affect the power this device is receiving. If you are comfortable working around electricity the next time this happens verify that the Black/White Line/Neutral connections actually have 120v power. There have been cases where the travelers were not done correctly and power was lost at a switch based on the On/Off state of another switch. I am still a big fan of Insteon and certainly ISY. I have lots of Insteon devices in the test bed managed by a dedicated ISY that are toys to play with. But enough is enough when it comes to Smarthome. Eventually my test bed will become out dated and then I will have to find something else to keep this old mind active.