Telnet creates a fresh connection, which is why it works, just as your socket works initially. Your strategy of disconnecting and reconnecting periodically is a good workaround. I wouldn’t do it as often as every 10 seconds. Maybe 30 minutes or an hour.
It would be instructive to know if you let telnet run, would it stop working after some time, as well?
Yes, it’s still an active thing. You can launch Activity Monitor, add the “App Nap” column (right click on the header to do so) and see whether your app is monitored by app nap.
But I’ve learned that when I’m the only one talking about a possible culprit in this forum, it’s usually not a track to follow, so you may disregard .
A little off-topic @John_Eidsvoog, but why aren’t you using a system like HomeBridge to do this for you if you already have Siri running at your location?
In a terminal do which telnet to get the full path to the executable and then use that in place of just telnet in your command using the shell.
When you install things using something like homebrew, it automatically adds to path to your zsh path variable, and that informs the terminal where to look for applications when you use the shortened command.
Thanks for the tip. App Nap is currently “No”. I’ll check it again when/if the fail happens. “App Nap” is not shown in the app’s info which should mean it’s not nap/aware.
I have Somfy shades, which I’m controlling through RS-485. I’m monitoring Lutron keypad presses over the LAN to send commands to the Somfy shades. I’m not sure how HomeBridge can help with this.
I’m using HomeBridge for Pentair pool control, Big ■■■ Fans (forum is laughingly censoring A-S-S), and a Bond bridge for controlling some RTS radio-controlled Somfy shades which aren’t connected to the LAN.
My Siri control uses Apple Shortcuts to SSH into another TCPSocket in my app to control shades.
Thanks for checking on this. Over the years, I’ve highly customized my app, specific to the Somfy ILT and RTS motors I’ve installed. I’d have to start all over using HomeBridge plugins and would likely run into snags that can’t be accomplished. There are a lot of different protocols and models of both Somfy shades and Lutron keypads.
I may have found the culprit. I removed a 4K USB3.0 video capture device yesterday morning and my app has been running successfully now for about 36 hours on the same TCP port. It’s a USB device (with unrelated HDMI in and out ports) and I was using OBS software with it. I had disabled OBS a few days ago but the failure still occurred until I removed the capture device.
I’m not sure why it would interfere with TCPSockets. I’ll report back if the failure occurs again.
I was premature in claiming victory. This morning (after 2 days), my Lutron socket has gone dead again.
This test has revealed 2 other clues. The Terminal’s telnet connection (opened at the same time 2 days ago) is still receiving commands from Lutron keypads but they are not arriving at my Data Available event. Also, Activity Monitor shows my app is not napping.
My final solution to this problem was to downgrade my MacMini server to Sonoma. It’s now been running correctly for several days.
The fact that data still came in through the terminal after it stopped coming in through my TCPSocket leads me to believe there’s some problem between Xojo and MacOS Sequoia’s additional security features.
But there are other factors to consider. When I had the problem, I was using an external SSD (Sequoia) as a boot drive. This is getting to be very difficult with Apple’s increasing security policies. Anyway, it’s possible there was corruption in the system because strange things were evident, like duplicate drive entries showing up in the Finder sidebar. I’m now using the internal 1TB drive with Sonoma.
Also, I was still using Xojo 2025 release 1.1 on that drive. After downgrading to Sonoma, I started using Xojo 2025 release 2. It’s possible that this upgrade was a factor.