A more discussion-oriented topic to start with and gauge interest: would an « EV Charging Station » integration be of interest to anyone?
Several questions then arise from this project:
OK, but for what? Initially, I think it would mainly be for « data consumption »… but maybe that’s not enough?
OK, but what kind of integration?
Fully integrated with Gladys: Gladys hosts the code on its side… not sure if that’s a great idea, but why not in absolute terms. Maybe it’s the most integrated in the end?
In ocpp2mqtt mode: a bit like Zigbee and Z-Wave: we rely on another project that acts as a CSMS and publishes messages on an MQTT broker. The broker can also be used to send commands to the charging station. In this mode, the charging station no longer communicates with the station’s native cloud server.
In Relay 2 mqtt mode: in this mode, a program acts as an intermediary to transmit messages to the MQTT broker while allowing messages to pass to the native cloud. Gladys can, a priori, only receive messages, not send them to the charging station (in absolute terms, yes, but desynchronized with the cloud CSMS… not sure about the impacts).
Via Node-RED? In which case, there’s nothing really to do in Gladys, more of a tutorial question? (I just thought of this solution while writing the post, I admit)
I’ve started some initial research, I’m still having a bit of trouble identifying everything that could be done with the protocol (knowing that there are 2/3 versions of it). Receiving data seems more or less OK. It’s more in sending commands that I haven’t dug into what can be done, but in principle, why not. Hence this post: are people interested? What information can be retrieved? What commands can be pushed?
For the different options, there are more or less different ways to proceed:
That’s a valuable idea. Rather than fully integrating it into Gladys right away, connecting via OCPP-to-MQTT might be more practical; it facilitates testing and allows for the initial implementation of features like charging status, power output, energy levels, and start/stop control.
Deeper native integration can be considered once the specific usage requirements become clear.
Quick progress report (I’m still being careful with this, I don’t really want to fry the charger… or the car… or the house )
At this stage, I have a relatively simple loop, outside of Gladys for the moment. But thanks to the project GitHub - gyzod/ocpp2mqtt: OCPP <==> MQTT Gateway · GitHub & GitHub - ocpp-balanz/ocpp-2w-proxy: A 2 way OCPP proxy · GitHub I was able to set up a web interface that can show me the real-time status of my charger.
The idea behind the ocpp-2w-proxy project, as its name suggests, is to act as a proxy (a kind of Man In The Middle) between the charger and the native Cloud server.
This allows me to keep the control via the native app. In my case, I notice that my Autel Charger app remains 100% functional (from what I’ve been able to test so far…). My MQTT also receives all messages. This allows me to update a fake web interface for the moment.
My problem is with starting a charge. Changing the configuration, stopping, refreshing: everything works. But starting a recharge, for the moment I’m stuck.
Perhaps the first step will be to make sure I can see the status of the charger. We can then dig into what’s not working.
Where I also have some reservations is that I had to modify the source code of the referenced projects for it to work. I’ll double-check this point, it might be a mistake on my part.
Nothing related to Gladys for the moment, but once I’m sure it’s OK: go for the plugin
If I were you, I’d run Claude on the topic with all the information from this post
In 30 minutes, you have an external integration with Gladys that has a good chance of working right away on the first try, testable with one click in Gladys, and you can iterate from there.
End to end, I think that today an external integration takes less than an hour of work, without needing to dive into the API or the code.
On my end, the results I get are really clean, often better than what a human developer would do because all edge cases are well managed, it’s worth a try
It’s not so much a matter of speed or ease of use with the APIs: that step isn’t a concern yet (this point won’t worry me, it will be quickly handled by AI).
Couldn’t the AI just rewrite the entire stack directly into the Gladys integration? This way, we’d avoid being dependent on these external projects while keeping control over the implementation, updates, and bug fixes. It would also offer more flexibility in the long run, right?
This was one of the possible tracks also mentioned in the initial post. Are we in agreement that when you say « all this stack in Gladys » we’re still on the idea of an « external plugin via the API »?
The question boils down to why look to redevelop something that already exists. I’m exaggerating, but basically you’re asking: why choose zigbee2mqtt instead of redeveloping it? If solutions on the market do the job, why want to re-implement them. Am I misinterpreting the question?
If these two projects do the job, we might as well not do without them. If they are limiting, I’ll look into a home implementation. In the absolute, I almost want to say, as an « external plugin » it’s an « implementation detail »?
I don’t have a definitive opinion on the question yet. As far as I’m concerned, I’m still in the exploration phase of the possible. I think this weekend I’ll work on this point to push an integration.
Yes, that is indeed the question. But when I look at ocpp-2mqtt, I see a relatively simple project that evolves very little.
The repository has only 90 commits, and a large part of them are related to documentation or CI updates. In the end, there isn’t much business logic.
ocpp-2w-proxy is even worse, with only 19 commits and the last update being 5 months ago.
This is exactly the kind of project that an AI can rewrite in about thirty minutes today. This way, we avoid dependency on a third-party project that evolves little, while keeping control of the code and the ability to evolve it or quickly fix bugs.
On the other hand, Zigbee2MQTT is on a completely different scale: over 6,400 commits, hundreds of contributors, and very active development. Here, there is real accumulated expertise and a huge compatibility base with Zigbee devices. In this case, it is much more relevant to rely on their work rather than trying to reimplement everything.
I haven’t ruled out this possibility. I was thinking in terms of a fork, but we could also imagine starting « from scratch ».
I’m testing the HA solution to see if the issue I’m identifying is specific to my device or the library, and here’s what I found: +1: +1: +1:
So you went with an additional container mode? Honestly, that’s clearly overkill in my opinion, you could have done it natively, a shame to have a dependency
So either I’m missing something in the documentation, or you’re not fully aware of how OCPP works.
For the OCPP integration, we need a new WebSocket to be available. The charging stations connect to this WebSocket. The idea behind the integration is to act as a Man In The Middle to see what’s happening. Otherwise: it’s total confusion.
From the documentation, I read three things:
the manifest fields: which don’t mention port exposure capabilities
the security model which explains that the Docker lives in an isolated Network
companion containers: which are there to (among other things) create protocol bridges… for me, this is exactly the case here
So either I’m missing information, the main container can perfectly open ports and make them available on the network, and in that case, I agree with you, tell me how to do it and I’ll modify it without any issues. Or it’s not possible and therefore it’s not overkill
I double-checked the spec: the main container of an external integration intentionally has no published ports, its only incoming channel is the outgoing WebSocket to Gladys. Published ports only exist on the sub-containers declared in containers[]. So for OCPP, where it’s the charging station that connects as a WS client, the companion container is indeed the only option today. Not overkill at all
After that, nothing forces you to use a third-party image in the sub-container, containers[].docker_image also accepts yours. You can therefore declare a sub-container that runs your own OCPP server if you ever want to limit external dependencies!
)
This way, we’d avoid being dependent on these external projects while keeping control over the implementation, updates, and bug fixes. It would also offer more flexibility in the long run, right?
