getting this new warning everytime a connection opens or closes, for instance if i issue quit and the device closes the connection i get this warning in the logs.. Is there anyway to disable it?
I get this same warning now but it's from my Envisalink app.
ya it appears for any telnet now.. ie my sendmail, ups status etc.
i am hoping there is an option in the connect to disable it.. you can filter it in the telnetStatus function but it doesn't help it still comes out.. It appears to be a bug to me.
Yes it had me worried, I'm seeing this now:
2021-03-25 06:15:38.496 warntelnet input stream closed
app:1202021-03-25 06:15:38.474 errorEnvisalink Integration: Connection Driver: Telnet is restarting...
app:1202021-03-25 06:15:38.322 errorEnvisalink Integration: Connection Driver: telnetStatus- error: receive error: Stream is closed
There was a documented change to Telnet in this release:
- Turned Telnet socket connection keep-alive ON.
if that is the cause then maybe some documentation on how to turn it off..
Noted, I'll come up with a better way, maybe alerting only if there are more than X disconnects per hour. The idea is to show devices that disconnect all the time. Suggestions are welcome.
That, or it broke something else. All of my cloud polling apps are exploding in the logs, causing “java.lang.StackOverflowError: null (setStatusResponse)” errors all over the place, unexpected results, etc.
C-7, 2.2.6.129
None of this with 2.2.5.131
thanks a disconnect is not really always a problem especially when you use telnet to connect to say an ups and issue the quit command or an email server etc.. the disconnect is normal .. i know it is abnormal for an always connected device .. maybe separate the two types with an option as to whether the device is supposed to stay connected or it is a transient type of connection . etc.
2 Likes
You might check the network code. Something in 2.2.6.129 and .130 has blown up my cloud devices that poll.
Here’s just a sample after the 2.2.6 updates from the SureFlap Pet Door that has been working fine through 2.2.5.131:
Yes, I realize it’s a user-contributed ST port by Dominic Meglio (@dman2306), and I don’t expect you to troubleshoot that integration, but something in the network code changed with 2.2.6 that blew up most of my cloud polling integrations. Hard to believe keepalive caused that.
Did you try reverting to an earlier version to see if it’s truly related? That’s a HTTP 504 errors there, which would point to an issue with whatever remote server that’s being communicated with.
That sort of error doesn’t seem like something the hub could cause, certainly not impossible but is unlikely in my mind.
If it was truly a widespread issue that it broke all cloud polling, the community would be ablaze with similar reports.
2 Likes
Agreed. This is almost definitely something on their side. It looks like a misconfigured server to me.
Edit: I’ll also add, this app doesnt use tenet at all, it’s only http.
2 Likes
Those were my thoughts, too, but the coincidence is so strong. I realize that correlation is not proof of causation. Yep, my next step is to revert to 2.2.5.131 and test.
And I realize that this app doesn’t use telnet, that’s why I said network code, not telnet. But, with all the Java stack overflow errors, it is behaving more like a buffer overrun than anything else.
post a link to the code. but my guess is it is something with the unexpected result in the poll error case that never happened previously and an incorrect implementation that causes it to go into a loop calling setStatusResponse as a result of the error causing the stack overflow.. I may be able to track it down without having the driver installed but maybe not.
it probably is a real error . .but it also could be just trying to pass that huge string it is dumping out to the setstatus function causes the stack overflow.. maybe try truncating what is getting passed.
Thanks for the offer, I will work on it myself. I was wrong, the stack overflows and blowup of everything stopped when I deleted the integration, and the other cloud polling apps started working.
Sorry to bother everyone.
FYI, the integration is here:
But I will figure it out. I’ve got an idle spare C-5 where stack overflows can’t harm useful stuff, and I can poke about there.
2 Likes
I'll look at the integration, but I don't own the device so it makes testing a challenge.
1 Like
Hi @gopher.ny, I'm having problems with my integration as well but it uses InterfaceUtils.socketConnect(...). I'm getting zero length responses from the method def parse(response). It used to work fine. You can find it here: GitHub - claudegel/Hubitat-sinope-GT125: Sinopé GT125 direct access for Hubitat platform
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
