rancid token
👋 Hey everyone — I’m Chris, founder of HeyCharge, an EV charging company specializing in offline-capable chargers for multi-user environments like underground parking. Our core product offer relies on a proprietary Zigbee- and Bluetooth-based application layer protocol to enable inter-charger communication and local communication resilience without requiring constant internet or cloud access.
We’re considering releasing our charger hardware to consumers (up until now it's only been available B2B) in Europe with tight Home Assistant integration — aimed at advanced energy management use cases:
• Dynamic tariff steering
• PV and battery integration
• SoC-aware charging based on driver habits and calendars
• Optional shared access with custom auth/billing logic
As a HA user (and hacking on my own integrations every now and then), I’d love your input to help us build the most universally-useful and open solution.
🔌 Desired integration capabilities:
• Charging control (pause/start, set max current)
• Real-time telemetry (instantaneous current, power, energy delivered)
• Vehicle SoC reporting, when supported
❓Two key architecture questions:
1. Should we expose our Zigbee mesh via a gateway device (Wi-Fi/Ethernet, REST or Modbus/TCP), offering near-universal compatibility (users don't need to have a working Zigbee coordinator) but at added cost?
2. Or go for native Zigbee integration using standard clusters? If so, what clusters would be the best fit? We imagine something like a smart plug/switch pattern extended with custom attributes/commands for EV-specific controls (e.g. set current, report SoC).
I couldn't figure out if I should post this in #1284966617670881350 or #1284966353798697001 ... It's honestly more of a product management question with technical underpinnings 😂
Appreciate any thoughts or experience you can share! ⚡
reef cypress
lunar night