OpenEMS
Matter Energy Management Support
Please add support for the new energy management feature introduced in Matter 1.4: https://csa-iot.org/newsroom/matter-1-4-enables-more-capable-smart-homes/
Hello Peter,
could you tell us:
- Is there a Documentation how to "support" this feature?
- What are the purposes/improvements for OpenEMS if we Implement this "feature" ?
- Why should we consider Implementing this?
- What is your Use-Case on OpenEMS ?
Greetings !
I'm just stopping by, got interested. Having screened the docs, this may be +- what I can infer was intended:
ad 1. The new device types of Matter 1.4 extend it into the realm of OpenEMS - I think data mappings is all that is required in a first step to prepare OpenEMS for Matter
ad 2. Using Thread as communication link and avoid the need to retrofit comm wiring (lower latency than potential alternatives WiFI / Bluetooth) / Make use of the multi-admin feature (really nice!) so that the same device can be monitored by different systems (e.g. Wallbox by the manufacturer's "Wallbox-App" + OpenEMS)
ad 3. Looks like Matter is the upcoming smart home standard pushed by Amazon/Google/Apple and Threads may replace zigbee as radio transmission standard. Matter is reaching out into OpenEMS domain (new device types) - that means, practically, Google/Amazon/Apple is reaching out. Better get ahead of the situation!
ad 4. Avoid comm wire-link retrofitting, leveraging Threads home mesh / potentially steer more loads / add steerable loads easily and quickly (by adding them to the Threads mesh) / collaboratively own devices via multi-admin feature (this may be a door opener to break loose of the vendor lock-in and compat issues)
Just my casually inferred conclusions. I have no skin in the game.
Edit: Matter works over LAN / WiFi / Threads and since it's a mesh it seems that as long as a border gateway is present on site somewhere (e.g. an Apple TV) this can bridge OpenEMS traffic to Threads devices without the OpenEMS edge device needing to act as a border gateway into Threads. Seems nice!
This issue has been automatically marked as stale due to inactivity. It will be closed in 7 days if no further activity occurs.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Hi, thank you for the suggestion and for keeping this issue open........ After investigating the current state of Matter support for Java/OSGi environments, I'd like to provide a technical assessment:
Technical Challenges
1. No Production-Ready Java SDK Available
The official Matter SDK (ConnectedHomeIP) is written in C++ and optimized for embedded devices. For Java, there are only two options:
-
matter.js-java (https://github.com/digitaldan/matter.js-java)
- ❌ Only 2 commits total, last activity November 2023 (>1 year ago)
- ❌ No releases published
- ❌ Explicitly not production-ready
- ❌ Platform limitations (Windows issues acknowledged)
- ❌ Very low community adoption (8 stars, 3 forks)
-
Google's matter-android-demo-sdk (https://central.sonatype.com/artifact/com.google.matter/matter-android-demo-sdk)
- ❌ Explicitly marked: "PROVIDED WITH NO WARRANTY OR GUARANTEE OF ANY KIND"
- ❌ "SHOULD NOT BE USED IN A PRODUCTION APPLICATION"
- ❌ Android-only context (JNI bindings)
- ❌ Not compatible with server-side Java applications
2. Architecture Incompatibility
- OpenEMS uses Gradle + OSGi (modular, dynamic service platform)
- Available Matter libraries use Maven + npm/webpack (static bundling)
- No OSGi-compatible Matter bundles exist
- Integration would require significant custom wrapper development
3. Matter 1.4 Energy Management is Very New
- Matter 1.4 released in 2024 (< 1 year old)
- Energy management device types (EVSE, Battery Storage, Solar Inverter) are brand new
- Limited hardware availability on the market
- Specification may still evolve in upcoming 1.x releases
Why This Matters for OpenEMS
OpenEMS is a production-grade energy management system used worldwide in critical infrastructure. Integrating unstable, experimental dependencies would:
- Risk system stability
- Create maintenance burden for unmaintained libraries
- Potentially introduce security vulnerabilities
- Provide no immediate value (hardware ecosystem not mature)
Alternative Approach
Most energy devices that will support Matter already support established protocols:
- Modbus TCP/RTU - Industry standard for energy devices
- REST APIs - Modern cloud-connected devices
- MQTT - IoT communication
- EEBUS - Energy-specific communication protocol
OpenEMS has mature, production-ready support for all of these.
Recommendation
Wait for ecosystem maturity:
- ✅ Wait for a production-ready Java Matter SDK (official or community-maintained)
- ✅ Wait for OSGi-compatible packaging
- ✅ Wait for Matter 1.4+ energy devices to be widely available
- ✅ Monitor the Matter ecosystem for 1-2 years
Timeline estimate: Realistically 2026-2027 before this becomes viable for production use in OpenEMS.
Next Steps
I suggest:
- Keep this issue open as a feature watch
- Re-evaluate annually as the Matter ecosystem matures
- Consider implementation when:
- A maintained, production-ready Java SDK exists
- OSGi integration is feasible
- Community demand increases (users have Matter-only devices)
Does this assessment align with your expectations? If you have access to different Matter Java libraries or see developments I've missed, please share!
@sfeilmeier whats your Opinion on this ?
Community demand increases (users have Matter-only devices)
At least for an end user, I think this tries to hit home the wrong point of value: In my view, the demand is not driven by users not being able anymore to connect their devices, but by wanting to control them from their (simple/unified/convenient) home automation apps / simplify wiring & connectivity.
The value added therefore would be in convenience, for which matter-enabled devices on the market would be sufficient over matter-only devices.
My recommendation would be to attenuate that particular requirement to a more permissive: "observe the adoption of matter/threads throughout the smart home". Consider the requirement met if there's a clear trend of adoption.
This angle to the requirement allows for OpenEMS to better stay ahead of the development and position itself as the best option for an EMS in the smart home.
Thanks for the perspective — I agree with the general idea that convenience and unified control are strong drivers for Matter adoption in the smart home. However, this still doesn’t address the main blocker we currently face on the OpenEMS side:
The limiting factor is not demand — it is technical incompatibility.
Even if user interest increases or Matter/Thread adoption grows, we still cannot integrate it because:
1. No production-ready Java Matter SDK exists
All currently available libraries are:
- experimental
- unmaintained
- Android-only JNI demos
- or NodeJS wrappers
None of these are suitable for a stable EMS environment.
2. There is no OSGi support
OpenEMS relies heavily on:
- dynamic OSGi services
- Gradle build system
- JVM modularity
Matter SDKs provide no OSGi bundles, no modular service structure, and no stable Java APIs.
3. Architectural mismatch
Matter today is built around:
- C++ controllers
- embedded devices
- Thread mesh networks
- border routers (Apple TV, Nest Hub, etc.)
OpenEMS is:
- a JVM-based controller
- running on industrial hardware
- not a Thread border router
- not a C++/embedded environment
These ecosystems simply do not align yet.
Conclusion
The idea of tracking market adoption makes sense, but regardless of demand, we currently cannot integrate Matter in a safe or production-ready way because the technical foundation for such an integration is missing.
We’re not waiting for demand —
we’re waiting for:
- a stable Java or JVM Matter SDK, and
- OSGi-compatible packaging
Once this exists, we can revisit the topic.
Until then, integrating Matter would pose more risk than benefit for OpenEMS.