We have gone through multiple tests including running a 66 line stripped down version that generates the exact same error which leads me to believe it's a platform issue.
As the error indicates, the problem arises in the parse() function. The LAN device is sending a simple text string of about 50 characters. A simple log command as the first line of the parse function never executes, so I believe the platform errors before the data is actually handed to the parse() function of the driver.
The user in question has tried multiple LAN devices and gets the same result each time. His hub version is 2.3.2.135. He has no installed libraries.
So the question is, what could introduce a unique element onto his hub that would cause the parse() function to misfire when it runs perfectly for everyone else?
FYI. If I search for "line 855" there are 9 other threads containing this but none indicate what the underlying problem was.
If you can, try outputting the data into another place like a local file, or call the API through another method like Postman to look at the results. The only reason I suggest this is I believe some aspects of the json may be stripped out during the logging process
Alternatively you try some string replacement when logging the json
I've not heard of postman so thanks for the pointer. Does that let you look at the HTTP headers? Even with a payload of "Message" he still gets the same error.
But in this case I don't think it would help debug, because there is an issue with the response from your remote client. The single quotes in the response are not valid JSON, and something is trying to parse the response as JSON.
Do you have control over the response from the remote client? What does a raw string print of the response look like on systems that are behaving correctly?
We may actually have been talking about different things, both of which are potentially useful here.
I thought you were suggesting to use @garyjmilne's Hubitat code to talk to postman-echo, which is useful for echoing back the entire request. I use it often to check if headers and data were as I expected (usually because something isn't working...).
The Postman application that you mention is also great, because you can quickly construct requests and see replies from the actual remote server you're targeting, before you get deep into a full Hubitat implementation. If I thought everything was set up correctly but that something specific to Hubitat was choking on the response, the Postman application would be my first stop.
Yes, I do have control. This is an example of what I'm sending from Tasmota:
WebQuery http://192.168.0.200:39501 POST {Message}
This is what I'm getting in parse() from:
log.debug ("data is ${LanMessage}")
def msg = parseLanMessage(LanMessage)
def body = msg.body
log.debug ("body is ${body}")
Log Output.
parse: data is mac:DC4F22F35C73, ip:c0a80070, port:e6f9, headers:UE9TVCAvIEhUVFAvMS4xDQpVc2VyLUFnZW50OiBFU1A4MjY2SFRUUENsaWVudA0KQ29ubmVjdGlvbjoga2VlcC1hbGl2ZQ0KSG9zdDogMTkyLjE2OC4wLjIwMDozOTUwMQ0KQWNjZXB0LUVuY29kaW5nOiBpZGVudGl0eTtxPTEsY2h1bmtlZDtxPTAuMSwqO3E9MA0KQ29udGVudC1MZW5ndGg6IDkNCg==, body:e01lc3NhZ2V9
But this same command generates the error on this person's system so unfortunately I can't easily get a hold of the header data. And he has tried it from two devices.
As it turned out the user had two devices with the same IP address. So, the data that was sent to the parse function was actually going to the parse() function of the other device and that was where the error was coming from.
Seems obvious now, but isn’t that always the case in hindsight.
