The select devices option works, thanks for the info @pierre-gilles, I had missed it. It’s a simplifier! But it still remains a not optimal and not simple user journey. Because basically the user must:
Modify the URL in their application
Go to Discovery and add the terminal to Gladys. But the terminal is in an « unstable » state at that moment. It can communicate with Gladys, but no longer with the Cloud Bridge.
Go back to Configuration to select the terminal and add a URL: but in an interface not directly linked to the device
To see a URL configured per terminal, you have to go to device or discovery where you can push the params (which I am currently doing)
It works, it’s cool. But it’s not the simplest. Also, tomorrow, I imagine an option where the user will choose: « yes I want to use the original cloud » or « no, leave everything on Gladys ». And thus have a slightly more advanced configuration interface per terminal if necessary.
For a V1, we can settle for the current mode of operation. But having a slightly more advanced management capability of the conf’ per device (conf’ managed on the side of the plugin providing the functionality) would seem to be able to unlock new scenarios.
To be able to move forward with the external OCPP integration, I would now need the merge of the PR that introduces the notion of category CHARGING_STATION and the associated types. What is missing on your side to move forward with this PR?
@pierre-gilles There is a bug in the external integration part when using the select devices mode. The validation does not work. This code does not correctly account for devices, always uses an empty array, and prevents the actual use of the option proposed here (I hadn’t tried the update on my interface):
// externalIntegration.validateConfigValue.js:36-41
case 'select': {
const validValues = (field.options || []).map((option) => option.value);
if (!validValues.includes(value)) {
throw new Error422(`config.${key}: must be one of ${validValues.join(', ')}`);
A new feature request: it would be interesting to be able to specify whether or not we actually want to display this button (today it automatically appears if I have defined a port):
However, in my case, the button as it is doesn’t make sense. What would actually interest me is the ability to customize the message or access the Gladys URL on this screen. Could the SDK expose the « getHost() »?
By the way, a small display issue with the selector here:
I currently have a Tesla Gen3 wallbox, I’m looking into what protocol it uses because for now I retrieve the information via HA (without control), and if I ever test your integration.
I’m also looking to replace it and get this one from DEPOW compatible with OCPP (and I see that its price has dropped by €200 recently!).
I love diving straight into complexity with multi-connector management!
I didn’t express myself well in my previous post: I haven’t made v1 public yet. An update to Gladys is needed first.
My biggest « concern on the subject »: it’s the lack of various tests. I have an Autel Charge at home. Single connector. Theoretically, the code supports multi-connectors. But I haven’t tested it. I couldn’t test ocpp2.0.1 in a real situation either. My station is on 1.6 (there’s a 2.0 option, I need to see if it works)
So I’m open to other testers.
If you have a Gladys instance running on master and you’re not afraid… I’m interested!
Before diving headfirst into the Tesla, screenshots interest me to see what you can configure (it’s the settings part that interests me and the notion of ocpp or csms server). If you have that ready, I’m interested.
For the Gen3, it’s dead in OCPP, Claude mentioned it to me
Good news and bad news: we can indeed retrieve a lot of information from the Gen 3, but not at all in OCPP, and control remains very limited. Here are the details.
1. OCPP on the Wall Connector Gen 3: Not Supported
Contrary to what one might hope, only the Tesla Universal Wall Connector (US only) supports OCPP; the Gen 3 and Gen 3 MID do not support it and cannot connect to an OCPP server. This is confirmed by several third-party platforms that manage OCPP integration (Plugchoice, Charge HQ): Charge HQ explicitly notes that no Tesla wall or mobile charger currently supports OCPP. PlugchoiceChargeHQ
There are indeed community rumors (notably around the Monta app) claiming to successfully connect a Gen 3 in OCPP, but these are unofficial and unreliable hacks — the documented position remains « not supported » for the Gen 3. So the OCPP protocol is out of the question for your charger.
2. How Does Home Assistant Retrieve the Information Then?
Not via OCPP at all: the charger exposes locally, on your Wi-Fi network, an officially undocumented HTTP REST API (reverse-engineered by the community since 2020). It responds without authentication to endpoints like http://<charger_IP>/api/1/vitals, /api/1/wifi_status, /api/1/lifetime, and /api/1/version. Tesla Motors Club
The /api/1/vitals endpoint is the richest: voltages and currents per phase, power, internal temperatures, charging state, current session data, etc., accessible simply via a browser or curl and returning a complete JSON object. Tesla Motors Club
The official « Tesla Wall Connector » integration of Home Assistant Core is based exactly on this:
Available since HA 2021.12, automatic discovery possible via the local network, it exposes entities like total energy and energy of the current charging session. Home Assistant
Its « IoT class » is « Local Polling » — so no dependency on the Tesla cloud, everything is done by querying the local IP of the charger at regular intervals. Home Assistant
Technically, it relies on a small dedicated Python library, « tesla-wall-connector », designed for local consumption and integration with Home Assistant, which exposes an asynchronous API around these same endpoints.
You can even test this yourself without installing anything: find the local IP of your charger (router, or hostname type TeslaWallConnector_XXXXXX.localdomain) and open http://IP/api/1/vitals in a browser.
3. And Control (Start/Stop, Amperage)?
There, it’s no — this local API is strictly read-only.
So for now, I can’t test anything, but I’m following the topic closely
Thanks, this feedback is super useful, I’ll take it in order.
The « Open » button: you’re right, it’s a blind spot. This link was designed for the Frigate case, where a published port = a web interface to open. Your case is the first where the published port is an endpoint for machines (your terminals) and not for a browser, and as a result the button sends the user to an error page. The correct answer is a flag in the port declaration in the manifest, to say « this port is not browsable, do not display a link ». It’s a small additive change, I’ll add it to the spec and then implement it.
The getHost(): the need is clear and I want to cover it, but not in this form, and I’ll explain why. Your container cannot know Gladys’ address as the terminal sees it on the LAN. On the server side, we can only resolve the view from the container (the bridge gateway, the internal alias…), and Gladys itself does not reliably know its own LAN IP (multi-interfaces, reverse proxy, VPN…). A getHost() in the SDK would therefore often return a false value, and I prefer no API to an API that lies.
The one who knows the correct address is the user’s browser, which is on the LAN. This is already how the « Open » link is built. The path I’m keeping is placeholders in the declarative texts of the manifest, resolved by the front end at display: a section block that contains for example {{gladys_host}} and {{port:ocpp}}, and the user sees a complete and copyable URL like ws://192.168.1.50:32768. This would also solve the first step of your 4-step process: it will remain manual, but it will become guided. The only limitation, assumed and already true for the « Open » link: if the user navigates via a Gladys Plus tunnel or a reverse proxy, the displayed hostname will not be the LAN IP.
The display bug of the selector: well spotted, I’ll look into it!
Version 1 is released.
It is limited in its capabilities: it can only read data for the moment, and only on version 1.6 of OCPP (the only hardware I have available for testing).
Tested on only one type of charging station (an Autel Charge).
I will look into version 2.0.1 of the protocol later (end of August)
As for actions… to be seen, it may depend on the charging stations. We will also try to tackle that.
diving straight into complexity with multi-connector management!
