status?

[sebastiankb]

@davidgraeff I just found this project and I'm wondering about the status. What are the concrete plans for realization such as for the bindings? Do you need some support?

[davidgraeff]

@sebastiankb I'm slowly grinding through this project and all of its facets. You are right that the roadmap or a checklist like status report is not existing anywhere else than in my mind at the moment. Because I can only dedicate like 10h or so per week, it'll still take some time for the MVP.

I assume that you are familiar with openHAB? It is an interconnection hub for various "smarthome" products and it allows for scripts and rules to interact with configured devices and services.

Project Motivation: I am or I was one of the core contributors, but I do not see a JVM (Java Virtual Machine) based software to be the solution. Addons and openHAB Core services all run in the same process space, share the same process file handlers and privileges. This is absolutely not safe for Internet provided downloadable Addons. Any Addon can take over the entire JVM. And on top that, a badly or just semi badly written Addon might leak memory and it is basically impossible to track it down.

This project: I'm calling this OHX for now. Stability and security are my main concerns.

• OHX itself is already split into 3 processes (marketing speech would be micro-Services): Core, RuleEngine, Auth. If the rule engine goes havoc or crashes, it will in no way influence the interconnection part (a zwave wall-switch will still switch the interconnected zigbee light).
• Ideally all services run as software containers which allows for automatic restart, cpu and memory limitation, filesystem access restrictions.
• Addons are isolated processes as well. They communicate via gRPC with OHX. I have chosen gRPC, because it is layered on top of http2, is binary encoded, self documenting and available for pretty much any programming language out there. The idea is to write an Addon in your favorite language and deploy it as software container.
• OHX acts as a software container supervisor, as it interacts with "docker" and docker-like applications to list, pull, run Addons.

I do not follow a strict implementation road-map as I do not want to get burned out by this project. Instead I implement various parts in parallel and continue with whatever I feel like next.

If I'd try to resemble a checklist of TODO and DONE tasks it would probably look like this:

• Website, Domain Management, User documentation, Developer documentation ✓
• Cloud Accounts, Payment option via Braintree for required Alexa/Google Home Cloud services ✓
• Alexa Skill, Google Home Fulfilment Action ✓
• Custom PubSub service to cross home NAT routers; targeting the smallest Amazon EC2 instance but for up to 1.000.000 concurrent users: 80%
• Addon Registry ✓
• Addon Publish Command line utility ✓
• Addon template for C++, Go, Python, Rust, NodeJS 1%
• OHX-OS: Operating system images for x86 and Arm with a minimal Linux environment, a Docker runtime and pre-provisioned OHX ✓
• Core service 1%
  • Boilerplate, shared-code, service-discovery: 10%
  • Static file server for web-ui's ✓
  • Installation / Management of web-ui's (via the npm registry) ✓
  • Thing Interconnections 0%
  • Container supervisor for Addon installation / management 10%
• Auth service
  • Flat files for user management: 0%
  • OAuth for token generation, required by web-uis and everything else that wants to use gRPC or the http API: ✓
  • Cloud token management for Addons and the Alexa/Google Home PubSub service 0%
• RuleEngine:
  • Javascript scripts via quickjs: 90%
  • Defining the on-disk yaml file-format: 0%
  • Custom Conditions, Actions via Addons: 10%
  • Predefined Triggers: 0%

There are still a few things to be sorted out before Addons can be written. And there might be ways to increase development pace by contributions, but I haven't thought this trough yet.

Cheers, David