You are welcome. I hope you find it useful! Any feedback is much appreciated.
Thanks for this code! I spent all weekend trying to get the “HubAction” request correct and was just about to give up.
One comment, if I change the status (HIGH/LOW) of one of the pins using other means, the device tile does not update. When I refresh, I can see under the logs (pasted below) that smartthings is receiving the correct pin status.
“debug result: [SPI:0, ONEWIRE:0, GPIO:[35:[value:1, function:IN],… 3:[value:1, function:OUT]”
Any ideas why the tile isn’t updated during refresh or poll?
No problem. It is because I have not implemented the functionality to update the UI based on external changes to the pin out. I’ve put the boilerplate code in place, but not had time to finish it off. I’ll see if I can get around to it this week 
I’ve been working on a parallel effort connecting my Raspberry Pi to the smart things hub and struggled with the same issues. Lack of adequate documentation, hidden restrictions - the deviceNetworkId unique requirement. I’m so glad I found your post having just hit the exception about the deviceNetworkId. I’m controlling relays with my Pi for garage door monitoring and sprinklers. I have a legacy smart home with a bunch of X10 devices so I’ve also connected the Pi to a CM11a X10 controller.
I’ve decided rather than rewriting my device controller, I added multiple (virtual) interfaces to the raspberry pi. My Pi now has 3 static IP addresses and I can use unique device network ids. The downside is that I need to add a new virtual interface for each device I want to control. I also thought I could have my web server listen on multiple ports - one for each device.
I don’t see the restriction going away any time soon. It seems that deviceNetworkId is used in order to route incoming HTTP traffic to the unique device handler.
Thanks again for your post - saved me a lot of time.
I can certainly fix the update issue. I plan to do this in the smart app. Parsing all the relay states and passing them back to the appropriate virtual device via a custom command on the virtual device
I plan to do this over the next couple of days.
Glad I could assist.
This looks great! I have been struggling the past couple days trying to get my Raspberry Pi hooked up with ST using some older projects (referenced below). But can’t get either of these up and running. Excited to try your code! Also glad yours is built around Webiopi as I have been using that for a couple years now Pi’s.
Quick question on your plans for updating. I am using my Pi in my Utility Room for the following purposes:
- Monitor an input from my legacy home alarm system that signals an alarm.
- Control a relay output that will activate the siren on my legacy home alarm system.
- Monitor a temperature sensor that I have hooked up to my hot water heater (to determine when it is heating, a.k.a. flame on)
- Control a relay output that will open/close a fresh air intake damper based on when the hot water heater is running.
With your setup I think I can handle the relay outputs no problem now. Any plans to include RPi GPIO inputs as ST open/close sensors? Any plans to include Webiopi temperature devices readings as an ST temperature sensor?
Thanks and keep up the good work! So surprised there aren’t more Raspberry Pi & ST projects out there.
Doug
1 Like
Tried the relay control just now and it is working great. Now I can control my electronic damper via ST. Thanks again for sharing this!
Doug
1 Like
Hi @iBeech I inadvertently added two GPIOs when initially configuring the SmartApp from my mobile device. I’m trying to delete it now to start over, and no matter what I try when I go to clear out device name and GPIO numbers, I get the error “Failed to save page: defaultPage”. Can you offer any advise for removing the devices so I can remove the SmartApp?
Thanks!
Edit: I figured out that if even with receiving the error, it would save some values. Once I changed the IP address to something other than my Raspberry Pi, and saved it, I was finally able to remove all the GPIOs and name to uninstall it.
@douglaseucken I’ve already coded support in for temperature sensors, however i’m trying to iron out an issue caused by WebOIPi… well, more SmartThings… When i sent my request to query the temperature, the response is simply the temperature; it does not include any details about which temperature sensor you requested. Due to the way SmartThings works, this causes issues as I don’t know which device to update.
It’s possible I could limit to 1 temperature sensor per Pi…?
I do not personally have any experience with any other inputs, however, I would like to help out- which REST services did you want to use?
@iBeech Thanks for the reply. I follow you on the limitation of multiple temp sensors to one Pi. For my personal application limiting it to one temp sensor per Pi wouldn’t be an issue. So I would love to see that.
In terms of the inputs side of things, all I was thinking about trying to implement was using the “get GPIO value” REST service.
Get GPIO value
HTTP GET /GPIO/(gpioNumber)/value
Returns 0 or 1
Example :
To get GPIO 0 value : HTTP GET /GPIO/0/value
Basically map that to a GPIO input pin and then to a Smart Things open/close sensor. This way the output from my old style home alarm system goes through the Pi and looks just like another door or window sensor to ST. Then I can use the ST security routine to notify me of alarms and turn on the alarm siren, lights, etc.
I would also echo the sentiments of @MAINEIAC on the refreshing of the ST relay state. I have a couple scenarios where I will use a python script with Webiopi to do things in the background on the Pi (turn on GPIO when the temperature is above a threshold, etc). But it would be nice to be able to see current status of the relay on ST, and not have to rely only on having ST change its state.
Thanks again for the reply and a super big thanks if you are willing to make some of these updates. This type of Pi and ST integration is sooooooo useful to the DIY crowd!
Thats what it already does, in the form of a switch. I will be updating it shortly so that if an external entity changes the GPIO state, SmartThings will become aware of that fact within a short period of time (10-20 seconds).
Does that solve your issue?
I have issues with the ST documentation. Can someone boil down the syntax of the ST/webiopi REST requests for me? I understand the adress has to be in hex, but I still cannot get a successful GET or POST under my own code.
Keep up the good work Tom!
@iBeech I think that should work just fine. I think I can install a “switch” using the Pi Relay Manager and then go into it’s device settings (on the ST IDE page) and change it to a open/close sensor. Hopefully the Webiopi mapping still works and then I am in business.
Can’t wait to try it out.
I can add an open close sensor for you
I’ve made a major update to the SmartApp.
- Supports Temperature sensors (I’ll post a tutorial on how to set your temperature sensor up)
- Your switch will update in SmartThings if it was changed from outside SmartThings, this takes up to 10 seconds
Please uninstall your current version by opening the SmartApp, remove all references to your relays and then save, next go and delete the relay devices from your ‘things’ page. Upgrade, and re-add them.
@iBeech Trying the updated code and having a couple issues. After devices are setup the ST app crashes. Everything seems to work fine after you relaunch it though. I am on a Android Nexus 5X.
I was able to setup a temperature device successfully, I even made a small code tweak to switch to report temps in Fahrenheit. What I am running into though is that after about 3-5 temperature refreshes the temperature device stops updating and so do any other relay devices. Nothing seems to kick it back into gear short of removing all the devices and reinstalling. But again after a few refreshes it stops. I tried just installing a relay device (no temp device) and that seems to have no problem auto-updating. Any ideas?
I do like the new setup page for the smart app and the removal process goes much smoother now too. Thanks again for sharing with everyone.
Smells like the runIn bug with SmartThings. Search the smart app for ‘runIn’ and change the number to something like 300 (this represents seconds) and see if things look better after that
Glad you have got things working (even if partially). And glad to help
I’ll see if I can update the app to pull which temperature measurement to use out of your location
@iBeech I have been trying this out and have not been able to keep one of the items active for very long. Even when I push the runin time up to 300 seconds it will eventually stop responding.
I did some Google-ing and it seems that most people say any runin time over 60 seconds should work.
Seems puzzling. Any ideas?
Unfortunately, it would seem that the SmartThings platform doesn’t do polling very well at all. It is inconsistent, even when it does work.
I also experience this issue regularly with my temperature sensors. I’m not actually sure if there is a solution… other than to write a custom service which can do the polling re-present the data via REST, and get the smartapp to subscribe…
I’ll have a think.
Hopefully this will change when the new scheduler gets rolled out…