HUIZHI-ChargeOS-cloud is a full open source EV charging platform for Spring Cloud teams

An operation platform, not a device firmware

HUIZHI-ChargeOS-cloud is the back end of the HUIZHI open source charging station platform, whose internal name is hcp-cloud. The README describes it as a Spring Cloud microservices based open source charging pile operation platform, built for modern charging pile management and operation, and it has two main parts: the operations management side and the mini program side.

The technology list in the README covers the whole stack. The back end is Spring Boot, the relational database is MySQL, the cache is Redis, and the front end is Vue 2 with Element UI. The original framework it grew from is vctgo-cloud, and the project states that features are synced from it periodically.

The product claims in the README are that the system is fully open source and commercially usable, that the front and back ends are separated so it works in a mini program, a public account, H5, an app and on the desktop, and that it is easy to install, use and further develop, with usage documentation, interface documentation, a data dictionary and secondary development documentation.

The honest framing is the sentence at the top of the README: an open source version will certainly not be perfect, but it will keep being updated, and problems should be raised as issues or discussed in the community group. That is a good sign about expectations and a warning about the finish level.

The module layout tells you the architecture

The repository top level is the clearest description of the system, because each directory is a deployable service or a shared piece.

There is hcp-gateway for the entry point, hcp-auth for authentication, hcp-register for service registration, hcp-api for the API surface, hcp-common for shared code, hcp-modules for the business modules, hcp-visual for the visualisation piece, and hcp-demo for demonstration code. Then there is sql for the database scripts, docker for container definitions, doc for the documentation, bin for helper scripts, and a pom.xml at the root, which is the Maven aggregator for the whole build.

A few files in that listing are worth a second look. A derby.log at the root is a leftover from an embedded database, which suggests the project was developed or demonstrated with Derby in the loop. And sscom5.13.1.exe with sscom51.ini is a Windows serial port utility, checked into the repository, which is the kind of thing a team does when they need to talk to a charging pile over a serial line during bring-up. Neither belongs in a clean repository, and both tell you about how the project was assembled in practice.

The sibling repositories complete the picture. The README links the microservice source under roinli/huige-ChargeOS-cloud, the charging management back end front end under roinli/HUIZHI-ChargeOS-admin, and the mini program under roinli/HUIZHI-ChargeOS-mini, and it states that the GitHub code takes priority over the Gitee mirror. A changelog is kept on a CSDN blog rather than in the repository, which is a Chinese development habit and a small inconvenience for anyone used to release notes in the tree.

The stack: MyBatis-Plus, Redisson and dynamic data sources

The technology table is the most detailed part of the README and it explains a lot about how the platform is built.

MyBatis-Plus is the database framework, chosen so that operations are done in Java with little SQL, and it comes with plugins for multi-tenancy, pagination and optimistic locking, which are exactly the three features a charging platform needs: isolated tenants, paged lists of devices and orders, and safe concurrent updates of device state.

The cache is Redis 5 to 7, reached through Redisson, described as the official recommended Netty based client, supporting more than 90 percent of commands, with safeguards underneath such as keys being converted to scan, and working in standalone, sentinel, single master cluster and multi master cluster modes. Spring-Cache is extended on top of it with expiry time, maximum idle time and maximum group size, so a cache declaration carries policy rather than needing hand written eviction code.

The multi-datasource framework is dynamic-datasource, which supports most databases, is managed through yml configuration, can add data sources from a front end page, and can switch data sources using spel expressions taken from request headers and parameters.

p6spy is included to print complete SQL and execution time for monitoring, and Jackson is the serialisation framework throughout, with Redisson also providing the distributed queue.

The one design decision that deserves scrutiny is the spel-based data source routing. It is a flexible way to route a request to a different database based on the caller, and in a multi-tenant platform that is convenient, but it also means the tenant boundary is enforced by an expression evaluated at runtime rather than by a fixed rule in the schema.

Multi-tenancy, time-of-use pricing and the pile simulator

The V3.0.8 update note in the README is the best summary of the current feature set, and it is written as a numbered list of capabilities:

V3.0.8 更新说明
1、全面拥抱微服务| 支持多租户
2、全面拥抱引入时序数据库
3、支持中电联互联互通协议
4、支持多租户
5、支持尖峰平谷

The visible entries read: a full embrace of microservices with multi-tenant support, the introduction of a time series database, support for the 中电联互联互通 protocol, support for peak, flat and valley pricing, device management, device ports, operation logs, login logs, multiple mini programs, object storage such as Alibaba Cloud OSS, Tencent Cloud COS and Qiniu Cloud Kodo, and an operations dashboard.

Multi-tenancy is described in the feature list as allowing several organisations to operate safely and independently on the same platform, sharing resources while keeping data isolated.

The pricing model is described as segmented or tiered pricing by charging period and power level, and the V3.0.8 note adds the peak, flat and valley tariff periods, which is the standard shape of Chinese electricity tariffs applied to charging sessions.

The charging pile simulator is the feature that makes the platform testable. The README describes a built-in simulation function for charging piles, which lets you identify and fix problems before going live rather than discovering them at a site with a real vehicle attached.

There is a catch worth knowing. The simulator module source is not in this repository. The README lists it as a community resource obtained from the group files after joining the WeChat group, alongside two professional solution decks for a SaaS car charging platform and a SaaS two-wheeler charging platform, hardware and software solutions. So the simulation support that the feature list claims is delivered outside the code you can clone.

Device protocols and the split into three repositories

The project description names the protocol support that distinguishes a Chinese charging platform from a generic management system: the 云快充 protocol versions 1.5 and 1.6, the 互联互通 interoperability standard, and multi-tenancy with segmented pricing. The V3.0.8 note adds the 中电联互联互通 protocol, which is the industry association variant of the interoperability standard.

The platform is therefore a three piece delivery. This repository is the microservice back end. The management back end front end is a separate repository, and the mini program is a third, which is the usual shape for a Chinese product that has to serve an operator on the desktop and an end user on a phone.

The project also links an online experience address, a site, and a documentation site, and the README asks people to raise issues or join the group to resolve problems. The community group is also where the release announcements and the extra resources live.

For an evaluator, the question to answer first is which piece you need. The back end alone is a large system to stand up, with a gateway, an auth service, a registry, business modules and a visual service. The front ends are separate projects with their own toolchains. Anyone budgeting this should treat it as a platform adoption rather than a library dependency, because the operational surface, including registration with the registry service and the deployment of every module, is the real cost.

What to check before you build on it

A few things deserve a decision before a team writes code against this platform.

The first is the licence, because the two sources disagree. The GitHub listing for this project records MIT, while the badge in the README reads GPL3.0. One of them is out of date, and since you are planning to run a commercially, the difference matters. Read the LICENSE file in the repository and settle it before you ship.

The second is the version and its cadence. The current version is 3.0.8, and the README points at a changelog hosted on a personal blog rather than at a tagged release, and the repository has no GitHub releases at all. So there is no version to pin in a build file and no history to diff.

The third is the parts that live outside the repository: the simulator source and the two solution decks are in the group files, and the front ends are in other repositories under a different name for the back end, with the GitHub copy of the microservice source listed under a huige-ChargeOS-cloud repository name rather than the HUIZHI one.

The fourth is the operating reality. This is a system that talks to physical hardware over the 云快充 and 互联互通 protocols, registers services, manages devices and meters sessions. The code gives you the platform, but the part that decides whether it works is the pile: the serial or network connection, the firmware version, and whether the operator's existing equipment speaks the protocol you enabled. That is why the simulator exists, and why obtaining it matters.

Editorial conclusion

Adopt HUIZHI-ChargeOS-cloud when you are building a charging station operation service in Java and need multi-tenancy, device management, protocol support and time-of-use pricing without buying a commercial platform outright. Do not adopt it expecting a finished product, because the README warns that the open source version will not be perfect, and because the pile simulator source and the solution decks are distributed through a chat group rather than the repository. Before you start, confirm the licence, since the GitHub listing records MIT while the README badge shows GPL3.0, read the documentation at doc.huizhidata.com, and plan for the operational work of running and registering real charging hardware, which no amount of source code removes.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. roinli/HUIZHI-ChargeOS-cloud on GitHub