Following my previous post about EEBUS’s fundamental flaws, I’ve created comprehensive technical analyses of the SHIP and SPINE protocol specifications and their implementations with the help of Claude. These documents provide the evidence behind my concerns.
For those new to EEBUS: it’s a communication standard designed to enable smart energy management between devices like EV chargers, heat pumps, solar inverters, and home energy systems. SHIP handles secure device connections while SPINE manages data exchange. The promise is vendor-independent interoperability - any device claiming EEBUS support should work with any other.
The Analysis Documents
The analysis documents are now available:
These aren’t light reading. They contain detailed technical examinations of specification ambiguities, implementation challenges, and architectural flaws. Each analysis includes executive summaries, implementation assessments, specification deviations, and improvement roadmaps.
What the Analysis Reveals
SHIP: Not Ready for Production
The SHIP analysis concludes the implementation is “NOT RECOMMENDED for production deployment” without significant security hardening. Critical issues include:
“The specification’s approach to preventing double connections is fundamentally flawed… Can lead to both nodes closing all connections (connection starvation)”
The real concern is robustness: the implementation lacks rate limiting and connection limits. This means a buggy or misbehaving device on your network could overwhelm other devices by opening hundreds of connections, effectively taking them offline. In a home with multiple smart devices, one malfunctioning component could disrupt your entire energy management system.
SPINE: “Plug & Play” is “Plug & Pray”
The SPINE analysis reveals even deeper problems:
“SPINE creates an illusion of interoperability while delivering expensive custom engineering in disguise.”
The specification creates 7,000+ potential implementation variations through its data exchange mechanism alone - combining 7 operation modes (like replace, update, partial) with 4 contexts across 250+ data structures. For example, when multiple devices want to control your EV charging, the spec says nothing about who gets priority. One vendor might give control to “any bound client,” another to “the first bound client,” and a third might require “specific permissions.” All claim SPINE compliance, yet none work together correctly.
Most damning: SPINE tells devices how to talk but not how to work together as a system. While it can work adequately for simple single-controller scenarios, multi-device coordination requires custom engineering that defeats the “plug & play” promise.
Where EEBUS Works Today
To be fair, EEBUS can function adequately in controlled environments: single-vendor deployments, pre-tested device combinations, or simple monitoring scenarios.
The Numbers Don’t Lie
But in the broader ecosystem, the problems compound. The implementations make reasonable choices where specs fail, but this creates its own problem: each implementation interprets ambiguities differently, destroying interoperability.
Key findings:
- Analysis revealed 50+ ambiguities in SHIP and 7,000+ possible implementation variations in SPINE
- No test specifications or reference implementations exist to validate interoperability
- Each vendor interprets undefined behaviors differently, creating incompatible “compliant” devices
- Testing device compatibility requires exhaustive vendor-by-vendor combinations
This is Just the Beginning
These documents aren’t perfect or complete. They’re a starting point - an attempt to document what every EEBUS developer knows but rarely says publicly. They need scrutiny, challenges, and expansion.
Read them. Understand them. Challenge the assumptions. If you find flaws in my analysis or areas where I’m being unfair, please share them. Your real-world experiences - both failures and successes - will make these documents more valuable for everyone.
The goal isn’t to bury EEBUS but to build it better. Whether that means fixing what we have or learning from it to create something new, we need honest technical discussions.
Discuss
Join the discussion at eebus-go Discussions or via Enbility Slack.
Together, we can either fix EEBUS or build something better. But first, we need to acknowledge where we are.