# SimItNow use cases for AI agents

Seven testing scenarios an agent can run with the REST API. Each one lists what it needs, the operations to call, what a good result looks like and where SimItNow stops. Read https://www.simitnow.com/ai-quickstart.md first: it explains the key check, the `sim` helper used below, polling and cleanup, and every command here is an operation in https://www.simitnow.com/openapi.json. The limits of each plan are in https://www.simitnow.com/llms.txt.

Two rules apply to all of them. SimItNow shows what the simulator did, and only your CSMS shows what it recorded, so check both before you report a pass. And delete what you create, also when a step fails.

## 1. Test an OCPP 1.6 CSMS with 100 virtual charge points

Needs: a CSMS reachable over the internet (`ws://` or `wss://`), 100 station ids that are yours, and an account that can hold them. A Free account cannot: it has a safety limit on stations and 500 messages a day. Every station sends BootNotification, StatusNotification, Heartbeats and meter values, and each message counts, so work out the run's messages before you start.

Operations:

```bash
for n in $(seq 1 100); do
  sim -X PUT https://api.simitnow.com/v2/cs/ai-run1-cp-$n -d "{\"csmsUrl\":\"$CSMS_URL\",\"protocol\":\"ocpp1.6\"}"
done
sim -X GET https://api.simitnow.com/v2/cs/ai-run1-cp-1
```

Create a few first and read one station back, then scale. Count the stations whose info answers 200 with `network.connected` `true` instead of assuming all 100 connected (a 409 `connecting` means not yet): a CSMS that refuses connections over a cap makes a station retry with a growing wait, up to about a minute, and never give up.

Expect: 100 chargepoints connected at your CSMS, each having sent BootNotification. Check the count on your CSMS.

Limits: a 429 on create means a limit (see the quickstart's Errors table); stop and report it. Settings your CSMS changes on a station are lost if the station restarts.

More: https://www.simitnow.com/articles/multiple-transactions-concurrent-ocpp

## 2. Validate an OCPP 2.0.1 backend integration

Needs: a CSMS that speaks OCPP 2.0.1, one station and one vehicle.

Operations:

```bash
sim -X PUT https://api.simitnow.com/v2/cs/ai-run2-cp-1 -d "{\"csmsUrl\":\"$CSMS_URL\",\"protocol\":\"ocpp2.0.1\",\"evseCount\":2,\"connectorsPerEvse\":1,\"authorizeLocalStart\":false}"
sim -X PUT https://api.simitnow.com/v2/ev/ai-run2-ev-1 -d '{"batteryCapacity":60,"initialSoc":20}'
sim -X POST https://api.simitnow.com/v2/ev/ai-run2-ev-1/connection -d '{"cbId":"ai-run2-cp-1","connectorId":1}'
sim -X GET https://api.simitnow.com/v2/ev/ai-run2-ev-1
```

Plugging the vehicle in already starts the transaction on 2.0.1, so do not call the transactions operation after it (you would get a 409). With `authorizeLocalStart` left at its default the station sends Authorize first and starts only if your CSMS answers Accepted; that call waits up to 10 seconds, so allow a longer timeout.

Expect: your CSMS receives BootNotification, StatusNotification, a TransactionEvent Started, then an Updated event with `chargingState` `Charging` once energy flows, then periodic Updated events with meter values, and the vehicle's `soc` rises. Stop with `DELETE /v2/cs/ai-run2-cp-1/transactions/<id>` (the id is on your CSMS) and check TransactionEvent Ended.

Limits: an EVSE takes one transaction at a time. Requests for ISO 15118 certificates are declined, and a station answers every request your CSMS sends. Reference: https://www.simitnow.com/docs#cs-tx-start

## 3. Simulate several concurrent charging sessions

Needs: one station with several connectors (or several stations) and one vehicle per connector.

Operations:

```bash
sim -X PUT https://api.simitnow.com/v2/cs/ai-run3-cp-1 -d "{\"csmsUrl\":\"$CSMS_URL\",\"protocol\":\"ocpp1.6\",\"connectorCount\":4}"
sim -X PUT https://api.simitnow.com/v2/ev/ai-run3-ev-1 -d '{"batteryCapacity":60,"initialSoc":20}'
sim -X POST https://api.simitnow.com/v2/ev/ai-run3-ev-1/connection -d '{"cbId":"ai-run3-cp-1","connectorId":1}'
sim -X POST https://api.simitnow.com/v2/cs/ai-run3-cp-1/transactions -d '{"connectorId":1}'
```

Repeat the last three for connectors 2 to 4 once each connector reads `Preparing` in `GET /v2/cs/ai-run3-cp-1`.

Expect: four open transactions at your CSMS at the same time, each with its own meter values.

Limits: on OCPP 2.0.1 and 2.1 each EVSE takes one transaction at a time, so give the station one EVSE per session (`evseCount`). Every session adds messages to your daily allowance. More: https://www.simitnow.com/articles/multiple-transactions-concurrent-ocpp

## 4. Test reconnection after a network interruption

Needs: a connected station with a running transaction (see the quickstart, section 4).

Operations:

```bash
sim -X POST https://api.simitnow.com/v2/cs/ai-run4-cp-1/network/disconnect -d '{"duration":60}'
sim -X GET https://api.simitnow.com/v2/cs/ai-run4-cp-1
sim -X POST https://api.simitnow.com/v2/cs/ai-run4-cp-1/network/connect
```

Poll the station during the outage: `network.connected` is `false` and `network.queuedMessages` grows. Use `network/connect` to end an outage early, or give no `duration` to stay offline until you do. `POST .../network/power-loss` is the harder variant: it stops every active transaction with reason PowerLoss and then goes offline.

Expect: when the connection returns, your CSMS receives the messages produced offline, in order, and `queuedMessages` falls back to 0.

Limits: RemoteStartTransaction cannot reach a disconnected station. A station held back by the daily allowance shows `network.quotaPause` and does not reconnect until then. More: https://www.simitnow.com/articles/ocpp-offline-transactions-reconnect-testing

## 5. Automate regression tests in CI/CD

Needs: the API key as a CI secret, a CSMS the CI runner can reach, and ids that include the run number so parallel runs never collide (for example `ai-$CI_RUN_ID-cp-1`).

Operations: the quickstart's complete example (section 8) is a CI job as it stands. It exits 0 only when every session charged, prints a result per station and deletes what it created, also on failure. Add assertions on your CSMS side after it, and fail the job when they fail.

Expect: a red job when the CSMS mishandles a session and a green job when it does not, with no resources left on the account.

Limits: a failed run that never reached the cleanup (a killed runner) leaves stations behind, and stations count toward the account's limits and keep sending messages; delete leftovers by their run prefix at the start of the next run. More: https://www.simitnow.com/articles/ocpp-testing-cicd-pipeline

## 6. Test an eMSP integration against the OCPI CPO interface

Needs: a private hosted CSMS, one registered chargepoint with a simulated station connected to it, and an eMSP that can reach https://ocpi.simitnow.com/ocpi/versions.

Operations:

```bash
sim -X PUT https://api.simitnow.com/v2/csms -d '{"public":false}'
sim -X PUT https://api.simitnow.com/v2/csms/cp/ai-run6-cp-1 -d '{"displayName":"OCPI test chargepoint"}'
```

The second call returns a one-time `password` and the `wsUrl`. Create a station that dials it: `csmsUrl` is the `wsUrl` without the chargepoint id, and `security.basicAuth.password` is the password (the user name defaults to the station id). Then, on the dashboard's OCPI tab, generate Token A and give it with the versions URL to your eMSP, which posts its credentials. The eMSP can now read locations and tariffs, push tokens and send START_SESSION and STOP_SESSION. After START_SESSION, plug a vehicle into the station within 5 minutes:

```bash
sim -X POST https://api.simitnow.com/v2/ev/ai-run6-ev-1/connection -d '{"cbId":"ai-run6-cp-1","connectorId":1}'
```

Expect: the session appears on the eMSP side, ends with STOP_SESSION and produces a CDR. The dashboard's OCPI tab lists the calls it saw.

Limits: OCPI 2.2.1 only, CPO role only, no roaming hub, and OCPI calls count against the same daily allowance as OCPP messages. On an OCPP 2.x chargepoint START_SESSION is answered ACCEPTED and its CommandResult is NOT_SUPPORTED. RESERVE_NOW, CANCEL_RESERVATION and UNLOCK_CONNECTOR answer NOT_SUPPORTED. Token A, the OCPI tab and the eMSP's side are not API-key operations, so ask the account owner for them. Reference: https://www.simitnow.com/docs#ocpi

## 7. Validate remote start and stop commands

Needs: your CSMS, which sends the commands, and a connected station. The REST API does not send OCPP commands to a station: the CSMS does.

Operations: create a station and a vehicle as in the quickstart and plug the vehicle in. Then send RemoteStartTransaction from your CSMS (RequestStartTransaction on 2.0.1 and 2.1) and read the station:

```bash
sim -X GET https://api.simitnow.com/v2/cs/ai-run7-cp-1
sim -X GET https://api.simitnow.com/v2/ev/ai-run7-ev-1
```

To test how your CSMS handles a station that refuses, create it with `"emulateRemoteStartRejected":true` (every remote start answers Rejected) or `"emulateRemoteStartFailsToStartCharging":true` (the start is accepted and charging never begins).

Expect: the connector reads `Charging` and the vehicle's `soc` rises; after RemoteStopTransaction the transaction ends. For the refusing station, your CSMS shows Rejected, or an accepted start with no transaction.

Limits: a disconnected station cannot receive a command. On the hosted CSMS the remote start and stop buttons are on the dashboard, and OCPI START_SESSION and STOP_SESSION reach it too; neither is an API-key operation. Reference: https://www.simitnow.com/docs#cs-create