Closed TobiasBecker closed 7 years ago
Yeah, the current 0.3.0
implementation won't let you do that, it eats the line endings when sending.
Do you know if Universe would accept multiple such CR/LF -separated lines within a single UDP packet? Then we could just drop the line-splitting and send the complete templated output as a single packet, including line-breaks.
I'll write something to optionally split on '\n' and preserve the packet separator.
v0.3.1 adds support for --universe-line-format=crlf
and changes the --universe-udp=
and --universe-tcp=
to support multiple TCP/UDP destinations.
The new defaults should send a CR+LF ("\r\n"
, ASCII hex 0d 0a
) for each line / UDP packet.
Hopefully this should be enough for use with Universe, please upgrade and test again.
@TobiasBecker TCP Support is great and is what worked in the end, [...] UDP: the CRLF worked, but still UV seems to have problems to filter the packets correctly. With TCP it works just fine and all packets are received and, more important, correctly interpreted.
So there's still some issues with the UDP messages, but TCP works.
Leaving this open to track what's up with the UDP messages. Needs access to Universe for testing.
0.3.2 changes the default options to send each tally update as a single UDP packet, containing multiple <tallyXX-{high,low}>
lines.
It seems the Universe "Line Format" field does not behave as expected, the correct settings to use are:
_None_
_60_ (ASCII <
)
_62_ (ASCII '>')
See the example configuration in the Wiki: https://github.com/qmsk/e2/wiki/Universe-Tally#universe
To use the UDP protocol, you must reconfigure the Start/End bytes, and remove the <...>
brackets from each trigger.
The TCP protocol should remain the same, so you can continue to use the End Byte = 10 workaround.
Talking about the work030 version which included UDP commands issues with every tally event.
Would it be possible to add a CR after each command? I’m not sure about the encoding but my UV UDP properties are as following:
String Encoding: ASCII Line Ending: CR (was NONE) Start Byte: (I can only enter a 3 digit number here)
End Byte: (I can only enter a 3 digit number here)
Is this precise? Alternatives would be: LR CR_LR LR_CR
All the other commands / syntax can remain the way they are. Thanks!