SmartThings device implemented in Linux?

Wiki Projects & Stories
1

I’m aware of the solution that uses Node-Red to bridge SmartThings to old X10 devices, and I expect I’m going to use that solution at some point. But I don’t speak Node-Red well enough to reverse-engineer that solution easily for my non-X10 prototype, and since I just want to have a couple of Raspberry Pis listen and speak as SmartThings devices the Node-Red bridge framework feels like it may be overkill.

(Basically, I’m implementing a Pi-based device that will be controlling air conditioning by pretending to be the AC’s IR controller. At the simplest level that’s very similar to a dimmer – set target temperature, plus on/off – though there are a lot of other parameters I could expose once I’ve got that working.)

So…

(1) Is there a good description somewhere of exactly how the Node-Red solution works, so I could switch it from controlling/responding via mocha to via my own code, and/or

(2) What’s the best current description of what protocols I would need to implement directly to run a service on the RPi that SmartThings would see as a switch/dimmer/sensor/whatever?

2

Which specific Node Red solution are you referring to? If it’s using groovy, it’s from the old architecture, and all of that will go away by the end of this year. :thinking:

The End of Groovy Has Arrived

There’s also a community FAQ on edge if you haven’t heard about the new architecture yet

FAQ: I have no idea what Edge is. Is that a new developer tool? (2022)

In the New architecture, there are two ways to pass information back-and-forth to your smartthings account.

  1. if you have a smartthings/Aeotec hub, then you can use an edge driver from the “edge services“ category to communicate with your pi on the same LAN. For example, there’s an MQTT integration based on that structure.

You can find those by checking the quick browse list in the community-created wiki.

Quick Browse Lists for Edge Drivers - Things That Are Smart Wiki

  1. Alternatively, if you don’t have a hub or if you have some other reason for not wanting to use an edge service driver, you can use the rest API to communicate with the SmartThings cloud. But that’s a whole other project.

I haven’t seen a good Quickstart guide for this method, but you can check out the tutorials in the forum

Tutorials - SmartThings Community

image
image850×385 53.9 KB

3

Thanks for the pointer to the Edge docs; that does appear to be the direction the home automation industry is heading.

I also just stumbled across https://toddaustin07.github.io/ , which is an effort to implement Direct Connect device communication. I’m not sure whether that’s the new Edge protocols or an older approach, but it looks like a good start. It’s in C, with a Python wrapper.

I’m bootstrapping Rust, so may tackle writing or porting something for that language as an exercise.

4

@TAustin has several Edge drivers and associated apps.

He may have something in place that lines up with what you’re attempting to do.

1 Like
5

Todd Austin in GitHub is @TAustin here. :sunglasses: he did the MQTT integration I mentioned, and you will see several of his projects on the “edge services“ quick browse list I linked to earlier. All of those are designed to let the hub communicate with other devices, sometimes server devices like a raspberry pi, on your LAN. So that all falls under the first category I mentioned.

6

Fun projects! Let me know if I can be of any help at all.

1 Like
7

Still a bit confused by terminology and by the code I’ve glanced at so far; apologies for stupid questions…

  1. I see discussion of Direct Connect devices; that’s a definite improvement over looping through outside servers and I’d prefer to go that route. Is Edge another name for that same set of APIs and designs?

  2. I’ve taken a brief look at st-device-sdk-c-ref, and an even briefer look at @TAustin’s “utility belt” implementation. Love the idea of the latter, especially for those of us who aren’t yet going for manufacturing implementation and value versatility for experimentation. But… At least for the API, it seems we’re expected to specify the processor we’ll be building for, and that presumes it is not the processor running the toolkit. However, in my case I’m prototyping with generic Unix boxes (Raspberry Pis, and I might even want my desktop Linux device to run my code while I’m debugging!), so I don’t need transcompilation; I just need code that I can compile on the machine which will run it, and which will use the OS-provided network support. Is that actually possible with currently available code, or is there an unavoidable proprietary/processor-specific blob which requires that we use one of the “approved” BSP’s?

  3. Would there be interest in a native Rust port of the C code? Yes, I know, Rust can call C functions through an “unsafe” wrapper, but that might be an interesting project while I’m learning Rust… and Rust does guard against some of the nastier mistakes possible in the “high-level assembler” of C.

adTHANKSvance…

8

No. Edge is for the devices which communicate to the hub, not the cloud. So there are Edge Drivers for Zigbee, zwave, Matter, and some LAN devices. Edge drivers are written in LUA and run on your own smartthings/Aeotec hub. These are run locally, no Internet connection required.

“Direct connected” is the smartthings term for Wi-Fi devices that are in your home, but communicate directly to the smartthings cloud. They don’t have their own cloud, and they also are not talking to your hub. In fact, you do not need a smartthings/Aeotec hub to use them. They do require an active Internet connection, because that’s how they get to the smartthings cloud.

I personally think “direct connected” is a really confusing name for this category, because most people are going to think it has to do with the hub. I think they should’ve called this group “SmartThings cloud connected,” which is longer, but more accurate. But they didn’t.

Direct connected devices do not have edge drivers.

Here’s the official schematic:

image
image850×385 53.9 KB

Oh, and here’s the official announcement on this:

SmartThings Edge is our new architecture for Hub Connected devices that uses Device Drivers to execute commands locally on SmartThings Hubs. Edge Drivers are Lua©-based and can be used for Hub Connected devices, including Zigbee, Z-Wave, and LAN protocols. Read more about SmartThings Edge in our public announcement.

And here’s the one on directly connected devices:

Direct Connected Devices integrate directly with the SmartThings Platform via WiFi, eliminating the need for you to launch or manage your own cloud. Easily integrate your device using the SmartThings SDK for Direct Connected Devices. The SDK manages all MQTT topics and onboarding requirements, freeing you to focus on the Capabilities of your device.

Again, if you look at the schematic, you can see that devices using edge are a different communication path than directly connected devices. Edge drivers are LUA running on the smartthings hub. Directly connected devices are using an SDK, which will use MQTT to communicate to the smartthings cloud.

And then there’s also a third path, which is a regular REST API.

9

Many thanks for the clarification. I think I’m starting to get it. Edge can run entirely local on the hub; Direct Connect can run entirely on Samsung’s servers?

It sounds like ideally what I’d want is to be an Hub Connected/Edge device. (Unless that would mean giving up the ability to integrate with Alexa, in which case I have some annoying decisions to make.) But I’m not exactly enthusiastic about adding Lua as another bump on the path. I want to get past learning Yet Another Language and start bringing up functionality. Unless there’s a boilerplate package I can start with, so I can delay that investment.

Would the REST solution be bouncing every transaction off Samsung’s (or my) servers, or would it also be local to my hub?

Given that my goal is to turn a Linux box into a SmartThings device (HVAC in particular), that I’m a fluent programmer with C and Java as the languages I’ve used most often and experience going down to hardware level, and that I’d rather keep the traffic on-site if possible… Which path should I be looking at?

“You come to a fork in the road.”
“Oh Look, there’s a Fork in the Road! … I pick up the fork.”

10

Yes, except for the firmware running on the direct connect device itself, as is true with any Wi-Fi device. And for the fact that the hub still has to communicate to the cloud from time to time, even if all you are running is edge drivers. I don’t know the details of all that, I just know staff keep telling us that you can’t run fulltime without an active Internet connection.

If you want a totally local platform, smartthings isn’t it. (Just as an example, the Smartthings app always requires a cloud connection, even if it’s on the same Wi-Fi as the hub. They didn’t have to design it that way, but they did.) If you want to be disconnected from the Internet all together, after initial setup, you would need to look at one of the competitors like. Hubitat, homeseer, Apple HomeKit, vera, etc. Even with edge, smartthings is still largely a cloud-based architecture. Edge runs more stuff locally than the previous smartthings architecture, but not everything.

It sounds like ideally what I’d want is to be an Hub Connected/Edge device. (Unless that would mean giving up the ability to integrate with Alexa, in which case I have some annoying decisions to make.)

Hub connected devices using Edge drivers are connected to Alexa exactly as hub connected devices are connected to Alexa before Edge: through the smartthings cloud. So you don’t give up anything in that sense, it’s the same smartthings integration.

But I’m not exactly enthusiastic about adding Lua as another bump on the path. I want to get past learning Yet Another Language and start bringing up functionality. Unless there’s a boilerplate package I can start with, so I can delay that investment.

It’s running in Lua, but you are fairly limited in what an Edge Driver is allowed to do, so it’s not like you have to learn the full LUA language. Just enough to issue the allowed smartthings commands. (although @taustin has managed to do some amazing stuff within those confines. But most people aren’t going for that level.) I’m not sure what to tell you about where to start, others will have to help with those details.

Would the REST solution be bouncing every transaction off Samsung’s (or my) servers, or would it also be local to my hub?

The rest API endpoints are in the smartthings cloud. Not local on the hub.

Given that my goal is to turn a Linux box into a SmartThings device (HVAC in particular), that I’m a fluent programmer with C and Java as the languages I’ve used most often and experience going down to hardware level, and that I’d rather keep the traffic on-site if possible… Which path should I be looking at?

I would think either a regular edge driver or edge services. You could even use MQTT if you’re familiar with that. In addition to what other resources other people will give you, why don’t you glance over the existing community-Created “edge services” edge drivers and see if they give you any ideas.

You can find these and all the other community-created edge drivers in the quick browse lists in the community-created wiki. The lists are organized by device class, so there’s one for sensors, one for lighting, one for edge services, etc…

https://thingsthataresmart.wiki/index.php?title=Quick_Browse_Lists_for_Edge_Drivers

”edge services” is a term that the community invented, not part of the official documentation. We use it for edge drivers which are connecting via LAN to some local server or a device like a streaming video box that has its own API. With your background, you should understand once you skim the list of the existing ones. :sunglasses:

11

Understood re SmartThings always having some cloud involvement. It’s what I currently have installed, so it’s where I was thinking to start. Originally, as noted up top I was actually looking at the old Node-Red solution because that basically sets up a virtual device that runs command-line programs on the Pi, and swapping out the mocha commands for my IR commands would be moderately straightforward… except for all the setup needed to get the bridge running, and the fact that it looks like that solution is somewhere between deprecated and dead.

(I actually have a Hubitat that I’ve been meaning to try out in my Copious Spare Time ™; if there’s a way to set up my device so it would work in both ST and H environments that might resolve which direction to jump.)

1 Like
12

Take a look at the edge services quick browse list, and particularly the work by @TAustin . I think you may be able to find something that will work there. :sunglasses:

13

If you are using Raspberry Pis and are a C programmer, than you could use my package to implement a “direct-connect” device. You code your app in C using an SDK, but no, you don’t have to worry about creating a MCU-specific version as you probably read about. You skip all that when implementing with Linux on a Pi.

There are two downsides to this approach: 1) as mentioned, this relies on an internet connection to the SmartThings servers, 2) the initial “onboarding” process of the device (in this case your Pi) is done through temporarily setting your Pi up as it’s own access point to mimick a typical wireless IOT device. My package automates all that, but it’s still a bit of a convoluted process.

The alternative of using Edge drivers may be more suitable to what you want to achieve since it is implemented all locally. However now you have to learn a new language - Lua, and all the ins and outs of implementing Edge drivers, PLUS you have coding to do on your Pi, PLUS figuring out how you are going to manage the interface between your Pi and the Edge driver running on your hub. Edge drivers cannot request a specific port number, so you have to implement some sort of discovery process for the Edge driver to find your device on the LAN and establish communications with it. Since your device app can’t know the Edge driver’s port number it can’t initiate the link-up.

As @JDRoberts suggests, MQTT might be something to consider. I have a number of solutions that might be useful for you - either using MQTT or HTTP.

1 Like
14

Many thanks. Homework assignment!

1 Like