Add support for OCPP based chargers #10
Comments
lbbrhzn
changed the title
|
That sounds cool, I'll take a look at it (won't happen too soon though). I'll try to verify if Easee chargers can benefit from the ocpp too, I remember it was discussed some time ago, but not sure if it is fully supported by Easee. |
|
Hi @nagydavid, I didn't have time to look at it yet. There was done some work to make the card generic though, but it has not been completed yet (see #12). If you would like to test it out there are two early stage proposals here and here which you could test and propose changes to. |
|
I did some work on making the card customizable, please see #19 It would be great if you could test my proposal and see if it fulfills your requests. For sure there are some bugs, kindly let me know or contribute if you feel for it. |
|
I am tinkering with that intention in my mind right now. I am progressing quite well by now, but one thing I do not get working at all is the following. That caused a lil break trying to fix that first. One of my badly failed experiments: The OCPP addin gives back the maximum current as number entity and lets it configure by the used service. I do that in a few templates/automations already and it works. You MUST use float numbers though. And here is the problem. Whatever I try, the service call fails with the error that value @ data['value'] is no float. Any idea? EDIT: Finished my first draft. Somehow the statetext fails to translate. Likely I misunderstood something? Current result:
P.S. This wallbox is madness. All the values regrding current and voltage come from other sensors as the wallbox does not provide these information. The session kWh couter is made with a few custom sensors, helpers and automations. But it works :D |
|
Update: Found something out. All is fine so far. If I move the current selection into one of the groups and try it from there, I get a dropdown menu and can easily select what I want. So this looks like a problem with dropdown menu from toolbar? I updated the code block with my whole config accordingly. |
|
Hi! Looks good @dreimer1986! I am aware that there are some issues with the dropdown that I couldn't figure out yet. It happened after Paper elements were removed from HA. With time, I'll get it working though. |
|
Hi @tmjo . Alright this explains the problem then. Thanks for clarification :D Is the statetext entries do not apply known, too? Only thing missing right now is the mess of identical symbols in the groups/menus. I put text there, but I understand too well, why it does not show it there and is meant for the hover messages. Limited space and text explainations? Sounds like a bad idea.
Question regarding the timestamps. HA interprets these:
Is integrating this a useful suggestion? |
|
Hi, I'll check into the statetext - there was a mention about some issue there in another thread too. Perhaps there is something wrong. Icons should be fully customizable, did you try to add them manually? I remember I had some issue, if I recall correctly the card will take the icon is long as there is a attribute for it on the sensor, but I've seen more and more are removed and come from the device class or something like that. I wasn't able to read out that data, but I'm sure it is possible somehow. |
|
I changed the icons in HA on all entities I thought I can find a better fitting one. Works fine. So for now the known dropdown menu problem and custom statetext not applied is all left I can find. Rest works like a charm :D |
|
Sounds good! I'll see if I can find some time to troubleshoot it, but I am afraid it won't be very soon! |
|
I can at least tell you that in my case the problem with statetext is found here: If changed to: All is fine, so it prefers the value I removed as it is the first in the row of OR I think. I did the same for the substatus as it has the same values possible and now:
|
|
Right, it's trying to look for a translation, so that's probably where it returns something that it shouldn't! Thanks for the tip. |
|
Seems so, localize seems to have a problem:
But I think this should be another report, so I am silent now ^^ |
|
Hi @dreimer1986, Thank you for your input! Based on your work it was very easy to integrate TeltoCharge which is also using the ocpp integration. For the current power consumption I also use template sensor, I'm also thinking of integrating the battery level from the we connect integration though it is not updating too often. @tmjo, I think this example would be nice do be mentioned in the docs, too, as maybe more people start using OCPP enabled chargers, it could be as useful to them as it was to me, since ocpp entities are more or less the same for all chargers using this integration. I'll also make a localization to Hungarian when I have some time. Thank you so much for the great work both! |
|
@dreimer1986; mind checking the new version (v0.1.2) and see if the statetext is working as expected now? @danielszilagyi; glad you got it working and translations are welcome. Both of you: I don't mind adding example (and also what I call "template" to make it easier for people to add). How does the openEVSE / OCPP work? Would the examples you guys used work for all ocpp-enabled devices? Or are they free to implement only parts of it? |
Well, some entities are created but are Unknown forever, for example sensor.whatever.error_code is always Unknown with TeltoCharge, however they promised to improve OCPP in the next firmware. The integration seems to follow the standard so I think whatever entities are created would be the same for any charger. |
I already updated to 0.1.2, but since then had one charging. Looks like it works quite fine for now. I keep you updated. |
|
Sounds good. Are the examples provided by you two identical (except for different names of course)? If it is, I can try to make a PR updating the 'template' to fit your needs. What's the best name for it? OCPP? openEVSE? Something else? |
|
I'd suggest OCPP since the integration we're both using is the OP's project: https://github.com/lbbrhzn/ocpp |
|
So regarding the text translation: As the update of course overwrote my hand edit I did in #10 (comment) and I did not notice any problems. It works (almost) I am 99% sure that not much changed on my side, but I replaced my draft with what I would call my final after months of working with it. |
|
Hi, Didn't have much time to start the translation in a branch, but played around my own card's look and feel. Teltonika released new firmware which now reports SuspendedEV when the charging was stopped on the car side, but still lacking some basic stuff. They don't support unlock, so I removed it from my card, also lot of sensors are present but don't contain much data. I edited the yaml in the original post, here are some screenshots: |
|
Hi! I'd love to add support for this charger, but kindly read the wiki on how-to. Let me know if anything is unclear and I'll update it or try to explain. Cheers! |
There is now a custom integration for chargers that support the Open Charge Point Protocol.
See ocpp, and this issue
I think this is the closest you can get to a universal interface towards the chargers. It should also be more responsive than a cloud based solution.
What would be needed to get ocpp working with the charger card?
The text was updated successfully, but these errors were encountered: