Thanks. I’ll continue to investigate as well.
@TAustin I have at least resolved this 401 issue with Web Req. The CLI logs showed that the key was not being sent even though present in the Web Req device settings. In settings I deleted a character, saved, then added the char back and saved again then the driver sent the key okay and all worked. So something certainly wonky there but I can get it to work.
Again, that’s the Web Req issue. The issue with HTTP Devices remains and the same trick doesn’t help there. But the difference of course is that the key IS being sent already by the driver (per logs).
I have seen this happen as well. There is a bug in the app where sometimes you edit settings, but they don’t actually get updated. And you have to do what you did - modify it again - in order to get the change to “take”. Unfortunately it’s nothing I can fix in the driver - it’s a SmartThings issue. (@nayelyz FYA)
The problem you were having with the HTTP Devices driver was due to a problem parsing header values that contain ‘=’ characters, which you said were in your bearer token. So I’ve tweaked the code to hopefully fix this problem and have pushed an update out to the channel (Driver Version 2024-02-22T18:03:47.75791669).
One other thing that you might want to do is add “Content-Type=application/json” to your headers (prior to your Authorization header; separate the two with a comma), since you are sending a json-formatted body. Devices are sometimes fussy about this and may not accept the message without it. However if you’re not using it with Webrequestor and it’s working, you evidently don’t need it.
I had a feeling, thank you.
Great, I will update and try again. Thanks!
Yeah I had thought about that but the field is not large enough to take it with such a large token. I know the two body fields concatenate but there’s only the one header field obviously. Thankfully it works without right now.
Working perfect now. Thanks again.
Hi, @TAustin
As I understand this issue doesn’t happen all the time, right? Have you noticed any patterns that could help us replicate the issue? I’ll make some tests to see if it happens to me as well.
Only on occasion, and it seems to be fairly random. It MAY tend to happen if you swap out and back into the app and change settings before the app has fully refreshed itself. I’m on iOS.
Hello,
I am a very novice on webhook. The only webhook I used was from IFTTT to trigger certain devices from my pebble watch. Recently, IFTTT does not provide webhook for the free tier. I already installed this web requestor on my smartthings, and I can see the device. But I don’t have any idea after that. The URL is the internal ip address of my smartthings? and how can I control on off of the device? I read pretty much all the postings here, but I could not find the answer for my question. Thank you very much for your help!
HI TA,
My home has a Vantage Infusion system that operates most devices in the house. I added ST devices because they were less expensive and I could do it myself. So I created a locally hosted WebAPI that forwards POST requests to the Vantage system. This allowed me to control the Vantage system from the SmartThings mobile app. That required that I develop Groovy device handlers which are now dead. I’m trying to use Web Requestor to replace the old Groovy integration.
I want to use a Custom HTTP POST but I can’t seem to make it work with body data. The request looks like this but I can’t get it to work.
http://192.168.1.20/InfusionIF/api/Commands/LoadLevel/90, {“VID”:90,“Level”:100}
I downloaded your simple server and redirected the request. I also sent a working request from Postman to your simple server. From postman, it seems to know the difference between the URL and the body data. When I use the string above in the mobile app, your simple server outputs a different response.
Here is the response using the mobile app:
Here is the response when I send using Postman where I can configure the raw body parameter.
Also, when I redirect that request from Postman to my WebAPI, it works - turns on the study light to 100%.
I don’t have the Web Requestor installed at the moment but I see the following:
- You used
POSTin the app/driver test andPUTin the Postman one. - There are ‘smart quotes’ in the JSON in the app/driver test rather than standard double quotes.
- The app/driver test has clearly included the JSON body as part of the URL in the request and it has got a bit mangled by the URLencoding. Did the driver do that or did you include it after a comma and spaces in the URL rather than separately as the body?
- The Postman test correctly separates the URL
http://192.168.1.20/InfusionIF/api/Commands/LoadLevel/90from the body{"VID":90, "Level":100}and doesn’t have any stray smart quotes.
- The API accepts both PUT and POST.
- I am using the only text editor available in the WebRequestor app on the phone. I assume I cannot use double quotes inside of other double quotes. There is no other way to enter the quotes on an iPhone.
- Again, this isn’t an option in the WebRequestor app and that’s why I submitted the question. I am following the instructions as I understand them.
- If you can figure out how to separate them from within WebRequestor, I’d love to know.
Hi @TAustin,
I just found your HTTPDevices Edge Driver and it looks more appropriate for my needs. I’ll start working with that one. On first glance, it looks good. I would like to see an other device that is a light - not with color or all the other features of a standard light, but all my Vantage system lights (loads) have ON, OFF, LEVEL settings in a single device.
I also notice that They do not receive HTTP requests from external sources - something I need. Before ST Switched to the Edge drivers, I developed a bunch of custom code so that my virtual ST devices talked in both directions. I created a listener program that captured events from my Vantage system and forwarded them to my device handlers. If someone used a Vantage button to change the state of a device, ST would get the update and make that change to the device in the ST hub.
I’m trying to figure out how to re-program this feature or create a new ST Edge device specifically for my Vantage system but I’m struggling to understand the new development environment and where to start.
If you have any suggestions, I will be very grateful.
In the old architecture, the DTHs and SmartApps were Groovy based code that ran in the ST Cloud. With the transition to the Edge architecture, DTHs were converted to Lua-based Edge drivers that run locally on a user’s hub. However, for SmartApps, there is no local equivalent and no way to run a program or service on a hub. The expectation in the new architecture is that developers will host their own applications and that those applications can be invoked through webhooks or AWS Lambda. To affect change to devices or virtual devices, the applications must call the ST API in the same manner that the mobile app or the ST web apps call the API.
So, your options are 1) develop an application that can run on computer on your local network and have that application interact with the ST API; or 2) host an application in another location (say AWS or Azure) and have the application interact with the ST API. Here is a link to the documentation on developing SmartApps.
Thanks @h0ckeysk8er,
That gives me a better understanding how/why my original integration stopped working - no place to run my SmartApp. My original integration was part DTH and part Groovy SmartApp. The smart app handled passing data back and forth from the virtual devices I created from a custom DTH and the Vantage system - in both directions. I created on Web API for commanding Vantage and I created another listener app the responded to events triggered Vantage events like someone turning on/off a light from a Vantage keypad.
I was looking at the MQTT [ST Edge] drivers created by @TAutsin and it seems that may be an option. I would have to modify my Web API and Listener programs to work with an MQTT broker. My listener would be an MQTT publisher and my Web API would become an MQTT subscriber - assuming that those drivers can function in both directions - send ST commands as MQTT messages and receive MQTT messages to update the status of a device. Otherise, I would probably choose your option 1) to have my applications interact with the ST API.
Any thoughts on which of these two options would be easier to learn and implement?
- Integrated MQTT into my locally running apps
- Integrate ST API calls into my locally running apps
Thanks again for your feedback.
I’m not well versed enough to say which would be easier, but I’d hazard a guess that if you are doing just a few basic things that need to issue commands to the ST API, a self-hosted app would require less work than integrating with MQTT. I’ll leave it to folks like @TAustin and @orangebucket who spend more time with app development to comment further.
I worked with the ST API but I could not find a way to update the status of a device from the API. I was able to command a device, read from devices but unable to change it’s state. So I switched to @TAustin MQTTDevices, installed a simple MQTT broker on my Windows PC and had a switch working in both directions pretty quickly.
@TAustin, I’d like to see your MQTT Dimmer present on the dashboard the same as your HTTP Dimmer with the on/off button right there.
Hi @TAustin, I was testing this situation but as you mentioned it is fairly random, I was able to observe it sometimes but when I tried to see the mobile I wasn’t able to reproduce it.
Based on my test I believe that is related to network problems, the hub that I use to test sometimes is on a very unstable network, and at these times is more common to see it.
Ok, thanks for the follow-up.
MQTT is a good way to go since you needed the two-way updating.
I’ll take a look at adding the switch to the dashboard for the MQTT dimmer. Simple to do; just need to find time to do it!
Thanks. I just got it all working. I use it now to integrated ST with my old Vantage Infusion home lighting system. I developed a new console app that replaces an HTTP REST Web API and a Windows Service application that handed the full integration on the old ST platform.
The MQTTDevices driver worked beautifully for full two-way updating. Installing and configuring Mosquitto was easy. The CLI tools made development and debugging very easy and the MQTT messaging was simple to program (in VB.Net).
Thanks for great driver.
BTW: If you get around to updating the dimmer, does it automatically show up in the app or do I need to do an update on your driver page?