ABL wallbox component evse.checkpoint.abl (created with Claude) #3428
Conversation
This skill provides comprehensive guidance for creating new Edge components including controllers, meters, batteries, and other device types. It includes: - Complete file structure templates - Step-by-step creation process - Code templates for all necessary files - Best practices and common patterns - Real examples from the codebase The skill automates the component creation workflow and ensures consistency with existing OpenEMS Edge component patterns.
… code. (first shot) co-authored-by: claude@anthropic.com
Created a detailed guide for AI assistants working with the OpenEMS codebase, including: - Project overview and component architecture (Edge, Backend, UI) - Complete repository structure and module organization - Technology stack (Java 21, OSGi, Angular 20, Ionic 8) - Build system documentation (Gradle + Bnd) - Development workflows and best practices - Code organization patterns (Component, Config, Nature, Controller) - Testing guidelines and examples - Key conventions and coding standards - Common tasks and quick reference - Important files and entry points This documentation will help AI assistants understand the codebase structure, follow proper development workflows, and maintain consistency with project conventions. co-authored-by: claude@anthropic.com
… as Modbus TCP), including extensive test suite and simulator for manual testing co-authored-by: claude@anthropic.com
…qBtFFPoLETAScvtKdZMW
https://github.com/janklostermann/openems into claude/edge-components-skill-017PqBtFFPoLETAScvtKdZMW
janklostermann
changed the title
There was a problem hiding this comment.
why has these files been changed? Speaking of AI..
There was a problem hiding this comment.
The change of the .project files was completely independent of AI. It happened as I opened the project with VSCode (initiated by following the Gitpod (now ona) route as recommended in the documentation for the UI) as I was trying to get a working complete dev environment up and running.
It seems to happen as soon as you open the project with VScode, having the JAVA plugins installed. I tried it more than once and I thought VSCode is common enough to allow this into the codebase. As the .project file is in there already.
There was a problem hiding this comment.
https://openems.github.io/openems.io/openems/latest/ui/setup-ide.html#_setup_visual_studio_code
as recommended in the documentation for the UI
Yes, you name it ! :)
Backend/Edge = Eclipse
UI = Visual Studio Code
Also in the Getting Started you can see "Clone" and not "Develop in Online IDE" - GitPod has been used to SIMULATE only in the past (before they completely refactored GitPod to an AI Assistant)
There was a problem hiding this comment.
Obviously I missed tools/prepare-commit.sh, which should have resolved the trouble with the .project files, if I understood it right.
| import io.openems.edge.evse.chargepoint.abl.enums.ChargingState; | ||
|
|
||
| /** | ||
| * Main ABL EVCC2/3 Modbus TCP simulator. |
There was a problem hiding this comment.
We have a whole Modbus Dummy Service for this - so why developing something new and not using the Intended Test Setup as in the Other Components?
There was a problem hiding this comment.
Due to a lack of knowledge and deep understanding of the inner workings of the project...
Sorry, this sounds like a refactoring needed to use the Modbus Dummy Service.
Also for such ramp-up in learning what to use and what not, which things already exist (e.g. in the Modbus Dummy Service), I find it helpful to have up-to-date guiding documents (like the .claude/skill/edge-component.md), not just for the AI but also for humans.
There was a problem hiding this comment.
I find it helpful to have up-to-date guiding documents (like the .claude/skill/edge-component.md), not just for the AI but also for humans.
I get your point, but this is again a thing for your local Project and not for everyone using and developing in OpenEMS as most of the devs actually can develop in OpenEMS (do not understand me wrong, we need devs and I love to see new devs on here aswell, but "bad-written-code" or "hallucinated code" does not help anybody aswell
There was a problem hiding this comment.
I am with you: bad-written (in-understandable), not-working, un-tested and un-maintainable code does not help anybody. And the lines are blurry. Working code easily let's close the eyes on the other - I have seen it too often.
What I do not understand: Why should up-do-date guiding documents be a private thing, and not be shared with fellow developers, for joint improvement? The project's documentation is in essence nothing else, done traditionally for humans. I can see @da-Kai 's point, that improving this documentation you consider more valuable. But there are things, I want to tell the AI, that I would not dare to bother a human with - they might believe I think they are idiots. Which I don't!
There was a problem hiding this comment.
Beyond that: With AI-generated code maybe it would be helpful to mark it as such. As the Linux kernel had the tainted flag, when linked with closed-source drivers. Then different rules applied.
For components created by AI, such a flag could mean level-up the acceptance criteria for testing (functional, non-functional (incl. performance), coding standards, requirement documentation, etc., maybe even including prompts, that allow to re-generate the code to adjust to new needs without a human forced to dig into the generated code...
|
I would suggest to not merge this PullRequest into the project's |
…skill Added comprehensive section (Step 10a) covering: - When and how to use DummyModbusBridge for testing Modbus components - All register configuration methods (withRegisters, withInputRegisters, withRegistersFloat32) - 6 complete examples from the codebase: * Simple meter (Eastron SDM120) * Complex meter with registers (Janitza UMG104) * Float32 meter (Fronius) * ESS component (Fenecon Mini) * EVCS charger with helper method (KEBA) * Dynamic register updates during tests - Best practices for Modbus testing - Register value encoding guide (integer, long, float32, boolean) - Troubleshooting common issues - Required dependencies and config parameters This ensures all Modbus-based components (meters, ESS, EVCS, inverters, battery systems) are tested consistently using the standard test infrastructure.
Also please read the: https://openems.github.io/openems.io/openems/latest/contribute/coding-guidelines.html |
|
I have read this and tried it. Not only once. For days.
Unfortunately I didn't get it up and running. Somehow I couldn't get it working, whatever I did wrong. (First it was an Eclipse version from 2024. Which I never have guessed to have such a big impact on building the project with gradle. Simon then recommended upgrading. Then I could build edge...)
With the help of AI and building in an environment where AI can directly help (VScode), I finally got it working together with UI as well. Without that help, I might have given up eventually...
Am 18. November 2025 14:08:15 MEZ schrieb Johannes Haller ***@***.***>:
@Sn0w3y commented on this pull request.
On cnf/.project:
https://openems.github.io/openems.io/openems/latest/gettingstarted.html#_setup_eclipse_ide_for_openems_edge_and_backend
> as recommended in the documentation for the UI
--
Reply to this email directly or view it on GitHub:
#3428 (comment)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
--
Jan Klostermann
Klostermann Engineering
AI Transformation Partner
Von /e/ Mail gesendet.
|
To be honest I do not understand why because many others have had no Issues setting it up. Also the Documentation on Getting Started is VERY detailled. AI is NOT always helpful. Especially in BIG Projects/Developments, where one needs to UNDERSTAND the Context and not only "Predict" or rely on Algorythms. |
…MS#3382) Bumps [actions/upload-artifact](https://github.com/actions/upload-artifact) from 4 to 5. - [Release notes](https://github.com/actions/upload-artifact/releases) - [Commits](actions/upload-artifact@v4...v5) --- updated-dependencies: - dependency-name: actions/upload-artifact dependency-version: '5' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…ith just the UI for edge development up and running
…ructure, did some minor fixes
…g the default setting of the tools/docker/ui/docker-compose.yml after running the start-dev-ui.sh under WSL2
…k, and requirement collection.
``` please revise the skill at .claude/skills/edge-component.md using opus instead of sonnet for profound analysis and the best suggestions to make claude with this skill the perfect openems component creator, collaborating well with the user to get the best understanding of what is needed for such a component and how to best implement it. Make sure it also helps with carefully improving existing code of components. ``` + plus additional fixes (e.g. related to md vs. adoc) co-authored-by: claude@anthropic.com
… .project changes reversed by prepare-commit.sh Summary of Improvements High Priority Changes (Completed) Change 10: Fixed EV_CONNECTED Type Safety Issue ✅ - Changed getEvConnectedChannel() return type from IntegerReadChannel to BooleanReadChannel - Added proper Value<Boolean> getEvConnected() accessor - Updated implementation to use correct type - Impact: Bug fix, improved type safety Change 1: Completed Channel Metadata ✅ - Added proper units (AMPERE, MILLIAMPERE) to all channels - Set persistence priorities (HIGH for state/connection, VERY_LOW for instantaneous values) - Added descriptive text for all channels - Enhanced JavaDoc documentation - Impact: Better data persistence, UI integration, documentation Change 4: Completed Interface API Methods ✅ - Added getter methods for all phase currents (L1, L2, L3) - Added Value<> accessors for convenience - Added getters for DEVICE_ID and FIRMWARE_VERSION - Impact: Complete, usable API Medium/Low Priority Changes (Completed) Change 2: Updated Bundle Vendor ✅ - Changed from "FENECON GmbH" to "OpenEMS Association e.V." - Impact: Project standards compliance Change 6: Removed Duplicate Markdown Files ✅ - Removed TEST_README.md, INTEGRATION_GUIDE.md, TESTING_PATTERNS.md - Kept only .adoc versions per project standards - Impact: Single source of truth Change 7: Enhanced Config Documentation ✅ - Detailed descriptions for all configuration parameters - Added usage guidance, valid ranges, and impact notes - Impact: Better user experience, clearer configuration Change 3: Created requirements.adoc ✅ - Comprehensive requirements specification document - 12 functional requirements with acceptance criteria and test cases - Complete channel and configuration documentation - Impact: Complete documentation, easier onboarding Test Results ✅ - All tests pass: 24 test cases, 100% success rate - Checkstyle clean: No violations - No regressions: All existing functionality preserved Files Modified 1. src/.../EvseChargePointAbl.java - Interface with complete API and metadata 2. src/.../EvseChargePointAblImpl.java - Updated to use correct types 3. src/.../Config.java - Enhanced configuration documentation 4. bnd.bnd - Updated vendor information 5. doc/requirements.adoc - NEW: Complete requirements specification 6. doc/improvement-proposal.adoc - NEW: Improvement documentation Files Deleted - TEST_README.md - INTEGRATION_GUIDE.md - TESTING_PATTERNS.md co-authored-by: claude@anthropic.com
co-authored-by: claude@anthropic.com
…unication with a physical ABL-eMH1 device co-authored-by: claude@anthropic.com
… testing of the whole communication path incl. Modbus/ASCII->Modbus/TCP-Gateway co-authored-by: claude@anthropic.com
3 participants
This is the implementation of evse.chargepoint.abl for the ABL Wallbox eMH1. It uses ModbusTCP (connected to hardware via a modbus gateway to modbus ascii).
It was mainly created by claude@anthropic.com. Therefore it also contains a starting point for a AI skill to create such components. It is equipped with a test suite and also a simulator for testing the component and also the connection to an existing hardware. Due to a lack of the hardware connection in the moment, I could not test it in real life yet.