Indigo Domotics

For the past few weeks I seem to be pretty consistently losing the IP connection to the main repeater. When that happens it basically quietly fails - some error messages in the log, but it doesn't attempt to reconnect or do anything else. I do see error messages like this:

Code: Select all

Aug 22, 2019 at 8:00:00 AM
   Schedule                        Inga lights off in morning
   Schedule                        Sebastian Lights off in morning
   Lutron RRA2/Caséta             Girls' Room - Dimmer 116 - Overhead: Set brightness to 0 with fade 3
   Lutron RRA2/Caséta Warning     Error sending IP command, resetting connection:  'Plugin' object has no attribute 'connIP'
   Lutron RRA2/Caséta Error       Error in plugin execution ExecuteAction:

Traceback (most recent call last):
  File "plugin.py", line 1619, in fadeDimmer
  File "plugin.py", line 843, in _sendCommand
AttributeError: 'Plugin' object has no attribute 'connIP'

   Lutron RRA2/Caséta Warning     Error sending IP command, resetting connection:  'Plugin' object has no attribute 'connIP'
   Lutron RRA2/Caséta Error       Error in plugin execution ExecuteAction:

Traceback (most recent call last):
  File "plugin.py", line 1509, in actionControlSpeedControl
  File "plugin.py", line 843, in _sendCommand
AttributeError: 'Plugin' object has no attribute 'connIP'

   Lutron RRA2/Caséta             Girls - Inga Nightstand: Set brightness to 0 with fade 3
   Lutron RRA2/Caséta Warning     Error sending IP command, resetting connection:  'Plugin' object has no attribute 'connIP'
   Lutron RRA2/Caséta Error       Error in plugin execution ExecuteAction:

Traceback (most recent call last):
  File "plugin.py", line 1619, in fadeDimmer
  File "plugin.py", line 843, in _sendCommand
AttributeError: 'Plugin' object has no attribute 'connIP'

   Lutron RRA2/Caséta             Girls - Noemi Nightstand: Set brightness to 0 with fade 3
   Lutron RRA2/Caséta Warning     Error sending IP command, resetting connection:  'Plugin' object has no attribute 'connIP'
   Lutron RRA2/Caséta Error       Error in plugin execution ExecuteAction:

Traceback (most recent call last):
  File "plugin.py", line 1619, in fadeDimmer
  File "plugin.py", line 843, in _sendCommand
AttributeError: 'Plugin' object has no attribute 'connIP'

   Lutron RRA2/Caséta Warning     Error sending IP command, resetting connection:  'Plugin' object has no attribute 'connIP'
   Lutron RRA2/Caséta Error       Error in plugin execution ExecuteAction:

Traceback (most recent call last):
  File "plugin.py", line 1314, in actionControlDimmerRelay
  File "plugin.py", line 843, in _sendCommand
AttributeError: 'Plugin' object has no attribute 'connIP'



Then, when I restart the plugin I get this similar error message:

Code: Select all

   Reloading plugin "Lutron RRA2/Caséta 7.2.7"
   Stopping plugin "Lutron RRA2/Caséta 7.2.7" (pid 57391)
   Lutron RRA2/Caséta             Shutting down Lutron
   Lutron RRA2/Caséta Error       Error in plugin execution shutdown:

Traceback (most recent call last):
  File "plugin.py", line 160, in shutdown
AttributeError: 'Plugin' object has no attribute 'connIP'

   Stopped plugin "Lutron RRA2/Caséta 7.2.7"


Is there any way to detect the failed connection and programmatically restart the plugin from within Indigo? Alternatively, any way for the plugin to detect the connection is hosed and reconnect?

Turn on debug level logging and let's see if there's more info to go by.

Alright, did that, will post once I get another connection drop. I wonder if its the crappy TCP/IP stack on an old Mac Pro running High Sierra?

rapamatic wrote:

Alright, did that, will post once I get another connection drop. I wonder if its the crappy TCP/IP stack on an old Mac Pro running High Sierra?

I have a Mac Pro running HS doing Security Spy and Plex and some other stuff. It seems fine. Unless you just have a hardware issue.

Open terminal and run ping, let it run for a day and check for timeouts.

I had a bad Ethernet cable once That created timeouts and lost connections.


Sent from my iPhone using Tapatalk

kw123 wrote:

Open terminal and run ping, let it run for a day and check for timeouts.

I had a bad Ethernet cable once That created timeouts and lost connections.

I can try that, but its probably a good idea for the plugin to catch a connection going down and re-establish it, or at least to figure out a way to create a trigger in indigo to reload the plugin when that happens... Connections go down for various reasons (Ethernet cable pulled, main repeater rebooting on programming update, power outages, etc. etc.)

rapamatic wrote:

I can try that, but its probably a good idea for the plugin to catch a connection going down and re-establish it, or at least to figure out a way to create a trigger in indigo to reload the plugin when that happens... Connections go down for various reasons (Ethernet cable pulled, main repeater rebooting on programming update, power outages, etc. etc.)

Oh, it's supposed to be reconnecting. But I just found a stupid error in the code. When I get an error on the write to the telnet connection, I try to close the connection before I set the restart flag. And the close is failing, which aborts the routine totally. Oops.

Try 7.2.8 - https://github.com/FlyingDiver/Indigo-r ... /tag/7.2.8

Alright, I'm running 7.2.8 now, will see how that works.

On a side note, just running ping for na hour or two I had around 4% packet loss to my router. I am using a MoCA coax bridge up to my office where this mac is located, maybe that is a bit flaky... I do have a spare UBNT wireless bridge I can try using instead of the coax bridge... I would think TCP/IP would be robust enough to deal with 4% packet loss pretty transparently though....

rapamatic wrote:

On a side note, just running ping for na hour or two I had around 4% packet loss to my router. I am using a MoCA coax bridge up to my office where this mac is located, maybe that is a bit flaky... I do have a spare UBNT wireless bridge I can try using instead of the coax bridge... I would think TCP/IP would be robust enough to deal with 4% packet loss pretty transparently though....

My experience with MoCA is that it's extremely unreliable and not in a consistent way (works well for hours, then fails randomly for a while). Of course, that was just with a couple of TiVO boxes, so it may just be their implementation...

The 4% is not the issue if it is evenly distributed. But normally 4% indictats that there are chunks of time where it does not work. My experience was that 7seconds of no connection can create a dropped indigo client connection.


Sent from my iPhone using Tapatalk

Alright, I guess it's time for me to do some testing and make sure my network is in good working order. The 4% did seem to be in chunks of 5-10 seconds without a ping, which seems enough to kill a connection

FlyingDiver wrote:

Try 7.2.8 - https://github.com/FlyingDiver/Indigo-r ... /tag/7.2.8

7.2.8 Seems more stable... I haven't had any issues, but will keep an eye on it. Thanks!