telnet regex (what am I missing?)

[Peter Truman]

Hi all

Been back to lurking for a while, now just playing with moving from 2.1 to 2.5 and trying to setup a telnet sensor.

Summary : I have an A/V device accessible over telnet, and upon connection it displays a status message (no input required).  The input is :

CH_STATUS 0123 LOCAL

Where 123 is a channel number, so I just want the 3 final digits...

My REGEX I'm using is:

^CH_STATUS 0(...) LOCAL

Which checks out in various regex testers.  I've specified I want group 1 (the only brackets shown).  Additionally, I've included a command (which I've put "null|" for, and have tried "null") - although I don't need to send anything, just connect, read and disconnect...

 

But what I get in the telnet.log is:

WARN 2016-10-20 12:34:05,916 (Telnet): Telnet Read Status: No Match using Regex: '^CH_STATUS 0(...) LOCAL' on response from command 'null|'

Any clues?  I'm missing something blindingly obvious no doubt...

(in better news, my LightwaveRF UDP listener is working and updating temperature AND detecting heating on/off status, so I might get to update the Wiki!)

Kind regards

Peter

[Peter Truman]

Just realised a mistype...

The line that reads:

Summary : I have an A/V device accessible over telnet, and upon connection it displays a status message (no input required).  The input is :

Should read:

Summary : I have an A/V device accessible over telnet, and upon connection it displays a status message (no input required).  The output is :

The error I receive also states "on response from command 'null|'" - so I'm presuming it's trying to send the command (that I don't actually need to send, but can't leave blank) and then fails to read a response, as it won't get one....

Any cunning ideas? :)

[Peter Truman]

Is there a general problem with TCP/IP and telnet regex?

I've now tried a sensor with my Onkyo, on TCP/IP....

Command is :

0x4953435000000010000000090100000021314d564c5153544e0d0a0d0a

This gets the volume

The response issued (visible in Hercules & Telnet) is:

ISCP

!1MVL14

My regex is:

.?\n!1MVL(\d+)

That should pick up all text, hit a line break and start from !MVL (nb: I've tried without the .?\n and no difference)

https://regex101.com/ says I should pick up 14 in group 1....

Nothing in the sensor :(

[Peter Truman]

Right, removed the regexp, and I only get the first row of returned text - and there are multiple. What do I need to do? (Help!)

[Erik Trapp]

Hello,

Have you tried just using

1MVL(\d+)

/Erik

[Peter Truman]

Found the problem on ONE item...

Issue a TCP command of 0x and I get a response....which I can parse.

Except TCP/IP ignores regex groups, and returns the whole match.

Now to tackle the break...

[Peter Truman]

Ok - some more debug info...output in Hercules format which helps transcribe...

When I connect to my Onkyo, it always responds thus:

ISCP#NUL#NUL#NUL#DLE#NUL#NUL#NUL#VT#SOH#NUL#NUL#NUL!1NLSC-P#SUB#CR#LF

I can then send a command...

In HEX, with TCP/IP command protocol, I send this:

0x4953435000000010000000090100000021314d564c5153544e0D0A

This translates as :

ISCP#NUL#NUL#NUL#DLE#NUL#NUL#NUL#HT#SOH#NUL#NUL#NUL!1MVLQSTN#CR#LF

This works, however I now want to read the response...

So using a TCP connection tool, I run the above and get this response back:

ISCP#NUL#NUL#NUL#DLE#NUL#NUL#NUL#LF#SOH#NUL#NUL#NUL!1MVL1A#SUB#CR#LF

It's the 1A I'm interested in, Hex for 20.

However, what I'm getting back in the TCP/IP log (after I enabled it) is this:

As you can see, OpenRemote is parsing the CR/LF (and some other stuff, apparently) - but it's not getting the last line...

If I use Hercules in text mode, watching as OR connects in, I see this conversation:

ISCP!1NLSC-P

ISCP

!1MVL1E

The above shows the ISCP!1NLSC-P as OR connects - we don't see the command issued, as we're a "watcher" in this case, but we do see the response...which is the MVL1E line.

Clues?  Can I extend the TCP buffer easily?

Annoying it WAS briefly working, but seems to have knocked itself out on a restart...

Cheers!

[Peter Truman]

Addendum - the screenshot shows a CH_STATUS line - that's a response from another device, which is working ok.