Well now you’ve brought up yet another way you could interact with SmartThings from a application on your Pi - the SmartThings RESTful API. You can use that to issue commands to devices from your app using simple GET/POST requests from a script. That could look something like this:
url = 'https://api.smartthings.com/v1/devices/' + self.id + '/health'
headers = {}
headers['Authorization'] = 'Bearer ' + MYSMARTTHINGS_TOKEN
headers['Host'] = 'api.smartthings.com'
headers['Accept'] = '*/*'
headers['User-Agent'] = 'devstatmon'
r = requests.get(url, data='', headers=headers, timeout=5)
The shortcoming in just using the RESTful API is that there is no asynchronous notification to your app of state changes for a SmartThings device. In order to get that, you have to write your application as a SmartThings SmartApp and use their SDK to interact with SmartThings. You’ll have to code it in nodeJS, but can SUBSCRIBE to device state changes and get notified when they change. If you want to see an example SmartApp using this SDK, check out the tutorials here in this community, or you can look at one of my SmartApps here, which was written to run on a Raspberry Pi using ngrok. Maybe more than you want to get involved with…
Here is an example of a python app that periodically pings IP address and sends an http message to an Edge driver to update presence status.
An example of a Pi app GETTING triggered by an Edge driver would require a script that implements a simple server to listen at a certain port number. This scenario actually wouldn’t require Edgebridge. You could do any http request from SmartThings (either from webrequestor or custom device driver) directly to your app; you just have to know the IP and port.
If you want to create shade devices in SmartThings that send HTTP post messages to your shades, you could accomplish this in a few ways. With no programming, you could create a virtual shade device (use my vEdge driver), and in combination with my webrequestor driver you could create automation routines to trigger http requests based on the virtual shade states. More elegant solution would be to have a custom shade driver that accomplishes the same without the automations.