I’ve written a Mac desktop application that uses RS-485 to control my Somfy shades. It’s been working for several years but has lately started dropping my TCP connection on another socket.
I use a TCPSocket to control the shades through RS-485. This socket works fine and I can receive trigger commands from Lutron keypads through another TCPSocket. The Lutron master controller sends commands over telnet on the LAN. A button press on a keypad sends a command like “~DEVICE,33,5,3”.
I set the local address on the Lutron socket using port 23 and MacOS returns a different port number. All works fine, but after a while (I’ve haven’t established how long but it’s at least several minutes), the socket stops receiving data.
I’m using the Data Available event to read data. I know it’s an internal problem because I can use Terminal to telnet into that address and still receive commands but they don’t show up at the Data Available event.
As a workaround, I’m currently using a timer to Disconnect, Close, and reconnect the Lutron socket every 10 seconds, getting a new port number each time. Obviously, this is bad but it’s the only way I’ve found to keep it working.
This is controlled by a Mac Mini. It seems like this started since I upgraded to Sequoia OS but I can’t be sure.
Does anyone know what’s happening here? Is this a known issue? I’ve been reluctant to ask for help but can’t figure this out.
It may also be related to App Nap, a feature that suspends apps when the OS thinks the process is “idle”. What was the Mac Mini running before you upgraded to Sequoia?
Thomas Roemert:
Thanks for that suggestion. Boy, that is daunting. What puzzles me is that I don’t get any warning about using the network. Also, it appears that security is not needed to read incoming data. I’ll look more into it and try adding a line to my info file.
DerkJ, in the DataAvailable event, I add the incoming command to an array to be processed in a timer. Then I get out. I don’t think that should cause a problem.
I haven’t tried polling instead of using the Data Available event.
Upon further study, I’ve found that Telnet has been removed from MacOS Sequoia. The link below talks about installing Telnet through home-brew. Perhaps I’ve already done that because I can connect to Telnet via Terminal.
So perhaps my process of expecting Telnet data over a TCP port is wrong and the cause of the missing data. Now I’m trying to use Shell commands to connect to Telnet. I can do this in the Terminal (MacOS Sequoia) which uses zsh, but I’m having trouble using the “telnet” command in Xojo’s Shell. My attempts to use Shell example code have not been joyful.
How can I issue the Terminal command “telnet 192.168.1.220” from a shell?
I think we should back up a bit and ask why you need to do that. Telnet via a shell is the same as using a TCPSocket to connect:
Dim t as TCPSocket
t=New TCPSocket
t.Address="192.168.1.220"
t.Connect
…and then handle the TCPSocket events to read the data and manage the connection. They’re very similar to a Shell’s events and methods so you should find it an easy transition.
If this works for you, it will remove your dependency on the ‘telnet’ program altogether and reduce your app’s complexity.
Thanks for your suggestion. My story above is quite long, but the problem is that for some reason, the TCPSocket stops sending to the Data Available event after some time (it might even be days). The Lutron system is still sending commands which can be seen by Terminal Telnet on the same machine. It’s still puzzling me.
Out of curiosity why is there constant communication from the ‘shades’? It seems to me there should only be communication when they are commanded to move.
Arnaud, all I know about App Nap is that I used to see it in an app’s info. Is it still a thing? How do I set it? The Mac Mini on which this is running is a server that never sleeps.
Derk, I haven’t logged it but I’ll check it. There’s very little traffic because commands only appear if someone presses a keypad or a shade moves. I’m checking it every tenth of a second.
I just did another test after making sure that I completely empty my buffer. I have another timer (every 10 seconds) that displays the socket ports and connection status. The Lutron TCPSocket port shows the same port number with connection status “true” as it did when I started the app this morning.
Initial testing showed keypad press commands received in the Data Available event (also showing in a monitor window). My app processed the commands properly by lowering and raising shades as expected.
At some point these hours later, keypad commands no longer arrive at Data Available, though the port and connection are still valid. The terminal, telnetting into the same IP address shows the commands on the same machine without fail.
I haven’t tried Polling, but I’m assuming there’d be nothing there if Data Available isn’t triggering.
I’m perplexed and hoping that there’s not some other stupid factor causing this and wasting your kind time in helping with suggestions. The Mac Mini is also a file server, ftp server, running HomeBridge, and Mac TV and Music apps. However, everything there and with the shades has been working for several years.
I did just uninstall OBS but I haven’t detached a video capture device. Hmm…I’ll have to test that…sorry, stream of consciousness going here.
The Lutron TCPSocket can fail while everything else (UI, timers, manual control) still functions, including 2 other TCPSockets and Siri control. I don’t think anything is napping.