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…
”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.