Rule:
Value of response after rule execution is empty.
Running the HTTP call from Chrome has this result:
My understanding is that the variable should contain <Response Status="OK"/> or something similar.
Value of response after rule execution is empty.
1 Like
Check your hubitat logs - if there is any error in the GET, which could include timeouts as well as anything that is not an HTTP 200 response, then the rule will immediately stop. I don't know of any way to catch and act on an error.
Is this a Maker API instance on the same hub? If so, you may need to use the alternate port (8080), but more importantly, there isn't any reason to use Maker API from the hub to control a device on the same hub -- which I'm assuming you know and were maybe doing this just for testing.
Maker API is not involved. Simply a 'Set from HTTP GET Response'. The destination is a PC running a service. The port number is set by the service API and can not be changed. There are no errors in the logs. The call succeed to perform the desired action. I hope I have answered everyone's questions.
I wrote this post with the hope that there would be some sort of response from the HE team. Is getting this response not possible for HTML responses? Is this a known bug? Am I misinterpreting the purpose of the call?
I have asked this question before Need response from GET response with absolutely no response. I'm frustrated, what do I need to do to get some support.
I suppose @bravenel would be the one to ask what response types are expected to be stored in variables as a result of this RM HTTP GET action.
1 Like
The response data field is stored into a String variable.
So you are saying that RM is not receiving the response to store in the string variable? Are you arguing that the call I am making does not return a value? Is is possible that whatever code RM is dependent on is consuming the result without passing it on?
What ever is assigned to the variable is no longer editable in RM after the call.
I have always been curious is the fact that the response is HTML has any bearing on the trouble I am having.
Could it be that the server is returning JSON and not a plain text string? That could cause the value to be Null. I ran into the same issue when getting Tasker to access my presence. I had to parse the JSON to get the string for the field I was looking for. Even though there appears to be only one field in the response you showed on chrome, it is formatted like the JSON strings I was having issues with myself.
1 Like
Actually I have no idea what the response is in your situation. My reply above was to describe what RM does. httpGet returns an object, and the data field of that object is stored in the variable.
This is the relevant code:
String s
httpGet(http) { response -> s = response.data }
The string s is subsequently stored into the variable.
Show the value for a Setting from the rule's App Status page that begins with httperVar followed by a number. That should be the url you are hitting with the httpGet. That would have come from this input:
I have 1 for the commented out line in the rule and one for the Set from HTTP GET response. If I copy the URL over to chrome I get the expected response. So it appears the groovy call is to blame. It's been suggested I try webCore piston, apparently it works. I'll have to figure out how to write a piston to try it out.
Very clever, yes the JRiver instance is always up. I have no doubt that RM is returning what it is given. I question if the groovy HTTP call RM is using is not returning the value.
I am currently sending many kinds of commands. All are received and perform the correct actions. Reaching the instance does not appear to be the issue. Not surprisingly Hubitat Ping is working fine.
Current list of actions that all work. This set of commands work in 4 different zones.
Stop
Play/Pause
Next track
Previous track
Play one of 3 playlists
Shuffle playlist
All of these work excellently without needing feedback but there are more advanced functions I would like to do but they require getting data back. About timeouts, the responses back from JRiver are instantaneous as far as the eye can tell.
I will try thebearmay HTTP test and report back.
1 Like
Were this the case many things in the hub that are known to work would not work. I have no problem at all getting this to work, so I know for a fact that httpGet works as expected. But, I have no idea why this problem is showing up in your system, and know that it could be due to a number of things. Sorry I can't be of more help diagnosing the problem for you. Perhaps you could isolate further by hitting some other URL to convince yourself that it is not RM and httpGet, so at least you'd get one step closer to the source of the problem.
1 Like
This driver is expecting something other than plain HTTP, JSON?. I may be using the driver incorrectly. The logs show:
[debug]GET [uri:192.168.1.122:52199, contentType:String, requestContentType:/, headers:[:], body:/MCWS/v1/Playback/Stop?Zone=10000&ZoneType=ID]
The acceptable request is formatted as follows:
(http://192.168.1.122:52199/MCWS/v1/Playback/Stop?Zone=10000&ZoneType=ID)
I am able to hit my OpenWeatherMap URI and I do get the expected result in the return response.
The differences I see are OpenWeaterMap response is formatted using { } where as JRiver is formatted < />. It's this difference that I suspect. The OpenWeaterMap response is editable in RM but the JRiver response is doing something to RM in that RM is unable to edit the response. You can click on the variable value but nothing happens.
Just a thought. You can replicate the issue I am seeing by running your own copy of JRiver. It has a 30 day free trial. Of course with your busy schedule I understand that this may not happen right away. I can provide support for installation if required.
@bbholthome try:
Content Type: text/plain
Request Content Type: text/xml
and put the full path in the URI (not the body)
Ok I have proof that there is a response.
When I make a Stop request the response is a simple HTML attribute name/value. Name=Status, value=OK. Chrome shows:
Now if I make a request with a more complex response.
http://192.168.1.122:52199/MCWS/v1/Playback/Volume
Chrome responds with:
And RM shows:
Which is the values of "Level" and "Display".
@thebearmay tool shows this:
I don't know if there is anything that you can do about this but it does show the return value is being interpreted instead of being treated as a string.
try adding
textParser: false
into the headers block and see if that changes the response you get (I might need to code that if it doesn't work).
