Testing Device Commands with the MyURemote Python Capture Tool

1. What this tool is for

In many integrations, the first question is not whether the target device is responding correctly, but whether the correct bytes are leaving MyURemote in the first place. When building or testing a driver, you often want to know:

• is the command sent over TCP or UDP?
• what is the exact byte payload?
• is the payload plain ASCII text or binary data?
• does the integration send one packet or multiple packets?
• does the client expect any kind of response?

The Python capture tool provides a fake target device that listens on a chosen port and logs whatever MyURemote sends to it.

2. Why this matters in real-world integrations

Many device protocols are poorly documented, inconsistent between firmware versions, or only partially understood from packet captures and reverse engineering. In practice, debugging becomes much easier when you can isolate one question:

What exactly is MyURemote sending to the network?

Once that is clear, you can compare the captured output against:

• a known working vendor app
• Wireshark traces
• existing driver definitions
• protocol documentation
• expected ASCII / HEX command formats

This avoids “guess debugging” and gives a reproducible reference point during development.

3. What the capture tool does

The Python script starts a small fake server that listens on a single configurable port for both:

• TCP traffic
• UDP traffic

For every received packet, it prints:

• timestamp
• protocol (TCP or UDP)
• client IP and source port
• packet length in bytes
• HEX representation
• ASCII representation

For TCP connections, the tool also returns a very small test response:

OK\r\n

That response is not meant to emulate a real device protocol. It simply helps in cases where the sender expects some response and would otherwise block or disconnect differently.

4. Download

The capture tool can be downloaded directly here:

myuremote.com/website/downloads/python/capture_tool/python tcp_sniffer.py

Save the script locally and run it on a machine that is reachable from the device running MyURemote. In most cases this will be a computer on the same local network.

5. Requirements

• a computer with Python 3
• the computer must be reachable on the same LAN as the MyURemote client
• the chosen TCP/UDP port must not be blocked by the firewall
• MyURemote must be configured to send commands to that IP and port

In most setups, no extra Python packages are required because the script uses standard library modules only.

6. How to run the tool

Start the script from a terminal or command prompt:

python3 capture_tool

The tool will ask which port it should use, for example:

Welke poort moet ik gebruiken? (bv. 4998) : 4998

It then determines the local IP address of the machine and displays the values you should use in MyURemote.

Typical output looks like this:

=== Fake Device Server (TCP + UDP) ===

🔍 Lokale server draait op IP: 192.168.0.120
➡ Stel in MyURemote IP = 192.168.0.120, poort = 4998
➡ Wireshark filter voorbeeld: host 192.168.0.120 and tcp.port == 4998

TCP-server luistert op 0.0.0.0:4998
UDP-server luistert op 0.0.0.0:4998

Wachten op verkeer... (Ctrl+C om te stoppen)

7. How to use it with MyURemote

The basic workflow is straightforward:

1. Run the capture tool on a computer in the local network.
2. Note the IP address and chosen port shown by the script.
3. In MyURemote, configure the test device or command target to use that IP and port.
4. Trigger the command from MyURemote.
5. Inspect the output printed by the Python tool.

In other words:

MyURemote → your computer running capture_tool → terminal output

This lets you validate the actual command payload before involving the real target device.

8. How to read the output

When MyURemote sends a command, the tool prints a packet log similar to:

[2026-03-13T14:23:10] TCP 192.168.0.45:53122 -> 8 bytes
  HEX:   50 4F 57 45 52 4F 4E 0D
  ASCII: POWERON.

This tells you:

• the transport protocol used
• which client sent it
• how long the packet is
• the raw bytes in hexadecimal
• a readable ASCII view where possible

The ASCII line is especially helpful for text-based protocols. The HEX line is essential for:

• binary commands
• non-printable delimiters
• carriage return / line feed differences
• null bytes or checksum bytes
• comparing exact payloads against Wireshark captures

9. Practical use cases

9.1 Testing a new TCP driver

When defining a new IP-based driver, you can point the device temporarily to the capture tool instead of the real target and verify that the outgoing command format is correct.

9.2 Verifying delimiter issues

Many protocols require exact terminators such as:

• \r
• \n
• \r\n
• no terminator at all

The HEX output makes these differences immediately visible.

9.3 Confirming UDP vs TCP behaviour

Some devices accept UDP discovery and TCP control, while others use UDP for actual commands. This tool allows you to confirm what the integration is really doing.

9.4 Comparing against vendor-app traffic

You can compare captured MyURemote commands against traffic captured from an official app to verify that the format, byte order and framing match expectations.

9.5 Debugging response expectations

If MyURemote behaves differently when the fake server returns OK\r\n, that can be a clue that the integration expects a response phase after sending the command.

10. Optional: combine it with Wireshark

The script already prints a suggested filter format. For example:

host 192.168.0.120 and tcp.port == 4998

Or for UDP:

host 192.168.0.120 and udp.port == 4998

Combining terminal logging with Wireshark is useful because:

• the terminal gives an immediate readable summary
• Wireshark shows session timing and packet structure in more detail
• you can compare multiple clients and repeated command sequences

In many debugging sessions, the terminal output is enough. Wireshark becomes most useful when timing, retries, retransmissions or multi-packet exchanges are involved.

11. Important limitations

This tool is intentionally simple. It is a capture endpoint, not a protocol emulator.

• it does not emulate a real device state machine
• it does not perform authentication handshakes
• it does not implement brand-specific responses
• the TCP reply OK\r\n is generic and only meant as a minimal test response
• it is mainly useful for raw command inspection, not full protocol validation

For complex protocols such as WebSocket, TLS-based sessions, challenge/response flows, or structured JSON exchanges, this capture tool is still useful as a first diagnostic step, but it is not a complete simulator.

12. When this tool is the right first step

Use the capture tool first when:

• a command appears not to work and you want to validate the exact outgoing payload
• you are creating a new driver and want quick feedback
• you suspect formatting issues in the command string
• you want to know whether traffic is TCP or UDP
• you need a fast local test target without involving the real device

This often turns an unclear integration problem into a very concrete technical question:

Is the wrong command being sent, or is the real device rejecting a correct command?

13. Summary

• The Python capture tool acts as a fake network device for TCP and UDP command testing.
• It helps verify exactly what MyURemote sends over the network.
• It logs packet size, HEX data and ASCII data for quick inspection.
• It is ideal for driver development, command validation and protocol debugging.
• It is not a full emulator, but it is an excellent first diagnostic tool.

Bottom line: this tool helps separate command-generation problems from device-behaviour problems.