Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Meta - API Endpoint #1000

Open
6 of 37 tasks
juherr opened this issue Dec 11, 2022 · 17 comments
Open
6 of 37 tasks

Meta - API Endpoint #1000

juherr opened this issue Dec 11, 2022 · 17 comments

Comments

@juherr
Copy link
Contributor

juherr commented Dec 11, 2022

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

@srigurubyo
Copy link

Would be really super useful!

@alexandre-da-costa
Copy link

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
Copy link

NikSays commented Jan 5, 2023

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 juherr changed the title Meta - API Endpoint for operations Meta - API Endpoint Jan 27, 2023
@juherr
Copy link
Contributor Author

juherr commented Jan 28, 2023

@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
Copy link
Member

goekay commented Jan 28, 2023

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
Copy link
Contributor Author

juherr commented Jan 29, 2023

@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:

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
Copy link

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
Copy link
Member

goekay commented Feb 21, 2023

@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
Copy link

emerout commented Feb 28, 2023

@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.

@mtomoda
Copy link

mtomoda commented Jun 10, 2023

Thx @juherr
But I cant understand.

I edited main.properties and rerun maven.

For example, how should the API be written to start charging from client?

@juherr
Copy link
Contributor Author

juherr commented Jun 10, 2023

@mtomoda As you can see in the issue description, the api you expect doesn't exist for the moment.

@vranbat
Copy link

vranbat commented Jun 27, 2023

I'm also very interested in the possibility of having an API for RemoteStart and RemoteStop.
It would be very useful for me to be able to set the charging current as well. I would like to manage the charging based on the availability of solar power using a Python script.
Thank you very much for the great work you have done!

@sijojamesjohn
Copy link

How to use API? AUTH?

@imre-evo
Copy link

Hi Everybody!
Are there any updates in the API endpoints? I can see lots of new features idea, for example start and stop transaction or read the meter values during a transaction, but I don't find them in the manager/v3/api-docs. Are these endpoints already implemented, or is it in the future plans?
Thanks for the answer in advance!

@smeatond
Copy link

Is there any updates on this?

@RealRunSpace
Copy link

Wish you could implement a proper full API, this way Steve could be really usefull as an admin overall standalone panel, and using the API, users can create APPs to manage users, chargers, etc without giving full access to the Steve interface!

@RealRunSpace
Copy link

Bumping this, I'd love to even sponsor the project if we get the full API!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests