Solar Node — Home energy on mobile

The product separates several kinds of work. Setup captures information about the household and its energy configuration. Devices contains the later connection of equipment. Home presents an overview, while Forecast organizes energy-related information over time.

These areas represent different levels of information: context, overview and analysis. This describes the designs, rather than a tested end-to-end journey.

On a phone, those levels also compete for space. Configuration needs explanations and fields. A dashboard needs priorities. Analysis needs axes, labels and enough context to interpret a chart. The case focuses on how I organized those different screen types.

I worked on the configuration flow for the home, energy parameters and tariffs, including the separation between household context and later device connection.

The location screen makes that separation explicit: this stage establishes the home’s context, and devices will be connected later through Devices. The setup designs then cover the household, energy profile, tariffs and a summary.

The energy profile includes PV-related parameters, a minimum battery charge reserve and charge or discharge limits. The tariff area includes purchase and export settings, along with optional import and export limits.

A note in the design states that limits will be verified after devices are connected and their capabilities mapped. That is a concrete dependency in the interface: some settings describe the household’s intended configuration, while later information depends on the connected equipment.

The division can be understood as context first, hardware capabilities later. I contributed to designing that flow, but cannot claim to have originated the entire product decision or designed the integration architecture behind it.

Devices is shown here to explain the wider product context. Its screens include categories, added equipment and connection states. My authorship of that module is not established as clearly as my setup work, and the materials do not verify a complete pairing process or working capability mapping.

The sequence shows the designed separation, without claiming a tested activation funnel or faster setup.

The Home concept and layout were my UX/UI work. That included the hierarchy, the presentation of information around a house, supporting cards and the organization of the screen for mobile.

The intent was to avoid starting with a technical panel for an installer. The house provided a familiar reference: PV on the roof, a battery as storage, a meter, an EV and the home at the center of the screen.

Information is placed near those objects, with further context below in cards. The hierarchy moves from header and system status to the house model, then to prices, monetary values, weather and tariff information.

This is an illustrative organization of information. It is not a verified diagram of every physical energy flow. The values around Meter and Battery are not sufficiently documented for me to define their pairs here, and the period represented by the household value is also unconfirmed.

The Home designs contain more descriptive and more compact variants. In one, cards use additional labels; in another, icons and numbers carry more of the presentation. I associate that compact direction with reducing text density on a small screen, although I do not remember the precise feedback that triggered it.

The comparison exposes a useful trade-off. Short labels can leave room for more information, but icons still need clear meanings. I cannot claim that the compact version improved understanding or that a particular variant won a usability test.

The material shows a Home hierarchy and variants in how much explanation it presents. Detailed analysis remains in Forecast.

My Forecast work covered its mobile structure: thematic tabs, the presentation and order of charts, and the arrangement of information over time. I do not claim exclusive authorship of every chart or variant in the file.

The designs separate Production, Consumption, Battery, Grid and Weather. They also show energy prices, controller states and expected battery levels. This gives each topic a place without putting every series into one undifferentiated view.

Home and Forecast can be read as two levels of detail: an overview organized around objects, and an analytical area organized around time and topic. That is a description of the information structure, not a verified interaction from every Home card to a corresponding chart.

The NOW marker provides a visible time reference. A separate summary variant uses recorded and remaining labels for production and consumption. Those labels support a distinction in that specific view; they do not prove that every series before NOW is measured and every series after it is predicted.

The Grid view is particularly useful for showing the composition of the analytical screen. It combines grid-related bars and totals with controller states, expected battery information and purchase or sale prices. Battery views use percentages, while Weather shows temperature and wind over time.

Read together, these arrangements suggest a way to compare related factors. That is an interpretation of the designs. The screens do not establish the algorithm’s decisions, the source or accuracy of forecasts, or whether users made better choices from them.

The chart details retain their axes and legends; captions describe the labels visible in each design.

The Home material includes device-addition prompts, inactive EMS labels, coming-soon indicators and an alert variant. These are different signals, and I do not treat them as evidence of a complete strategy for missing, delayed or offline data.

The file also contains a UI Kit, components, instances and variants for recurring patterns. They provide useful context for the project’s interface consistency, but my individual ownership of the entire kit is not confirmed. I describe the available material as a UI Kit and components, without implying a fully implemented Design System.