CASE 02 / NVT · SUNGROW · SOLAR & ENERGY STORAGE

iSolarCloud.
From China to Europe.

My frontend work on Sungrow’s solar and energy-storage platform spans the China-to-Europe migration, plant and device feature settings, and more recent EU Data Act data-access requirements.

Explore the platform Inside the migration ↓

CN → EU

Frontend migrationRegional routing · Country rules · Localization

↳

Plants & devicesFeature settings · Capability-aware operations

PLATFORM TECHNOLOGY

Vue 3 · TypeScript · Pinia
ECharts · Axios · MQTT

01 / THE PRODUCT

An energy operations platform.

Plants, devices, energy analysis and operational workflows within a shared, multi-region web application.

The iSolarCloud public European visitor demo showing a residential solar and energy-storage plant overview and energy flow. — A plant brings the system together.
Solar generation, storage, consumption and the grid share one operational view. The wider platform supports residential, commercial and storage plants.
PUBLIC VISITOR DEMO
EUROPEAN PLATFORM

Screens from the public iSolarCloud European visitor demo ↗. They illustrate the product context; the contribution sections describe my own frontend work.

02 / CHINA-TO-EUROPE MIGRATION

More than translating the interface.

Adapt regional behavior and service dependencies while keeping the original platform’s workflows compatible.

Product, cloud and language are different contexts.

A European interface can still need a test gateway.

The migration involved keeping European product behavior separate from the target cloud environment and the user’s language. The shared request layer resolves the intended service, while individual flows can override that default. A European test deployment must retain European UI behavior without sending its requests to production.

Country selection changes business eligibility.

An allowed-country list and an excluded-country list cannot share the same filter.

The localized European product uses configured countries as an allowed set. The original platform’s European-country path excludes countries assigned to that rollout. These are different business rules, even when the country names are identical. Configuration failures, historical selections and string-versus-number IDs also affect the frontend behavior.

Preserve the meaning of a measurement.

Formatting affects inputs, requests and interpretation.

German decimal and grouping separators need consistent parsing and display. Zero readings must remain distinct from missing values. Browser time-zone offsets, plant time zones and daylight-saving boundaries also represent different contexts; a date or numeric label alone does not settle how a measurement should be interpreted.

Follow the task beyond the first API response.

Task creation, push updates and file delivery cross different services.

Report exports create a task over HTTP, follow updates through an MQTT connection and receive a separate download destination. A successful API call therefore does not prove that a report can be downloaded in the European environment. The implementation also needs to account for task ownership and cleanup of subscriptions, timers and registrations.

A direct link carries its own regional context.

An existing browser session must not choose another email’s destination.

Email entry points can derive their cloud context from the host or from URL parameters, depending on the workflow. They can also use explicit service addresses and a different login path. Migrating the main application gateway alone does not cover report, upgrade or unsubscribe links; parameter parsing and the downstream request have to agree.

03 / PLANT & DEVICE FEATURES

Settings meet real equipment.

My work also covered feature settings and business interfaces for specific plants and devices.

PLANT CONTEXT

Configure features for the right plant.

Plant-specific interfaces need to keep the selected plant, its data and its available features together as the user moves between views.

DEVICE CAPABILITIES

A device type is only the beginning.

Parameter-setting logic considers country, grid type, firmware and protocol capabilities. Batch settings need to respect differences between the selected devices.

AVAILABILITY & RECOVERY

Explain what can happen next.

I coordinated plant and device states with country rules: explaining disabled features, hiding unavailable functions and providing fallback actions for abnormal states.

04 / ADDITIONAL WORK · EU DATA ACT

Data access, within the wider platform.

More recent work adds owner-facing data-access workflows to iSolarCloud, alongside the ongoing plant and device experience.

My work connects authorization, privacy consent and scope selection with asynchronous export states and download handling.

Task state and link validity need separate recovery actions; API access and third-party sharing also need an explicit scope. The sample below illustrates the export flow.

01Choose scope
02Confirm identity
03Prepare data
04Verify & download

BUILDING A COMPLEX BUSINESS PRODUCT?

Let’s make the workflows usable.

Let’s talk ↗