Charger installation & configuration

What an installer, an electrician, or a charger vendor needs to connect any OCPP 1.6J unit to Neticks Charge.

The eight questions Architecture Connecting a charger OCPP messages Session lifecycle Troubleshooting Buying checklist Security & compliance

The eight questions, answered

These are the questions to put to a charger vendor in writing before you buy. Every one is a yes on this platform; each answer says exactly where the setting lives.

Yes 1. Can the charger use a custom OCPP 1.6J server URL?

Every station connects to a URL of the form wss://ev.neticks.com/ocpp/<ChargePointId>. That URL is generated for you on each station's OCPP tab, ready to paste into the charger's own configuration page. There is no vendor cloud in the path — the charger opens a WebSocket straight to this server and holds it open.

Console → Stations → (a station) → OCPP tab → Server URL

Yes 2. Can the WebSocket/WSS port and path be customised?

The path prefix is /ocpp and is set with the OCPP_PATH_PREFIX environment variable — change it to /ws, /ocpp16, or anything a particular firmware insists on. The port is whatever your deployment listens on: run behind nginx or a load balancer on 443 for wss://, or expose any other port directly. Both plain ws:// (bench) and wss:// (production) are accepted.

Environment: OCPP_PATH_PREFIX, OCPP_PUBLIC_URL · reverse proxy

Yes 3. Can I set a custom Charge Point ID?

You choose the ID when you register the station in the console — VISTAS-01, HOTEL-LOT-A-03, whatever your labelling scheme is. It is the last path segment of the OCPP URL, so the charger identifies itself simply by connecting. The server keeps a live ChargePointId → open socket registry and sends each command down the right socket.

Console → Stations → Register a station → Charge Point ID

Yes 4. Does it support a custom OCPP username and password?

Each station has its own credentials, checked as HTTP Basic authentication on the WebSocket upgrade — this is OCPP 1.6 Security Profile 1 (Basic auth over TLS). Set them per station, or click Generate for a strong random password. A station with no credentials is accepted for bench testing; once credentials exist they are enforced, and a wrong password closes the connection with a policy-violation code and writes an audit entry.

Console → Stations → (a station) → OCPP tab → Credentials

Yes 5. Can the charger connect directly to my own OCPP server?

That is the whole design. The charge point is the WebSocket client, this server is the CSMS, and nothing else sits in between — no manufacturer's back end, no subscription, no API we do not control. Any unit that is genuinely OCPP 1.6J with a configurable server URL works, which means chargers are commodity hardware you can swap by brand without touching the software.

Architecture — see the diagram below

Yes 6. Are RemoteStartTransaction and RemoteStopTransaction supported?

Both are implemented and used in anger. A public session is started by RemoteStartTransaction the moment Stripe confirms the authorization hold, and stopped by RemoteStopTransaction when the driver taps Stop or an administrator does. You can also fire either by hand from the station page to test a unit on the bench. Reset, UnlockConnector, ChangeAvailability, ChangeConfiguration, GetConfiguration and TriggerMessage are supported too.

Console → Stations → (a station) → Remote control

Yes 7. Does it read MeterValues including kWh consumption?

MeterValues are consumed continuously and stored per session. We read Energy.Active.Import.Register (normalised whether the charger reports Wh or kWh), Power.Active.Import for live kW, and SoC when the car provides it. Energy delivered is meterStop − meterStart, and the running total is what the driver watches climb on their phone. The sample interval (60s by default) and the measurand list are pushed down to the charger with ChangeConfiguration from the station's OCPP tab.

Console → Stations → (a station) → OCPP tab → Push configuration

Yes 8. Can I use my own QR code and payment system (Stripe)?

Every station gets its own QR code and a print-ready placard, generated here — the QR encodes that station's pay page, so a payment is tied to the exact physical unit. Payments run on your customer's own Stripe account: each customer stores their own secret, publishable and webhook keys, and money lands in their balance, never ours. The flow is a manual-capture PaymentIntent — authorise a hold at the start, capture exactly kWh × rate at the end, release the rest. If a placard is defaced or stolen, rotate the QR token and the old sticker stops working without touching the charger.

Console → Stations → QR tab · Console → Stripe Settings

How it fits together

The charger dials out to this server over a persistent OCPP WebSocket and holds the line open. The server drives it (start/stop) and reads energy. Stripe talks only to the server, over signed webhooks. The charger and Stripe never talk to each other — the server is the middle.

 Driver phone ──scan QR──▶  Pay page  ──▶  Stripe (PaymentIntent, manual capture)
      ▲                        │                          │
      │ receipt PDF            │                    Signed WEBHOOK (HTTPS)
      │                        ▼                          ▼
 ┌──────────────────────────────────────────────────────────────────┐
 │                Neticks Charge — CSMS + API + console                │
 │  OCPP 1.6J WebSocket · Sessions · Pricing · Payments · Invoicing  │
 └──────────────────────────────────────────────────────────────────┘
      ▲  wss:// (OCPP 1.6J, persistent)              │  SQL
      │  charger dials out via 4G / WiFi / Ethernet  ▼
 ┌───────────────┐                            ┌──────────────┐
 │  EV CHARGER   │  ID = VISTAS-01            │  PostgreSQL  │
 │ (J1772, OCPP) │  RFID reader on unit       │  or SQLite   │
 └───────────────┘                            └──────────────┘

Key concept: the charger is the client; this server is the server. The charger opens the connection and identifies itself by its Charge Point ID — the last segment of the URL. The server keeps a live ID → open socket map and sends each command down the right socket. Each QR code encodes its own station's ID, so a payment is always tied to the exact physical unit.

Connecting a charger

Register the station in the console and choose its Charge Point ID (for example VISTAS-01).
Set credentials on the station's OCPP tab, or generate a strong password there.
Open the charger's own configuration page — usually its built-in web interface or a vendor app.
Enter the OCPP settings exactly as the console shows them.
Reboot the charger. It should appear as connected within a minute or two.
Push the metering configuration from the OCPP tab so it reports kWh at the right interval.
Print the QR placard and fit it to the unit.
Run one test session end to end before the station goes public.

Connection reference

Setting	Value
Server URL	`wss://ev.neticks.com/ocpp/VISTAS-01`
Protocol	`OCPP 1.6J (JSON over WebSocket)`
WebSocket subprotocol	`ocpp1.6`
Path prefix	`/ocpp`
Charge Point ID	`VISTAS-01`
Authentication	`HTTP Basic on the upgrade (Security Profile 1)`
Heartbeat interval	`30 s`
MeterValues interval	`60 s`
MeterValues measurands	`Energy.Active.Import.Register, Power.Active.Import`

Some firmware asks for the URL and the Charge Point ID as separate fields, others for one combined URL. If they are separate, give the base wss://ev.neticks.com/ocpp as the URL and the ID on its own — the charger appends it. If a unit refuses wss://, its firmware may not trust your certificate authority; prove the wiring with a plain ws:// bench test first, then fix the certificate before the unit goes outside.

OCPP messages we speak

From the charger to us

Message	What we do with it
`BootNotification`	Charger announces itself; we accept, park as pending, or reject.
`Heartbeat`	Keeps the socket alive and drives the online/offline flag.
`StatusNotification`	Connector state: Available, Preparing, Charging, Finishing, Faulted.
`Authorize`	RFID card presented; we check it belongs to this station's customer.
`StartTransaction`	Energy starts; we assign the transaction id and open the session.
`MeterValues`	Cumulative energy, live power, state of charge.
`StopTransaction`	Final meter reading; we compute cost and capture the payment.
`DataTransfer`	Vendor extensions — acknowledged, not acted on.
`FirmwareStatusNotification`	Firmware update progress.
`DiagnosticsStatusNotification`	Diagnostics upload progress.

From us to the charger

Message	When we send it
`RemoteStartTransaction`	Close the relay once the hold is authorised.
`RemoteStopTransaction`	Open the relay when the driver or an admin stops.
`ChangeConfiguration`	Push heartbeat and MeterValues settings.
`GetConfiguration`	Read back what the charger thinks its settings are.
`Reset`	Soft or hard reboot.
`UnlockConnector`	Release a stuck cable.
`ChangeAvailability`	Take a connector in or out of service.
`TriggerMessage`	Ask for an immediate MeterValues or StatusNotification.

Session lifecycle

A public session paid by QR code:

Charger boots ──▶ BootNotification ──▶ server replies Accepted
every ~30s     ──▶ Heartbeat
car plugged in ──▶ StatusNotification (Preparing)
── Driver scans QR → pays → Stripe webhook hits the server ──
server ──▶ RemoteStartTransaction(VISTAS-01) ──▶ charger closes relay → power ON
charger ──▶ StartTransaction (meter start reading)
charger ──▶ MeterValues (kWh) every ~60s   ← server tracks energy live
driver taps Stop ──▶ RemoteStopTransaction ──▶ relay OPEN → power OFF
charger ──▶ StopTransaction (final meter reading)
server: final kWh × rate → capture the Stripe payment → email the PDF receipt

A member skips the QR and Stripe steps: they tap an RFID card, the charger sends Authorize(idTag), we check the card is active and belongs to this station's customer, and accept. Their energy is logged and rolled into a monthly invoice.

Troubleshooting

Symptom	Usual cause	What to do
The station never appears in the console	The charger cannot reach the server, or the URL is wrong.	Check the URL ends with the exact Charge Point ID and uses `ws://` or `wss://` (not `http`). Confirm the unit has network. If TLS fails, the charger may not trust your certificate authority — try a plain `ws://` bench test first to isolate it.
It shows as Pending and refuses to charge	The charge point dialled in but is not assigned to a customer.	Open Stations, find it in the pending list, and assign it to a customer account. Then reboot the unit (or wait for its next BootNotification) so it receives `Accepted`.
The connection is refused immediately	Wrong OCPP username/password, or the station was rejected.	Re-enter the credentials from the station's OCPP tab exactly, including case. Check the Activity Log for `ocpp_auth_failed` entries.
kWh stays at zero while charging	The charger is not sending MeterValues, or sends a measurand we are not reading.	Use Push configuration on the OCPP tab to set `MeterValueSampleInterval` and `MeterValuesSampledData`. Some firmware needs a reboot for these to take. Confirm the unit actually has an energy meter.
The driver paid but nothing happened	The Stripe webhook is not reaching us, or the charger refused RemoteStart.	Check the webhook URL and signing secret in Stripe Settings. The Activity Log records both `payment_authorized` and `remote_start`; whichever is missing tells you which side to look at. Holds on sessions that never start are released automatically after 30 minutes.
The card is rejected at the reader	The card is unknown, inactive, expired, or belongs to another customer.	Cards are valid only on stations belonging to the same customer. Check RFID Cards, and look for `authorize_denied` in the Activity Log to see the exact idTag the charger sent.

Buying checklist

Get these confirmed in writing before you order more than one unit.

Configurable OCPP 1.6J server URL (no vendor-cloud dependency)
Accepts wss:// with a public CA certificate
Configurable Charge Point ID
OCPP Basic authentication (Security Profile 1) supported
RemoteStartTransaction and RemoteStopTransaction obeyed
MeterValues with Energy.Active.Import.Register, interval configurable
Revenue-grade / certified meter (MID in the EU, NTEP-style in the US)
J1772 240 V, 50 A / 11 kW (or the connector standard for your market)
4G/SIM, Wi-Fi or Ethernet backhaul
On-board RFID reader that sends Authorize(idTag)
UL/ETL listed — required for the permit, the inspection and the insurance
Outdoor rated IP54 or better; pedestal if it is a street installation
Seller supplies the OCPP configuration manual in writing
Order one sample, validate it against this server, then order the rest

Security & compliance

WSS/TLS for the OCPP connection, plus HTTP Basic per station (Security Profile 1).
Stripe webhook signatures are verified against each customer's own signing secret; an unsigned payload is refused. Card data never touches this server — PCI scope stays with Stripe.
UL/ETL-listed hardware for the permit, the inspection and the insurance.
A revenue-grade meter is what makes per-kWh billing legal — MID in the EU, NTEP-style in the US. If a unit's meter is not certified, bill by time or by session until it is.
Governance: document who owns the software and where revenue flows, so the system survives if the person who built it is unavailable.