parseLanMessage() issue extracting body text/xml

Running into issues getting body text from HubAction response…

Here is the response (description):
mac:123456789091, ip:0a0001f0, port:c001, headers:SFRUUC8xLjEgMjAwIE9LCkNPTlRFTlQtTEVOR1RIOiAzNzYKQ09OVEVOVC1UWVBFOiB0ZXh0L3htbDsgY2hhcnNldD0idXRmLTgiCkRBVEU6IFN1biwgMTEgTWFyIDIwMTggMTY6NTg6MjcgR01UCkVYVDogClNFUlZFUjogVW5zcGVjaWZpZWQsIFVQblAvMS4wLCBVbnNwZWNpZmllZApYLVVzZXItQWdlbnQ6IHJlZHNvbmljCg==, body:PHM6RW52ZWxvcGUgeG1sbnM6cz0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9lbnZlbG9wZS8iIHM6ZW5jb2RpbmdTdHlsZT0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9lbmNvZGluZy8iPjxzOkJvZHk+Cjx1OlNldEJpbmFyeVN0YXRlUmVzcG9uc2UgeG1sbnM6dT0idXJuOkJlbGtpbjpzZXJ2aWNlOmJhc2ljZXZlbnQ6MSI+DQo8QmluYXJ5U3RhdGU+MDwvQmluYXJ5U3RhdGU+DQo8Q291bnRkb3duRW5kVGltZT4wPC9Db3VudGRvd25FbmRUaW1lPg0KPGRldmljZUN1cnJlbnRUaW1lPjE1MjA3ODc1MDc8L2RldmljZUN1cnJlbnRUaW1lPg0KPC91OlNldEJpbmFyeVN0YXRlUmVzcG9uc2U+DQo8L3M6Qm9keT4gPC9zOkVudmVsb3BlPg==

def msg = parseLanMessage(description)

and here is the result of parsing:
[mac: 123456789091, ip:0a0001f0, port:c001, headers:[HTTP/1.1 200 OK:null, CONTENT-LENGTH:376, CONTENT-TYPE:text/xml; charset="utf-8", DATE:Sun, 11 Mar 2018 16, EXT:, SERVER:Unspecified, UPnP/1.0, Unspecified, X-User-Agent:redsonic], body: 0 0 1520787507 , header:HTTP/1.1 200 OK CONTENT-LENGTH: 376 CONTENT-TYPE: text/xml; charset="utf-8" DATE: Sun, 11 Mar 2018 16:58:27 GMT EXT: SERVER: Unspecified, UPnP/1.0, Unspecified X-User-Agent: redsonic , status:200]

Extracting the header detail works but the body is incorrect.
body: 0 0 1520787507

decodes to:

Tried using decode on the base64 response but doesn’t translate correctly. How do I extract the body text correctly either prior or post the parseLanMessage output?

Specifically, the original (unparsed response - description) body: base64 value is what I am after as that translates correctly to the appropriate XML response…

<s:Envelope xmlns:s="" s:encodingStyle=""><s:Body>
<u:SetBinaryStateResponse xmlns:u="urn:Belkin:service:basicevent:1">
</s:Body> </s:Envelope>

But haven’t been able to get to that via groovy code in habitat where the content-type is text/xml. Any insights on what I am missing or a simple way of doing something like:

Does not find a property ‘body’ of description…

The body is being parsed fine, its the display of the output on the logger page this is the problem. there is a bug which doesn’t display xml properly on the logging page. Which I made reference to in your other thread here: Hubitat.device.HubSoapAction

Unfortunately we do not parse out the xml yet in theparseLanMessage, but you should be able to parse it yourself from the String that is body. I’d recommend using one of these 2 classes:

Thanks @chuck.schwer - I backed into the same conclusion as well by manually extracting the encoded text via regex:

def m = description =~ "body:(.*),?"
def bodyS = new String(m[0][1].decodeBase64(), 'UTF-8')
logger("bodyS: ${bodyS}", "debug")

The results in the log are the same:
debugbodyS: 1 0 1520791238

I will try leveraging the XML utils to parse and ignore the log issue. Any ideas when this will be addressed or ways to work around to know that the code is functioning properly? Am I just missing something on how to develop against Hubitat or am I really just limited to trial and error and parsing log output?

btw… do you have a fully functioning Wemo device driver that maintains state? I’ve got the dimmer responding to commands and working on the subscriptions and state management now.

give this a shot for logging the body for now:

def msg = parseLanMessage(description)
log.debug groovy.xml.XmlUtil.escapeXml(msg.body)


Perfect - thank you!

@Hubitat1 - Ive been working on transferring a few of my device handlers over from ST to HE and encountered one missing feature here (well this is a semi related topic and I dont have permission to post a new thread yet!).

In ST you can use encodeAsBase64 and decodeAsBase64 but in HE you have decodeBase64 (I havent yet checked encodeBase64). Totally minor thing to either add a definition which mirrors the existing function, or add it to the instructions for transferring device types over from ST.