NeLeSo OCPP Gateway · Features
Keep your charging infrastructure. Choose your backends and how you use your data.
The OCPP Broker connects your charge points to their operational backend and additional systems. Manage data access and routing, deliver events to your own applications and investigate faults in a shared interface.
OCPP & routing
Connect existing backend environments and evaluate new target systems step by step.
Routing by Charge Point ID over WS/WSS. Station and target use the same protocol version; the Broker does not automatically translate between versions.
Each station can connect to one primary backend and up to eight additional backends. A passive observer receives approved events. A virtual connection presents a separate OCPP view to the additional backend.
Review targets, data filters and assignments before changing a route. Plan the switch around your stations, connections and operating procedures.
Sites & permissions
Manage sites and fleets together while defining each party’s responsibilities.
Organise stations, filter inventories and apply routing profiles to multiple stations after reviewing a preview.
Assign a defined station scope to partners, user accounts and API keys. Roles determine which functions are available within that scope.
Access to data does not grant permission to send station commands. For additional OCPP backends, station scope, permitted data actions and control actions are configured separately.
HTTPS & MQTT
Use meter values, session events and operational data for analytics, storage or further applications.
Send data to configured HTTPS endpoints or MQTT brokers. MQTT 3.1.1 and MQTT 5 are available with TLS, QoS 1 and non-retained messages. The Broker publishes data; it does not subscribe to control channels.
A PostgreSQL outbox preserves pending deliveries across restarts. Bounded queues, retries and ordered delivery per station and target make backlogs traceable.
The event ID links every output to its source. Each output also has a delivery ID that stays the same on retries. Recipients can recognise duplicates even when a workflow produces several outputs. Delivery status, errors and backlogs are visible.
NATS JetStream
Optional export to your NATS instance, with targeted message selection and visible reception in a web test client. Available according to the installed release and agreed scope.
Select CALL, CALLRESULT and CALLERROR by OCPP action, Charge Point ID and direction. Responses are associated with their request where correlation is available.
Manage the target connection and filters, inspect runtime status and publish a labelled test message with a JetStream storage acknowledgement.
Accepted messages are stored according to the configured JetStream retention. Your own web client displays subject, timestamp and content. Redelivery is possible; consumers must handle duplicates.
NATS export in the Gateway uses a bounded queue within each process. A restart can discard messages that have not yet been published. Runtime status exposes queue overflows and publication errors.
Visual workflows
Build workflows in the browser and test them without side effects before activation.
Combine event and time triggers, filters, conditions, branches, field mapping and delays with alarm, HTTPS or MQTT outputs. Workflows are directed graphs without loops.
Save changes as a draft, publish a version, restore earlier versions and deactivate workflows. A dry run shows the execution path and planned outputs without sending messages or creating alarms.
Waiting steps resume after a restart. A delay uses the original event data. Arbitrary scripts and physical station commands are not workflow building blocks.
The MQTT destination is explicitly selected before publication.
Diagnostics & alarms
Connect current states with historical records and act on recurring problems.
Open event timelines and views covering days, weeks or months. Filter by station, site, group and period to investigate connection problems and repeated errors.
Monitor station and backend outages, repeated errors or delivery backlogs with minimum durations, reminders and escalation. Report incidents per station or across a selected inventory.
Acknowledge alarms and wait for stable recovery. Missing or stale telemetry is treated as unknown; it does not establish that normal operation has resumed.
Review station states and charging history in the interface. The digital twin records observed station states and transactions at the external primary backend. Gaps in the data remain visible.
MCP & AI queries
The MCP server connects enabled installations to ChatGPT or Claude. Ask natural-language questions about stations, charging sessions, routing and selected charger parameters.
Check connection states, search and summarise charging sessions, or inspect the backends assigned to a station.
Mini-CPMS history and observed Broker history remain separate. Responses include their source, timestamps and known data gaps; missing or stale values remain explicitly unknown.
Query approved configuration values through OCPP 1.6 GetConfiguration or OCPP 2.0.1 GetVariables. MCP access remains read-only: configuration changes, start/stop and reset are outside its scope.
Administrators explicitly enable personal Broker accounts. Enabled accounts can read the entire installation. Connections can be revoked individually, and tool calls are logged.
Command priorities
Order authorised requests from different sources before they reach the station.
Configure priorities for the primary backend, local operation/API and additional virtual backends. Requests with the same priority are handled in arrival order.
Priorities apply to requests that have not been sent. Queue length, data volume and waiting time are bounded, with at most one physical command awaiting a reply per station.
Permissions and the connection are checked again before sending. A command already sent is neither interrupted nor automatically sent again after an uncertain result.
Your infrastructure
Run on customer-managed Linux with Docker Compose and PostgreSQL, in your data centre, cloud tenant or at the site.
A lightweight Mini-CPMS is available as a local primary target for station states, charging sessions and RFID authorisation. External primary backends can still be selected per station.
Encrypted connections, protected credentials and traceable changes support operations. Your IT team manages networking, certificates, backups and restoration.
Integrate inventory and operational information into your applications through a documented REST API. API keys, roles and station permissions limit access.
Defaults are 30 days for the event journal and completed workflow runs, and 365 days for resolved alarms. Pending deliveries are retained; retention periods can be adjusted to your operations.
Operating boundaries
OCPP acknowledgements to the physical station and charging authorisation remain the responsibility of the primary operational backend. This can be an external system or the integrated CoreCPMS. An additional backend does not automatically take over during an outage.
Durable buffering is available for HTTPS/MQTT data exports and approved virtual additional connections. It starts once the data has been committed to the database. It does not provide local acknowledgements for primary messages or automatic charging control when a cloud backend is unavailable. A passive observer is not a durable replay destination.
Your use case
We review your existing backends, data destinations and partner access with you and define the appropriate operating scope.