Include documentation for attributes used

[pcon]

I'm trying to use this card for my wallbox charger, but all of the sensors are separated instead of being a single one with lots of attributes. Can you provide an example of the sensor and it's attributes that you are using for this? That way I can create a template sensor that pulls in all of the other sensors into attributes.

[tmjo]

Hi @pcon! Yes, you're right. The card is written specifically for the Easee charger. It was my intention to extend it to support other brands, but it may be a bit complex since there is no "base class" for chargers to inherit from so all different chargers will work in different ways in HA. Anyway, I believe you're idea of using template sensors may work (or at least partly), so it could be worth a shot. If it seems to work well for the Wallbox, I may consider to try to add some more official support.

Take a look in the const-file for Easee, look for the two dicts MANDATORY_EASEE_ENTITIES and OPTIONAL_EASEE_ENTITIES and the entity names used by Easee. For instance the first one «status» appears in HA as «sensor.CHARGERNAME_status» and this is the main sensor the card expects and then (dirty, I know) uses this main sensor name to predict the other ones.

Mind sharing how it looks for the Wallbox entity/entities?

[pcon]

Here's a screenshot of the entries I have

So it sounds like the Easee charger does a bunch of entities as well. It would be nice to have the component read everything from under a single sensor so you could do

- platform: template
  sensors:
    garage_charger:
      friendly_name: "Garage EV Charger"
      value_template: '{{ states("sensor.wallbox_portal_status_description") }}'
      attribute_templates:
        siteName: 'Home'
        maxChargerCurrent: '{{ states("number.wallbox_portal_max_charging_current") }}'
        sessionEnergy: '{{ states("sensor.wallbox_portal_added_energy") }}'

And then in the card just reference garage_charger.attributes.siteName. This would then make it agnostic to which charger you're using.

[tmjo]

That's a good point. I'll take a look at how it can be implemented. It could also be something like selecting specific charger brand at top of card config which is used to target specific sensors, and then there could of course be a "generic" one that acts like you describe. We have discussed in the Easee dev team to add a "one-size-fits-all sensor" with all attributes either as an optional sensor or as the only sensor, but then again I personally like having some of the info in specific sensor since it makes logging and trending easier. In general, I find making template sensors quite cumbersome, but it will of course work great as a workaround for specific cases.

[pcon]

I agree. I like having them split into their own sensors for 99% of the time, but I think for front-end work like this, having a consistent view into all chargers. Another option would be to do something like the power-distribution-card does and to have each of the parts be definable as individual entities instead of derived from the name of the primary entity.

[purcell-lab]

Looks like we could also map a number of entities from the Tesla integration into the easee structure required by this car.

Here are the Tesla entities:

[tmjo]

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.

[tmjo]

Nothing heard, so closing issue.