Quote Originally Posted by passel View Post
It is difficult to read posted images, as they are shunk when added to the page. The hex data is showing the complete transfer, which will include transport overhead and protocol overhead. You are sending UDP, so the first level of the message should the IP protocol header, then the UDP protocol header, then the data you sent.
If you hover your mouse over the byte display in the bottom window, it should highlight some number of bytes, which correspond to different parts of the total message.
If you click on various parts of the middle section, it should highlight the bytes in the hex dump that correspond to that part of the message. The middle window is trying to identify the values of things it recognizes and show you the interpreted values, i.e. you have a destination IP address and port, and a source IP and port, so it will highlight the bytes that make up those fields, and show you an interpretation of those byte.
The Length column value is probably the length of the UDP packet, including UDP protocol header and your data. At the end there is a Len=xx note which may be the length of just the data being sent, so your packet or message, or whatever you want to call it, would be the last xx bytes of the displayed hex data.

The data that you send, should be the last bytes of the message, so if you click on the "payload" or "data" field, or whatever the last item is called in the middle window, it should highlight the data bytes below, and they should match what you are sending.

It looks like every time you send something, you are getting a response back, so you might want to see what that response is and if it makes sense. It might be telling you that you are not sending good data. The format of the commands to send over the Ethernet may not be the same format as the commands sent over the serial. I don't know, since I don't know anything about the interface.

Also, it doesn't look like there is five seconds between transfers. From the timing column on the left, it looks like you're sending (and getting a response) about two times per second.
Perhaps the portion of the capture you're showing isn't the part where you sending the messages with a delay.
The last three transmissions you're showing to appear to be more spaced out. Can't quite make it out, but it looks like if goes from 14 to 23 or 33, to 43 (or something) so perhaps about 10 or 20 seconds between sends.

You'll need to verify what the format of the data is suppose to be when using the UDP interface, and what the response from the panel (an acknowledge or error response) may be telling you.
Other than that, it looks like you are sending data to something, and are receiving data from that thing, so that is the first step.
Here is what I have found so far from viewing the WireShark data using the Bosch software.
The HEX Data changes based on the sender's port which is different every time.
So I matched the port to the HEX data sent now that is the same.
But still can't get the panel to reboot.
The only thing I see different now is the Identification Number and it changes every time the Bosch software sends a HEX string, would this make a difference?