Meta - API Endpoint

[juherr]

This feature request completes #990 and could be a meta ticket for all tickets for a dedicated API.

Could be done in steps:

Operations

1. Remote Start / Remote Stop (Implement REST Endpoint for Start and Stop Transaction #388 solved by WebApi of remote start, remote stop and connector status #1291)
2. The ones provided by OCPI
   • Reserve Now + Cancel Reservation
   • Unlock Connector
3. Everything else
   • Change Availability
   • Get Configuration / Change Configuration
   • Clear Cache
   • Get Diagnostics
   • Reset
   • Update Firmware
   • Data Transfer
   • Get Local List Version / Send Local List
   • Trigger Message
   • Get Composite Schedule
   • Clear Charging Profile / SetCharging Profile

Data

• Chargepoints (feat: add api for chargebox/reservation/user juherr/evolve#34)
  • Create
  • Read
    • Connectors (WebApi of remote start, remote stop and connector status #1291)
  • Update
  • Delete
• Users (feat: add api for chargebox/reservation/user juherr/evolve#34)
  • Create
  • Read
  • Update
  • Delete
• OcppTags (API endpoints for automation and integration #910)
  • Create
  • Read
  • Update
  • Delete
• Reservations (feat: add api for chargebox/reservation/user juherr/evolve#34)
  • Create
  • Read
  • Update
  • Delete
• Transactions
  • Read (API endpoints for automation and integration #910)
  • Read details (including meter values) (API REST MeterValuesSampledData #596)

[srigurubyo]

Would be really super useful!

[alexandre-da-costa]

In my opinion, step 1 is essential to integrate with third party services.

I am actually in dire need of it right now to be able to advance in a university research, where I have to able to remote start and stop charging operations from my backend.

I am a PHP guy, and have little experiencie with Java, but will try to work on these endpoints.

Or does someone already have something working and can help a brother?

Thanks.

[NikSays]

Hello,
A while back our team actually implemented some REST endpoints ourselves. Current implementation can be seen here. It does not comply to the code style of this repository, but we are interested in fixing it up and merging it here.

Firstly, we can help with step 1 (Remote start/stop)

Then, we propose some other endpoints

• Get chargepoint list
• Get transaction details (including meter values)

We consider those to be important for 3rd party integration

Thanks.

[juherr]

@NikSays Thanks for the idea. I updated the issue description accordingly.
I'm not the owner of the project but I think you can go ahead and propose some pull requests with the changes you proposed.

Edit:
I had a look at your implementation. It is working but it does not follow REST principles. I think you should update the design before propose it in a pull request.

[goekay]

i vaguely remember that i expressed my general opinion about this in some other issue, but cannot find it at the moment. here is a short version:

i am quite wary about exposing these as APIs... not much the data-related ones, but the ocpp operations. here is the reason: every feature request comes from a specific perspective and use case, and addresses %1 of the functionality. this is easy to do in a fork that solves your problem, but in a mainstream project like this one i have to think about the completeness and other %99. step by step, if completeness is desired, it will arrive at the same functionality and complexity as ocpp. some operations even have some slight differences between versions. so, you have to respect ocpp versions as well. great, we recreate ocpp but in REST form.

[juherr]

@goekay I understand your "ocpp first" approach and you are right when you say that the API will look like OCPP at the end.

But as we have seen many times, users expect a simpler way to deal with stations which is not OCPP (at least because they don't want manage the different OCPP transports). #117 is one uses-case between some which will benefit of an API.
Steve is an awesome piece of software that is doing all the technical OCPP parts.
At the same time, I don't think OCPP explains how to deal with the CentralPoint from the outside.
OCPI is maybe the closest approach to that (#56) but doesn't cover (yet?) all operations (at least in the official modules) and has its own complexity.

For reference, some API descriptions by similar softwares:

• https://developer.greenflux.com/docs/remote-commands
• https://api.emabler.net/api/swagger/ui

On another side, the current UI of Steve is working well but is a bit raw. Having a full feature API will open the opportunity to create external projects dedicated to UI, with maybe another UX approachs, and trying to fix its own problems (for example #991 or #1029).

If I read well between the lines, you propose to fork the project but I don't think it will benefit the community and the effort would be large to keep the sync with the upstream.

Please, could you specify your thinking?

[engsandro]

Hi guys, I have some GreenFlux Smart Charging Controller DSCU (discontinued products) that I need to update the firmware to the latest available version, probably 4.3.5). Does anyone know the server address to download the FW?

https://www.eautotoltokabel.hu/wp-content/uploads/2021/04/GreenFlux-DSCU_Smart-Charging-Controller-installation-manual-v4.6.pdf

Thanks

[goekay]

@juherr

If I read well between the lines, you propose to fork the project...

not really. in fact, i would really would like to prevent that. i do not propose a solution, i don't have a solution. i am just raising a concern and trying to engage the community in active decision making. my concern is a parallel ocpp-like behaviour with different technical realisation and the maintenance hell that would come with it.

On another side, the current UI of Steve is working well but is a bit raw.

i would agree. i am not a frontend developer. i tried my best. PRs and contributions are always welcome in that area. but there was nothing so far in the last X years.

[emerout]

@juherr

On another side, the current UI of Steve is working well but is a bit raw. Having a full feature API will open the opportunity to create external projects dedicated to UI, with maybe another UX approachs, and trying to fix its own problems (for example #991 or #1029).

This pull request #1074 could be useful for creating a different UI without implementing a brand new API.