sWORDs, we are in agreement on the message size and EOL termination. Thanks for helping to confirm this and clarifying for me.

I'm still using read= with some string manipulations that, so far, has not failed. I implemeted a routine that sends one query at a time and only after one complete message has been returned/processed does it request the next. I have a series of 6 queries that load up a status page when jumped to. Then, it sits and listens for events and processes the messages one at a time as they come in.

Next, looking at the read+= implementation.

But first, can't figure out why the pre/pro now refuses to connect to Pandora and iRadio :( while is finds the PC music servers (local net) and Rhapsody (Internet) just fine...

Yes, I think so.

The device likely sends data in chunks of 26 bytes, to its TCP/IP stack. In MOST cases, this will cause data being received in the Pronto's onData callback also to be in chunks of 26 bytes. But you should not assume that this will ALWAYS be the case.

The code layout I posted is much easier to extend with all the commands and parsing. I would recommend that you use it. I might extend it so it contains all parsing and sending commands.

The Onkyo only sends a frame when it needs to send and creates a new frame for every command. There is no way that it will chunck frames this small, maybe it doesn't even support it. So don't worry about it.

sWORDs, wow, what a terrific example!

Your professional approach (and code provided) along with w3 schools has allowed me to learn quite a bit. I have not tried the code yet, but rather I've studied it to understand how it works.

The paradigm I used is simply to find the piece of the string that I care about, and throw away the rest.

Your paradigm defines all elements of the string, and through pattern matching, assign each element to a variable for later use. Your understanding that the device will only send a frame and not less is key. Using the read=, though, I have seen two or more frames on occassion. But this only occured when I sent all the queries at once versus the one-at-at-a-time method.

This is what I have learned:

- Create a new object (eISCP) and that object has several properties
- Some properties are static (IP:, Port:...)
- The rest are variable and hold the data sent back in the reply string
- Some properties are a string with length fixed by defining each character in the string as having a range of charaters - the expected characters will be in that range. Actually, must be in that range for the string.match() method. Q: Does it really matter to define the range of expected characters? I would think that a match to "any" four characters, in the HeaderSize for example, will still work too. I agree, though, that what you have done makes it very clear what's going on and what is expected.
- Create a regular expression that is the sum of all the characters and possible character place holders. I must admit that the notation for specifying this is not intuitively obvious to me.

Q: What's not clear to me also... after the v.match(), "x" is treated as an array() with ten addressable elements - e.g. x[8] is the eight property and represents the command we're interested in. Is this a function of the RegExp? I'm lost on this one.

All very nice, thank you for the education!

Matching the regular expression does this. It returns an array where [0] is the complete found string, [1] the first part (header). [2] the second (headersize) etc. The parts I'm talking about are between () in the regex. That's why I posted:


To explain this a bit further all I do is tell match to find a string that holds
ISCP\x??\x??\x??\x??\x??\x??\x??\x01\x00\x00\x00!????*\x1a\r\n
and split it into parts. [] tell the regex the range (like 0 to 9, A to Z or \x00 to \xFF). I've put the regex parts into variables so 1,4,5,6,7 and 10 could be used for the send function aswell, where 3 could be created from the length of 6+7+8 (+1 for the EOF char) and 2 could be created from the length of 1+2+3. 7 and 8 would be parameters of the function. Please note that the IP and Port are only there as static because it's a quick and dirty post. Normally this would be moved to a parameters page of the module in the GUI.

If you've got some patience you could use my finished library aswell.

sWORDs,

With regard to the RegExp.match() example provided earlier, do you not have to specify Global or Multi-line options to work with strings containing \r or \n?

I think not, because it just uses it as end character, it always contains a single line.

The reason that I asked that question was that I assumed you had buffer concatenation in place. I see now, you do not.

However, if as sogliphy has suggested, the packet is broken apart by the network and delivered in 2 pieces, the code below will lose a message as it is not concatenating read data onto the end of a buffer.

v = eISCP.Socket.read();
x = v.match(eISCP.RegEx);

What is said about message size is absolutely correct and possible lost data.

sWORDs rouine work perfectly for requesting and receiving status which are always 26 bytes and it still has never failed though, I suppose it could.

However, now that I have Pandora streaming the async data coming in is variable and totally unpredictable.

Off to write a buffer/parse routine for that...