Would a platform-neutral deterministic policy layer be useful to openHAB users?

Development
1

I am researching an openHAB adapter for Spatial OS, a platform-neutral policy layer that keeps natural-language intent separate from physical execution.

The core builds a spatial graph, compiles requested outcomes into typed actions, runs a shadow preview, asks for explicit approval and verifies observed state after execution. Home Assistant is the only live connector today. This is not an openHAB-compatible release announcement.

Before writing code, I would like feedback from openHAB developers on the adapter boundary:

  • Can the REST API plus event stream support a reliable read, command and post-action verification loop?
  • Should this be an external service, an add-on, or a local sidecar?
  • Which Items or actions should be denied or require explicit approval by default?
  • Would this safety model add value beyond existing rules, or mostly duplicate openHAB concepts?

Architecture and virtual-home demo:

I am looking for two design partners before implementing an adapter. Technical objections are especially useful.

  • Spatial OS Team
2

I don’t see why not. All the UIs as well as some third party tools like HABot (provides a separate server with native Python rules which interacts with OH over the APIs).

It looks like it would fit as an add-on similar to the ChatGPT and Gemini add-on with hooks into the “Chat” function. So user would configure the Chat function to use Spatial OS instead of these other two options.

Each individual OH user will need to determine that for themselves. Currently, we use a deny by default approach where things like this can see nothing. Then the users tag or add metadata to Items to expose them to the service.

Actions are a little more challenging though. Usually, an action becomes a command to an Item so that’s straight forward. But other times the action might be “run this rule”, “start this scene”, “call this Action” (Action is a term of art in OH referring to special capabilities provided by individual add-ons).

Personally I think it is an interesting approach that lets one pull in some more natural language ways to command the home yet maintain control over what’s going to be done.

I tend to be more of a UX advocate here so I don’t know how useful I’d be from a technical perspective. But I’m always willing to help where I can to try to make sure what gets produced fits with the existing OH user experience without needlessly introducing new ways to do the same thing. I dont’ always succeed of course, but I try.

There have been lots of discussion over how to enable AI control over the home automation. We’ve had a ChatGPT add-on for quite some time that mainly was useful for announcements and stuff like that. But the latest release of OH introduced a new Chat feature which lets AIs actually control parts of OH. There is also an MCP add-on that was introduced to enable AI to help develop/create OH configurations. I think this idea helps address some of the trust concerns that have been raised.

3

This is a commercial project, where the privacy policy states that:

You may use the Virtual Home Lab without connecting a real home. Creem’s customer portal provides subscription cancellation, invoices and payment-method controls.

Other than that, it doesn’t seem like you have much privacy at all. So, you can choose to subscribe to a paid product and then create a fake home that you connect - to protect your data. What exactly would be the point of that?

4

Thank you, Rich. This is exceptionally useful, especially the distinction between Item commands and higher-level effects such as running a rule, starting a scene, or calling an add-on Action. I should not flatten those into one generic command type.

The openHAB deny-by-default model also maps well to the capability manifest I had in mind: Spatial OS would initially see nothing, and users would explicitly expose Items through tags or metadata. Approval policy could then be configured separately for ordinary Item commands, rules, scenes, and Actions.

Your suggestion to integrate as an add-on with the Chat function is also a much cleaner openHAB-native boundary than forcing a generic external-service experience. And UX feedback is exactly what I need here; the main risk is adding ceremony without enough clarity or trust.

Would you be open to reviewing a short adapter contract or testing the virtual preview flow once I have an openHAB-specific prototype? No implementation work would be expected.

5

It depends on the details. However, be aware that openHAB is a 100% volunteer driven open source project. Commercial licenses, proprietary code, and any stuff like that is not compatible with the project. Obviously you could host any add-on or anything else you make yourself. But if you want this to become an “official” plug-in to openHAB it must be unencumbered open source.

I only mention this because words like “contract” raises alarm bells.

6

That criticism is fair. The sentence you quoted did not explain the actual data boundary and made the privacy model look much weaker than it is.

I have now corrected both the implementation and the public policy. For the Home Assistant connector, authorization is session-only; room names, entities, device states, policy text and execution traces are processed in the browser and are not uploaded to Spatial OS servers or product analytics. Analytics retains daily aggregate counters only, without IP addresses or per-visit event records. Payment processing is separate and never receives home data.

The Virtual Home Lab is a preflight environment for evaluating the interaction model before connecting anything real; it is not the proposed privacy solution for a connected home. A real connector must preserve the local-data boundary above, otherwise it should not ship.

Thank you for calling out the ambiguity. It led to a concrete policy and implementation correction.

7

Thank you for catching that wording. By “adapter contract” I meant a technical interface specification — data types, capabilities, scopes and verification semantics — not a commercial or licensing contract.

Your boundary is clear: if we ever pursue an official openHAB add-on, that adapter would need to be unencumbered open source under a license compatible with the project. A separately hosted optional service could remain outside the openHAB project, but proprietary code should not be presented as an official plug-in or inserted into the openHAB codebase.

At this stage I am only asking for review of an adapter interface and user experience, not endorsement of a commercial product. I will use “adapter interface specification” from now on to avoid the ambiguity.

8

In that case I think we are good. But I’ll also say that while I code, I do not contribute to the code for OH so beyond what’s in the docs I have little technical I can offer concering technical interface specifications. I can point at what’s already there but little more. Speaking of which, I think the Gemini binding is going to be the closest to what you are trying to accomplish. Looking at that binding and the API would be the first place I would recommend looking, if for no other reason than to discover if indeed what you are proposing matches and the interfaces used can support what you want to accomplish.

I highly suspect changes to core will be needed in the end, but that’s not based on anything concrete.

I’m happy to trial run prototypes and answer specific usability questions. But often my time is short so adhoc works best for me, unfortunately. I’m better able to be responsive when I can review and respond from my phone. The hardes thing for me right now is finding an hour or two I can spend in front of an actual computer.

9

That working style is completely fine, and I appreciate the concrete pointer. I’ll study the Gemini binding and its API first, and keep any prototype review mobile-friendly and asynchronous: one short scenario at a time, with a screenshot or brief result and one focused question. No scheduled calls or long desktop session.

I’ll also separate two questions before asking for your time: what can be implemented as an add-on with existing interfaces, and what would require core changes. Once I have evidence, I’ll share a small virtual preview for usability feedback rather than a broad technical specification.

Thank you for being willing to trial it under those constraints.

10

@rlkoshak — I have converted the first usability question into the short, mobile-friendly preview I promised:

This is a platform-neutral interaction preview, not an openHAB adapter or add-on. The focused question is: before approving an action, is room, device, requested change and expected observed state enough, or should the interface also expose the underlying openHAB Item and exact command?

A one-line answer after the preview is enough; no desktop session, credentials or home data are needed.

11

I think the idea is interesting, especially the focus on making actions predictable without tying the policy layer to one platform. For openHAB users, keeping the interface simple while still showing enough detail to understand exactly what will happen seems like a useful balance. I’d be interested to see how the beta handles more complex device actions.

12

It’s not clear enough to me how a typical user would use this to answer the question. The preview doesn’t actually show anything related to how this would look from a usability perspective. It’s just a feedback form asking for feedback on something I haven’t even seen.

It all looks very much AI driven and vibe coded and your responses here read like AI. I’m pretty happy to assist with this if I’m talking with a human. But I’m not all that interested in talking with an AI directly and definitely not interested in designing and implementing this through forum posting and vibe coding. I’d do that on my own if I had interest in that.

My primary contributions to the openHAB project are people focused. I want to interact with and help people. I’m not interested in interacting with an AI in this way.

13

@rlkoshak First, I owe you an apology for the delayed reply. I was pulled into two urgent production-support and reliability tasks over the past few days, and I did not give your feedback the timely, personal response it deserved.

You were right about both the page and my earlier replies. The preview did not show a real user workflow clearly enough, and some of my wording sounded generic and AI-generated. I am a real person and I am personally responsible for this project and for the conversation here. I do use AI-assisted tools in parts of the development process, but they are tools, not a substitute for a direct human conversation or for my own technical judgment.

My background has been in AI and applied computing, and spatial intelligence is something I have cared about for a long time. What I am trying to explore is not simply another automation or rule engine. My longer-term goal is a consumer home world model that can adapt to each household: a model of rooms, devices, relationships, state and human context that helps AI understand a home as a space rather than as a flat list of Items.

If this can be done well, the home could eventually respond with more contextual, human-like intelligence while execution remains deterministic, inspectable, privacy-preserving and under the user’s control. That combination of a spatial world model and a verifiable execution layer is the direction I want to pursue.

Your usability criticism was fair. I have now replaced the earlier feedback-only preview with one concrete workflow that shows the user’s request, the compiled device actions, the shadow result and the verification steps. It is still a Home Assistant example, not an openHAB integration, and I want to be explicit about that boundary.

Thank you for being direct. I do not expect you or the community to design or implement this for me. If you are still willing to comment once there is a concrete openHAB flow to inspect, I would genuinely value your judgment. If not, I still appreciate that your feedback exposed a real problem in how I presented the work.

Edward