-
-
Notifications
You must be signed in to change notification settings - Fork 7
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
Ocpp #30
Comments
I checked the code a bit, and I noticed that this integration is using Services to start and stop charging. The OCPP integration does not provide that today. Instead one can either use Device Actions or a Switch Entity. Would it be reasonable for this integration to support either Device Actions or Switch Entity for controlling the charger? |
Yes, absolutely. The aggregator-part of it (for locale and chargertype) should be as low-level and type-agnostic as possible. |
Unfortunately, I have no experience with Home Assistant development, so to add support for Device Actions and/or Switch Entities, is a bit above what I would like to commit to. If the chargerbase.py had support for Device Actions and/or Switch Entities, then I should be able to make an OCPP realization. Actually, to add start and stop services to the OCPP integration seem like an easier path for me... |
I'll backlog it. Myself or someone else will handle it. Aim must be agnosticity for it to be an aggregator worth developing. Thanks for heads up again |
@elden1337 Can you please give a hint on a workaround to get OCPP working with your fantastic piece of code you have? I guess focus is not OCPP in near future.. |
@andreasropel i have yet to examine the existing repo (https://github.com/lbbrhzn/ocpp), but the working process to get a new chargertype into peaqev is basically to copy paste chargeamps.py for example, and go from there. I should write up a guide on how to implement new ones for other devs. I'd be happy to do it, but the reason as to why I haven't started is because it's very hard for me to QA the chargertypes (i've had many many rounds with easee for example since i haven't got one myself to test with) and therefore have been more focusing on general improvements as of now. What is needed, unless we re-write a larger piece of the aggregating part that is chargertype-folder is:
|
ie, no workaround possible as the types are being wired into the code specicially per chargertype. But you are right, i should get started soon-ish on this. ocpp probably brings a lot of users that are able to utilize this. |
Alright! Will see if I can manage to dig into the chargeamps.py and see if I can replace specific parts so they can match OCPP. I am glad if I can help to QA the OCPP charger type since I have one myself. |
I ll start and determine where i need to alter stuff (generic for switch instead of service call) first. Made a branch just now. Will get back to you asap. |
@andreasropel i've pushed a first boilerplate for this in a separate branch. feel free to fork and continue if you wish. I've added todo's in the ocpp.py-file mainly. |
Thanks @elden1337! |
@elden1337 As I see, there is no switch for on and off. The OCPP integration has option for availability and to have the ability to controlling the box but not start and pause as Easee has. Controlling the current seems to be controlled in the same way as Easee. Not sure on how to proceed as this is not my strongest skill :) |
I'll have a think about it and continue a bit more first then. No worries |
I have edited the code a bit. |
yes please, do a pull-request. |
Made some adds to the code. I guess I cannot come any further without your support now @elden1337 |
if you do that, i think i can release a first alpha for you to test. the init testing then would be to just see that it loads, and if not, why, and if it loads, check that the charger will turn on/off. |
https://github.com/lbbrhzn/ocpp
Note from @jonasbkarlsson: make sure to alter on/off/pause/resume to not be bound to service calls.
The text was updated successfully, but these errors were encountered: