MyURemote ↔ IP Controller (Raw TCP Commands)
Official guide for using the MyURemote “IP” controller to send custom commands over TCP/IP directly to network-enabled equipment. No extra hardware is required.
Use this controller when your device supports control over the network (IP) and you want to send your own command strings to a specific IP address and TCP port. Typical examples: AV receivers, matrix switchers, audio streamers, LED controllers, home automation gateways, and custom devices.
What the “IP” controller is (and isn’t)
- It is: a generic TCP command sender from MyURemote → sends raw strings to ip:port.
- It is not: auto-discovery for every brand/device. You normally configure it manually.
- It is not: a serial bridge. If your device only has RS-232, use the serial controller + a TCP↔RS232 bridge.
- It is not: an HTTP/REST API wrapper (although you can sometimes send HTTP-like lines over TCP if your device expects it).
If you need IR or RS-232 hardware I/O, use Global Caché (IR/serial hardware) or the serial controller (TCP↔RS232 bridges).
Contents
1. Concept
The MyURemote IP controller sends raw command strings to a device on your network using TCP/IP. You configure: IP address + TCP port, then map buttons/macros to the command strings.
MyURemote (tablet/phone) → LAN/Wi-Fi → IP device listening on a TCP port
- No IR emitters, no RS-232 cabling, no extra controller hardware.
- Great for devices that already expose a TCP control port.
- Works best when your device protocol is well documented (command strings + termination rules).
2. Best use cases
- Matrix switchers
- Audio DSP / amplifiers
- Streamers / players with TCP control ports
- Projectors with LAN control (TCP)
- Custom controllers that accept TCP messages
- Automation hubs that expose LAN sockets
- DIY / Arduino / ESP devices with TCP servers
- Devices without MyURemote native database support
- Integrations where you already know the exact command strings
- Rapid prototyping and testing
If your device only supports HTTP/REST, you may still be able to use IP control in other MyURemote methods (depending on your integration). This page specifically describes the raw TCP “IP controller”.
3. Requirements (device side)
Your device must accept commands over TCP on a known port. Many devices expose a “control port” (sometimes called “Telnet control”, “TCP API”, “ASCII protocol”, or “LAN control”).
- Device must be reachable on your LAN (same network).
- Device must listen on a TCP port (example ports: 23, 80, 4998, 5000, 6000, 10001…)
- You must know the command strings and the required termination (CR/LF/CRLF/none).
- Some devices require login/authentication after connecting (advanced case).
Note: If a device requires a multi-step session (login, prompts, stateful exchange), raw TCP control may require a custom integration. For simple “send command and receive response” protocols, the IP controller is ideal.
4. Network setup
- MyURemote device (tablet/phone) and your IP device must be on the same LAN/Wi-Fi.
- Avoid guest Wi-Fi networks and client isolation.
- Use DHCP reservation so the device keeps a stable IP address.
- If using VLANs/firewalls, allow traffic to the required TCP port.
If the device IP changes, control will break. A DHCP reservation prevents this.
5. Command format & termination
Most TCP control protocols expect one command per line and require a terminator such as CR (\r), LF (\n), or CRLF (\r\n). Others require no terminator or use binary payloads.
Most common. Example: POWR 1\r
Often port 23. May still behave like raw TCP + terminator.
Some protocols use bytes (0x..). These can work, but require careful formatting.
Important: the MyURemote IP controller sends the command exactly as you define it. If a terminator is required, you must include it in the command definition (or use the appropriate device profile).
6. MyURemote configuration
6.1 What you need
- IP address of the target device
- TCP port the device listens on
- Your device’s command strings (from documentation or known working examples)
6.2 Setup overview
In your MyURemote configuration, select controller type: IP and enter: IP address + Port. Then map buttons/macros to your custom IP commands.
Start with a single “Power” or “Status” command before building full remotes and macros.
7. Testing strategy
7.1 Verify connectivity first
- Confirm the device IP is reachable from your LAN.
- Confirm the TCP port is open (device documentation / network tools).
- Ensure no firewall/VLAN blocks local traffic.
7.2 Verify command format
- Check whether commands require \r, \n, or \r\n.
- Check if commands are case sensitive.
- Try a simple query/status command if available.
Many device control protocols provide a “status” command that returns a response, which is ideal for validation.
8. Troubleshooting
Cannot connect / timeout
- Confirm IP address and TCP port are correct.
- Ensure tablet/phone and the device are on the same LAN (no guest isolation).
- Check VLAN/firewall rules.
- Use DHCP reservation to avoid IP changes.
Connected, but device does nothing
- Most common cause: missing/incorrect terminator (\r, \n, \r\n).
- Verify command syntax (case, spaces, prefixes).
- Check if the device requires a login/session handshake.
Works once, then stops
- Some devices require persistent connections; others require reconnect per command.
- If the device has a “single client” limit, another app may already be connected.
9. FAQ
Do I need extra hardware for IP control?
No. If your device exposes a TCP control port on your LAN, MyURemote can send commands directly to it.
Is this the same as HTTP/REST?
Not necessarily. This controller sends raw TCP strings. Some devices use HTTP-like text over TCP, but many use custom ASCII protocols.
What if my device requires authentication?
If authentication requires a multi-step session (login prompts), a custom integration may be required. For simple command protocols, the IP controller is ideal.
10. Changelog
- v1 – Initial MyURemote “IP controller” guide (raw TCP command sending).