- ComfortClick
- bOS Configurator
- Devices
- Basic
-
Questions
Regex multiple line text parsing
Hi,
I have issued a basic http command that retrieves multiple lines, effectively we cannot get the values of the 7 groups that are returned under a specific matching. The question is how does COmfortClik handle the groups within regex text to be able to handle the group values, remember this is a text regex not a JSON or XML regex, so there are no tokens!!
The REGEX listener I have created is for a string (it has been validated as it works in any regex tester) ^\#>(?[0-9]{2})(?[0-9]{2})(?[0-9]{2})(?[0-9]{2})(?[0-9]{2})(?[0-9]{2})(?[0-9]{2})(?[0-9]{2})(?[0-9]{2})(?[0-9]{2})(?[0-9]{2})$/gm
However, Comfortclick does not seem to handle the groups within a Text REGEX, despite multiple lines are coming in the system response
When executed through a host connection this is the same code returned
Customer support service by UserEcho
The receiver set-up where the text REGEX waits for the multiple line response
Ok, after further investigation, the issue is looking bad, even when the remote device sends a single line, 24 characters, BOS splits the response into teo lines, hence the RegEx is deemed useless, because BOS processes the response as if two strings were sent, when actually is only one long line of 24 characters, as the telnet screen shows.
@Comfortclick team any thoughts on why BOS processes the device response as two separate strings responses?
a single command executed to get a single line response made of 24 characters, is split in two
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
@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
Hello,
thank you for reporting this issue. Values are being treated differently depending on the connection type, end of line is missing in tcp and other connection types, which we will add it and the values should be coming trough correctly.
You can expect this fix in the future release.
Best regards.
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?
Hello,
hard to say how the current parsing works as it spit out different info here. The programming team was already able to implement the end of line function in our TCP connection type, so you should be able to see this in the next beta release.
Best regards.
Great, looking forward for that Beta.
Hi team, any thoughts when that Beta might be released? THanks.
Hello,
we are working on it, we will try to release it asap.
Best regards
Great, looking forward for it!
Sorry to pester guys, Any chance when that Beta will be coming to the market? :-)
Hello,
it's currently not in beta release, but it is in alpha release. Alpha release cannot be installed on your own, but it would require a remote session with our support team to install it (it comes with many other features that will be released in our future updates).
You can contact us directly at support@comfortclick.com or open a support ticket so we can arrange a remote session and install alpha version.
Best regards.
Hi team, thanks for the new superversion, unfortunately the issues with execuitng one single line and BOS processing two lines, still remains
Command in basic driver
Successfully executed as per Putty command line shows
However, the response is parsed, but data not accessible -the regex tags-
How is BOS extracting the values or where are the tag values from the Regex stored in BOS?
hello,
could you send us the exact data that is send by the device and export of your basic driver so we can recreate the issue and try to resolve it.
Best regards.
thanks, details sent to support@comfortclick.com just now. thanks