First, the assertion that PMU Connection Tester is connecting to the device is probably incorrect. UDP is often referred to as a “connectionless” protocol meaning there is no handshake process to verify that both devices are actually able to communicate. In this case, when PMU Connection Tester says it’s connected, it really just means it was able to open a socket on port 8800 and start listening for packets. Even if it’s trying to send command frames to the device, UDP doesn’t have any built-in packet acknowledgement mechanism so PMU Connection Tester would be none the wiser if those command frames were simply lost en route (except for the fact that it’s receiving nothing in response, I suppose, but PMU Connection Tester has no logic to time out UDP communications).
Now, to the root of the reason why I think PMU Connection Tester is lying about the connection. In your relay’s configuration, it looks like you configured the remote port to be 4713. Given that this is the remote port from the perspective of the relay, that would make it the local port from the perspective of PMU Connection Tester. That suggests to me that the
Local Port setting on the PMU Connection Tester should be set to 4713 as well.
It doesn’t look like the relay allows you to configure a local port. It could be picking a random port, or just setting the port value to zero. At least until you can learn more, I would recommend unchecking the
Enable Multicast / Remote Udp setting. You won’t be able to send commands to the device, but
UDP_S is probably designed for unidirectional communications anyway. Note that you will have to wait up to 60 seconds to receive the configuration frame. If you do not see any hexadecimal output from data frames in the bottom of the window, that indicates that the communications are still not working.
Example hexadecimal output: