Zappi Charger Plug status, can it just show "EV Connected" or EV Disconnected"

[DaveTiff]

Is your feature request related to a problem? Please describe.
At the moment the sensor.myenergi_zappi_charger_plug_status shows various conditions:-
EV Disconnected
Charging
EV Connected
Waiting For EV

Describe the solution you'd like
As its the Plug Status I would like to just show "EV Connected" or EV Disconnected" as we have a charge status which this seems to duplicate

Describe alternatives you've considered
None

Additional context
No

[gdotp01]

Hi. Awesome work on this plugin.
I’d like to second the above request if I could. I’d like to use sensor.myenergi_zappi_charger_plug_status but as it’s currently implemented I can’t get it working. The sensor does not seem to be available for automations and in reality a simple binary sensor would probably suffice.

[LeiChat]

This is somewhat related to my post #355

The myenergi API returns a property named 'pst' and I'm not sure where the friendly names for each value is defined.

Is there any official documentation for the myenergi API? If not, is 'plug_status' the presumed descriptive name for 'pst' ?

[API - pst]
[HA entity - myenergi_zappi_XXXXXXXX_plug_status] :
A = EV Disconnected
B1 = EV Connected
B2 = Waiting for EV
C1 = EV ready to charge
C2 = Charging
F = Fault

Might it be worth including entities for the actual API properties? e.g. myenergi_zappi_XXXX_pst
And have them return the myenergi API value (A, B1, B2, etc.) and users of the HA integration can use a template/helper to map them to whichever friendly names they would prefer to show on their dashboards.

Or can we reach out to myenergi for clarification about what each 'pst' and 'sta' value mean?

[jaket91-1]

Thanks for opening this issue. I too would love to see the plug status values available to use with automations but can’t seem to at the minute. Despite the plug status entity showing correctly, the only values I can select from as a trigger are ‘Any State’, ‘Unavailable’ or ‘Unknown’

[LeeUKM]

love this add on.. bit heavy getting going as in the learning curve, but left info here on Automation..

https://community.home-assistant.io/t/trigger-home-assistant-actionable-notifications-by-connecting-ev-myenergi-zappi/623967

hope it helps

[G6EJD]

This is complete as implemented. Please close the issue.

[AJediIAm]

I thought the request was to implement a binary sensor of type "plug" (https://www.home-assistant.io/integrations/binary_sensor/) instead of a sensor with a specific string as it's state.

I have added two binary sensors for the plug and charging:

These are much easier to use in automations compared to a sensor. I think a lot of users will be very happy with these two binary sensors.

[LeiChat]

Adding a binary_sensor with the 'plug' type sounds like a nice idea but, it would have to be based on a value returned by the API and the property that seems most relevant ("pst") has some states that don't necessarily map to true/false.

A = EV Disconnected
B1 = EV Connected
B2 = Waiting for EV
C1 = EV ready to charge
C2 = Charging
F = Fault

A would map to false and B1, B2, C1, C2 would map to true.
We would need myenergi to confirm if "F" for "pst" only occurs when the plug is connected, or should could a binary_sensor return an error/unavailable state in that circumstance?

EDIT: The plug_status labels are defined in the pymenergi library, rather than the ha-myenergi integration: https://github.com/CJNE/pymyenergi/blob/1f171406e1b12706ea05b06507e923a79dcfd075/pymyenergi/zappi.py#L11

[AJediIAm]

A binary sensor for fault would also be nice to have. In case of a fault, it doesn't matter if the EV is plugged in or not. The EV needs to be unplugged and the zappi reset before it works again. The plug status could be unknown or left at the last known value.

I have had a fault once in a while, but I cannot recall that plug status showed a fault state.

[LeiChat]

I suspect that the "F" value returned by the myenergi API in the "pst" property is specifically for a fault related to the plug status.

[G6EJD]

None of this needs to be done by this integration all the conditions can be handled by the automation logic controls.

[AJediIAm]

None of this needs to be done by this integration all the conditions can be handled by the automation logic controls.

True, but binary sensors are very convenient to use. Especially beginner users will be able to work more easily with the integration when binary sensors are provided.

[G6EJD]

There are 'applications' and there are 'integrations' and home assistant isn't meant to be a collection of applications.

[AJediIAm]

I'm not familiar with the concept of applications in home assistant.

Home Assistant prefers to use specific device classes where possible. Official integrations are mandated to map to explicete device types where possible. There is no device class for an EV charger, but the battery and plug binary sensors are a near perfect match.

I understand the simplicity of the one-on-one mapping from the vendor API, but there is a clear trend to use specific device types where possible. The UI and Assistant can leverage specific device types better than generic entities and I think this trend will continue in the future.

Edit: I do respect every opinion. It's an interesting discussion with many valid perspectives.

[AJediIAm]

I forgot that I already submitted a similar feature request here: #593
Since the requests are slightly different (asking to simplify the current sensor vs asking to add an additional binary sensor), I'd like to keep mine open.

It's up to @CJNE to determine if the requests can be approved for implementation.

[G6EJD]

It is, but you can help Johan enormously if unnecessary or vanity requests weren't being requested, especially when so many can be achieved by the tools in Home Assistant.

[AJediIAm]

I can't speak for Johan, but I think the home assistant community as a whole is better served with people helping each other instead of toxic sidekicks bullying people to close their issues.

[G6EJD]

Most of the issues aren't issues they are created by people who don't understand GitHub, or how to use the integration or can't be bothered to read or learn, then to cap it all, they leave the issues languishing often for years on end and never follow them up. Then there's those who carp on about helping, then don't, then do.
I helped out with the formation of the integration years before you got involved commenting from the sidelines.