Great, looking forward for it!
Hi team, any thoughts when that Beta might be released? THanks.
Thanks guys, however, there must be something else here, for example when the max value shown in graph (red line) is 3.5 for the period the graph covers (e.g. 24 hours), it is a real time graph, then BOS scales it properly, ignoring that supposed max value of 20.
Regarding your recommendation, not sure whether the graph allows, setting a max value, I cannot find such a thing in the graph properties. See below please the controller behind the graph
Has this been fixed to work in celular networks? We do no want to update ios15 ahead of time
Anyone has any thoughts? @Comfortclick team? I have not been able to find any parameter to set the above up, and yet the graph scales and creates unnecessary padding
Great, looking forward for that Beta.
Thanks guys, Can we please clarify what is the current behaviour, as I have an external TCP device with RS232 commands that I cannot handle because of this situation. Regardless of the multiple line processing
a) Currently BOS is splitting the response message at will, with random logic, as per the logs shared. Is the bug you call out addressing this symptom?
b) Currently there seems to be a limit on the response length, accepting a maximum of 24 characters, even if there is a single line response BOS is dropping anything beyond 24th character. Is the bug you call out addressing this symptom?
c) Multiple line response processing is the third item in this bug
None, except the last, of the items mentioned, require multiple line response processing with carriage return coded in the message, BOS is quite powerful so I´d struggle to believe it cannot handle a simple TCP response with more than 24 characters, even that no one has reported similar scenario before in so many years.
Currently craving to get an answer, happy to test a Beta, because as of now I cannot control with BOS an external music device via TCP/RS232 from a well known brand. Any thoughts?
@Comfortclick team any thoughts on why BOS processes the device response as two separate strings responses despite one single response being generated (or two if the command is accepted as a line based on the hex codes 00-0A
Any thoughts team on how to solve the BOS string split? I have tried multiple things but it is not possible to parse a text whose structure you do not know how it will be received. I´d expect someone has dealt with RegEx parsing of strings longer than 24 characters
a single command executed to get a single line response made of 24 characters, is split in two
Customer support service by UserEcho