Networks & access
Remote solar viewing is offline: a five-step check
Start at the last place where you can prove the data is current. Working outward avoids changing an inverter connection to solve an account problem.
1. Confirm current data at the property
Open the local dashboard and check the reading timestamp, equipment identities and responding count. A page left open yesterday is not proof of current collection. If local data is stale too, investigate the host or equipment path first.
If nobody can inspect the property, record that limitation. “Remote unavailable, local state unknown” is an accurate report. “The inverter is offline” is a diagnosis you have not established.
2. Check the host’s connection
Confirm the host is connected to the intended network and that the property’s internet service is available. A phone at the site may silently use mobile data, so its successful web browsing does not always prove the property network works.
Review Remote & displays for the host’s remote-connection state. Capture any exact error before restarting anything. A router restart may change the circumstances but can also erase useful clues about the original failure.
3. Confirm pairing and the account
Sunstead’s phone sign-in workflow starts from the host’s Remote & displays view. Pairing associates the property with an account; signing into the public website alone does not grant access to every device.
At your Sunstead account, verify the Google account and selected property. Invited viewers must use the account the invitation was intended for and complete acceptance. An expired or revoked invitation cannot be fixed by refreshing a dashboard.
4. Compare a separate remote connection
Useful separation
The local host has fresh data. The owner sees the property on mobile data, but one invited viewer cannot open it. That narrows the next check toward that viewer’s account, membership or browser. It does not establish a general outage of the property.
Conversely, if all authorized remote viewers fail while local viewing works, record the common failure and remote-connection status. Do not expose the local dashboard port as a workaround.
Raspberry Pi’s access documentation describes several distinct remote technologies. Sunstead account viewing, a local dashboard, SSH and remote desktop are separate services; success with one does not validate the others.
5. Report the last successful hop
- Local readings: current, stale or unverified.
- Host network and property internet: checked or unknown.
- Remote status and exact error.
- Account role and invitation state, without tokens.
- Results from a second authorized viewer or connection.
- Last successful remote use and recent changes.
Include timestamps and timezone. Remove invitation links, pairing codes and session details from screenshots before sharing them.
When service returns, verify that live timestamps advance. A previously cached chart can look reassuring while still showing old information. Keep the incident record if the problem repeats; a pattern across times and connections is more useful than a series of unexplained refreshes.
Sources & further reading
Documentation checked October 10, 2026.
Your next step
Create a support report