I’m looking for information about whether Hubitat plans to support a true TCP server / listening socket in drivers or apps.
Current Hubitat capabilities only allow outbound connections:
• telnet → TCP client only
• LAN / HubAction → outbound TCP/UDP/HTTP
• WebSockets → client only
• mDNS listener → UDP multicast discovery, not a TCP listener
For certain integrations (e.g., alarm panels and devices that expect the hub to behave like a central-station server and initiate a TCP connection into the hub), we need the ability to:
• Bind to a port on the hub
• Accept an incoming TCP socket
• Maintain that session (ACK/NAK, heartbeat, counters, etc.)
Is there any existing API, beta feature, or roadmap item for enabling a general TCP listening socket in Hubitat?
Or can staff confirm that inbound TCP listening is definitively not supported now (beyond the hub’s internal mDNS/SSDP listeners)?
If anyone has workarounds or context from prior feature requests, I’d appreciate links.
To play the ill-informed devil's advocate... Could that not open up a range of security elements users would then need to be across and manage? Which would be beyond many non-tech users?
Point being.... to make Hubitat appealing to the masses (I know, realistically that is a way off yet...), would overly technical setups be something we would want to introduce for people to potentially mess up, or guide people to more bespoke solutions that match the users technical knowledge?
Hi @sburke781 ,
Appreciate your reply.
I understand the concern about complexity, but adding a TCP listener wouldn’t affect ordinary users at all. It would simply be an optional, advanced feature, similar to telnet, WebSockets, custom drivers, or Maker API. None of those features confuse non-technical users because they never need to touch them.
Right now, integrations that require the hub to act as a TCP server cannot run directly on Hubitat, so users must add external hardware (Pi, Node-RED, etc.). That actually increases complexity and security exposure.
A TCP listener would only be used by advanced developers, completely opt-in, LAN-only, and could be sandboxed like Hubitat’s existing network APIs. For regular users nothing would change; for technical users it would remove a real limitation and enable integrations that currently aren’t possible.
There's also this, which at one point was considered beta but I think was just dropped after some time. Can't say I've seen it used much, and not sure if it will help with this use case, but it's there.
That complexity increases risk is a reasonable axiom for security, however it isn't always true. Use of proxy agents is generally a place where it isn't.
Thanks — I looked into the LAN driver documentation.
Port 39501 can only receive HTTP messages.
The alarm system I am working on uses a raw TCP connection with its own binary protocol, not HTTP, so unfortunately this method can’t handle the type of connection the panel requires.
Good point — using a proxy or external agent can absolutely reduce risk in many setups, especially when it isolates the hub from direct low-level connections. My point was only that a TCP-listener API, if it ever existed, would be an optional tool for advanced users and wouldn’t affect the default security posture of the hub. Most users would still be better off with a proxy, and nothing in this request changes that. The idea is simply to make certain integrations possible without forcing extra hardware when it isn’t needed
The LIFX LAN integration uses UDP to send and receive raw packets, so the hub already has this functionality. Outside of the docs provided the functionality you are looking doesnot seam to be exposed to external developers. Considering the other integrations that use raw tcp/udp packets ie Airplay and Homekit the decision not to expose this functionality outside of internal use may be intentional.
I doubt this is the lens through which HE assesses security. Any user could easily unknowingly install community code (via HPM or otherwise) that leverages this feature.
I just use port forwarding in my router and open up the specific ports i need. I do that to have multiple ecowitt weather stations in another state report back to the 39501 port.
Sure. I’m using a PIMA Force alarm system. Their latest firmware added the ability to connect locally to the panel through a TCP endpoint and receive real-time events, as well as send commands like arm, disarm, and data requests.
I’m currently building an integration for it. Because Hubitat doesn’t support acting as a TCP listener, I’m using Node-RED as the TCP bridge, and then Maker API to communicate with Hubitat. This setup works very well, but I’m concerned that some users might not have Node-RED available, which could make the integration less accessible for others.
I’m really hoping it’s using something like TLS over TCP to encrypt the connection and the data. Getting that working with Node-Red, i agree is not a trivia task. Though if you are just parsing unencrypted raw TCP packets… from a security system, i would be more concerned with how relatively easy that would be to exploit.
Good point.
In this case the panel’s local connection is plain TCP, not TLS. It’s designed for use strictly inside the LAN, with the assumption that the local network is already secured and isolated. The protocol itself is not exposed to the internet, and the integration never opens any external ports.
You’re right that TLS would be preferable from a security perspective, but implementing it would require support from the alarm panel itself. Since the device only offers raw TCP, Node-RED (or any other bridge) is simply handling what the panel provides.
If the panel ever introduces TLS or certificate-based authentication, I would absolutely update the integration to use it.
I often don't mind unencrypted/unauthenticated communication in a LAN for status (a UPS is a good example), but for command/control I would view it as unacceptable.
Could that not open up a range of security elements users would then need to be across and manage? Which would be beyond many non-tech users?
