Reliability issues? "Repeat" command could be your friend

[SpicyMikey]

I do not have hard connection issues with any devices, or even devices that have more issues than average.  But, I do have transient reliability issues which occur periodically.  I'm sure everyone has seen this, especially if you have 20, 30, or more devices on programmed cycles.  For some reason, a particular device did not respond to a particular command on a particular day.  For me, with all my electronics equipment in my home, it happened a few times a week since switching to the ISY9941

I tried several things.  Every little thing helped but it still didn't solve everything.  In the end, the simplest solution worked best.   I've put all appropriate programs inside a REPEAT clause. It seems to have solved those last few transient failures and now things are rock solid reliable.   It might add a bit of extra network traffic.  But its a short time burst.   For now, repeat everything 5 times.  In a few seconds or so the program is done and the person can turn the light on/off manually if they didn't like the programmed action

[nathagt]

Just curious if you've tried using this with a scene? Seems like that would reduce the network traffic while still accomplishing the same thing. 

[SpicyMikey]

1 hour ago, nathagt said:

Just curious if you've tried using this with a scene? Seems like that would reduce the network traffic while still accomplishing the same thing. 

Hi nathagt.  No I haven't tried it but I realize that would be a further improvement to reduce the number of transmitted commands.  The problem is that, as you can see, there are several scenes already  being executed by this program.  I don't see any way to "nest" scenes inside other scenes.  I have several keypads around this house and I use scenes to group the related buttons and devices.   Creating a new set of scenes for all these programs just adds more complexity to the entire setup,  so I'll only do it if the extra network traffic shows to cause other problems .  So far, none.   It's been rock solid for 4 days now with most of these 35 devices around the house going on and off via scheduled programs.   

[lilyoyo1]

Create 1 scene and drop all devices in that scene. Then add that 1 scene to the program

[SpicyMikey]

14 hours ago, lilyoyo1 said:

Create 1 scene and drop all devices in that scene. Then add that 1 scene to the program

Everything is working great calling the individual  devices and scenes I want to turn on/off. At this point probably no need to complicate my setup by adding more scenes, but I'll keep an eye on it.  The key to success for me is the Repeat command.   Even just using scenes did not solve all my issues before.  Some devices reacted to the commands and some did not when just using scenes without repeating the commands several times.  I suppose at any given moment anything is possible to cause interference and failure.   I thought the retry logic built into the insteon communication protocol (supported by ISY) would solve it, but it didn't. Again, systematically program all your commands to be repeated several times to virtually eliminate all chance of failure due to those one-off failures.

[larryllix]

15 minutes ago, SpicyMikey said:

Everything is working great calling the individual  devices and scenes I want to turn on/off. At this point probably no need to complicate my setup by adding more scenes, but I'll keep an eye on it.  The key to success for me is the Repeat command.   Even just using scenes did not solve all my issues before.  Some devices reacted to the commands and some did not when just using scenes without repeating the commands several times.  I suppose at any given moment anything is possible to cause interference and failure.   I thought the retry logic built into the insteon communication protocol (supported by ISY) would solve it, but it didn't. Again, systematically program all your commands to be repeated several times to virtually eliminate all chance of failure due to those one-off failures.

You need to find and fix that comm error.

When you make a tight list of Insteon devices to operate and one fails or is offline the few following devices can get missed for the operation. Using scenes can make this worse as ISY will not even know it was missed.

Repeating attempts to devices with comm problems, after Insteon has done all it's retries can bog your Insteon channels down so that nothing will get through. Again. You need to find and fix the comm problem before your system gets bigger and harder to find.

[SpicyMikey]

 Thanks but everything is working fine Larry.  So there's nothing compelling me too do anything more.  I have so many electronic devices in my home, including 2 big Dell power edge servers, That I fear finding and solving the noise problem may be impossible.

I didn't submit this asking for help, i posted this to offer my experience with transient/random failures, and my solution.  But I do appreciate the input and  I'll remember your advice if this stops working. I agree finding the source(s) of the noise would be the ultimate solution.

[larryllix]

If everything was working fine you would not be considering using repeat constructs for bad comms. While your repeat is going on your other Insteon systems will be crippled. With comm errors that may be for several minutes at a time.

This is never necessary for systems working properly. It will only get worse. Watch for spontaneous rebooting.

[apostolakisl]

It is great that this works for you, but as mentioned, it isn't exactly the best way.  There will be times when this creates trouble with all that traffic.

Creating a single scene and dropping all those devices into that one scene will 

1) Reduce the traffic to a single command

2) However, there will be no ack from the devices, so a missed device doesn't get a retry

- but, retries will really start to clog up traffic when you have both repeat on the entire thing, all those individual commands and their acks and all the retries.

Usually with individual device commands, "repeat" doesn't help much since it will automatically repeat when it doesn't get an ack.  Depending on what version of stuff you are running, you can adjust the retries.

If you put everything in as a scene, having it do a "repeat" a few times doesn't really create any traffic problems since it is just the single command.  Devices that get the command will respond with a status update, but only if they change status, so something that gets repeatedly set to the same setting won't create traffic with multiple status updates (I'm 99% sure on this point, but not 100%).

Creating a single scene is pretty easy.  Especially if you have the pro version of isy that allows for delayed writes.  Just drag and drop it all into the scene, then hit to have it execute, walk away for a couple minutes and it should be done.  You only need to concern yourself if you have lots of really big scenes, the PLM can run out of memory for link tables.

[lilyoyo1]

I'm with @larryllixon this one. Repeating is a Band-Aid at best. It's your system so if your happy and it works then that's all that matters.

We both (as many others on here)  have extensive knowledge of how the system works and the problems that can/will go wrong. We're just giving you a heads up to prevent bigger system failures and issues

[nathagt]

1 hour ago, larryllix said:

You need to find and fix that comm error.

Just for my own education, what steps should be taken to find a device that is causing an error? 

[apostolakisl]

13 minutes ago, nathagt said:

Just for my own education, what steps should be taken to find a device that is causing an error? 

Generally speaking, you have signal "suckers" and "noise makers".  it can (will) be challenging to track these down.  Common sources of problems are power supplies and ballasts.  Low voltage light transformers, ballasts/power supplies for fluorescent or cfl's, and other devices that require power transforming from standard 120/240 vac to something different.

Look for things that turn on without issue, but have issues turning off.  The device behind the insteon switch is likely a trouble maker.

Look for associations between the times certain things are on and the times you have issues.

Try putting filterlincs on suspicious devices and see if things get better

Try turning circuit breakers off to sections of the house and see if reliability is better while the breaker is off.  If so, look for trouble makers on that circuit.

EDIT: Or spend a boat load of money on a nice oscilloscope.  Better yet, borrow one from your good friend the EE.  You can watch the noise on your system as well as get some ideas of signal attenuation by suckers.

[SpicyMikey]

Thanks @apostolakisl, @larrylinx, and, lilyoyo1

I appreciate what you are saying and can't argue.  But like @apostolakisl stated, it's not easy, and to some degree, impossible, to "solve" the problem without spending enormous amounts of time and money.   I'm not new to this game, just new to the ISY device.  Been doing smart-home automation before it was even a thing.   Started with X10 devices 20 years ago.  My ultimate goal was to get this as reliable as i had it using the old Insteon HomeLinc software with the same environment and devices.   I think I've acheived that with a simple solution.  Sometimes the simplest solutions are the best.  But, I understand the downside and will keep an eye out for problems that become more device (or area) specific.   Thanks again everyone

[apostolakisl]

9 minutes ago, SpicyMikey said:

Thanks @apostolakisl, @larrylinx, and, lilyoyo1

I appreciate what you are saying and can't argue.  But like @apostolakisl stated, it's not easy, and to some degree, impossible, to "solve" the problem without spending enormous amounts of time and money.   I'm not new to this game, just new to the ISY device.  Been doing smart-home automation before it was even a thing.   Started with X10 devices 20 years ago.  My ultimate goal was to get this as reliable as i had it using the old Insteon HomeLinc software with the same environment and devices.   I think I've acheived that with a simple solution.  Sometimes the simplest solutions are the best.  But, I understand the downside and will keep an eye out for problems that become more device (or area) specific.   Thanks again everyone

Well I would at least try to associate things being on with times of trouble.  Also understand that things like "wall warts" can cause issues just being plugged in without the attached device being on.

[SpicyMikey]

4 hours ago, larryllix said:

If everything was working fine you would not be considering using repeat constructs for bad comms. While your repeat is going on your other Insteon systems will be crippled. With comm errors that may be for several minutes at a time.

This is never necessary for systems working properly. It will only get worse. Watch for spontaneous rebooting.

 

I added the repeat because it wasn't working initially.  Now it IS working, so in my universe, it's no longer a problem.

Not sure I know what you mean about "spontaneous rebooting".   Are we talking about the ISY rebooting?   is this a flaw in the device to be aware of?

You make a good point about other potential traffic being interrupted for the duration of this burst of repeated commands  But that is 6 times a day for about 10 seconds.  Also, with all due respect, it will not get worse, as you stated  This is a static problem caused by other devices in the environment that are interfering with signal transmission, either PLC or RF.  if the environment doesn't change the problem wont change,  except for the occasional device failures in the field.   You are making this all sound more ominous than it is and not sure why.   

[SpicyMikey]

2 hours ago, apostolakisl said:

Well I would at least try to associate things being on with times of trouble.  Also understand that things like "wall warts" can cause issues just being plugged in without the attached device being on.

Wish I could, but there are no "times of trouble".  I have the problems reduced to random failures that can occur at any time on any device.  No pattern.   Situations where the light goes off but the associated keypadlinc button it is paired within a scene does not.   Or, even weirder, the light does not go off but ISY had it shown as off in its status list.  These sort of things were happening once or twice out of 60-70 command executions.  Minor thing but annoying.   With the added Repeat 5, added to all programs, so far I've had no failures in about 600-700 command executions.  I'm sure things will still fail now and then.   No communication device is perfect (ISY or the controlled Insteon devices), but the goal is to reduce it to a minor annoyance and accept the rest.   Thanks again for your reasonable responses. :)

[mwester]

I'm reminded of the "fiddly light switch".  It was at the bottom of the basement stairs in my grandparent's home -- if you pushed the toggle gently to the side as you flipped it up and down repeatedly, it would finally "click" and the light would turn on.

Worked great in their universe.  Only problem was when someone other than them had to go down into that ancient, dark basement...

Anyway, I get it - and as long as it mostly works, and you're the only one that deals with the issue, then it's not really a problem -- even if so many of us wouldn't leave it like that.

Just for the record, and for those googling and finding this thread, this is not the intended purpose of the "repeat" statement, and in terms of retries, they only work for outbound ISY traffic, not for Insteon scenes, nor for incoming messages from switches or devices (those messages will not be repeated more often than the Insteon protocol defines, regardless of the programming of the ISY).  So in general, for *MULTI-WAY* communication, the repeat command is not a solution -- although it certainly addresses the OP's situation.

[lilyoyo1]

1 hour ago, SpicyMikey said:

I added the repeat because it wasn't working initially.  Now it IS working, so in my universe, it's no longer a problem.

Not sure I know what you mean about "spontaneous rebooting".   Are we talking about the ISY rebooting?   is this a flaw in the device to be aware of?

You make a good point about other potential traffic being interrupted for the duration of this burst of repeated commands  But that is 6 times a day for about 10 seconds.  Also, with all due respect, it will not get worse, as you stated  This is a static problem caused by other devices in the environment that are interfering with signal transmission, either PLC or RF.  if the environment doesn't change the problem wont change,  except for the occasional device failures in the field.   You are making this all sound more ominous than it is and not sure why.   

Experience is the best teacher. He's not making it sound ominous. It's simply a situation where one has seen how stuff Cascades. Works for months w/onissue then all of a sudden it crashes. No one is saying you will definitely have issues. Just that you're increasing the chances of having issues. 

[SpicyMikey]

1 hour ago, lilyoyo1 said:

Experience is the best teacher. He's not making it sound ominous. It's simply a situation where one has seen how stuff Cascades. Works for months w/onissue then all of a sudden it crashes. No one is saying you will definitely have issues. Just that you're increasing the chances of having issues. 

I truly understand the warnings lilyyoyo1.  Written responses may not capture that but  I am taking notes as it seems many of you have much more experience than I.  Maybe you are installers and developers.   i respect that deeper insight. 

From my experience, over the years, I was never able to reach 100% reliability (e.g. like throwing a mechanical light switch).   In the "old days" when we used PLC for all communication it was very unreliable and it was worth it to try to hunt down the sources of noise and signal killers causing those dead spots.   But since Insteon added RF to their devices (with builtin repeaters), the problem is obviously much less of an issue.  I have a 4500sqft two story house so just to make things even better, I have two standalone Insteon Repeaters on separate phases.    That reliably brings meup to 95+%.   Adding the program Repeats (as ugly as it sounds) seems to have brought me the other 4.99% (so far).