That is very cool!
Yeah I've had to rely on my Pi for various things over the last few years where it wasn't directly possible with Hubitat. Unfortunately I have to blindly copy and paste commands from ChatGPT (or previously some techies website) to get things working. I've had no issues but get concerned about how much redundant left over crap I leave on there.
They are very handy, I run several of my 3D printers on them using Klipper.
I have a PI, but really don't want to use it. I power it up from time to time to test something, but as a general rule it stays in the closet.
I'm not too worried about the cloud api to the Sofabaton. None of that is critical to me and if it doesn't work it's no big deal. I just use the buttons on the remote itself.
However, if it apparently can be done local, or so it seems, maybe some of the gurus here can figure out an app or driver to use on HE.....
I’ll have a look at it with Claude if I get time on the weekend.
I think that it will have to be Hubitat sending a command to the Pi as Hubitat won't have the Python library. I had similar when I was messing about vibe coding a driver for Starlink - a Python helper file needed to be hosted on the Pi but it all worked fine.
Way over my head 
. But I’m good with what I have.
@johnwill1 is correct, there's really no good way to do this 100% on Hubitat.
The Sofabaton hub expects to be called back: you send it a small UDP message telling it where to find you, and the hub then opens a TCP connection to you, which means whatever talks to it has to be sitting there listening on a port, ready to accept an incoming connection and hold a two-way conversation on it.
A Hubitat driver simply can't do that — Hubitat lets a driver make outgoing TCP connections, but gives it no way to listen for and accept an incoming one. The hub's own listener on port 39501 doesn't fill the gap either, because it only receives HTTP-shaped messages and gives you no way to write anything back down that same connection, so at best you could hear the Sofabaton and never answer it.
That's why a small always-on machine is needed in the middle: it can do the listening and talking the Sofabaton protocol requires, then relay to Hubitat over plain HTTP, which Hubitat handles perfectly well in both directions.
Has that ever made it’s way to a feature request?
Not that I know of, but I haven’t gone looking either.
@gopher.ny is this something that would be considered for HE?
Just wondering, has anyone tried using Maker to get stuff from the remote?
Was doing some tweaking on my application. For my curiousity I looked at your driver code. I realized there is really no theoretical limit to how many buttons you could have. Practical limit obviously. You limited it to 20 but could be more if anyone needed that many.
Yeah I could definitely add more if folk would like it. The original version only had 10.
Hello Hubitat users. I'm the developer of the Sofabaton X HA integration and the sofabaton-x Python library. I'm checking in to see if I can be helpful in any way. @dJOS is right, for the library to integrate with Hubitat it needs a REST + WS wrapper, which must run external to the Hubitat hub.
I have this sitting in some notes for future plans:
┌─ Home Assistant (native Python)
│
Sofabaton hub ←→ sofabaton-x
│
└─ sofabaton-x-server
REST + WebSocket
│
┌─────────┼──────────┐
│ │ │
Homey Hubitat openHAB
Node.js Groovy Java
The idea is that I make a second consumer of the sofabaton-x lib, sofabaton-x-server. The server would host REST and WS services, and can potentially mirror all functionality the HA integration has. It could follow OpenAPI specifications, allowing code generators to be efficient.
It would run standalone as a Python script from the command line. It could come with a Docker compose file for building a container that hosts the script. People could run it on their NAS etc.
I also understand that this might not be the right solution for many (maybe most?) Hubitat users. But certainly if there is interest, I'm happy to help.
While I do run HA on my NAS for a couple of things, I personally don't need Bi-Directional integration between HE and Sofabaton. Im happy to support it if others want it tho.
It's worth noting that there is already an HA-HE integration for connecting HA devices to HE, so the options are there already if folk really want to use them.
I also don’t think I have a use for it. I already have the ability to start/stop activities from HE. And I have several buttons configured on the remote to trigger things in HE. In addition using the start and stop sequences in X1S allows me to also trigger things in HE depending on a particular activity starting or stopping. I really can’t think of anything else I would want to do. But thanks for considering it.
That's good to know, and sorry for my limited knowledge on HE and its community.
So yes, the sofabaton-x lib manages bi-directional control, can make in-place hub configuration changes (add/change/remove devices and activities), features backup/restore, command payload editing including conversion and direct emission of Pronto Hex. It includes "cards" for control and configuration (they could run from sofabaton-x-server too). And fully local.
Many of these features do not require an "integration" to be useful, and the sofabaton-x lib already ships with a CLI that supports some of these functions directly (like backup).
The path I took with the HA integration is about ease-of-use. I noticed on socials that many buyers of Sofabaton remotes are looking to connect with Home Automation platforms, but are quite new to it and most of the time not that technical. Getting it to work can be a fairly steep hill. So one approach that's in the HA integration is to just ask the user which action he's looking to trigger in the automation platform, then ask which button on the physical remote he'd like to attach that to, and then just deploy that entire config to the Sofabaton hub automatically.
Where I see friction is when a thing that is about increasing usability and accessibility requires command-line scripts, additional always-on devices, docker containers etc. This is where there may be a mismatch that is so fundamental that there's no point in investing time.
Having said all that, I love working on this stuff so I'm looking for any excuse to make more things.
Being able to use those features would be very cool for sure. 
Wow, this just went way over my head. 
But no problem, I'm happy.
Edit 16 sept: this post is now largely outdated,
sofabaton-x-serveris now released on PyPi. Scroll down for updated information.
I did work on this. On the dev branch of my repo I added sofabaton-x-server.
It's not yet released on pypi, so if you want to try it you have to checkout the repo and switch to the dev branch, then follow the readme and starter guide. The server reproduces all functionality of the Home Assistant integration, minus the cards. It also currently lacks the ability to subscribe to an MQTT broker.
Core concepts are:
- server is a REST and WebSocket service that provides full read and write access to the hub, can send commands to the hub, receive HTTP callbacks from the hub and maintains current Activity state.
- server establishes and retains a TCP connection with 1 or more hubs, leveraging APIs intended for the Sofabaton app.
- the hub allows only a single app connection at a time and server takes that connection. To still allow the app to connect, server runs a virtual hub for each of your real hubs. It functions as a proxy that sits between the app and the real hub.
The server's API should be straight forward to implement for coding agents. I am unable to test this myself, but I had GPT Astra have a go at making an implementation for Hubitat. I have no intention of making and maintaining a full implementation for Hubitat as I'm not equipped to do so, but I hope this is an OK starting point for someone who is. As with all my code, you can do with it as you please.
I will likely do a proper release on pypi in a week or so, it might not contain the Hubitat example (if I learn Astra created a bunch of nonsense). Server itself I consider robust; it has been tested in a range of environments against all hub types and across its entire API surface.
Functionally server covers 100% of the Home Assistant integration's capabilities. With sufficient interest I will also port the cards (UI) to server and add MQTT subscription capability, to those can be captured by the server as well.
I understand that this is a lot, and I know to not hold any expectations towards people actually using this thing. Whatever happens with this, I'll be around to answer questions and help out.