A suitable device
A field computer or gateway capable of running the agent. Verify OS, architecture and service reachability before a pilot; installation directly on every inverter or charger is not claimed.
ENERGY · RENEWABLESRemote sites.
Remote sites.
Closer maintenance access.
We are developing EdgeSocket for authorized remote access to existing maintenance services on solar and wind gateways, energy monitoring computers and edge devices at EV charging locations.
Example: a solar gateway’s web panel
Imagine a gateway that already collects field data and has a web interface. The goal is to reach that existing service from a maintenance computer, without introducing a new energy management system.
- 01
Authorize the device and user
The EdgeSocket component runs on a supported field device or approved gateway. An enterprise user receives an explicit grant for the target device.
- 02
Connect to the existing service
A web panel or SSH service reachable by the gateway is configured as a target. The operator uses their existing browser or SSH application through a local connection address.
- 03
Establish the connection path
When WebRTC can establish direct P2P connectivity, traffic avoids a relay detour, which may reduce latency. Otherwise an accessible, authorized TURN server relays encrypted traffic.
What the site needs
A defined service
An existing SSH endpoint, web interface or other TCP/UDP target. The service’s own authentication and permissions still apply; an EdgeSocket device grant does not replace them.
Approved network access
Both endpoints must reach the identity/signaling services. TURN must also be reachable when needed. Carrier and site-network behavior must be checked in the actual environment.
Energy protocol integration is separate
The TCP/UDP transport core is implemented; this is not a claim of ready-made Modbus, IEC 61850, SCADA or OCPP integration. Protocol behavior and access limits need separate evaluation. Device authorization exists; separate port/service-level authorization is not implemented and requires its own scope decision.
Explore the connection technology →Cloud or on-premises deployment
Both deployment models are in the product plan. The connection core and server packaging exist; the complete management app, simple enrollment and GUI are not generally available. Real device/network acceptance and secure-update preparation remain open.
CRA preparation and source SBOM →Common questions
Can I reach a site using mobile connectivity?
This is an intended use case. Direct P2P depends on network conditions; TURN may be needed. Service reachability at both ends and device authorization must be validated in a field test.
Does this expose the whole plant network?
This example describes access to a configured service. LAN routing needs separate configuration and risk assessment; access to the whole network should not be assumed.
Is this ready for production control?
There is no generally available field product or deterministic real-time guarantee yet. Define pilot scope, maintenance windows and connection-loss behavior with the site team.
Share your site requirements
Describe the device/OS, target service and site connectivity. Do not include passwords, tokens or actual facility access credentials.