RUSSOUND SMS3 Protocol Help
rolo
Posts: 51
I ahve to code one of these soon - the russound Media Server...I dont understand what to do with this protocol as it appears to be XML based.
Help Please...maybe some sample strings....thanks guys
Below Are linx to protocol
Thanx
Rolo
http://www.harmonysoundandvision.com/Russound%20SMS3%20RS-232%20Commands.htm
http://www.harmonysoundandvision.com/Russound%20SMS3%20RS-232%20Protocol.htm
http://www.harmonysoundandvision.com/Russound%20SMS3%20RS-232%20Queries.htm
Help Please...maybe some sample strings....thanks guys
Below Are linx to protocol
Thanx
Rolo
http://www.harmonysoundandvision.com/Russound%20SMS3%20RS-232%20Commands.htm
http://www.harmonysoundandvision.com/Russound%20SMS3%20RS-232%20Protocol.htm
http://www.harmonysoundandvision.com/Russound%20SMS3%20RS-232%20Queries.htm
0
Comments
But otherwise, the syntax for what you're sending isn't difficult - don't be intimidated by the label of "XML"...
Each example they show in the protocol can simply be sent with SEND_STRING commands in sequence, so their "stream 1, nextsong" would look like this:
Technically, if they're processing your XML-formatted commands properly, you don't need to put a $0D,$0A at the end of each line, but their comments on the end of message character seems to indicate that you should use them.
Parsing responses doesn't initially appear too difficult, as you're getting something like this in your buffer:
I >assume< each line in a response will have a carriage return, linefeed, or both at the end, although there's no guarantee. You'll either have to try it for yourself, or ask Russound T.S. If each line has a delimiter, you can pretty easily take an instance of:
and pretty easilly determine that that should go into a variable called (something along the lines of) "Title". If there's no delimiter, then you need to write some code that uses a lot of FIND_STRINGS for the tags and the "<" and ">" characters to pick stuff apart. Time consuming to write, but really not >that< scary.
It looks like each <info> block starts with the stream number, so if you're dealing with the possibility of 2 or 3 streams, your parsing code can easilly keep track of which stream data is currently coming in by setting a flag any time it sees the <stream>x</stream> tags. I believe you can safely assume that any data that comes in is associated with the most recently reported stream.
Kinda looks like fun to work with - wish I had one!
- Chip
Rolo,
Did you get this working? I've got to develop a module for one of these as well. Curious to learn how well the controls worked out for you.
TIA.
Sheldon Samuels
IPS Resources LLC
So here's some old code that if I had to do it again, I'd probably rewrite. Since I'll probably never use the SMS3 - someone do let me know if this works (even partially.)
Snippet of attached code:
Variables are explained in code.
Then once you have a complete file commence parsing. If the xml file is real long then I would probably pick at it by looking for individual tags like </Theme>, </Genre>, etc using a select active or switch case to list all possibities. But if your picking it a part I would remove and pass just that part of the received buffer string that's is prior to and including the find_string 'string' to the parsing function.
The main thing is starting with complete file or portion of file then it's just parsing for what you want.
CHAR sBuffer[1024]
CHAR sChunk[1024]
CHAR sData[1024]
sChunk = REMOVE_STRING(sBuffer, "'>'",1)
So lets say you get a string like this:
sChunk = <Title>Heart And Soul</Title>
Your first REMOVE_STRING with "'>'" as an argument is going to give you "<Title>." There is no /, so you can store <Title> as your current tag type. The next REMOVE_STRING will net "Heart And Soul</Title>." Since you can find a / in there, you know the tag was closed, so you can do a subsequent:
sData = REMOVE_STRING(sChunk, "'<'", 1) and sData will be "Heart And Soul<". Drop the < off the end, and store it; you've processed that tag.
I've found in many cases, it's easier to just throw away the opening tag. When you detect a closing tag and break away the data, what's left will identify the type of tag it was, and you don't have to fuss over where the tag was - unless, of course, your XML format duplicates certain types of data tag names and you need a context from an enclosing tag. Much depends on the format of the XML.
You need to know what you're parsing - as in which element you want. You just can't parse blindly and say an end delimeter is ">" because that could be either the closing sign for the opening element tag, or the closing of the closing element tag.
Is there a faster way to parse an element with three REMOVE_STRING commands?