programming to bail out mediocre communication issues?

[someguy]

I have a few insteon devices that are pretty mediocre at communicating, for reasons I've intermittently looked into for years and haven't been able to solve, so I came up with a workaround a while back.  

the problem I'll have is that a light (usually an outdoor light that is turned on by a program) is not on when it is supposed to be and the admin console says that it is on when it isn't.

my solution is three programs:

malibu stubborn ON - [ID 003A][Parent 017D][Not Enabled]

If
        'Outside / Malibu-Garage' Status is On
     Or 'Outside / Malibu-NE Corner' Status is On
     Or 'Outside / Outdoor Fountain Light' Status is On
 
Then
        Set 'Outside / Malibu-Garage' Query
        Set 'Outside / Malibu-NE Corner' Query
        Set 'Outside / Outdoor Fountain Light' Query
        Wait  1 minute 
        Run Program 'malibu stubborn ON 2' (If)

 

malibu stubborn ON 2 - [ID 003B][Parent 017D][Not Enabled]

If
        'Outside / Malibu-Garage' Status is not On
     Or 'Outside / Malibu-NE Corner' Status is not On
     Or 'Outside / Outdoor Fountain Light' Status is not On
 
Then
        Run Program 'malibu stubborn ON 3' (Then Path)

 

malibu stubborn ON 3 - [ID 0188][Parent 017D][Not Enabled]

If
   - No Conditions - (To add one, press 'Schedule' or 'Condition')
 
Then
        Stop program 'malibu stubborn OFF'
        Stop program 'malibu stubborn OFF 2'
        Stop program 'malibu stubborn OFF 3'
        Set 'Outside / Malibu-Garage' On
        Set 'Outside / Malibu-NE Corner' On
        Set 'Outside / Outdoor Fountain Light' On
        Set '.Scenes / Malibu Lights' On
        Wait  5 seconds
        Run Program 'malibu stubborn ON' (Then Path)

 

 

does anyone have any better suggestions?  

Edited January 4 by someguy

[paulbates]

A couple of things

1. The root cause it probably Insteon communications itself and its probably best to address that.  There's a number of posts on Insteon Communications issues to search under the Insteon communications section of the forums
    
2. Consider putting these devices in a single scene, and turn that scene on and off

           Set 'Outside / Malibu-Garage' On
           Set 'Outside / Malibu-NE Corner' On
           Set 'Outside / Outdoor Fountain Light' On
           Set '.Scenes / Malibu Lights' On

   
    
3. For the queries and individual devices in the iox programs... put a 3 second wait between each command. Insteon device commands take time to receive and acknowledge and iox doesn't wait. Those sequence of set commands is banging into each other on the Insteon network
    

           Set 'Outside / Malibu-Garage' Query
   	wait 3 seconds
           Set 'Outside / Malibu-NE Corner' Query
           wait 3 seconds
           Set 'Outside / Outdoor Fountain Light' Query

   
    
4. Tweak the 'retries' on the problem devices. Right click on the device in iox, and pick advanced/PLM communication. Increase the retries. I makes the Wait after that device even longer. This approach is generally frowned upon, but I had a few at my last house where it ultimately worked ok. I would not recommend going beyond 3 retries

Edited January 4 by paulbates

[Guy Lavoie]

Ah yes, the "use a bigger hammer" approach. Works as a short term solution, but will leave you unsatisfied over the long term, and cynical about the technology. As Paul said, the real solution is to try and work out the communications issues by testing, making small fixes or changes and observe if it improves, by not using the programming workarounds that you have added. Are your devices dual band? Are the ones that aren't reliable in an isolated location, where signal strength might be a problem. If you put other types of Insteon devices in the same area, so they also fail to respond? Sometimes, just adding something like a lamplinc to act as a signal booster/coupler helps. All things to consider.

The Insteon support forum also has good suggestions, though it appears to be down, has been for at least a week.

[Techman]

@someguy

Take a look at these two articles regarding Insteon communication problems:

INSTEON: Troubleshooting Communications Errors - Universal Devices, Inc. Wiki

INSTEON Signal / Noise Troubleshooting - Universal Devices, Inc. Wiki

 

 

[someguy]

@Techman  I appreciate the help.  The second article says to use a keypadlinc to watch for flashes with insteon traffic.  are there other devices that will flash with traffic? 

 

@others:  I appreciate the frank assistance.  you are right.  I need to solve the problem and stop the armchair "solution" attempts.  Thank you!!

[paulbates]

When you're in iox, look at insteon devices that are out in the open where you can visibly see the LED and review them.

Depending on which insteon product or revision of it you have,

• There could either be button on the buttons on the bottom of iox, or ..
• There's be an options button, look under there

The label for what you're looking for can vary, it can say:

• LED on TX - which can mean only when the device transmitts
• Error Blink
• Blink on Traffic

You might have to look around and experiment to see what results you get.

 

 

[Techman]

53 minutes ago, someguy said:

@Techman  I appreciate the help.  The second article says to use a keypadlinc to watch for flashes with insteon traffic.  are there other devices that will flash with traffic? 

I'm not sure of any of the other dual band devices indicate Insteon traffic. It's probably a trial and error process.

[IndyMike]

@someguy, as @paulbates indicated the ISY provides a Option box for enabling the Blink on Tx for most devices. 

@MrBill had a nice post on the subject here: https://forum.universal-devices.com/topic/35258-blink-on-insteon-traffic-setting/#elControls_330388_menu

The option has been around since at least 2015.  From what I can see, it's available on all of my V.45 and newer KPL's, SWL's, and plug in devices.  Earlier devices are hit and miss.

As it turns out, Blink on TX is the same as Blink on Traffic since all modules repeat Insteon traffic.

In looking at your original post, I noticed that a number of your problem items were named "Malibu" and all seemed to be associated with outdoor devices.  I tend to associate Malibu with low voltage lighting (maybe incorrectly). 

Is it possible these are low voltage applications on outdoor GFCI circuits?  Any photocells on fixtures?  The presence of GFCI's, LV transformers, and/or photocells can send troubleshooting in different directions (boosting vs filtering vs isolating).

Would you mind describing your problem circuits a bit more (indoor/outdoor, load type, GFCI, fixture type)?

[CoolToys]

@someguy I see that the Malibu programs are all [Not Enabled].  Any reason for that?  Also when the console says it should be on and it isn't, can you manually press the switch or outlet button and it comes on?  If you query the device what does it do?  Does the query come back correct or does it stay incorrect?  As @IndyMike is questioning, step one is to see that the device is actually on or off and then verifying communication with IoX by query and manual control.  In theory if you send "on" from the console, the console should not indicate "ON" unless the device responded that it is on. 

The caveat is that if you are sending the "ON" command as part of a scene the ISY does not verify status before changing to the "expected" status.  

[someguy]

@CoolToys the reason they are all "not enabled" is that I call them from other programs.  

I find switches "on" according to the console when they aren't fairly often.  I guess I have a noisy land-line.  when I notice a light is off when it should be on, I'll look in the admin console and it will say that it is on.  I will then query it and it will switch to off in the console.  

[CoolToys]

@someguy, that is very interesting.  Are these lights in scenes?  If the ISY sends a direct "ON", the device should send a response.  I have an issue with a few programs sending "ON" but to a scene.  In that case the ISY just logs the command as the status and doesn't wait for a response from each device.  If the device didn't turn on or off along with the scene command, the ISY gets out of sync.  

My experience is that a noisy line might turn things on, but the console will still read off because it doesn't "hear" the response as long as the commands are direct not embedded in a scene.  I also keep two PLM's on hand so I can flush and reset them just as a way to remove them from the culprit list.  I had a cyberpower UPS cause a ton of problems this way.

To save you a lot of reading in another thread, I also migrated from and ISY to an eisy, and the position of a state variable in one program suddenly became an issue in another program and I had to move the variable to the very top to stop the conflict.  Several scenes with three way switch set ups failed to migrate properly as well.

 

Edited Monday at 01:20 AM by CoolToys
why the noisy line added

[CoolToys]

One other thing I learned the hard way was "retries".  When I migrated from the ISY to the eisy, many scenes didn't work.  I had to delete and rebuild but a few still failed.  Looking back at the ISY (I keep it plugged in with the PLM just dangling so it can't do anything but I can compare programs) I realized that many scenes had "2 retries" so I edited the ones that were giving me fits and of the four, three were fixed.

[someguy]

@CoolToys I appreciate your efforts to help me.  How many retries worked best for you?

[larryllix]

2 minutes ago, someguy said:

@CoolToys I appreciate your efforts to help me.  How many retries worked best for you?

More retries doesn't mean they will take effect every communication attempt. Retries only take effect when a device doesn't get and ACK back, showing successful communication transmission from the receiving device. Most communication packets do not take any retries unless you have bad comms, having interference on your power lines or RF noise in your air.

Note that "Retries" are not "Echoes" that Insteon does between devices, to support it's mesh featured protocol structure.

[IndyMike]

Device level retries as explained be LeeG: Understanding Retries in ISY