Dashboard for electric vehicle chargers

Context and problem

After the sales agent for the battery store, the model was replicated for a company that sells electric vehicle chargers, also a Hunt Sales client. The catalog is mainly portable chargers with swappable plugs and a wallbox.

The question buyers ask before closing is how long their car takes to charge. The answer depends on both sides: the car's battery capacity and charging limit, and the power of each charger output. The dashboard feeds the database that the AI agent queries to answer this in the conversation, car by car and product by product, which helps close the sale.

My role

After the battery agent's results, I became responsible for automations and similar systems for other Hunt Sales clients. This was one of them, with the same design: agent, database and management dashboard.

Solution and architecture

1. 01Management dashboardNode.js + Express serving the front-end
   ↓→
2. 02n8n webhookValidates and applies the business rules
   ↓→
3. 03SupabaseVehicles, products and outputs, per company
   ↓→
4. 04Simulator and agentCharging time on each output

• Vehicles with battery capacity (kWh) and alternating current charging limit (kW).
• Products with several outputs: one charger can have several outputs with different power ratings. The example is the portable charger with swappable 10 A, 16 A, 20 A and 32 A plugs: each plug is an output with its own power (a product → outputs relation, with cascading deletes).
• Charging simulator: for the chosen vehicle, it calculates the time on each charger from the technical bottleneck, time (h) = battery (kWh) ÷ min(car's AC limit, plug power). The agent does the same calculation in the conversation and also gave the DC fast-charging time, so the customer gets an idea before buying.
• Multi-tenant: the dashboard checks that the company is active before loading data, and every query is filtered by company.
• Real time: Supabase Realtime updates the screen when data changes, without reloading.
• Business rules in n8n: writes go through an n8n webhook, which centralizes validation before reaching the database.

Try it

Pick a car and see how long it takes to charge from 0 to 100% on each charger: on the portable charger with swappable plugs, on each plug. It is the dashboard simulator's calculation, the same one the agent makes in the conversation: the battery divided by the lower power between the car's AC limit and the output.

Simulation with fictional data · made-up cars and chargers

Load the demo

What matches the system and what is simulated

• Same as the system: the rule, time (h) = battery (kWh) ÷ min(car's AC limit, output power), and the product types: a portable charger with swappable plugs (each plug is an output), a single-output portable charger and a wallbox.
• Simulated: the names, cars and batteries are fictional. Plug power is the current times 220 V, rounded. There is no database, n8n or agent; the calculation runs in your browser.
• The rule is a 0 to 100% estimate: it doesn't count charging losses or the slowdown near a full charge.
• AC charging only, as in the dashboard simulator. In the conversation, the agent also gave the DC fast-charging time, which is not simulated here.

Stack

• Dashboard: Node.js with Express serving the front-end in HTML, CSS and JavaScript.
• Database: Supabase, with Realtime to update the screen.
• Rules and writes: n8n, through a webhook.

Decisions and trade-offs

The bottleneck sets the time

The power that actually charges the car is the lower of the car's AC limit and the charger output. That is why the simulator shows the time per output, not per product: on the portable charger with swappable plugs, the 32 A plug (≈ 7 kW) only helps if the car accepts that power. On a car limited to 3.7 kW, the 20 A and 32 A plugs give the same time.

Business rules in one place

Writes go through the n8n webhook before reaching the database, instead of each screen validating on its own.

Outcome

• The “agent + database + dashboard for humans” pattern worked in a second niche, with a different kind of technical data.
• The agent answers charging time from the data registered in the dashboard.

There was no formal measurement of metrics, so there are no numbers here.

What I learned

• What carries over from one client to the next is the design (agent, database and dashboard), not the tables: here the central data is the relation between car and output, not a compatibility table.