SQ 5 Connection error

[michaeltbrennan]

I'm, still getting intermittent connection errors - I've search the web and cannot find any conclusive solution for this.

[jswalden]

I've observed this with the existing legacy module if the Companion module somehow loses its network connection to the mixer -- it doesn't seem to well handle reconnecting. (I also see this simply disabling and reenabling the connection in Companion web UI.) I'm honestly not sure why this is.

Ultimately when this has happened for me, my only solution has been to turn off the amps, disable the SQ connection, reboot the mixer, reenable the SQ connection, and turn the amps back on. It works. Obviously it's not a great solution.

The latest module code handles things somewhat differently, and it seems to work. Yet if I sniff the TCP packets in Wireshark, the same ones get sent in both cases. So I dunno. I'm hopeful the next release -- which I hope to spin sometime during the day today (not post-midnight as it is now) -- will exhibit similar reduction in this behavior. If it somehow doesn't, despite me seeing it reduce it during my local development...well, honestly I wonder if it's not a bug in the SQ's TCP stack and there's nothing to do about it.

[cmcrombie]

Just moved from 3.5.3 to 4.0.3 and the module will not launch. I tried rebooting the console and connection as per jswalden's note, but it's not connecting any way I try.

[jswalden]

@cmcrombie Is it at all possible that you have multiple things attempting to connect to your SQ? (I don't mean MixPad or SQ4You, and I presume Mixing Station gets lumped in here too -- that kind of connection is not this TCP kind.) My SQ-5 seems to only support a single TCP connection at a time -- if you already have an active connection, then I believe that attempting to create an additional connection will hit this ECONNRESET thing.

I am 100% open to the idea that the module's connection handling is buggy. I actually had partially rewritten the connection handling in the latest release, but I ran out of time to really fully get it working and ended up reverting the changes -- leaving them for the future. But TCP connection resets are the sort of thing devices do to say "go away, I don't want you", and I have only seen this when trying to have multiple connections active at once.

[ssnelgrove]

I am having a similar issue where I have to disable the plugin and restart the mixer and re-enable to get connection complete and haven't confirmed but if I wait for any amount of time before re-enabling it the connection fails and I am back in the same loop. If this is mid event I am stuck unable to restart mixer.

I have only one instance of Companion trying to connect and no other software running to connect to mixer.

Is there an expected time for updated plugin or anyway I can get a beta copy to try?

Companion: 4.1.1
SQ Plugin: 3.0.0
SQ5 Firmware: 1.6.0

[michaeltbrennan]

I found that I had to power down the SQ5 - power it back up and it would connect immediately. Just an irritating work around. Michael Michael Brennan Senior Creative Media Technician School of Information, Journalism and Communications The Wave University of Sheffield e: ***@***.*** m: 07545 548472

…

On Sun, 5 Oct 2025 at 16:20, Stefan ***@***.***> wrote: *ssnelgrove* left a comment (bitfocus/companion-module-allenheath-sq#77) <#77 (comment)> I am having a similar issue where I have to disable the plugin and restart the mixer and re-enable to get connection complete and haven't confirmed but if I wait for any amount of time before re-enabling it the connection fails and I am back in the same loop. If this is mid event I am stuck unable to restart mixer. I have only one instance of Companion trying to connect and no other software running to connect to mixer. Is there an expected time for updated plugin or anyway I can get a beta copy to try? Companion: 4.1.1 SQ Plugin: 3.0.0 SQ5 Firmware: 1.6.0 — Reply to this email directly, view it on GitHub <#77 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BLLRXVUVSUZWYDRPXJPG5AL3WEZNPAVCNFSM6AAAAAB6E4CNMKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGNRZGEZDOOBTGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[MeestorX]

My guess would be that the module isn't implementing keepalive.

[jswalden]

The TCPHelper class has keepalive enabled in it, and the connection code is relatively similar to what the ptzoptics-visca module uses, and I've never had these issues with it. I really do still think this is most likely a bug in the SQ TCP stack.

[MeestorX]

As far as I can tell, that keepalive doesn't work for hardware like we're connecting to. In all my modules, I had to implement keepalive separately.

[jswalden]

Be that as it may, turning off the connection and back on doesn't even manage to reestablish a connection consistently for me. And at that point it's hard to see how the module's code could be where the issue lies.

[MeestorX]

Be that as it may, turning off the connection and back on doesn't even manage to reestablish a connection consistently for me. And at that point it's hard to see how the module's code could be where the issue lies.

If restarting the console fixes the issue, then it's most likely what I said. Restarting companion or the connection is the wrong end of the wire. :-)

[jswalden]

Well, randomly losing the connection and then being unable to reestablish wouldn't relate to keepalive. It would relate to handling of the one extant connection, then properly recognizing when it drops in order to permit a new connection to be made.

Or we're talking in circles here somehow and I just can't see it. 🙂

[MeestorX]

Basically, without a proper keepalive mechanism, the server can run out of ports and stop accepting connections. I discovered this after finding that I had to reboot my RIO after being connected to companion for a very long time. Whether or not that's the issue here, I don't know, but it certainly CAN be an issue. Use this information as you see fit.

[ssnelgrove]

I only switched to companion 4.1.1 a month ago with the latest version of SQ plugin (the reason I waited was for ver 3 of SQ plugin) I stayed on ver ver 2.4.2 of companion due to stability I had tried ver 3.x of companion a few times with not enough stability to even make it out of my basic testing.

On ver 2.4.2 I could power on SQ and companion would reconnect 95% of the time then I upgraded to 4.1.1 and it struggles to get a connection I usually have to disable the SQ plugin and power cycle the SQ console and re enable the plugin to get a connection. Once connected I haven't observed it ever dropping as long as its kept on and connected.

But if I turn mixer on and leave it for a while (did this once had to deal with another task before returning) I then enabled the plugin and couldn't connect and I was to close to show time to power cycle SQ console so I had to do everything manually.

Not sure what this proves this is just an observation but it seems something times out maybe?

When I get more time I can attempt to test a little more to nail down some details.

[cmcrombie]

Hey all, sorry for the delay. I did not see the response from August.

I don't have anything else connected to my SQ so far as I'm aware. I have had Mixing Station connected, but even right now, I don't have anything connected to it whatsoever and so far no permutation of toggling the module and power cycling the console has worked to establish connection. The ability to connect is completely broken for me, and I'm not sure how or why.

Companion 4.0.3, module 3.0.0, SQ-5, version 1.6.1.

[junodite]

I also kept getting this error when I was using a regular PC, but when I use CompanionPi, this error does not appear.