Teken

Tools -> Diagnostics -> Event Viewer -> 3 Device Communications Events.

If you believe that is the best course of action you can certainly use the *Delete PLM* option in the Admin Console. Once done you should also complete a hard reset the 2413S PLM using the full users manual as the guide. This process is not favored by many here, but my personal experience is if you believe starting fresh with a good known state is the desire. Then, I don't see that being a problem at all to have that peace of mind. Its only your time being used up and if that is something you wish to do go ahead. I would follow up that if you're intent on doing this task you might as well hard reset the entire home. This will ensure all half links are erased and brings each device to a OEM known state. Best practice is to always hard reset any new device prior to enrollment anyways. Good luck . . .

I'm more distressed to read that at least two people have indicated the latest 2.XX hardware based 2413S PLM's have died well under 12 months. I really can't believe these devices after seven years hasn't been thoroughly designed, tested, and validated to operate with a MTBF were it exceeds a minimum of ten years?!?! You could be forgiven if this was your first go at it like some random Kick Starter project. But this isn't a KS campaign and Smartlabs has been around for a long time and has the resources to make it happen. Its clear to me they simply don't want to . . . It amazes me this company allows *big mouths* like me to continue throwing them under the bus so easily. You would think they would be saying to themselves. I just have to shake my head this conversation hasn't taken place . . .

No offense to anyone but it's pretty sad when you need to have a few spares of something because a product is simply not reliable. [emoji58][emoji37] Ideals are peaceful - History is violent

Apparently having a 2.XX PLM doesn't seem to be offering many people long term use or reliability: http://forum.universal-devices.com/topic/17734-i-think-my-new-plm-is-dead-please-help/ What a pity . . .

Good to see it worked out in the end. I'm not sure why sometimes this process is required to enroll a new device? But, I've found in different installations this method is required which doesn't offer much insight besides that it works.

1. What is the ISY firmware & UI as stated in the Help -> About? Both should be the same and if not please ensure you clear the Java Cache and download and use the correct Admin Console for the firmware you're using. 2. Hard reset the On-Off Relay module per the full users manual. 3. Once step two is done you can try the Start Linking option. Select the *Start Linking* two whirling arrows in the Admin Console. Next press and hold the set button on the Insteon device until it it beeps and starts flashing the LED. Afterwards select option 1 to delete all existing links and press finish. While you do so set the level 3 error logs to record the actions and provide them here.

Hello Peter, Can you provide a screen capture of what the negative values look like exactly.

This is a very common mistake made by others which is simple to resolve. Place all of the responding lamp linc in the *On* position. When you initiate the 4 tap beacon test if any dual band device is on the opposite side of the electrical leg it will continue to show a green LED. If the lamp linc is on the same electrical leg it will flash red and alternate with current state of *On* green LED. This is the easiest way to see the true colored LED. Also it should be noted unlike other dual band devices the lamp linc does not have a 4 minute timer. Meaning if you use a lamp linc as the initiator it will continue to send out the RF beacon test until you push the set button.

The trace indicates very poor communications as you have zero hops left.

Just a quick note for those following this thread and who may be new to the *Replace With* option. When you enroll the new device name it something different like say: Kitchen Light 2, where as the old one is called Kitchen Light. Failure to adhere to this basic rule will cause the 994 Series Controller to cry and try to replace the device and then close out the Admin Console. What you're left is a corrupted and poorly added Insteon hardware in your system. I've seen this many times over the years so don't make that mistake! Lastly, it should be noted that some devices actually need to be deleted & removed once it has been replaced with another piece of hardware. A perfect example is the Trigger Linc vs the newer Open-Close sensor. The older unit did not have a heart beat feature and if you try to use the replace with it will come back all screwed up. So essentially you will need to do the replace with first then delete the device from the controller and then add it back. What this does is keeps any massive scenes, programs, etc still linked so you don't have to start from scratch.

As others have indicated one of the first things to do is ensure the two sides of the electrical feed is properly coupled / bridged using the 4 tap beacon test to confirm. Regardless of all the coupling in the world it will not supersede the need to identify any noise makers / signal suckers in the home. As Brian H noted I am a huge fan of the dual use and given the choice of the Range Extender (RE). I would choose a lamp linc / On-Off relay module first over a RE unit. The On-Off relay module would be my preferred choice given it has some of the latest firmware embedded features. The major one worth noting is having the ability to turn off power line or RF communications. I surmise that all future Insteon devices will have this feature in the not too distant future. As this would allow Insteon to mimic Z-Wave as a RF only hardware device. The over all intent is that it should technically negate any sort of power line interference from impacting the signal from getting to the 2413S PLM. Having said this it also assumes Smartlabs will grab a brain and change the position of the antenna and also increase the RF power output. RF power output has been increased in at least three items and this is good to see because the existing output is much too low. This has been seen on the HUB II, Dual Outlet, On-Off Relay Module.

LOL . . .

Mwester, Sometimes I wonder if you're in my head reading my inner thoughts?!?! Ha . . . I am sure what you wrote is a combination of things; first if this issue was really important to them you would have seen real change and interaction with the general public. This has not been scene since the SH forum was created and back in the good old days they had actual people who worked there taking on feed back and relaying the very same. Then the Chinese wall was erected and the company policy was say nothing, ever . . . From time to time there have been some random attempts to engage the public as was seen by the new Wish List and Isaac who asked that people select the *Like* button in any idea to help them gauge interest and need. Sadly people like Isaac, Carlos, have no say as to what is going to happen etc. On a related note I was shocked to hear one of the best people who I knew there *Carlos* is no longer in the Beta program or not with the company any longer? I can literally count on one hand the amazing people that I have engaged with. These people were the heart and soul of the company and to see people who really want to make a difference get moved or leave. Wow, all I have to say is its just dumb luck this company is still operating on all cylinders. With respect to the PLM chip my feelings are this issue is more about two things. One that they have not 100% narrowed down the ALL ON / ALL OFF issue and Smartlabs (Joe Dadda) as we have read here have not given UDI the means to flash the chips should it ever be required. I find this part extremely amusing and irritating at the same time . . . Lets all speak plainly here shall we there isn't one global vendor in the free market that is interested in taking on Insteon as a HA protocol, none! That ship has sailed away like it did in the VHS vs Beta wars. This same war was fought in the Blue Ray DVD standards and ironically it was funny to see Sony finally wake up and smell the coffee as they finally relented in accepting the porn industry would and has changed the balance of which standards would ultimately win. Porn is king and Sony had to accept that fact or see the infamous Beta loss be seen again with respect to the Blue Ray. Back on topic: Of all the (active) vendors which there are only 3 UDI has been the Insteon champion that has made many products OK to be excellent and bearable. I have to gather the thread I created which indicates at least three new global PLM's are either all Smartlabs or one is being assigned for the 994 Series Controller but who really knows. This is the problem with signing a NDA because lots of this information can't be shared to the general public etc. It would be great to know from UDI at least if there project is still in the works and simply waiting for the chips to be sold and they are given the rights to flash them should the need arise. I hope 2016 will see a global PLM in any iteration for those across the pond though. As this will help everyone in the big picture as the extra revenue will help each company grow and hopefully obtain more resources to complete random projects.

It would have been interesting to see if the capacitor fix would have resolved this issue? I don't believe a 2.XX 2413S PLM would have been impacted by a failed capacitor issue and believe more this is a power related matter. Its too bad you don't have any kind of power logging to determine how clean / bad the power line is in your home. Its safe to say if you had the time to replace the caps and it brought back the PLM it would offer the forum members another data point. If on the other hand it didn't it would affirm my thoughts that this device is still not designed properly to sustain moderate amounts of voltage swings and surge events. Most common electronics appliances are built to sustain 89 - 150 VAC for short duration's. More commonly electronics are designed to operate in a range of 90 - 132 VAC. As I have indicated many times here and in other forums most electrical surges happen with in the home which is self induced and rarely caused by outside factors like lightning etc. The most common devices which cause in band surge events are sumps, fridges, HVAC, etc. Anything with a motor and large start up current will inject large and very brief micro surges in the home. This is why its so important that as many large appliances such as these are placed on dedicated and isolated breakers. This limits the amount of injected line noise and micro surges impacting the rest of the home. As stated here and many other forums its important to use all three types of SPD's. That is from Type 1, 2, 3 in all areas of the home in hopes of reducing surge currents from impacting those sensitive electronics. Having said all of this it should be noted unless you have a some serious AVR systems in place none of the SPD's will resolve a voltage sag (brown out) or frequency drift. This is important to note because again depending upon circuit design which most reputable engineer would follow anyways. Can't say Smartlabs falls under that label . . . When voltage drops, current rises and unless the PSU is purpose built and designed to regulate such lulls it will blow out IC's in short order. Its a often misconception that a device which incorporates a regulated PSU is in fact tuned to respond to voltage sags when that isn't the case at all. You will note 99% of all PSU designs indicate voltage rise (limit) protection - no where does it say it protects the hardware against voltage sags, ever. The only place you will see that stated and written as the SOP is in aerospace, military, and industrial applications.

The reality is most American companies are still living in 1878. The majority of the free world use Metric as the measuring scale but as you noted even if a company offers Metric in their system. Its either inaccurate or hobbled down where it simply makes no sense! If you look around at other EU TSTAT's which offer some kind of open API / Network access perhaps you might find a happy medium.

Hello Mike, Is the 994 Series Controller using a static IP or DHCP? If static change it to DHCP and see what happens. Also, you will need to confirm if this is a Anti-Virus / Fire Wall issue. Turn them all off and report back what the outcome is. Keeping in mind even if you turn off both software applications you really need to ensure they are white listed to ensure the 994 can reach the Internet. Also, I would reboot the ISP modem then the router . . .

Hello Mike, Have you hard rebooted the 994 Series Controller? Often times after the firmware update the soft boot does not actually bring the system back on line. Pull the plug on the controller and wait about 10 seconds than apply power to the device.

When you first add the devices to the ISY there will be an option to save the existing links. I would however advise you to hard reset all the devices and remove all the links as the first option when enrolling. Failure to do so will leave your home in a unknown state and you will be running around like an idiot wondering why things don't operate consistently. The time invested now will save you time, effort, stress, and the hair on your head . . .

Submit a service request to UDI so it can be reviewed. Ideals are peaceful - History is violent

As stated in another related thread a phase coupler will not help a marginal Insteon network in the home. The 2406H does not repeat or regenerate the Insteon signal it simply couples the two sides of the electrical feed. Only a dual band device will repeat and regenerate a Insteon signal in the network. Regardless of all the coupling / bridging in the world it will not supersede the need to identify and remove, isolate, filter any noise makers / signal suckers in the home. I can guarantee you haven't identified all the noise makers / signal suckers in your home using two of the most common methods. As a simple test take one of the lamp lincs and plug it into the same 2413s PLM and try to add it into the system. Does it work?

Hello Mwester, I was wondering when you would chime into this topic. Ha . . . Back on topic: I have to agree a bridge device should be used to log all inbound / outbound data packets. As Xathros indicated he doesn't believe the PLM has any real impact on this whole issue and I and many other agree completely. I can tell you from personal experience what my observations are with respect to what's going on. First, this is a waiting game in terms of how many people are impacted and documenting those numbers. Next, its reducing their liability and risk moving forward because Smartlabs has initiated a product wide removal of the ALL ON / ALL OFF command set. This was done to the 2413S PLM because in the early days people were under the belief this was the root cause. Well time and history has proven the 2413S PLM is not root cause or solution because if it was those using them would not be seeing this persistent issue would they? Next, Smartlabs figured we better get a handle on this moving forward and removed the ALL ON / ALL OFF command set to all current shipping products. Again, this was done to reduce liability and future risks . . . It does not help or resolve those millions of installations which have native ALL ON / ALL OFF command sets written into their hardware (firmware) set. So next people are saying random RF Insteon based signals from battery operated devices are one of the main drivers and the primary culprit has been the Insteon Motion Sensor (MS). I would probably accept and believe this to be true but given the dozens of stories in this forum and others where not a soul was present or awake when a ALL ON / ALL OFF event occurred the facts don't track. Then we have lazy, inept, programming to blame . . . I freely concede, I fall into this category of lazy, inept, and unaware of dirty coding as its apparent 40 plus people are too! Because what people are trying to sell me and others (which I won't buy) is that bad coding in the system is the another factor in causing this issue to arise!?!?! As indicated above this so called ticking time bomb of bad / dirty coding is going to resolve itself by adding wait periods and so forth. Lets all sit down and track what I just wrote for a minute shall we. I have every possible condition that is a cesspool to generate this terrible situation. Yet I can walk around naked all day long for days, weeks, months, years, having the above things in place. Yet it won't happen every second, minute, hour, day, week, month, year?!?! Does anyone smell what's brewing, what does the Rock say when such conditions exist? Again, lets even dumb this down to its basics and fully understand what is being said and not said. If I have a Insteon network void of any sort of controller in my home there hasn't been a documented case here or other that has experienced a ALL ON / ALL OFF condition, ever . . . I mean ever . . . So we have tens of millions of homes with no controller at all and not a soul has ever experienced this condition. Its safe to say based on time and history its not from RF battery operated devices causing the same. That is a plain simple fact and not conjecture at this point in time. Ultimately as I stated above with the advent of removal of the ALL ON / ALL OFF command set from shipping hardware everyone is simply buying time and waiting for the dust to settle. I've been following this condition since day one and over the years its incredible that this issue hasn't been laid to bed. This issue is distracting, and harmful to UDI and the 994 Series Controller. Every month I receive at least one personal e-mail asking me what can be done and my thoughts. I've abstained from offering anymore insight that hasn't already been posted in the public domain. As its not something I have direct control over or insight too on a personal level. Having said all of this, its my belief more can be done as Mwester has indicated above. As stated in the ALL ON thread there are several things that can be initiated and started to identify root cause. 1. Take a user who is impacted by this problem and swap out all existing devices with new hardware which is void of ALL ON command sets. This user is the epitome as a controlled subject because we know 100% the hardware is not capable of accepting these bad comms. 2. Next we take another user and remove the controller from the environment for a specific duration leaving everything else in place. 3. Last, we take another user and review all programs, links, scenes, etc. In this case we do nothing except track the frequency of the events via data logging. Of course all three test cases would have a bridge to monitor all inbound / outbound traffic. All of these examples are doable and quite frankly should have been done two freaking years ago! In case its not clear this whole situation frustrates the hell out me because something can be done!

LMAO [emoji38] I know for a fact if there was one company that prides itself in security / privacy that is UDI. [emoji4] Lastly, I don't want anyone to take my writings the wrong way. UDI has stood fast in helping and facilitating with Smartlabs in obtaining Beta PLM's in hopes of solving this issue. My point is this is just a band aid to a much larger issue that isn't being explored or reviewed. As others have mentioned in the past more low level diagnostics needs to be implemented system wide which monitors all traffic and command sets. It's simply not possible a global all on - all off is issued to the entire network by a malformed data packet due to collision. Keeping in mind why doesn't a low battery state which is known to send endless on's (without a controller in place) never cause a all on / all off? [emoji58] Where are people placing a (wait command) in the Insteon network? [emoji53] It certainly isn't being placed natively into any Insteon hardware now is it? Ignoring hardware that is known to resume on upon power failure. Even if you had the crappiest power known to man why doesn't it happen every time there is a power blip?!? Lastly, there are several users who have replaced the PLM yet this problem is still present. Really?!? It's impossible a device which has no command set to do so has this capability. Why is this important to note? Because people are saying some random message caused the PLM to issue a global all on / all off. There is a higher likelihood that I get struck by a pink elephant from the sky then the PLM doing this all by itself all the while the ISY is unaware of this action? Come on, I wasn't born yesterday! [emoji23] Ideals are peaceful - History is violent

I think people really need to sit down and really consider some of the basic elements which most of us believe is grounded in facts. In my experience there are several ways a controller may not be aware of state change. There may be more but off the top of my head here are the most common ones. - Device(s) are linked manually outside of the controller. - Links are lost in the 2413 PLM due to the ever present capacitor issue. - Noise: Typically when noise makers / signal suckers are present it can cause Insteon signals to be lost in the ether. - Power: If there is ever a loss of mains power and the PLM is not brought back on line before the ISY there will be out of sync issue. - ISY Lock Up: Depending upon how many network, programs, etc are active this condition can cause the controller to miss a change in state. Now the above are known and accepted scenarios where it is outside of the control of the 994 Series Controller. Lets assume none of the above is true and all hardware is operating perfectly fine. There are user issues that are supposedly at play here that cause these conditions to be more prevalent when compared to others. - Tight loop programs (repeats, polling, query, active on start up) - Poorly crafted programs that have direct conflict of other active programs. - Too many network related applications being executed thus causing a delay or missed status. So now we have what some believe are collisions of data packets in the Insteon network. - This could be from battery powered devices because they are known to send out multiple On/Off commands. - Low battery condition where the MS sends continuous streams of On's when in a low battery state. Now, the next possible culprit is hardware that has firmware that by default restores a device to a on state when power is lost. Keeping in mind some hardware devices require at least 1-3 seconds of power loss before this happens. Where as others simply need a blip in power and this condition will be seen. Having said all of the above I want people to sit down and really consider how it is someone can walk around for months, years, and have the exact same set up and never make a change. Out of no where this problem arises? Read what I stated and say it aloud does that logic track?!?! Its not very often I use the word impossible because most of us who have been around long enough knows. Impossible simply takes longer to accomplish. My point being is if your home was a ticking time bomb because you were too stupid to program your controller with clean code, had crappy power, didn't bother changing out batteries, had dozens of network resources running 24.7.365. Why isn't this problem happening everyday, every hour, every second?? You see how none of that makes any sense? If your home was teetering on imploding because you were completely clueless about basic *Best Practices* this problem would be happening all of the time. In fact it doesn't and yet dozens of the smartest people on this forum, engineers, and application experts are unable to isolate, reproduce, and repeat any of this in another environment? Impossible . . . As I stated above (assume all is well hardware wise) and ignore any possible hardware that is affected with a return to a on state when power is restored. There are dozens of Insteon devices which are linked to a PLM. The controller has direct connection to the PLM and should know when a state change has occurred. Yet we are to believe none of this is visible to the controller on a massive scale?!?! Impossible . . . My view is this isn't visible in the logs because its simply not known and tracked. Its impossible that 1 - 100+ devices which have links in a PLM which the controller manages and has complete command and control over has no clue something on such a massive scale has happen. Keeping in mind there isn't one controller or software application in the open market that does the very same, none. Smartlabs isn't known for making very reliable and robust controllers yet even their most feeble device has never been documented to see such a condition?!?! There are dozens of software only applications which also use the 2413S PLM for direct communications and not one of them has ever seen this issue. Now, on a complete tangent I was told there were model years of Insteon hardware that could issue a ALL ON / ALL OFF command set when failing. I have never seen or heard of such an event that was ever documented here in the forums so don't put too much weight on such a scenario. I have also never read of a person who could invoke a system wide ALL ON / ALL OFF command using what ever method via software / controller. This last part is important to note because I believe if we fully understand how this command can be invoked at a basic level. Then, it should not be a stretch to craft software to negate the very same . . .

Yeah, the search doesn't bring up that specific thread unless you know the key phrase. Apologies you had to wade through all 36 pages for information but its best you read whats going on and what some of the possible interim fix's are. I am of the opinion most of these fix's are just band aids to a underlying issue. There isn't a soul that can explain why and how a person can walk around their home all day long and nothing happens for months. Yet in the same breath the majority of people will also be dead asleep or out of the house and come back to see the entire home all lit up?!?! Any reasonable person would call bull sh^t that (added) wait times are going to solve the issue at hand. There are several people who also have no motion sensors, replaced the PLM with the latest and greatest yet this issue still appears. The fact it still happens indicates there are other factors not being considered . . . At the end of the day there isn't one single person who can reproduce the ALL ON / ALL OFF issue at will and let others do the very same. I find that incredible, and hard to believe at the same time, but apparently its true. The biggest problem is there are too many moving parts in this whole issue. Many people have various model years, firmware, and programs in place. While others have hardware that are known to default to a on state when their is a power loss. There was a thread not too long ago where a fellow almost burned down his house because his daughter dropped her scarf on a lamp and when she was out and about the power blipped. When the power came back on that switch resumed in a on state. So, people have to take that into consideration in knowing do they have such hardware in place? Was the actual ALL ON caused by bad firmware in the switches? Now it doesn't explain the I/O Linc but then again who knows if certain years also had odd behavior programmed in their firmware. Knowing Smartlabs its not a stretch they had bad firmware in place and have since corrected some of them. People could say *Teken, how the hell do you know that* well because today's I/O Linc has a different hardware revision number along with different firmware listed in the ISY. They didn't change that because it was fun . . . It was changed because they decided or found out a specific scenario would cause XYZ to happen. As of this writing Smartlabs is in the midst of removing the ALL ON / ALL OFF command tables from all shipping products. Nobody really knows if this project is completed or where it is in the pipe line. Considering there are lots of NOS gear in the market place from various on line sellers etc. Ultimately, what will prove very interesting is to see an entire home void of any hardware that has native ALL ON / ALL OFF commands inside along with the same 2413S PLM and if the this issue is still present. If it happens in this scenario well you pretty much know where its coming from . . .