Ocpp

[elden1337]

https://github.com/lbbrhzn/ocpp

Note from @jonasbkarlsson: make sure to alter on/off/pause/resume to not be bound to service calls.

[jonasbkarlsson]

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?

[elden1337]

Yes, absolutely. The aggregator-part of it (for locale and chargertype) should be as low-level and type-agnostic as possible.
So we nudge it in that direction, either together with the community (faster) or in slower pace with just me coding ;).

[jonasbkarlsson]

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

[elden1337]

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

[andreasropel]

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

[elden1337]

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

• Service calls for at least on/off
• Sensor that reports the current state of the charger
• Sensor (or attribute) that reports the current wattage
• If updatemaxcurrent is gonna work, we also do require sensors/attributes for such things, plus a service-call to alter it if applicable.

[elden1337]

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.

[andreasropel]

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

• Service calls for at least on/off
• Sensor that reports the current state of the charger
• Sensor (or attribute) that reports the current wattage
• If updatemaxcurrent is gonna work, we also do require sensors/attributes for such things, plus a service-call to alter it if applicable.

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.

[elden1337]

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.

[elden1337]

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

[andreasropel]

Thanks @elden1337!
will dig into this tomorrow.

[andreasropel]

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

[elden1337]

I'll have a think about it and continue a bit more first then. No worries

[andreasropel]

I have edited the code a bit.
I need to test all the states to see what they say.
Shall I upload what I have done until now?

[elden1337]

yes please, do a pull-request.

[andreasropel]

Made some adds to the code. I guess I cannot come any further without your support now @elden1337

[elden1337]

@andreasropel

hass-peaq/custom_components/peaqev/peaqservice/chargertypes/types/ocpp.py

Line 85 in dbe8f23

self.powerswitch = self._determine_switch_entity() #todo: hardcode switch.... yeah whatever it is, for now.

, please add a hardcoded version of the switch-entity that would be used to turn charger on/off. Same schema as the ones above and below, but switch. instead of sensor.

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.