blueman2

OK, I finally got it to write and it now works. The trick, as people have mentioned, is location. I had the remotelinc in the same room as the new PLM I just installed. When I moved the remotelinc across the house away from the PLM, it worked just fine. Apparently, this new PLM (2413S) has a bad radio. Same issue with other remotes that are used anywhere near this PLM. I think I may need to return it.

Exact same issue here. I had to replace my PLM and now I cannot communicate to my Remotelinc 2440. I deleted it, re-added it, and it adds along with all 6 buttons, but it continues to show the '010101' icon and gives failure message on trying to write. Exact same message as I have read in several other posts on the 2440. I have added and removed it 4 times, done factory reset 4 times. Used all different ways to add (2440, auto). Tried restore with no joy as well. Using a new 2413S V2 PLM with 9E firmeware, and 4.2.28 on my ISY and java.

Thanks, Michel. I have the highest respect for UDI and the ISY product. I also find your responsiveness and willingness to help customers to be exceptional. I will work to make the changes you recommend. I need to do some more research to make sure I really understand what I need to do/disable with my programs. That said, I am still amazed that Smarthome continues to sell a product explicitly for Garage Door Automation when there is a known bug that makes the product unsafe for that exact usage. This is not a case of the customer using a product incorrectly. I had it installed exactly as in their instruction booklet. Yes, there is a warning about CLOSING the door and making sure there are no obstructions. But there is no warning that the door can open at any time, day or night, and remain open until you manually close it. Perhaps for days or weeks if you are traveling and not home. I think Smarthome should stop all sales of the Garage Automation kit until this is resolved, and provide a recall of existing units so that customers know about this problem. We should not have to read forums on the internet to find out about such a serious security issue. Sorry if I come across as being negative towards UDI. I am not. But I am increasingly negative about Smarthome. Creating this level of risk and not warning customers about this SPECIFIC issue of a known bug is reprehensible.

Update. I now have my Garage Door being controlled by ELK (should have done that long ago!), I have removed 80% of programs that were not critical, have added 1-2 second program delays where recommended in the master thread on the ALL ON bug, and have Air Gap shut off my whole house fan until summertime. Given all these changes, I think I will be able to survive another ALL ON event should one occur. Only issue I see is WAF. If she gets woken up at 3:30am as has happened with some, or if it occurs when I am traveling, I will pretty much be forced to remove the ISY and perhaps even all the Insteon devices. Fingers crossed.

Yes, as I think you and I have laughingly traded posts on before, we all should take a page from Battlestar Galactica. Integration and automation are all well and fine until they go horribly wrong!

Thanks, Lee. This probably should be in the Bugs thread in the other forum area, but in my case there was no RF device apparently involved. I say apparently because I do have several RF devices, but they were not involved in any of the scenes that might have triggered the event based on the logs. It was either a program looping itself (I am still investigating that) or a command from an ELK motion sensor (hard wired to the ELK) that somehow triggered the event. I did recently install a DB device, but in another part of the house and apparently unrelated to this event. Only thing that has changed was a new PLM the day before (my old one had a capacitor failure so I placed with a new v2.0 PLM. Before that, I have 3 years of no issues. So I think it is fair to say that we are still not sure what is causing this. We have working theories, but no hard proof. Given that, I think prudence dictates we take a safe approach and assume this ALL ON event can happen anywhere at any time. Over time, this bug will be resolved. But until then, and until we are Five9s sure what the root cause is, we should all take the safe approach and assume it can happen.

Xathros, just read your post. You are 100% right. This is exactly what I am going to do. I am personally comfortable with any other device turning on and staying on. But my garage door and whole house fan cannot. So I have already put my door on my ELK (it was a trivial switch over since both are in the garage), and will replace my whole house fan controller with a z-wave switch and leave it air-gap off until I do. But I still think UDI/Smarthome have a responsibility to quickly and fully disclose to all consumers the safety issue involved with this bug.

Teken, your points are well taken. And anyone who is completely ignorant of safety, or who does not understand the risks we take in doing this type of 'hobby', simply should not be doing this type of 'hobby'. But what is the rationale for Smarthome to sell a Garage Door Controller? You cannot sell a device you know is inherently unsafe, and then try to protect yourself by putting a label on it saying 'unsafe'. Of course, there is not even that label. All I have seen is a vague warning not to use unless someone is near to door to watch for safety. I see nothing that says 'warning: do not use this on a garage door because it might open itself at any time'. Guys, this is a serious safety problem. It needs to be well disclosed to consumers. UDI and Smarthome have a responsibility here. This problem has apparently been around for many months. There should have been a very clear and LOUD disclosure before now about the safety issues involved with this bug.

Great input, guys. I would normally agree that taking a step by step approach to debugging is the way to go, and would normally just delete programs that I suspect cause the issue, or delete them all and add them back one by one. That is what debugging is all about. But my concerns are: 1) We apparently do not really know the full root cause of this. So any action we take is only a guess. 2) Some of us have devices controlled by Insteon that are a danger if they turn themselves on without warning and stay on Given the safety issue involved here, guessing is really not good enough. I only see 2 options 1) remove any device from Insteon control that I am not comfortable turning itself on at any time of the day and staying on indefinitely if I am traveling 2) remove my ISY Frankly, I am not sure there is enough value left to ISY if I have to go with step 1. But definitely something to consider down the road. Option #2 seems the only prudent option. Folks, we are talking SAFETY here. I don't want to have to 'debug' safety related issues. Too much risk. Either UD/ISY or Insteon (or both) needs to make a very public disclosure about this issue and fast. Also, Smarthome needs to stop selling Garage Modules immediately if their system is not safe for access control. And they need to disclose that none of their switches or devices should be installed on a device that cannot safely turn itself on at any time and remain on indefinitely if no one is home.

Due to the random ALL ON event issue, I may have to remove the ISY control box from my setup. We have a very dangerous event happen today due to this (garage door opened by itself, whole house fan turned on with windows closed), and my wife is none to happy with me. If we had not been home, it would have been bad. So I need a safe backup plan. I know I will lose all programming as well as ELK integration, but there may be no choice. So, that raises the question of how to do it? I want to keep all of the linkages and scenes if possible. Can I just power down the ISY and keep the PLM plugged in? I assume all scenes will continue to work, right? If I do need to unplug the PLM, should I just do a PLM remove in ISY before disconnecting the ISY? Otherwise, my switches will try to talk to the PLM and when they get no answer will do that funny blinking to show the comm error. I guess I will keep the ISY for modifying scenes (much easier than doing from the switches) and for if/when the ALL ON issue is resolved. Thanks, Blueman2

I have always wondered what the Hops Left and Max Hops numbers meant. Anyone know?

You both are getting to the heart of my question, so thanks! LeeG, as you said, the ISY links table has indeed been updated to the address of the new PLM. So I do not need to do any more "restore PLM" commands. That is good. What I did not realize is that when I re-enable one of the devices that was disabled during the PLM restore, it will show up with the little "010101" icon showing that it needs to be updated. So stusviews, you are right, I can just wait until I need each device and do a 'write updates' at that time. I was worried that I would forget in the future which devices have been updated with the new PLM address and somehow cause problems (thus the thought that I might need to sit down now and do them all to avoid uncertainty as to which devices have been updated). But ISY has taken care of all of this for me with the pending 'write updates'. Thanks, both of you, for the help! Blueman2

I have about 20 devices that I linked to my ISY, but then disabled and put in a drawer. These are backups and future use devices - I like them to show up in the ISY screen so that I know what I have as spares. I just did a PLM replacement and went through the Wiki steps. But I did not see any procedure for disabled devices. Since they have not been written to, I am guessing ISY still has the old / stale links for the old PLM, right? What is the best practice for updating all these devices? Do I need to connected them one by one and do a restore PLM each time?

OK, well I did go ahead and order a new PLM from Smarthome. In the mean time, I am seeing lots of "could not communicate with xxxx" every time I log into my ISY. I can query the device and it does respond, but clearly I am having either PLM issues or network issues. If the latter (network), what could be causing this?? I did just add the Z-wave module to my ISY and added several Z-wave devices, but that should not cause this issue should it?

So the PLM that is to be sold by UDI is just a regular PLM with better caps, or is it one with different features and capabilities? If the latter, I might wait to get a new one and get it from UDI.

I have been having issues with KPL LEDs that are controlled by ISY programs not always being in the correct state. I tried replacing the KPLs with no improvement. Also, I am starting to notice that light being controlled by my ISY (through programs) are not turning on or off as reliably as I am used to. Could this be a symptom of a failing PLM? I was not sure what their failure modes are. Do they fail DEAD (no lights on the unit, no nothing), or can they also fail with intermittent communication?? Secondly, I was going to buy a new PLM, but I understand that UDI is creating their own which sounds interesting. Any idea on release date? If they are doing their own and it provides features that are useful, I might just try re-cap'ing my existing PLM and wait rather than buying a second 2413S. Advice?

Thanks for the answer, MWareman and LeeG. Makes sense. So any Scene command coming from the PLM itself is not ACKed or retried. Good to know. That actually explains a lot. My issue is that there is one area of my house that seems to have a lot of noise in the line. I have put a filterlinc on some nearby transformers, and put a Dual Band device right next to the KPL (non-DB) hoping that the DualBand device would give clean communication to the KPL. But apparently not. Odd thing is that my PLM (2413S Dual Band) is just about 20 feet away from the DualBand switch located right next to the KPL (non-DualBand). I guess my wireline is so noisy that even with the DB switch right next to the KPL, the noise is still drowning out the signal. Time to replace it with a DB KPL I guess.

I know that Insteon has the ability to verify receipt of a command and retry if not received. But do programs do that same? I ask because I have a program the turns on/off various KPL LEDs. Often, I find that my LEDs are not consistent: one KPL's LED will be on, while another will be off, when both are in the same Scene that is being controlled by a program. I almost never have this happen when a scene is being controlled by an Insteon device. Only when controlled by a program. Any ideas?

For me, it was all about the number of nodes. I exceeded the limit on standard version in my home. Now that I got the pro version, I have decided I should have purchased it before anyway. I like the ability to do lots of changes and then batch update my devices. Much more efficient.

I empathize with you on this one. I either have or would like to have all of the components you mention. Here is what I have learned so far: 1) I have gone entirely with wired motion detectors, wired into my ELK. I then access their states and run programs based on MDs in ISY because I like the ISY programming language MUCH better than the ELK's. This is the most cost efficient, stable mode of operating IMHO. 2) I have been looking (without success) to find a whole home security DVR system that will provide dry contact relay outputs for things like alarming, motion, etc, so that my ELK and ISY can respond to these inputs. But I have yet to find any video security system that provides either dry contact or 5V/12V output triggering. Maybe something could be done via HTTP talking to ISY, but I am not sure anyone has been successful there either. 3) My brother has this same issue. Surprisingly, we just installed a dual band device and it worked. Not sure if it is using RF or Electrical wires, but it works. And yes, this is probably the ONE area where using an Insteon MD will be required. 4) ELK: all of your door/window sensors should be hard wired. All motion detectors should be hard wired to ELK. All smoke detectors hardwared into ELK. I have my garage door sense and control on my ELK (the Insteon ioLinc solution for garage doors is a kludge). Insteon: For switches, plugs, etc. I do not use motion detectors on ISY unless I have no choice (e.g. your barn) Z-wave: Door Locks, Pool Controller (basically, devices that I wish had good support by Insteon but do not) 5) Other thoughts: I am doing EXACTLY the same setup for iTunes. I like having a dedicated server running iTunes 24x7, and use Remote apps (there is one for Android and IOS) to play my library. And yes, people can still use airplay from their device if they want their own music. Overall, I say good luck with this. Looking forward to what others say. particularly around integrating home video security systems into ELK/ISY. This has been a major issue that needs resolving.

Ah, now I see where the 344 number came from. So that method does not help me. So as far as my original question, is there any way to do that math aside from manually counting each node and scene? Doable, but since this is an important licensing issue, I thought there might be a more simple way to see how close I am to needed to upgrade to Pro version.

I thought the 256 limit was for total of scenes AND device nodes. Or is it scenes OR device nodes?

Thanks. That shows 344 items. So I am already over the limit for non-pro version? I did a manual count of all nodes (devices and scenes, including for example all 8 buttons on a KPL) and came up with closer to 210. Something seems off, at least in terms of what ISY counts as devices/scenes. ??

I know I can generate a topology report, which lists every node and every program, but is there an easier way than to manually count each node line by line? I have about 80 devices and if you count each node under each device (e.g. 8 for a KPL), and add all the scenes, I am worried I might be running up against the 256 limit (for non-pro version).

Yes, I have several 4 button KPLs. They have a very high WAF due to the more simple look and layout. My wife hates the 8 button and even the 6 button. But 4? Loves it. I just put AB in one scene, CD in 2nd scene, EF in 3rd and GH in a 4th.