I seem to be getting a result: dev:402021-11-11 20:31:08.436 debugresponse content type is Content-Type: application/json dev:402021-11-11 20:31:08.432 debugResponse.data: {"wifi_ssid":"Berg-WiFi","wifi_strength":88,"total_power_import_t1_kwh":1.273,"total_power_export_t1_kwh":0,"active_power_w":0.265,"active_power_l1_w":0.265} dev:402021-11-11 20:31:08.375 debuggetting Basic device information
But how do I get the long return {"wifi_ssid":"Berg-WiFi","wifi_strength":88,"total_power_import_t1_kwh":1.273,"total_power_export_t1_kwh":0,"active_power_w":0.265,"active_power_l1_w":0.265} into seperate attributes, with there headers?
Not refrencable I'm afaid: groovy.lang.MissingPropertyException: No such property: wifi_ssid for class: java.io.StringReader on line 40 (method getBasicInfo)
Getting a java error on that one:
org.codehaus.groovy.runtime.metaclass.MissingMethodExceptionNoStack: No signature of method: user_driver_Fan_HomeWizard_Power_Socket_509.jSlurp() is applicable for argument types: () values: []
Possible solutions: sleep(long), sleep(long, groovy.lang.Closure), dump(), run(), run(), run(java.io.File, [Ljava.lang.String;) (method jSlurp)
While JsonSlurper should also work, Hubitat has a built in parseJson() method that looks like it should also get you there: Common Methods Object - Hubitat Documentation. (OK, that docs link won't help much--only the signature is there, and it returns an Object, but in my experience this is either a Map or a List, depending on the format of the original JSON. Probably a wrapper around the JsonSluper.parseText() method?).
Also, if there's any way you can make that HTTP call asynchronous, that is generally the recommended way: Async HTTP calls. It shouldn't be an issue either way, but unless you absolutely need the synchronous behavior, users seem to report fewer issues (resource usage, etc.?) with the async approach.
The text parser comes in handy when parsing straight text, like XML or HTML, but for JSON the built in stuff can parse it for you, or the other options mentioned here are also valid as well.
Your example code, converted, I believe. The biggest mistake I've made in doing these conversions is assuming (resp, data) only to quickly learn the original code used "response", ie. response.data or response.header, etc.