RDP probe unlinked/offline

[KasperV79]

Hi guys. I’m new to Roastmaster so hope you can help me.

I just made a esp6288 module with thermcoupler. Modified the example code a bit to suit my setup.

When starting up the esp search forc Ack from the app and the Ack is received when the app is opened, hereafter the rdp starts to send temp data, event type 3.

But nothing is no data to see on app prope. And the prope has status “unlinked” I checked the serial “name” and everything seems correct.

Are there been any updates to the RDP protocol or can it be due to running on IOS 12?
Br
Kasper

[Danny Hall]

Hi Kasper

So, you've got it to the point where you send a SYN request, and Roastmaster replies back with an ACK, correct?

If so, then it's probably a simple formatting issue.

Can you reply back with a sample of the JSON that you create as text for a temp reading? I'll see if I can spot the problem.

Danny

[KasperV79]

Thanks for quick answer:

heres copy of log:

I added the RDPevent meta type as tes to see if that did the trick. but it didnt do any different.


WiFiconnected with IP Address: 192.168.1.253 Mask: 255.255.255.0
Transmitting SYN datagram to IP: 192.168.1.247, Port: 5050, JSON: {"RPVersion":"RDP_1.0","RPSerial":"Probe1","RPEpoch":0,"RPPayload":[{"RPEventType":1}]}
Transmitting SYN datagram to IP: 192.168.1.247, Port: 5050, JSON: {"RPVersion":"RDP_1.0","RPSerial":"Probe1","RPEpoch":1,"RPPayload":[{"RPEventType":1}]}
Transmitting SYN datagram to IP: 192.168.1.247, Port: 5050, JSON: {"RPVersion":"RDP_1.0","RPSerial":"Probe1","RPEpoch":2,"RPPayload":[{"RPEventType":1}]}
Transmitting SYN datagram to IP: 192.168.1.247, Port: 5050, JSON: {"RPVersion":"RDP_1.0","RPSerial":"Probe1","RPEpoch":3,"RPPayload":[{"RPEventType":1}]}
Transmitting SYN datagram to IP: 192.168.1.247, Port: 5050, JSON: {"RPVersion":"RDP_1.0","RPSerial":"Probe1","RPEpoch":4,"RPPayload":[{"RPEventType":1}]}
Transmitting SYN datagram to IP: 192.168.1.247, Port: 5050, JSON: {"RPVersion":"RDP_1.0","RPSerial":"Probe1","RPEpoch":5,"RPPayload":[{"RPEventType":1}]}
Received packet of size 103 from IP Address: 192.168.1.247 Port: 5050: {"RPEpoch":1560402127.518846,"RPVersion":"RDP_1.0","RPPayload":[{"RPEventType":2}],"RPSerial":"Probe1"}
Packet was an ACK packet from server.
Beginning temperature transmission.
Transmitting Temps datagram to IP: 192.168.1.247, Port: 5050, JSON: {"RPVersion":"RDP_1.0","RPSerial":"Probe1","RPEpoch":6,"RPPayload":[{"RPEventType":3,"RPChannel":1,"RPValue":99.90,"RPMetaType":3001}]}
Transmitting Temps datagram to IP: 192.168.1.247, Port: 5050, JSON: {"RPVersion":"RDP_1.0","RPSerial":"Probe1","RPEpoch":7,"RPPayload":[{"RPEventType":3,"RPChannel":1,"RPValue":99.90,"RPMetaType":3001}]}
Transmitting Temps datagram to IP: 192.168.1.247, Port: 5050, JSON: {"RPVersion":"RDP_1.0","RPSerial":"Probe1","RPEpoch":8,"RPPayload":[{"RPEventType":3,"RPChannel":1,"RPValue":99.90,"RPMetaType":3001}]}
Transmitting Temps datagram to IP: 192.168.1.247, Port: 5050, JSON: {"RPVersion":"RDP_1.0","RPSerial":"Probe1","RPEpoch":9,"RPPayload":[{"RPEventType":3,"RPChannel":1,"RPValue":99.90,"RPMetaType":3001}]}

[Danny Hall]

Everything looks right to me.

I fired up my own RDP sender test app, and replaced the JSON I was generating based on UISliders and such, by pasting one of your Temp datagram JSON strings - just subbing out the Epoch for another value to make it easy. {"RPVersion":"RDP_1.0","RPSerial":"Probe1","RPEpoch":1560432161,"RPPayload":[{"RPEventType":3,"RPChannel":1,"RPValue":99.90,"RPMetaType":3001}]}

RM connects as expected.

Do you have the "Channel" field set to 1 in the Probe definition in RM? That's the only thing I can think of that would prevent a connection.

See screenshot for the results I get. It will look a little different than yours - the next version of RM has a lot of new features for probes and curves, but the 3 things that RDP requires: - UDP Port, Serial and Channel - are still the same.

[KasperV79]

Yes it’s channel 1.
One thing.
When RM send AcK, the RPEpoch is: {"RPEpoch":1560402127.518846,"RPVersion":"RDP_1.0","RPPayload":[{"RPEventType":2}],"RPSerial":"Probe1"}
Packet was an ACK packet from server.
Beginning temperature transmission.

When the host start sending Temp, the RPEpoch continuous from whatever it was when it was syncing, which is less then the value Ack returned:
Transmitting Temps datagram to IP: 192.168.1.247, Port: 5050, JSON: {"RPVersion":"RDP_1.0","RPSerial":"Probe1","RPEpoch":6,"RPPayload":[{"RPEventType":3,"RPChannel":1,"RPValue":99.90,"RPMetaType":3001}]}
Transmitting Temps datagram to IP: 192.168.1.247,


Do RM reject/ ignore packets with lower RPEpoch number??

[Danny Hall]

It does after the connection begins, yes, but when RM transmits an ACK response back to you - the very next line of my code resets its internal Epoch to -1, so that the next datagram it processes (assumedly a temp datagram) will always have a larger Epoch.

What is the interval between packet sends in your code? I’d ry the following:

1) Try setting the send interval to every 2 or 3 seconds to make sure that datagrams are not "bottlenecking” on the network interface of either devices and being a) discarded or b) processed out of order.

2) Try sending the following string constant instead of the actual information that you build: {"RPVersion":"RDP_1.0","RPSerial":"Probe1","RPPayload":[{"RPEventType":3,"RPChannel":1,"RPValue":99.90,"RPMetaType":3001}]}

This is the same string that you originally posted, minus the Epoch. I tried this on my end, and got a connection instantly. When sending datagrams, if you do NOT include an Epoch, RM will process every datagram it receives without question. That may shed some light as to whether or not the Epoch is mucking things up

3) Finally, make sure that the methods you are using to LOG the information you posted (IP addresses, JSON strings, etc.) are actually logging the same information you’re sending. Sounds silly, but I’ve encountered many situations while coding where I formulate data for use, encounter a problem, and then re-formulate that data for logging and can’t find the problem. Often, it’s because the logging method is building it differently (not escaping quote marks, missing a comma, referencing the wrong variable etc.). If your logging method isn't already doing so, try logging the data exactly as it is being send.

Let me know - I'm very interested to know what the issue is.

[KasperV79]

Thanks for taking your time to answer.

Fault found.!

My code is build on your example on github with minor changes.
I did change the udp.beginmulticast() to udb.beginpacket(), but I did only change it in the SYNC function and not in the sendTemperatureTelegram function.

Every thing works flawlaess now. Thanks again for your time!
 

[Danny Hall]

Great news!

Glad you got it fixed - you're very welcome!!