[ST Edge] Web Requestor: a driver to issue local POST and GET HTTP requests

There is a type problem when this GET HTTP type is a string and even though the string is a number.
@TAustin can tell more about driver details.

Yes unfortunately right now the extracted value is always a string type. I will have to add a second number- type field for numeric values and then the automation would work.

I think this is important so will try to have it done within a few days. Thanks for bringing this up!

1 Like

That would be awesome. Thanks.

I wonder if something else needs updating to be able to use the value the way I want to.

In the IF section of a routine, if I select my web Req device it gives me these options…

And if I get extracted value I get this…

I think that means I can only search for an exact match. Not sure how I would set the routine to trigger if the value was LESS THAN a selected value.

Because that Extracted key value field is a string, all you can do is type in something that would be tested for a match.

Once I add a numeric field, it will allow you to not only provide a value to test for, but also ‘matches, equal or below, equal or above, range’ comparison options.

2 Likes

I’m converting the text result into a number in SharpTools using the round() expression. Having the result automatically in a numeric field would be great.

1 Like

Thanks, it works now :slight_smile: It was probably the driver version that was not up to date on my device.

I’ve got this done and am testing now. Should have it out soon.

There indeed was a problem with the json key parsing code in the driver. Have it fixed and testing now.

DRIVER UPDATE ALERT!

I have an update to the Web Requestor driver that addresses some requests and issues from recent posts. This update includes the following:

  • Fix to JSON key parsing to properly handle array within array; e.g. key of ‘values[0][0]’ when extracting a value from received JSON. Thanks to @Adam_Smith for reporting this
  • Addition of new NUMERIC field for extracted key value. This will allow for proper number value testing in automation routines. So there are now two extracted key value fields - one for string values, and one for numeric values. Note that you will have to create a new device to get the new field. Existing devices continue to work as before. Thanks to @Gavacac and @TapioX for highlighting this need.
  • Ability to display the extracted string or numeric value on the dashboard (@Adam_Smith). This is configured in device Settings. This option will only appear for newly created devices.

One thing to note about switching dashboard state display options: I’ve noticed with the latest app (iOS) that it can take time for the dashboard display to start showing the new value, so be patient. It may require both time and a restarting of the SmartThings app. Android users might see better response.


Updated Driver Version: 2023-01-16T18:28:28.199004731

3 Likes

The app I’m trying to interface with uses PUT requests. Would this tool work for such scenarios? Thank you.

Yes, PUT is supported.

1 Like

Thanks! I just tried it out with a status GET first and it worked only once. Most of the time it failed after a while with: A network or server error occurred. Try again later.

Am i doing something wrong? The same GET works fine 100% from a laptop on the same LAN.

Cheers.

UPDATE: looks like the GET is starting to become reliable now. Perhaps i just need to wait a bit for some config to propagate.

The PUT however does not seem to have any effect. Testing using the driver returned 400. I did a curl from my Mac and it worked though.

These are SmartThings app issues, unfortunately. Keep it open for a while and retry. Otherwise close and try again later. Just be sure to give it lots of time to update all your devices.

These issues are typically worse for a new device, so give it some time and things should improve.

Yeah GET works 100% reliably now!
Sadly the PUTs remain completely broken. I now always get 400 status back.

Note that I’m not able to test custom URL in a routine since it only supports GET and POST there…

For your reference I used slot 9 with this string:
PUT:http://192.168.0.127:3689/api/player/play

Using curl -X PUT on this URL works reliably…

Any suggestion on how to diagnose? Thanks.

@TAustin
good job
It works perfectly. Now I can send the status of the motion sensors to hubitat
But after a day I started to face a slight problem
Every time I search for a new device, a new master device is created
Is there a solution to this problem

What are you configuring for the body? A PUT is nearly always going to require one.

No body is required for the request. This is the API doc JSON API - OwnTone

I’m using the player/play which takes no other parameters. They are curl examples in that doc.

Well that is because I’m an idiot :slight_smile: This was my fault and it will be fixed when your hub receives the update.

No, this is a great job
We are waiting for your update

Very strange. You are certain there are no extraneous spaces at the end of your configured HTTP request?

I wonder also if you are experiencing the infamous chunking issue with the Lua HTTP library, which tends to send HTTP requests in multiple chunks. Most servers don’t have a problem with that, but I’ve found that some IOT devices do. I’ve made SmartThings staff aware of the issue. (BTW, curl sends the entire request in ONE ‘chunk’, as does Postman and other tools).

If you are willing to experiment, I have an alternate driver you can try that does not use the stock Lua HTTP library. It is called HTTP Devices Alt V1 and is available from my alternate test channel here. This driver is a different design from web requestor. The HTTP Devices driver allows you to create individual type-specific devices and can be configured to send specific HTTP requests when device controls are invoked.

To get it installed, once you enroll in the channel, select the HTTP Devices Alt V1 driver to install to your hub. Then when it is installed, the next time you do an Add device / Scan for nearby devices, a new device will be created called HTTP Alt Device Creator V1. Open this device to its Controls screen and use the button there to create a device type of your choosing. For this test, I’d recommend using the Momentary Button. Once that device is created, go into its device Settings screen and and configure your HTTP request (just like in web requestor, except here there are not multiple slots, just one which is used when the button is pressed). See if you have any different results with this. If it works, then we’ve confirmed your device doesn’t like the chunking of the Lua HTTP library.