Example: HTTP request emulator for SteVe control panel

[DeltaVetal26]

Hi,

I had the task of accessing the SteVe control panel from a php script so that I could automate the process of sending commands to the station.

While there is no official API, this can simplify the task for those who want to connect charging points with Home Assistant and other systems.

I did it for the first time, but it works.

Theory: 1) We turn to the php file through curl, indicating in the parameters the command, the number of the charging point, etc.). 2) Steve will redirect the team to the charging point.

Implemented commands: 1) Get connector state (Return state) 2) UnlockConnector (Not return) 3) DataTransfer (Return response) 4) RemoteStartTransaction (Not return) 5) RemoteStopTransaction (Not return)

Example: Get connector state

curl "http://youraddress/main.php?Key=YourKey&ChargeBoxID=001&cmd=getConnectorState&ConnectorID=2" Return: Available

This script has only a few basic commands, you can add new ones by template.

Repository - https://github.com/DeltaVetal26/SteVe-OCPP-HTTP-Client

[csamsel]

So you are saying in your home automation software you construct an curl command line to send a request to a php application, which sends a request to steve, to control the charging station? instead of just controlling the charging station with the home automation directly using ocpp?

what a world to live in.

But yeah, thanks for your effort.

[DeltaVetal26]

Undoubtedly, managing through an OCPP server directly is the best option.

But if I use Steve as an OCPP server and, for example, I want to control charging depending on the load on the house. OK. I can go into Steve's panel every time and enter commands, but do I want to automate this?

This was written because Steve does not yet have a direct API implementation. In my case, it helped.

[goekay]

thanks for sharing your contribution and repo @DeltaVetal26!

i agree that steve not having a direct api is problematic and can result in less-than-optimal solutions, but i am not sure whether having an api for an api implementation (ocpp) is something worthwhile. every time i think about this, i drop the idea. in your solution, you hardcode for example the ChargeBoxID and ConnectorID, which might be suited for your use case.

a proper api should have CRUD endpoints for data management (for example, to get ChargeBoxIDs and ConnectorIDs) and, on top of that, should expose the operations to manage the stations. congrats... it replicates basically what OCPP stands for.

[DeltaVetal26]

@goekay , thanks for the feedback.

I agree with your opinion on the correct API.

In my case, this was the only external control option for Steve. Perhaps this will be useful to those who have similar needs.

[TechOverflow]

I think an API is crucially missing from SteVe. This added layer would allow other languages to cooperate with the Central System and for example allow a public user to start charging from a wordpress site for example.

[redhell]

@TechOverflow I'm implementing a simple API for my thesis in university. It contains:

• Starting/stopping remote sessions
• charging data
• adding/removing ocpp tags

I will publish this after the thesis is done.

[untouch68]

@redhell Hey Dominic,

your approach and solution is actually exactly what I would need. I hope your studies went well and you got your bachelors degree :)

Might sharing your solution?

Greetings

[goekay]

closing this issue due to inactivity.