I spent the past 4 years on getting to know EEBUS and implementing it on all levels: SHIP, SPINE and multiple use cases. Because I was curious, interested, and needed it to charge my EVs with the wallboxes I had. But also because I do think an open source specification is worthless without an open source implementation. Additionally, no other existing protocol provides the promises EEBUS does. And no, Modbus does not, that’s like comparing apples with bananas. And on top of that: because I have the capability to do it. Overall I spent thousands of hours funded by myself.
Adoption
These efforts resulted in the current state. Providing multiple repositories with the stack implementations for SHIP, SPINE and some use cases for some device roles (actors) in eebus-go. Some additional repositories provide example implementations and forks of other open source projects that needed some adjustments. This work echoed in interest in open source and commercial fields. I started providing 2-day EEBUS introduction workshops for interested companies and consulting. Some companies have already adopted these EEBUS implementations for providing EEBUS support in their products.
But the work on the source code is not finished and never will be. The implementation (of course) has bugs, needs changes and documentation for better usability, is missing lots of use case implementations or even support to implement some usecases. None of the implementations are feature complete, if that is even possible.
Maintenance
Obiously, it is impossible to maintain such a huge endeavor alone and it is impossible to do it for free. The repositories are licensed under the very permissive MIT license. The code can be taken in any kind of projects and products, without paying any kind of fee and without any obligation to provide changes or updates back to the project. But that doesn’t mean that maintenance is and will be done for free.
Getting more contributors and maintainers added requires a lot of specialized EEBUS know how. EEBUS is nothing like any other protocol. It is a monster in complexity, and no stack implementation does or ever will fully conform to the written specification. Applications built on top of any stack often don’t behave as expected, thus making it even harder to achieve compatibility.
Funding
As a first step to improve this, I applied to the Sovereign Tech Fund Fellowship Program last year. But sadly it did not work out.
That is why I am announcing the following change: For commercial entities I will no longer provide reviews for tickets, pull requests etc. for free. Wethere it is about possible bugs, bug fixes or support for more features or use cases.
In addition, I would also like to offer sponsoring options that could fund the above mentioned tasks. Sponsors could be mentioned on the enbility.net web page and/or the EEBUS repositories.
Please feel free to contact me if any of these options are of interest for you.
There is more
Sadly. I do NOT recommend on adopting EEBUS in products. Sadly, because there is no alternative available on the market. But that doesn’t make it better. With all the know-how I gathered over the past 4 years I have to say: EEBUS is broken. Here are some key points for which I do have multiple examples at hand, but are mostly way too technical to be explained in this post:
- No EEBUS stack implements the EEBUS specification, none. They all implement the best guess that seems to work somehow with taking hints from the specifications but also ignoring them often because it is impossible to implement as specified.
- The EEBUS specification can not be implemented because it contains contradictions, too many options, too little guidance, too many consequences that are not documented and often unrealistic to work at all
- No device providing support for EEBUS use cases is guaranteed to work with other devices supporting the same use cases
- It is impossible to know if an EEBUS device is compatible with another. Even when connecting devices it is impossible to know if something will work, or not.
- There are no tests defined for SHIP, SPINE and the majority of the use cases. Even the tests defined for LPC, LPP, MPC do NOT guarantee that EEBUS will work in all common scenarios!
EEBUS has major technical design flaws, was never designed for the current usage in the first place and basically is “hacked” to somehow provide the theoretical chance to maybe make some promised functionality possible. This cannot be fixed, there cannot be good workarounds, EEBUS is a mess. EEBUS will fail and I do fear it to be the next tech debacle made in Germany. I really hope to be wrong, but I do fear otherwise with reasons.
For the time being EEBUS should be limited to specific scenarios and setups.
The criticism is not new, I raised it on multiple levels continuously over the past years, including with the EEBUS initiative. I do not know a single software engineer working on EEBUS who disagrees.
Sadly, I only see one way to solve this: start from scratch. But this cannot be an effort of a few engineers. A new specification that is designed alongside an implementation including test definitions is needed. This is a major task. A technical solution that is easy to install, maintain, implement in products and which guarantees compatibility and wide adoption is needed. Matter is such a candidate that has the focus on the right aspects. But I do not think that it will ever be standardized and therefore recommended for usage in critical areas like an energy grid infrastructure.
Discuss
I appreciate an open discussion on these topics, either via Enbility Slack or in eebus-go Discussions.