If you could that would be great.
My challenge is that in routines you can’t turn on a dimmer for a specific amount of time. But you can if there is also an on/off switch.
I’ve got a work around involving a virtual switch but it’s clunky.
If you could that would be great.
My challenge is that in routines you can’t turn on a dimmer for a specific amount of time. But you can if there is also an on/off switch.
I’ve got a work around involving a virtual switch but it’s clunky.
Just to say thank you, I now have my amp control working with a series of commands using Rules.
I coded the requests into the rule itself because as you guessed the Yamaha API calls are POST requests that just have PUT in the tag for some reason.
Thanks for this.
For others that might have Yamaha amps, it would be nice for you to publish the rules you created in a separate thread noting the model number(s) that they would work with.
Is it possible to include actual smartthings variables in the body (such as the devices status, temperature, etc)
Without webcore, there is no longer anything like variables available. You can accomplish some level of mirroring of device attributes using Rules.
If you want to send HTTP messages with specific device values, then have a look at my HTTP Devices driver. I’ll be adding more device types like temperature in about a week, and you’d be able to use a Rule to set values based on another device, and have the value sent in an HTTP message.
If you have a computer on your LAN that is always on, probably a better approach is to use the SmartThings RESTful API to grab the values on some periodic basis and then send them where you need to. It would take a very little bit of Python or nodeJS script to do.
Hey we do now have variables in SmartThings actually, take a look at @Mariano_Colmenarejo’s Aplicaciones Virtuales driver…
Okay, at risk of looking dumb in front of everyone and embarrassing myself, I have a stupid question. I am sure it must be something simple, so please go easy on me as I am just a novice trying to move everything over from webcore to keep SmartThings limping along.
It seems that others may have figured this out, but I have been trying to get it going for the past few days. I am trying to control the lights and sirens on my ip cameras, but am having trouble with the login and password required for all my cameras.
From a web browser, the following commands work just fine:
Reading through the other posts here, I took note of the fact that “login:password@ip:port” won’t work, and that others had found success with using “Authorization=Basic bG9naW46cGFzc3dvcmQ=” in the headers field.
Basic authorization works (HTTP Response Code 200) if I shorten my address to just the ip and port (http://192.168.1.100:80), but if I add the rest of the url, or any other working destination on a browser, Web Requestor gives me HTTP Response Code 401.
Wondering if I should be including something different/more in the headers field, or if I somehow need to divide up the url and send it in chunks.
I downloaded the CLI and pulled logs (this is for the Light on command):
2023-02-16T01:42:30.742862751+00:00 TRACE Web Requestor Multi v1.2 Received event with handler capability
2023-02-16T01:42:30.750685168+00:00 INFO Web Requestor Multi v1.2 <Device: [my device id] (Web Req Multi Master)> received command: {“args”:{“value”:“1”},“capability”:“partyvoice23922.webrequestselect”,“command”:“setSelection”,“component”:“main”,“positional_args”:[“1”]}
2023-02-16T01:42:30.756605751+00:00 TRACE Web Requestor Multi v1.2 Found CapabilityCommandDispatcher handler in webreqDriver
2023-02-16T01:42:30.757349335+00:00 DEBUG Web Requestor Multi v1.2 Web request selection = setSelection 1
2023-02-16T01:42:30.758022543+00:00 INFO Web Requestor Multi v1.2 <Device: [my device id] (Web Req Multi Master)> emitting event: {“attribute_id”:“selection”,“capability_id”:“partyvoice23922.webrequestselect”,“component_id”:“main”,“state”:{“value”:“1”}}
2023-02-16T01:42:30.761320960+00:00 INFO Web Requestor Multi v1.2 SEND GET COMMAND: http://192.168.1.100:80/cgi-bin/coaxialControlIO.cgi?action=control&channel=8&info[0].Type=1&info[0].IO=1
2023-02-16T01:42:30.761933085+00:00 INFO Web Requestor Multi v1.2 with body: nil
2023-02-16T01:42:30.762825126+00:00 INFO Web Requestor Multi v1.2 with headers: Authorization=Basic bG9naW46cGFzc3dvcmQ=
2023-02-16T01:42:30.769476376+00:00 DEBUG Web Requestor Multi v1.2 Web Req Multi Master device thread event handled
2023-02-16T01:42:30.771547168+00:00 DEBUG Web Requestor Multi v1.2 driver device thread event handled
2023-02-16T01:42:30.820824376+00:00 INFO Web Requestor Multi v1.2 response code=<401>, status=<HTTP/1.1 401 Unauthorized>
2023-02-16T01:42:30.826406460+00:00 INFO Web Requestor Multi v1.2 <Device: [my device id] (Web Req Multi Master)> emitting event: {“attribute_id”:“httpcode”,“capability_id”:“partyvoice23922.httpcode”,“component_id”:“main”,“state”:{“value”:“401”}}
2023-02-16T01:42:30.830767501+00:00 WARN Web Requestor Multi v1.2 HTTP GET request to http://192.168.1.100:80/cgi-bin/coaxialControlIO.cgi?action=control&channel=8&info[0].Type=1&info[0].IO=1 failed with http code 401, status: HTTP/1.1 401 Unauthorized
2023-02-16T01:42:30.835818543+00:00 INFO Web Requestor Multi v1.2 <Device: [my device id] (Web Req Multi Master)> emitting event: {“attribute_id”:“response”,“capability_id”:“partyvoice23922.httpresponse”,“component_id”:“main”,“state”:{“value”:“–”},“visibility”:{“displayed”:false}}
2023-02-16T01:42:30.841853460+00:00 INFO Web Requestor Multi v1.2 <Device: [my device id] (Web Req Multi Master)> emitting event: {“attribute_id”:“keyvalue”,“capability_id”:“partyvoice23922.keyvalue2”,“component_id”:“main”,“state”:{“value”:“–”},“visibility”:{“displayed”:false}}
2023-02-16T01:42:30.850137960+00:00 INFO Web Requestor Multi v1.2 <Device: [my device id] (Web Req Multi Master)> emitting event: {“attribute_id”:“keynumvalue”,“capability_id”:“partyvoice23922.keynumvalue”,“component_id”:“main”,“state”:{“value”:-999},“visibility”:{“displayed”:false}}
2023-02-16T01:42:30.857481043+00:00 DEBUG Web Requestor Multi v1.2 Web Req Multi Master device thread event handled
2023-02-16T01:42:35.779228209+00:00 INFO Web Requestor Multi v1.2 <Device: [my device id] (Web Req Multi Master)> emitting event: {“attribute_id”:“selection”,“capability_id”:“partyvoice23922.webrequestselect”,“component_id”:“main”,“state”:{“value”:" "},“state_change”:true,“visibility”:{“displayed”:false}}
2023-02-16T01:42:35.780223750+00:00 DEBUG Web Requestor Multi v1.2 driver device thread event handled
Humbled for any pointers you all may have for me.
Hi there.
Are you saying that in this case you are including this in the header?:
Authorization=Basic bG9naW46cGFzc3dvcmQ=
Where did you get the authorization key to use here?
Thanks @TAustin,
Yes, this is an example of what I have in the header:
Authorization=Basic bG9naW46cGFzc3dvcmQ=
“bG9naW46cGFzc3dvcmQ=” is “login:password” encoded via base64encode.org. This is just an example/placeholder for use in this forum post, in my case I am using my actual login and password for my cameras encoded via base64encode.org.
Edit: I should have mentioned that my login and password do not have any special characters, just letters and numbers encoded to base64.
If you computed the key yourself, you might try issuing the exact same URL (with the login:password@ prefix) in a browser, and use the browser’s developer tools to inspect what Authorization header was sent. That would give you a way to sanity check the key. Not that I doubt your work
EDIT: you should also verify that Basic authentication is in fact being used. You’ll be able to tell by looking at the WWW-Authenticate header on the 401 return.
Thanks for sticking with me. Using Chrome’s developer tools, I am not sure what I am looking at or should be looking for. I don’t see the base64 converted key to sanity check:
General
Request URL: http://login:password@192.168.1.100:80/cgi-bin/coaxialControlIO.cgi?action=control&channel=8&info[0].Type=1&info[0].IO=1
Request Method: GET
Status Code: 200 OK
Remote Address: 192.168.1.100:80
Referrer Policy: strict-origin-when-cross-origin
Response Headers
CONNECTION: close
CONTENT-LENGTH: 4
Content-type: text/plain;charset=utf-8
Request Headers
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cache-Control: max-age=0
Connection: keep-alive
DNT: 1
Host: 192.168.1.100:80
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36
Is there no 401 error return and then a retry?
Try it also without providing the userid & pw. You should get a popup window asking for your credentials if the camera is asking for them.
You may also need to reset the connection to the camera; you’re probably already logged in through your browser as far as the camera is concerned.
Thanks,
When I hit it again (without the login:password@ prefix) in Chrome and entered the login and password in the pop-up dialog, I get:
Authorization: Digest username=“login”, realm=“Login to XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX”, nonce=“XXXXXXXXX”, uri=“/cgi-bin/coaxialControlIO.cgi?action=control&channel=8&info[0].Type=1&info[0].IO=1”, response=“XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX”, opaque=“XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX”, qop=auth, nc=00000002, cnonce=“XXXXXXXXXXXXXXXX”
I masked the numbers, since I have no idea what might be sensitive.
This makes me think it is using Basic for the main ip:port, but Digest for any sub urls.
Yup. You won’t be able to do what you want to; Digest authentication can’t be done through webrequestor. This is something I’d have to look at adding in the future.
Thanks for your hard work on all of these great tools, they have saved my bacon several times and kept me out of trouble with the wife lately as I make the transition.
I apologize for taking your time on this, I assumed that if I could hit the ip and port with Basic auth, that every other sub-url would be the same. My bad. Thanks for guiding me through it.
Any plan to add the ability for “login:password@ip:port” in the ip address field for this tool down the line? Or do you know if rules engin, or rules api, or whatever it is, can handle Digest auth?
It’s on my list of potential enhancements but can’t say right now when I’ll get it done. I have the Digest code from my ONVIF driver which has to support it, so at least I wouldn’t be starting from scratch. I think I’d want to provide both basic and digest and possibly ws-security.
Rules engine has nothing related to LAN-related authentication.
Sounds good… standing by. Let me know if I can beta test anything.
Hi , sorry to ask a stupid question. im trying to use your driver to talk to a KNX gateway. how do i get it to push these commands
this turns device 97 on
http://192.168.1.240:80/baos/SetDatapointValue?Datapoint=97&Format=RAW&Command=SetSendVal&Length=1&Value=1
after running it returns
{
“Result”:true,
“Service”:“SetDatapointValue”
}
and this turns it off
i tried just pasting this url into a web request #1 but it didnt work . should i use POST or GET or Put or what am i doing wrong ?
From my experience, as long as entering those into a browser works without needing to enter a login and password for the device, you should be able to use GET:
Try this in web request #1:
And if that doesn’t work, try this: