I have a rule that periodically checks the health of another device. It sends an HTTP GET and expects a response of "ok". The Rule lists as Set aliveResult from GET response: http://%AutomatorIP%:3092/checkAlive where aliveResult is a Hub Variable of type String, and AutomatorIP is the device I'm checking (confirmed to be correct). Instead of the String value of the response, aliveResult gets set to something like java.io.StringReader@56e720, which I presume is the value of the StringReader.toString() rather than actually reading it.
This has only been an issue for the past few weeks (likely since 2.3.6). I'm currently on 2.3.6.144.
For reference, when checking from Chrome the response headers are as follows:
HTTP/1.1 200 OK
Content-Length: 2
Content-Type: text/plain; charset=UTF-8
Connection: keep-alive
and the body is just ok.
1 Like
I have this same problem since I upgraded from 2.3.5.152 to 2.3.6.136. It used to work under 2.3.5.152 and previous. It stopped working under 2.3.6.136 and still fails under 2.3.6.144.
I just created a test Rule-5.1 that assigns the result of an HTTP GET to a local string variable. The incorrect string returned into the variable is always some variation of java.io.StringReader@49b574, where the hex number after the at-sign changes every time I run the rule. I no longer get the result of the HTTP GET request.
It used to work fine before I upgraded from 2.3.5.152 to 2.3.6.136. I run 2.3.6.144 now and it still doesn't work.
This problem is a bug. See Known Issues in Release 2.3.6.144 -- "Set String variable from httpGet returns response data field, and sometimes response data.text field is required instead."
They created a work-around for this bug in 2.3.5.145. You have to go back to all your rules and change the HTTP GET response operation to use the new HTTP GET response data.text operation. The resulting action will appear as Set <variable> from GET response datat.text [sic].
1 Like
Thanks, just stumbled upon this while trying to solve a similar issue.
