Description:
Some external integrations need to display a URL to the user pointing to Gladys itself. Concrete case with the OCPP integration: the user must configure their charging station (via the manufacturer’s app) to connect to the relay hosted by the integration, with a URL of the type ws://<gladys-ip>:<assigned-port>. Today, nothing allows displaying this URL: the user must find the IP of their instance and the assigned port themselves.
The integration container cannot provide this information reliably: on the server side, only the address of Gladys as seen from the container (bridge gateway, internal alias) can be resolved, and Gladys does not know its own LAN IP with certainty (multi-interfaces, reverse proxy, VPN). Exposing a getHost() in the SDK would often return a false value. However, the user’s browser knows the correct address; this is already how the « Open » link for published ports is constructed.
Proposal: support placeholders in the declarative texts of the manifest (initially the section blocks of the config_schema), substituted by the front end at display:
{{gladys_host}}: the hostname by which the user accesses Gladys{{port:<name>}}: the host port assigned to the port declared<name>in the manifest
The OCPP integration could thus display a block like: « Configure your station to point to ws://{{gladys_host}}:{{port:ocpp}} », with a complete and copyable URL. The mechanism remains 100% declarative, with no code injected by the integration.
Known and accepted limitation (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. This needs to be documented.
Context: field feedback from @Sescandell on the OCPP integration, see the topic WIP Electric Vehicle Charging Station OCPP Protocol.