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 126.96.36.199.
For reference, when checking from Chrome the response headers are as follows:
HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8
and the body is just
I have this same problem since I upgraded from 188.8.131.52 to 184.108.40.206. It used to work under 220.127.116.11 and previous. It stopped working under 18.104.22.168 and still fails under 22.214.171.124.
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 126.96.36.199 to 188.8.131.52. I run 184.108.40.206 now and it still doesn't work.
This problem is a bug. See Known Issues in Release 220.127.116.11 -- "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 18.104.22.168. 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].
Thanks, just stumbled upon this while trying to solve a similar issue.