I have a GC100 attached to my A/V gear, which gets power cut off at night. When power is restored, Vera’s connectivity to the GC100 is never restored. Vera reports “GC100[<device_number]: Failed to open IO Port”, and I have to restart Luup to restore connectivity. Sending IR commands does not restore connectivity.
MCVFlorin was kind enough to work with me on the GC100 plugin over the past few days to try and add a feature to the GC100 plugin to check for connectivity and try to restore it if lost; however, sending any requests to the GC100 does not work. So, we started wondering if this problem is just isolated to my Vera and GC100.
Does anyone else have this problem, or can anyone else duplicate it?
My GC100 is configured in a similar way by cutting the power to it when my AV system is shut down. V2/UI4, the only way I could get the GC100 working again was to restart Luup.
V3/UI5 I don’t remember ever having this issue.
[quote=“JOD, post:2, topic:171811”]My GC100 is configured in a similar way by cutting the power to it when my AV system is shut down. V2/UI4, the only way I could get the GC100 working again was to restart Luup.
V3/UI5 I don’t remember ever having this issue.[/quote] @JOD,
There is currently a general problem with TCP connected devices, in all releases, if the device just goes “offline” without notifying Vera. In these cases, it will typically take another command (from Vera, to the device) in order for Vera to work out that the device has one away, and needs a new connection to be established.
You’ll see this discussion in the DSC, and the older Brultech Powermeter discussion threads.
One fix, which it sounds like Florin has attempted, is to have the Plugin periodically “poll” the Device [over TCP] by sending it some sort of command (like a status call, etc). This can trigger Vera to reconnect when it realizes that the connection is down.
Of course, this “polling” operation can eventually cause a UI4 box to crash due to Lua concurrency problems in UI4 (fixed in UI5), so you generally can’t use that as a solution if you plan to have UI4 users…
That said, given the error message above, this is somewhat of a different issue. It looks like Vera has detected that the GC100 is down, and is failing to connect to it. When this next happens, it might pay to run:
netstat -a -n
and see what (if any) connections are being kept open to the target device/IP address. If something is being kept open, then Vera will not be able to establish a new connection. Typically TCP will “sit on” any existing connection for up to ~5mins during which time attempts to reconnect will fail… The [tt]netstat[/tt] command above will give clues as to whether this is going on (as will Verbose logging on Vera)
It looks like that while I was collecting the netstat information this morning, the problem resolved itself without restarting Luup, but I am using a modified Implementation file from MCVFlorin. I had just unsuccessfully sent an IR command to Vera a few minutes before. This modification tries to reopen the connection every 2 minutes, so it looks like his most recent attempt may have been successful after all. This would explain why I see a different local port for Vera’s IP address in the TCP session; it is actually opening a new session every two minutes. If this is in fact working, then I will see if MCVFlorin can only open the connection if one is not already established. I will do some more testing and then report back here.
I have retested this, and the GC100 still does not automatically recover. Debugging shows that there is a TCP session ESTABLISHED while the GC100 is online. After unplugging it, Vera will start to send TCP SYN to it using another local port. It keeps doing this for a few minues. At this time, the session goes into FIN_WAIT1. This is when Vera starts displaying the message: GC-100[<device_id>] : Failed to open IO Port. About 30 seconds later, the original TCP session is dropped.
At this point, it appears that Vera stops trying to connect to it, because no more SYN_SENT are seen in netstat. About 10 minutes after restoring power to the GGC100, another TCP session is established by the plugin, but Vera still reports that it failed to open the IO port. Sending IR commands does not work. There is no flashing of the red LED on the IR emitter to show that a command has been sent. So, even though a TCP session has been re-established, Vera does not recover from the failure to open the IO port, even after almost an hour and periodically attempting to send commands. There needs to be some way to tell Vera to clear this condition so that commands are actually sent to the device, because luup.io.open apparently does not; it seems like it should though as long as it results in a successful connection.
It looks like the only ways to recover from this condition, that I know of, is to make a change to a device and save it, or restart Luup from Apps >> Develop Apps >> Luup Files, checking the box for Restart Luup after upload (no need to provide any files). You can also do this from the command line with /etc/init.s/cmh restart. This kills the current TCP sessions and establishes new ones. I looked through the Luup Lua extensions wiki page but found no function to do this from within a plugin; however, restarting Luup is not the preferred method for restoring connectivity to just one device. It is much too intrusive. This condition should be able to be cleared for just one device at a time. The function luup.io.open should do this but does not, so this is really a bug.
@JOD, There is currently a general problem with TCP connected devices
I wasn't aware of this; and come to think about it, I did have a similar issue with the TED plugin in UI4 if the connection went bad (for whatever reason.)
Again, no problems with either device/plugin since running UI5.
My apologies if it seemed I was implying the issue goes away by using UI5, I only meant that I’ve not experienced these issues using UI5.
restarting Luup is not the preferred method for restoring connectivity
Agreed, [b]it should just work,[/b] no matter what..
Florin,
It seems like some of the users here are seeing the effects of 2282. When that happens, Vera will silently move on without connectivity… but [with the current Production builds] the next time it attempts to write() something to the Socket it should detect it’s dead (eventually) and reconnect.
Other users are seeing something different though, with Vera itself failing to reconnect in these cases, and the resulting error presented in the UI. This is a different kind of problem.
2282 mostly impacts folks that get async events “back” from the device, with little-to-no data being sent “to” it (since the latter would trigger a reconnect)
Your work-around to put in a timer, and have it periodically poll the GC100 should have had a similar effect of keeping the connection alive… for UI5 users at least. For UI4 users, it will periodically corrupt the state of their Vera unit due to a Lua thread-safety issue in UI4.
Thanks for digging up this old thread. I have experienced this same issue, but with UI5. I just gave up on trying to solve it for the long term and plugged it into a port that always stays on.
So based on this thread, this is something that should automatically fix itself without a reload?
I had two GC-100 installed awhile back and had no issues. I sold one of them and haven’t had the other setup in vera for awhile. I installed the app today and put the IP in and it sees it but i’m getting the failed port message. I thought when you added the GC-100 into vera it showed more than the picture below
Is it staying on all the time? I had the issue when I would shut off power to the ir blaster (plugging it into a USB port that only turned on when the tv was on).
Make sure it is on and cycle your Vera. If it works, then I think you are good to go - just make sure you keep it powered on.
Are you sure you have the right IP ? If it can’t talk to the device It can’t figure out what devices are supported.
The GC100 plugin supports a wide variety of Global Cache products.