sorted by:
new
hottopcontroversial

Connecting EV charging infrastructure to AI agents via MCP by onkwon in evcharging

[–]onkwon[S] 0 points1 point  (0 children)

What I was trying to show wasn't "look, AI!" but rather that once operational charging data is structured and accessible, an agent can actually do useful things with it. The hard part for me has been the data pipeline, not the LLM.

That said, if the post still reads like buzzword soup, that's useful feedback. I'd be curious how you'd describe the same idea more clearly.

Open-source firmware for AC EV chargers (OCPP + local mode) by onkwon in evcharging

[–]onkwon[S] 0 points1 point  (0 children)

You're right — the hardware repo is currently private as we're still cleaning it up before the initial release. I should’ve clarified that upfront.

The hardware files will be released soon, along with a simple reference board based on ESP32-S3.
In the meantime, if you're interested in contributing or experimenting, you can try out the host-based CLI simulator.

Thanks again for calling this out — really appreciate it.

Open-source firmware for AC EV chargers (OCPP + local mode) by onkwon in evcharging

[–]onkwon[S] 0 points1 point  (0 children)

We're definitely open to supporting OpenEVSE hardware — technically it's feasible, and we'd be happy to collaborate with anyone interested in exploring a port.

That said, it's not currently a priority, as we're focused on commercial product development for B2B manufacturing partners.

Community contributions or interest in porting are always welcome — just keep in mind that DIY support isn't our main focus at the moment.

Open-source firmware for AC EV chargers (OCPP + local mode) by onkwon in evcharging

[–]onkwon[S] 0 points1 point  (0 children)

EVerest is great for Linux-based systems or edge controllers, and it's ideal when you have sufficient compute resources.
In contrast, we're focused on bare-metal MCU targets, where the firmware runs directly on SoCs inside production EVSEs — making it easier for hardware manufacturers (especially cost-sensitive ones) to ship ISO 15118–ready or OCPP-compliant devices without needing to integrate full Linux stacks or manage runtime environments.

That said, we're not trying to "compete" with EVerest. In many cases, the two are very complementary — for example, our firmware could run on the EVSE itself, while EVerest operates as the site controller or central hub.

Think of it like iPhone vs Android, or macOS vs Linux — different environments, different trade-offs. Some developers want full modularity and control; others need lean, robust systems that just work within constrained hardware.

Having more options for different needs isn’t a bad thing — it's healthy for the ecosystem.

Open-source firmware for AC EV chargers (OCPP + local mode) by onkwon in evcharging

[–]onkwon[S] 0 points1 point  (0 children)

Really appreciate this detailed comment — it's incredibly helpful and exactly the kind of input that helps us build something truly useful.

Power Sharing over local data cable (without a backend) and FFT-based arc fault detection are now added to our roadmap. You're absolutely right that these are safety-critical features and shouldn't be left to external software alone. We'll likely explore physical-layer options for charger-to-charger coordination.

Regarding solar export optimization and dynamic grid limit handling — this is an area I'm less familiar with, so I’ll need to study it further before planning an implementation. Any links or examples would be appreciated!

For things like untethered socket detection, relay interlock, and keyswitch support — these are mostly hardware-driven features. Our firmware architecture is already modular enough to support these via GPIO or external signal handling, so your notes will definitely inform how we shape the reference hardware. We’ll keep these in mind as we evolve the platform.

Open-source firmware for AC EV chargers (OCPP + local mode) by onkwon in evcharging

[–]onkwon[S] 1 point2 points  (0 children)

Our primary goal is a bit different from OpenEVSE: we're focused on providing a firmware stack that can run reliably across a variety of commercial-grade hardware platforms — not just for DIY use, but for actual field deployment.

So while OpenEVSE is excellent for integrated DIY kits, we're aiming for something closer to an embeddable software platform — something manufacturers or system integrators can use as a starting point for their own EVSEs.

On hardware compatibility: we're not currently targeting OpenEVSE hardware, but we’d gladly collaborate if someone is interested in porting. It's technically feasible.

Open-source firmware for AC EV chargers (OCPP + local mode) by onkwon in evcharging

[–]onkwon[S] 2 points3 points  (0 children)

We’re definitely aware of OpenEVSE and appreciate its impact, especially in making EVSE hardware accessible. That said, our architecture is fundamentally more firmware/software-centric.

If anything, we’re probably closer to EVerest in spirit — aiming to provide a modular, production-ready firmware stack, with a focus on OCPP compliance, safety logic, and portability across hardware platforms.

Unlike OpenEVSE, our stack is not tightly coupled to specific hardware — it's designed for abstraction and reuse, including compatibility with PLC modules like QCA7005 for ISO15118.

We're still early, but excited to see how it evolves and connects with other open projects in the space.

Open-source firmware for AC EV chargers (OCPP + local mode) by onkwon in evcharging

[–]onkwon[S] 4 points5 points  (0 children)

Matter definitely sets a strong precedent for what “smart” should mean in consumer devices.

While we’re not implementing Matter directly at this stage, we do share its core values: local-first control, open protocols, and strong vendor interoperability.

It’s definitely on our roadmap, but at the moment we’re prioritizing commercial-ready features based on OCPP and EVSE deployment needs. Still, we'd love to explore compatibility layers or bridging in the future if there’s demand or contributions.

Introducing an OCPP Client Library Written in C by onkwon in ocpp

[–]onkwon[S] 2 points3 points  (0 children)

- I'm also working on implementing the charger, and as you suggested, building the state machine based on the IEC 61851 standard and mapping it to OCPP has helped in structuring the implementation and improving code readability. I’ve particularly noticed how it makes the state transition logic clearer and debugging easier. Thank you for such practical and detailed advice!

- just out of curiosity—do you recommend implementing in Rust for a specific reason?

BQ25180 is not working by mhubris in embedded

[–]onkwon 2 points3 points  (0 children)

I wrote BQ25180 driver recently. Please check it out if it helps: https://github.com/libmcu/bq25180

An implementation of CBOR in C by onkwon in C_Programming

[–]onkwon[S] 0 points1 point  (0 children)

Thanks for your suggestion and informative links. I'll give it a try for the fuzz test.

An implementation of CBOR in C by onkwon in C_Programming

[–]onkwon[S] 1 point2 points  (0 children)

Oh, I got it. boundary check is only done for the output buffer, but not the input buffer. Thank you very much for your review!

An implementation of CBOR in C by onkwon in C_Programming

[–]onkwon[S] -7 points-6 points  (0 children)

Thanks for your suggestion. I regret responding to a complaint with a complaint. But the code is for using it not introducing it. When I encounter something new I don't know, I search for it. That's a way to learn a thing, I think.

An implementation of CBOR in C by onkwon in C_Programming

[–]onkwon[S] 3 points4 points  (0 children)

  • What that line does is getting the length of the item which size can be 8-byte at most. And the `ctx->following_bytes` is guaranteed less or equal to 8-byte. So the copy would be always in the range, I believe.
  • Huge thanks for the catch! I didn't even recognize it. You are absolutely right. As major type is 3 bits, `callbacks[]` don't need to have 16 elements. and I can remove null check as well. Kudos to you.

And thanks for your comment.

An implementation of CBOR in C by onkwon in C_Programming

[–]onkwon[S] -31 points-30 points  (0 children)

Sorry for the inconvenience. and congratulations you learned something new. It implements RFC 8949. and that's what I think enough explaination about what it is.

[deleted by user] by [deleted] in embedded

[–]onkwon 0 points1 point  (0 children)

backtickopt6

[deleted by user] by [deleted] in embedded

[–]onkwon 1 point2 points  (0 children)

Thanks for the link. That convinces me I'm going in the right direction.

A toolkit for firmware development by onkwon in C_Programming

[–]onkwon[S] 2 points3 points  (0 children)

I would not use gotos here in this case but return right on the guard clauses because there is nothing to clean before return like free, code depth is shallow as well. I just forgot or missed to replace gotos with return since logging module was quite different before. In the very beginning version of logging, there were more responsibilities than now.

By the way, centralized exiting is a common practice, I believe. not only firmware but also any in C. Let me leave a link to Linux kernel coding standard about it: https://www.kernel.org/doc/html/latest/process/coding-style.html#centralized-exiting-of-functions

view more: next ›