Hi Martin! I’ve only been testing with one charger, so it is interesting if you can test how it works with two. I believe Easee has built-in functionality to distribute the current available between chargers on the same circuit, and as for now we’ve got functions to set both max circuit current and max dynamic current. With one charger it seems to do the same, but I expect the max to be circuit limit while dynamic is something - ehh - yeah, dymamic. So perhaps Easee is distributing on this, I’m not sure.
The circuit_id is exposed as an attribute on the status-sensor amongst other, so you can find it there. However, the last PR also implemented services which automatically finds the charger circuit so the limits can be sent to the charger as well (easee.set_charger_xxx vs easee.set_circuit_xxx).
In fact I just discovered today that there is a specific limit per charger as well exposed in the Easee API on the last two attributes under /api/chargers/{id}/settings. I have to investigate it a bit more, but I’m not sure if has been recently added to the documentation or if I simply missed it initially.
Cool if you could do some testing with two chargers and let us know how it behaves.
Found it there, thanks. Seems to work.
Yes, Easee should be able to use the dynamicCircuitCurrent and distribute it itself. I have set the circuit to 13A in the Easee app and the cars shares that without problem.
If I look at the sensors of one of my individual chargers they are set to 40A max circuit current (I have not touched that one) and the circuit to 13A. I will do some testing with dynamicCircuitCurrent, right now both cars are fully charged after a day with cheap electricity.
Great! I noticed that when I rebooted my charger, it reset the dynamic current to 40A on my installation as well. So apparently 40A dynamic current is some kind of default level. There’s also a circuit rated current which is setup during installation and returns a “service forbidden”-reply if one try to call it from API. My assumption is that this will be respected no matter what the dynamic or max currents are set to.
Tested, just a single easee in my garage. Works very well with the single status sensor.
Nice work!
Looking forward to getting power usage, both W and kWh if possible. Separate sensors for these would be nice.
Hi Helge! If you click on Options for the Easee integration under Configuration -> Integrations, you can add the sensors you want from a checklist. These include kW and kWh amongst many others.
I’m just about to start testing this. and i just read through the discussion here. My guess about the dynamic current is that tibber is having a service where they do set the max current dynamically based of the usage in the house. they use 2 different type of equipment for measuring this. Either the tibber pulse or watty.
For now it is sensors + services. Look for the easee.* services and you’ll find most of what is available in the API there. But for now it’s only sensors and not switches etc, but I have a working version in my dev container which is working well with switches, so I’ll propose and discuss it with fondberg quite soon.
Here are the ones I selected in my dev container. It works well. I’ll clean it up a bit and upload to a branch on my fork so you can see if it seems to be the right way to do it or not.
I was also looking to make the current limits as sliders for analogue values, but that seems to be more complicated than I first imagined. Can’t believe it’s not already a core feature of HA, but input_number doesn’t allow inheritance with async_setup since it is not a entity platform. Perhaps there is another way, but anyway there is hope ref discussions here and here.
Anyway, once we’ve settled the correct way to do it, adding different platforms is a piece of cake.
It was mainly cable locked that I was looking for at the moment. I want it unlocked when I arrive home (if I need to change charger, I have two chargers and two different standards in my cars. Type 1 and type 2). And also I need it unlocked for 5 min after I arm my alarm away and when I stop the charging if the door recently has been open. But all of this can be done using service calls. I just missed them when looking quickly
Well, those are useful for a GUI but I think services and sensors are fine.
Keep in mind that the goal is to bring this in to HA and they accept as small new integrations as possible
Sure, we can always bring this to HA officially first, and later propose extensions and improvements. But I think it is much easier to have a switch than the user having to create his custom button with a service call doing the same thing. Unless someone makes a beautiful card that has it all included of course Anyway, with the increasing number of electric cars, I really believe HA should have a ev_charger platform similar to media_player. Just not sure how to proceed to suggest it.
The only official one that I know of is Keba and then two custom components ChargeAmps and Zaptec.
About human vs automatically, not sure yet, but is there any good reason for a switch not to be integrated as a switch? Can’t see any benefit in keeping it a sensor, the code isn’t very much different.
Enable idle current is enabling/disabling the car to draw current for heating/cooling and similar when it’s not charging (and outside of charging schedules I assume).
I’m not against switches. I just don’t want the component to be huge when it’s brought in as a PR… Like, should we add a lock like Keba did?
I would like to be able to add some tests and much better documentation. You are the most knowledgable when it comes to what each thing actually does (like the idle current mode et.c.)
I agree with you there, better to get it official and improve it along the way. I think there is a good chance Easee will make modifications to the API as well, there’s quite some interesting requests on their site, but who knows. On the other hand it could be wise to have it prepared for other platforms such as switches etc etc so the rewriting isn’t too big once we decide to do it?
Was thinking about locks too, but think its easier to decide on the overall structure first, then it should be fairly easy to convert sensors to whichever platform we want. I hope
I’ll contribute with docs as well, no doubt.
Not sure if you saw it, but I sent a proposal for multi-platform on Discord here. I tried to follow the Blueprint examples but maintain the generic way that we have in sensor. It is working well, but can probably be more efficient.
Best would be to have a generic OCPP-plugin for all chargers that supports it. Have anyone compared Easees API againt the OCPP-API? They promised it would be at least V1.6 compliant.
Anyway, with the increasing number of electric cars, I really believe HA should have a ev_charger platform similar to media_player. Just not sure how to proceed to suggest it.