PVS5 observations

[andreasplesch]

Since the PVS5 is referenced in this repo a few times let me share a few observations I made experimenting with my early 2017 PVS5 (see krbaker/hass-sunpower#125 (comment) and krbaker/hass-sunpower#125 (comment)):

• I can connect through the installer LAN but not through the home LAN to which the PVS5 is connected by powerline ethernet. Apparently some can use the home LAN with newer firmware.
• authentication is required and works
• vars API works, and some of the dl_cgi API
• cgi-bin/dl_cgi/supervisor/info returns just an empty object {}
• cgi-bin/dl_cgi/devices/list works and returns complete list and fields. First time I could see detailed panel data in 8 years.
• SWVER is 2025.10, Build 5408 which I could not find mentioned anywhere else
• /sys/info/sw_rev has 0.0.25.5408 which looks off
• /sys/info/fwrev has TBD which looks off
• vars with match and fmt parameters works, so potentially could just look for all vars easily.

Does the integration assume that supervisor/info is available ?

Happy to look up more detail or background. Also saw the PVS6 Bluetooth vulnerability bulletin which may also apply PVS5.

[smcneece]

Thanks for the detailed investigation! This is really valuable info on PVS5 compatibility.

On BUILD 5408:

That's fascinating - SWVER "2025.10, Build 5408" means your firmware is from THIS MONTH (October 2025), It appears PVS5 uses a different BUILD numbering scheme than PVS6:

• PVS5: 5xxx BUILD numbers (yours: 5408, Oct 2025)
• PVS6: 61xxx BUILD numbers (current: 61845, Sept 2025)

Critical question for integration compatibility:

Our integration uses BUILD >= 61840 to detect new firmware with authentication. But your PVS5 might have authentication too, just with different BUILD numbers.

Can you confirm:

1. Does authentication work with password = last 5 characters of PVS serial?
2. Does the /vars endpoint work for device data?
3. Which endpoints work: /supervisor/info, /cgi-bin/dl_cgi?Command=DeviceList, or both?

On /supervisor/info:

The integration has a fallback when /supervisor/info isn't available - it tries pypvs first, then dl_cgi device_list. Since you confirmed dl_cgi works, setup should succeed.

On LAN connectivity:

You mentioned unreliable home LAN connection. We recently discovered Raspberry Pi bridges/proxies don't work with new firmware (BUILD 61840+) because they can't handle HTTPS authentication on port 443. If your PVS5 has
authentication, this might affect you too.

Testing request:

Can you test the integration and share setup logs? Your PVS5 data would help us:

• Determine correct BUILD threshold for PVS5 authentication
• Ensure PVS5 compatibility
• Update documentation for PVS5 users

[andreasplesch]

Let me try to answer below:

Thanks for the detailed investigation! This is really valuable info on PVS5 compatibility.

On BUILD 5408:

That's fascinating - SWVER "2025.10, Build 5408" means your firmware is from THIS MONTH (October 2025), It appears PVS5 uses a different BUILD numbering scheme than PVS6:

* PVS5: 5xxx BUILD numbers (yours: 5408, Oct 2025)

* PVS6: 61xxx BUILD numbers (current: 61845, Sept 2025)

Agreed, I was very surprised to see this and was hoping other PVS5 owners could confirm. I did notice that the PVS5 had offered a SSID (SunPowerXXXX) for its wireless network for a while which normally is only available through commissioning, and then stopped (perhaps after updating the firmware).
What do you think about the somewhat strange /sys/info/sw_rev value of 0.0.25.5408 ?

Critical question for integration compatibility:

Our integration uses BUILD >= 61840 to detect new firmware with authentication. But your PVS5 might have authentication too, just with different BUILD numbers.

Can you confirm:

1. Does authentication work with password = last 5 characters of PVS serial?

Yes, password authentication works and is required, and uses the last 5 characters of the serial number. This was a big step forward when I got it to work. It needs https and I believe the -k option for curl.

2. Does the /vars endpoint work for device data?

It does work but I did not test all variables listed here: https://github.com/SunStrong-Management/pypvs/blob/main/doc/varserver-variables-public.csv

3. Which endpoints work: /supervisor/info, /cgi-bin/dl_cgi?Command=DeviceList, or both?

Both do not work (even after authentication). But /cgi-bin/dl_cgi/devices/list works (see krbaker/hass-sunpower#125 (comment)).

On /supervisor/info:

The integration has a fallback when /supervisor/info isn't available - it tries pypvs first, then dl_cgi device_list. Since you confirmed dl_cgi works, setup should succeed.

I should clarify that /supervisor/info is available but only returns an empty JSON object {}.

Agreed, pypvs should work (if it is tested against the PVS5). Could you please confirm if the integration also falls back on /cgi-bin/dl_cgi/devices/list (rather than /cgi-bin/dl_cgi?Command=DeviceList) ?

On LAN connectivity:

You mentioned unreliable home LAN connection. We recently discovered Raspberry Pi bridges/proxies don't work with new firmware (BUILD 61840+) because they can't handle HTTPS authentication on port 443. If your PVS5 has authentication, this might affect you too.

Sorry for the confusion. By home LAN I did not refer to a Raspberry (or perhaps Mango) proxy connected to the installer LAN, but the regular LAN which is used by the PVS (somehow) for reporting back to SunStrong. My impression was that some could start to use that regular LAN as it seems to be recommended by the new official SunStrong pypvs based HA integration.

Testing request:

Can you test the integration and share setup logs? Your PVS5 data would help us:

* Determine correct BUILD threshold for PVS5 authentication

* Ensure PVS5 compatibility

* Update documentation for PVS5 users

I was able to install a Hyper-V based HA on my laptop, then HACS and then this integration. But then I could not get back to the initial set-up step with the discovery after doing something else, and removed the integration. Hopefully I can just reinstall ?
I can then try again with a direct installer LAN connection (in the basement).

[smcneece]

"Thanks for testing! Sorry you hit that setup issue - 'could not get back to the initial set-up step' sounds like you encountered the integration showing 'Failed to setup' after the initial attempt.

This is a known issue with the current version - pypvs discovery sometimes times out during initial setup. The workaround is:

1. Setup shows 'Success' but integration shows 'Failed to setup - Check the logs'
2. Go to Settings → Devices & Services → Enhanced SunPower
3. Click the three dots → Reload
4. Integration should start successfully on the retry

We're working on a fix for the discovery timeout. Your enhanced logging from v2025.10.14 will help diagnose what's happening with PVS5 specifically.

Regarding PVS5 compatibility:

Your BUILD 5408 from October 2025 is actually newer than current PVS6 firmware (BUILD 61845 from September 2025) - just different numbering schemes. Since /vars works and authentication is functional, pypvs should handle discovery fine. The BUILD comparison logic (BUILD >= 61840) was based on PVS6 and may need adjustment for PVS5.

Network Setup Clarification:

The PVS5 has two network ports:

• LAN port: Used by installers. This is what Keith Baker's hass-sunpower and older versions of this integration had to use. Important: The LAN port has a DHCP server, so it must be isolated from your home network (VLAN or other segmentation) to avoid network conflicts.
• WAN port: Originally for reporting to SunPower/SunStrong. Also connects to home network via WiFi (at least on PVS6, likely PVS5 too). With new firmware authentication, this integration can use the WAN port directly without network isolation.

When you reinstall and test with installer LAN, please share the logs (even if it shows 'Failed to setup' initially). The enhanced logging will show exactly what's happening with the empty /supervisor/info response and how the integration handles the PVS5 firmware detection.

Thanks for your willingness to test!!

[andreasplesch]

"Thanks for testing! Sorry you hit that setup issue - 'could not get back to the initial set-up step' sounds like you encountered the integration showing 'Failed to setup' after the initial attempt.

It times out with "Unknown error occurred" using the regular ip for the PVS5. This is the correct ip as confirmed in the router admin. The WAN port on the PVS5 is not connected, it is using ethernet over powerline instead (as originally commissioned). The SunStrong Connect app works. Nmap scanning of the ip shows only 'filtered' 80 and 443 ports, and a open 55232 port which is recognized as using ssh.

So I am hoping for the next firmware release to enable that network connection.

This is a known issue with the current version - pypvs discovery sometimes times out during initial setup. The workaround is:

1. Setup shows 'Success' but integration shows 'Failed to setup - Check the logs'
2. Go to Settings → Devices & Services → Enhanced SunPower
3. Click the three dots → Reload
4. Integration should start successfully on the retry

We're working on a fix for the discovery timeout. Your enhanced logging from v2025.10.14 will help diagnose what's happening with PVS5 specifically.

Regarding PVS5 compatibility:

Your BUILD 5408 from October 2025 is actually newer than current PVS6 firmware (BUILD 61845 from September 2025) - just different numbering schemes. Since /vars works and authentication is functional, pypvs should handle discovery fine. The BUILD comparison logic (BUILD >= 61840) was based on PVS6 and may need adjustment for PVS5.

Network Setup Clarification:

The PVS5 has two network ports:

• LAN port: Used by installers. This is what Keith Baker's hass-sunpower and older versions of this integration had to use. Important: The LAN port has a DHCP server, so it must be isolated from your home network (VLAN or other segmentation) to avoid network conflicts.

Yes, I can use that LAN port, after turning off wifi for isolation.

• WAN port: Originally for reporting to SunPower/SunStrong. Also connects to home network via WiFi (at least on PVS6, likely PVS5 too). With new firmware authentication, this integration can use the WAN port directly without network isolation.

When you reinstall and test with installer LAN, please share the logs (even if it shows 'Failed to setup' initially). The enhanced logging will show exactly what's happening with the empty /supervisor/info response and how the integration handles the PVS5 firmware detection.

Here is a log from that unsuccessful attempt:
home-assistant_2025-10-22T02-12-06.052Z.log

Thanks for your willingness to test!!

I will try next with 172.27.153.1 while connected to the installer ethernet port (LAN).

[smcneece]

Thanks for the log file - found the bug!

The Problem:
Your log shows config flow crashing with TypeError: '>=' not supported between instances of 'NoneType' and 'int' at line 142.

When supervisor/info times out (network blocks ports 80/443), the integration gets build = None but tries to compare it to an integer → crash.

The Fix:
Just pushed v2025.10.16 (pre-release) with a None-check that forces legacy detection fallback when supervisor/info unreachable.

Next Steps:

1. Install pre-release via HACS: (pre-releases are somewhat hidden and will need to be manually installed)
   - HACS → Enhanced SunPower → ⋮ (Three dot menu)→ Redownload
   - Need a different version - Click the "release drop down"
   - Select v2025.10.16 (should be at top)
   - Restart HA
2. Try setup using installer LAN port IP: 172.27.153.1
   - Your nmap results show ports 80/443 filtered on home network
   - Installer LAN port should work (requires network isolation from main LAN)
   - See TROUBLESHOOTING.md for VLAN setup or Raspberry Pi proxy options
3. Report back if setup completes successfully with legacy detection

Note: You have BUILD 5408 (old firmware), so integration will use legacy dl_cgi mode without authentication.

[andreasplesch]

Next Steps:

1. Install pre-release via HACS: (pre-releases are somewhat hidden and will need to be manually installed)
   - HACS → Enhanced SunPower → ⋮ (Three dot menu)→ Redownload
   - Need a different version - Click the "release drop down"
   - Select v2025.10.16 (should be at top)
   - Restart HA

Sounds straight forward, I will do that.

2. Try setup using installer LAN port IP: 172.27.153.1
   - Your nmap results show ports 80/443 filtered on home network
   - Installer LAN port should work (requires network isolation from main LAN)
   - See TROUBLESHOOTING.md for VLAN setup or Raspberry Pi proxy options

Yes, let me try the installer LAN port next.

3. Report back if setup completes successfully with legacy detection

Note: You have BUILD 5408 (old firmware), so integration will use legacy dl_cgi mode without authentication.

I found using curl that the dl_cgi mode on the system also requires authentication with session cookie with my firmware, so this may not work but let's see.

[andreasplesch]

I could update ha-esunpower to v2025.10.16 and then tried to add the integration while being only connected to the installer lan. I had to relogin to HA using the local IP for the hyper-v homeassistant instance. The setup then got one step further after providing 172.27.152.1 as IP address (153.1 does not work) and recognized the serial number and so the password. But it then fails:

Here is the corresponding log. It has a similar error due to using 'None' with int.

home-assistant_2025-10-22T22-25-58.905Z.log

[smcneece]

Ok thanks for the log very helpful!! Give me 30 minutes or so, and I will have a new version to try. Will reply again when it's ready. You'll need to install it via HACS as before, it will be a pre-release so only the couple testers will get it. v2025.10.17

[smcneece]

v2025.10.17 is now ready!

[smcneece]

Good news, another user with a PVS5 is now up and working: #22

[andreasplesch]

I could upgrade to 2025.10.17 and tried to add the integration. This time it succeeded in authorizing the connection to the PVS and then recognized the supervisor, meters, and inverters from the panels. So this looks good !
Here is the generated log which shows additional, non-fatal None errors related to flash related parameters being expected but not available.

home-assistant_2025-10-23T13-06-19.510Z.log

I think the integration may be using dl_cgi/devices/list. Let me generate a larger query of parameters available through the vars API on the system and share that as well. As you recognized the build numbering follows different schemes depending on the PVS type. It may be beneficial to use not just the build number but the build number together with the PVS type as a criterion if the new vars API should be used.

[smcneece]

Thanks for testing v2025.10.17 and confirming setup works on PVS5! Great to see 12 inverters discovered successfully.

I spotted the health check errors in your logs (flash memory monitoring crash). Working on a new pre-release v2025.10.18 that fixes this - added the missing None-check in health_check.py.

Your feedback about PVS5/PVS6 BUILD numbering differences is valuable - we may explore using BUILD + PVS_MODEL as detection criteria in the future. For now, the None-safe fallbacks handle both hardware types.

Thanks for the thorough testing and detailed logs! I'll post again when it's ready to download via HACS.

[smcneece]

New version is now live, actually released as a full release since it had other fixes and new features as well, not just PVS5 related. Look for v2025.10.18.

Please let me know of any issues.

[andreasplesch]

I could retrieve all varserver variables which are published on my system. They are listed below. Out of the 68, 65 are listed in https://github.com/SunStrong-Management/pypvs/blob/main/doc/varserver-variables-public.csv and three are not:

/net/cell/state,
/net/plc/state,
/net/wan/state,

cell is probably for cellular, and plc for powerline connection. /net/plc/state is online for me.

Four are valued TBD:

       "/sys/info/fwrev": "TBD"
       "/sys/info/boardtype": "TBD"
       "/sys/info/ssid": "TBD"
       "/sys/info/wpa_key": "TBD"

Two have Unknown:

       "/sys/info/finance_type": "UNKNOWN"
       "/sys/info/sys_type": "Unknown"

Here is the full list:

/net/cell/state,
/net/plc/state,
/net/sta0/state,
/net/wan/state,
/network/report/send,
/sys/devices/inverter/{index}/freqHz,
/sys/devices/inverter/{index}/i3phsumA,
/sys/devices/inverter/{index}/iMppt1A,
/sys/devices/inverter/{index}/ltea3phsumKwh,
/sys/devices/inverter/{index}/msmtEps,
/sys/devices/inverter/{index}/p3phsumKw,
/sys/devices/inverter/{index}/pMppt1Kw,
/sys/devices/inverter/{index}/prodMdlNm,
/sys/devices/inverter/{index}/sn,
/sys/devices/inverter/{index}/tHtsnkDegc,
/sys/devices/inverter/{index}/vln3phavgV,
/sys/devices/inverter/{index}/vMppt1V,
/sys/devices/meter/{index}/ctSclFctr,
/sys/devices/meter/{index}/freqHz,
/sys/devices/meter/{index}/i1A,
/sys/devices/meter/{index}/i2A,
/sys/devices/meter/{index}/msmtEps,
/sys/devices/meter/{index}/negLtea3phsumKwh,
/sys/devices/meter/{index}/netLtea3phsumKwh,
/sys/devices/meter/{index}/p1Kw,
/sys/devices/meter/{index}/p2Kw,
/sys/devices/meter/{index}/p3phsumKw,
/sys/devices/meter/{index}/posLtea3phsumKwh,
/sys/devices/meter/{index}/prodMdlNm,
/sys/devices/meter/{index}/q3phsumKvar,
/sys/devices/meter/{index}/s3phsumKva,
/sys/devices/meter/{index}/sn,
/sys/devices/meter/{index}/totPfRto,
/sys/devices/meter/{index}/v12V,
/sys/devices/meter/{index}/v1nV,
/sys/devices/meter/{index}/v2nV,
/sys/info/active_interface,
/sys/info/active_interface_mac,
/sys/info/boardtype,
/sys/info/cpu_usage,
/sys/info/finance_type,
/sys/info/flash_usage,
/sys/info/fwrev,
/sys/info/hwrev,
/sys/info/lmac,
/sys/info/model,
/sys/info/ram_usage,
/sys/info/serialnum,
/sys/info/ssid,
/sys/info/sw_rev,
/sys/info/sys_type,
/sys/info/uptime,
/sys/info/wpa_key,
/sys/livedata/backupTimeRemaining,
/sys/livedata/ess_en,
/sys/livedata/ess_p,
/sys/livedata/midstate,
/sys/livedata/net_en,
/sys/livedata/net_p,
/sys/livedata/pv_en,
/sys/livedata/pv_p,
/sys/livedata/site_load_en,
/sys/livedata/site_load_p,
/sys/livedata/soc,
/sys/livedata/time,
/sys/toggle_cell/broadband_connected,
/sys/toggle_cell/cell_connected,
/sys/toggle_cell/low_data_mode,

And here is the full list with some current values for my system:
kV.txt

[jeffkowalski]

In case it's helpful, I've created a log of my new experiments with the PVS5 hardware under the SunStrong regime here: https://github.com/jeffkowalski/pvs/blob/master/HARDWARE.org

It's part of the home-grown monitoring I've built using Influx, here: https://github.com/jeffkowalski/pvs/tree/master

[andreasplesch]

@jeffkowalski super. What is your PVS5 firmware build ?
cgi-bin/dl_cgi/devices/list may work and returns SWVER. For my system, it is 2025.10, Build 5408.
vars?name=/sys/info/sw_rev has 0.0.25.5408 for me.

[jeffkowalski]

{
  "values": [
    {
      "name": "/sys/info/hwrev",
      "value": "3.3"
    },
    {
      "name": "/sys/info/fwrev",
      "value": "TBD"
    },
    {
      "name": "/sys/info/sw_rev",
      "value": "0.0.25.5408"
    }
  ],
  "count": 3
}

[andreasplesch]

Thanks, same here.

[andreasplesch]

I could update to version 2025.10.18 and capture a debug log. pvpvs is using the LocalAPI (varserver). Looks good to me, I did not see errors. Here is the full log:

home-assistant_2025-10-26T17-22-29.609Z.log

[smcneece]

Thanks for testing v2025.10.18 and sharing the log it looks like everything is working well on your PVS5 system. pypvs is correctly using the LocalAPI/varserver and all 12 inverters are being discovered properly. I did notice one transient polling error that recovered with cached data, which is exactly what should happen. There's also a minor diagnostic device creation warning during that fallback, but it doesn't affect functionality.

v2025.10.19 should be released in the next few days with some additional resilience improvements and a new polling control feature. Feel free to update when it's available (HACS will notify everyone), but v2025.10.18 should serve you well in the meantime.

Thanks again for helping test PVS5 support!

[andreasplesch]

Agreed, looks good to become more operational. Currently, I am just testing and not continually running HA. My understanding is that pypvs with the latest firmware on PVS6 allows access from the home router (WAN connection) and not just from the installer LAN. This does not work for me but if that is correct I may wait for another firmware update before investing in a bridge/proxy to the installer LAN. Happy to give the next release a quick run in any case.