[BETA RELEASE] URI Switch -- Device Handler for controlling items via HTTP calls

Troy,

I have the same question as a couple of folks above.
Is it possible to capture a status via URL so that device handler can decide whether to call open or close URL?

I also have a custom made Raspberry Pi garage door opener, but it also has door sensors so I have a real state I can serve via another URL.
Can you provide a way to modify this?

Thanks

Hi there, I am not sure it will answer your question but have a look at my implementation [RELEASE] Honeywell HPA250B Air Puriifier integration (through Raspberry Pi) which polls requests to my Raspberry regarding the status of my air-purifier and then get the answer thanks to a JSON the pi builds and sends back to the DTH. Hope it helps

Hello there @Mark_deVane and @tguerena ,
So i have a USB UPB controller/interface that registers as a simple Human Interface Device / USB Input Device under Windows and a few UPB light switches and lamp modules and appliance modules from my older home automation system that it will be fantastic if i can get them to work with SmartThings.

I already connected all my X10 devices by using a Raspberry Pi and Mochad and following the instructions of other people (I a have a tech background but not a programmer) and i can tell you that they work better than with what they were originally controlled with :slight_smile: i was wondering if i could do the same with the usb UPB interface and the Raspberry Pi in place of your RUC01 but have not idea how and what is required did you solve your UPB issue?? any pointers that might help me??
thank you for your time any help is appreciated.
Denis

Has this stopped working. Had all my URL switches working on internal IP address and now they do not work???

The same URL address works in browser but not in this device anymore

NVM I got it working again

Hello @richland007

I assume your problem is sending commands to UPB using a script - came across a couple of projects in github that look promising

The first one listens on a TCP port so you should be able to send commands to it from outside.

For interfacing with ST I have become a fan of HA-Bridge - GitHub - bwssytems/ha-bridge: Home automation bridge that emulates a Philips Hue light system and can control other systems such as a Vera, Harmony Hub, Nest, MiLight bulbs or any other system that has an http/https/tcp/udp interface. This is a compact impl to run on small format computers. This is impl started from this project https://github.com/armzilla/amazon-echo-ha-bridge.

It is dead simple to install and appears like a hue bridge on the local network, and you can define custom devices, and supports a variety of protocols including http:, tcp, udp etc. as well as command line scripts. As long as you have an internal endpoint for your UPB device, its pretty much point and click and adding a command for your device/controller - you can have a look at my post on using it with mochad and X-10 and google other implementations. The thing I like about this approach is that Hue support is natively built in so no setup is needed in ST beyond discovery. Here is the link to the afore-mentioned post.

Enis thank you for your reply,
I have a mochad deployment already set up for my X10 devices using a raspberry pi and CM15A i am not using the HA bridge for that purpose i am using the older device type / handler smart app for ST approach.
I also have a HA bridge server running that automates my roomba vacuum cleaner with a Roowifi adapter through Alexa. I have not created any of these approaches i have merely followed steps that others have written LOL
I do have 2 UPB dimmer switches already installed that used to work really well with an older automation system and a usb UPB control interface that registers as a HID but i have no clue of what to look for as far as how the mochad can communicate with the usb UPB interface or how to find the addresses of the UPB devices that need to be controlled.
I guess i am going to do some more research and hopefully with your help or expertise we can get this figured out :slight_smile: do you have any upb switches of your own??
Please continue to point me to the right direction and any help is really appreciated.

By the way judging by your name / member id i think we might be of the same back ground :slight_smile: … maybe apo jo vella?

Thank you again
Denis

Unfortunately I learnt about UPB reading your post :slight_smile: If you are not a programmer start with https://github.com/DaAwesomeP/upb-cli/ - its a node based project, if you don’t have node installed on your Pi do that first then follow the instructions on the github page.

Probably not :slight_smile: this is just my online identity -

Thanks for this, I have set up the URI switch and it works great when I use the switch in the smartthings app, however when I use Core or SmartRules for the URI switch the URL request is not sent, the switch does turn on/off but I cant see anything hitting my webserver logs. Any ideas why this is?

Thanks

That is strange. I have not tried using the CORE to tie in to the URI
switch. Generally speaking, I would think that the switch and the switch’s
triggers would line up to each other 1:1. In other words it sounds like
it’s working right, but maybe the switch isn’t? I’ll have to try with mine
later and see if it works.

Troy Guerena

I hope this thread is still active. I’m trying to use this Device Handler to control my Hunter Douglas blinds. I have a gen 1 hub and it doesn’t have native Alexa or SmartThings integrated. however I’m able to access the APIs through my browser. For example executing http://10.0.0.39/api/scenes?sceneid=7974 closes one of my blinds. I would expect this to work with the URI Switch, but for some reason I can’t get it to work.

Here’s the Log:

7:17:58 PM: info postEventToEndpoint: event successfully posted.

7:17:58 PM: debug Property Change Event switch: off (source: DEVICE)

7:17:58 PM: debug GET /api/scenes?sceneid=7974 HTTP/1.1
Accept: /
User-Agent: Linux UPnP/1.0 SmartThings
HOST: 10.0.0.39:80
Content-Type: application/x-www-form-urlencoded
Content-Length: 4

null

7:17:58 PM: debug Executing OFF

What am I doing wrong? Seems so simple. Thanks for your help and for the development. This looks like it has a lot of potential.

Can you send a screenshot of the smartthings setup for the URI Handler?

Garry, you may be interested in this:
https://community.smartthings.com/t/release-hunter-douglas-powerview-hub-integration/105388

You are correct…That’s exactly what I needed. Thank you!!

OK, I’m tired, don’t know whats wrong.
When I use a web browser to post:
http://192.168.1.210/tools?cmd=event%2CTurnOn
My device turns on as expected.

When I use URI Switch, nothing happens. Log file shows:

**4:12:46 PM: debug GET /tools?cmd=event%2CTurnOn HTTP/1.1 **
**Accept: / **
User-Agent: Linux UPnP/1.0 SmartThings
HOST: 192.168.1.210:80

What am I missing?

Need a little bit more info to help you. Just judging by your message, looks like the issue might be that doing a POST is working, but doing a GET is not. Maybe a screenshot of your settings in smartthings? And a little info as to what you’re trying to setup?

Thanks for getting back to me so quickly.
Yes, I’m trying to post to 192.168.1.210 the message /tools?cmd=event,TurnOn.
So I set URI settings like this:
External - not set
Internal IP 192.168.1.210
Internal port - not set
Internal On Path: /tools?cmd=event,TurnOn
Internal Off Path: /tools?cmd=event,TurnOff

I see the default in URI Switch uses GET

I have a wifi relay on the local network at 192.168.1.210 that can be turned on/off in this way. I can get it working using Webcore, but I would prefer something that’s not cloud based.

Have you tried changing the method from GET to POST?

Yea I tried just changing the GET to a POST in your device handler.
It did not work.
Maybe I need to provide extra parameters for the POST?

Generally, with a POST request, a payload is needed. Usually a beater token for auth or some other kind of json payload like {action:“on”} or something. It depends on what the device expects. Usually noted in the API documentation.