[Custom Integration] Tap Electric Charger (Community) — dual-mode HA integration for Tap Electric EV chargers

Share your Projects! Custom Integrations
1

Hi all,

I’ve just released a community Home Assistant integration for EV chargers managed through the Tap Electric platform. It’s been running live on my own setup (EVBox Elvi on Tap) for a few weeks, and I figured I’d open it up for others to try.

Repository

Install via HACS (custom repository for now)

  1. HACS → three dots → Custom repositories
  2. URL: https://github.com/weemaba999/homeassistant-tap-community
  3. Category: Integration → Add → Install
  4. Restart Home Assistant
  5. Settings → Devices & Services → Add Integration → Tap Electric

HACS Default submission is on the roadmap once the installer path has seen some real traffic.

What it does

Basic mode (just an sk_ API key from the Tap developer portal):

  • Charger status, session history, energy totals
  • Charging allowed switch, current limit, remote reset
  • Connector/plug/charging binary sensors
  • OCPP measurands where the charger emits them (my EVBox Elvi only emits Energy, but Alfen / Wallbox / Zaptec etc. likely do more — those entities are default-disabled so you don’t see ~20 “Unavailable” entities on EVBox)

Advanced mode (optional, Firebase email+password):

  • Live session energy, duration, start time
  • Current driver name and location
  • Same credentials you use in the Tap mobile app

Both modes: graceful degradation on network issues, dynamic coordinator interval (30s during active session, 5 min idle), automatic token refresh, reauth flow on credential expiry.

Status

  • v1.0.0 live on GitHub Releases
  • 185 pytest cases green in CI (pytest-homeassistant-custom-component)
  • Hassfest + HACS validation passing
  • MIT licensed, NOT affiliated with Tap Electric B.V. (pending their blessing on branding, currently ships as “Tap Electric Charger (Community)” with a generic icon)

Known quirks

  • Tap’s public API has GET /charger-sessions/{id} return 404 — the session detail endpoint only lives on the management API. Advanced mode bridges this.
  • ~22% of sessions lack endedAt on the public API (orphan sessions). The coordinator cross-checks against connector status.
  • Some measurand entities will always be “Unavailable” on certain chargers (hardware-dependent, not a bug). Default-disabled where known.

Looking for

  1. Testers with non-EVBox chargers (Alfen, Wallbox, Zaptec) — want to know which measurands your charger actually emits.
  2. Native DE / FR speakers — translations are machine-generated, could use a proof-read.
  3. Feedback on the options flow, setup UX, entity naming.

Questions, issues, or “my charger does X but the integration says Y” reports welcome here or on GitHub issues.

Cheers,
Bart

1 Like
2

Hi Bart, you are a hero! Great to have the TAP Electric integration.

I have a question - I can start the charging of my car via the app (it is in a semi public location so normally I would use either the RFID card or the app). As my household members tend to connect the cable but forget to start the charging, I would like HA to start it. Is this possible through the integration?

3

Hi,

Can you elaborate a little bit more on what you actually want to achieve ? Do you mean that automatic charging is a feature when cable plugged in ? (without RFID) ?

Kind regards,

Bart

4

Hi Bart, yes indeed. I would like the status change of the cable being connected (can be derived from my Tesla integration) will automatically trigger the charging to start. Even without the RFID tag being used.
As it it possible to initiate the charging from the mobile app without RFID, I hope this can also be achieved via the API.

5

Hi Ronald,

Great question — and this is exactly the kind of automation that
makes a Tap integration worth building.

Short answer: technically possible, but not yet built into v1.0.0.

I reverse-engineered the API endpoint that Tap's own mobile app and
web app use for remote start/stop today. It's a separate management
API (not the public developer API the integration currently uses
for monitoring). The schema looks like:


POST https://tap-electric-app-api.azurewebsites.net/api/1.0/ chargerManagement/chargers/{chargerId}/ocppMessages

{ "message_type": "remotestarttransaction", "remote_start_transaction_details": { "connector_id": 1, "id_tag": "<your token>" } }

Two complications:

  1. This endpoint requires Firebase auth (advanced mode in the
    integration). The same auth the mobile app uses — your Tap
    email + password. The integration already handles this for
    reading live session data, but not yet for writing.

  2. I tested RemoteStopTransaction today on my own EVBox Elvi and
    the charger firmware rejected it ("Rejected" status from the
    OCPP layer). Tap's own webapp can't stop my sessions either —
    it appears to be an EVBox firmware restriction, not a Tap or
    integration limitation. Other charger brands may handle this
    differently.     Since you say you can start via the mobile app,
    your charger likely accepts these commands.

**Would you be open to being the first tester for v1.1 (or v1.0.1) **
which would add Remote Start / Remote Stop?

If you give me:

  • Which charger brand/model you have
  • A small Network-tab capture (F12 in the browser) of one
    successful Start action from web.tapelectric.app — specifically
    the request payload to .../ocppMessages

...I can verify the schema matches what we expect, build it into
the integration, and ship it within a week. Even a screenshot of
the F12 Network tab payload for a single click would be enough.

Either way: this is on the roadmap. Thanks for the nudge.

Bart

1 Like
6

Hi Bart, I have a Gen3 EV box. I have the advanced mode active. Happy to be a tester. I will PM you details.

7

Hi Bart,

I was looking into the Tap API docs today when I found that you can send OCPP messages via the public API to trigger a remote start: https://developer.tapelectric.app/reference#tag/chargers/post/api/v1/chargers/{chargerId}/ocpp.

To use RemoteStart, the following body data is needed:

{
  "action": "RemoteStartTransaction",
  "ocppVersion": "ocpp1.6",
  "data": "{\"idTag\": \"<RFID_TAG_ID>\",\"connectorId\": 1}"
}

Use an Android device with NFC tools to read the RFID_TAG_ID from your charging pass or keyfob. Wallbox says you can also get it from the logs but it's obfuscated there.

To stop, the API needs a transactionId:

{
  "action": "RemoteStopTransaction",
  "ocppVersion": "ocpp1.6",
  "data": "{\"transactionId\":123}"
}

The transactionId can be requested by the charger sessions endpoint and then using the session id to get session meter data. I think that's the only way.

I tested this on my Wallbox and it works. Happy to test a little although I'm time crunched. It would be great if I can use Home Assistant to auto start a session using my employer's keyfob when I plug in my charger cable into the Wallbox.

8

Ok, nice updates in v1.1.1! Just installed and will send a DM with more info!

9

Welkom JorisDr! Glad v1.1.1 already installed cleanly. Looking
forward to your DM — feel free to drop logs, captures, or just
questions there.

Quick update on where things are: the chip-UID approach you
describe is exactly what v1.2.0 will productize. Pieter (5bomen
on this thread, ronlimon on GitHub) shipped a reference toolkit
at GitHub - ronlimon/tap-electric-toolkit: Ad-hoc Python CLI tools for the Tap Electric REST API — diagnostics, charger control, OCPP envelope reference, and webhook helpers. · GitHub that
demonstrates the same pattern in standalone Python — useful
read while v1.2.0 is in the oven.

Your Wallbox datapoint is gold. So far we have confirmed working
remote start/stop on:

  • Ratio io6 (Pieter)
  • Wallbox (you)
  • EVBox Elvi: Reset works, RemoteStart/RemoteStop firmware-rejected
    (verified on mine + Tap's own webapp)

If you're up for it, two small test asks when you have a minute:

  1. Is the Wallbox a Pulsar Plus, Copper SB, or another model?
    And firmware version if you can find it in your Wallbox app.
  2. RemoteStart with a SECOND keyfob while one is already
    authorized — does that take precedence, return an error,
    or get rejected silently? That's an open question Pieter
    couldn't test (only one pass).

No rush, whenever the DM lands and we see what you've shared.

Bart

1 Like