Originally this was just PVS6_NOTES.
Lately, a lot more information - and need for it - has come along, so I split the files up.
Ideas for profitable investigations and an index of experimental results. Free to a good home; will post results as they come in.
Very fruitful - finally understood how the mySunPower app's SunVault mode changes are communicated to the PVS6, which performs the system control described by the modes, and found a potential method of changing the command and data acquisition server from one in the cloud to one that is locally controlled.
communicatorcommunicator connect to an MQTT server with no mTLS?
communicator send to its EDP server? On what interval?
dl_cgi API
DeviceList are nearly staticDeviceList take an extremely long time to ingest and should be queried rarely
EDPCommands can we document as working?
mime for polling)It turns out that it is possible to control many system aspects via MQTT.
Summary: This approach allows controlling the battery discharge mode (i.e. Cost Savings/ENERGY_ARBITRAGE or Self-Supply/SELF_CONSUMPTION or reserve) and reserved SoC (e.g. save 40% for backup, save 4% for backup) - among many other system parameters - using a simple protobuf-emitting MQTT server. (To my knowledge, there was no known way to do this without SunPower's cloud services until now.) It also allows a more efficient capture of system monitoring data, as the PVS emits data asynchronously and on its own timetable rather than in response to a synchronous long-running HTTP request that has numerous asynchronous internal datasources as with dl_cgi.
This approach also allows us to use nearly all of the code in the PVS6 without having to re-implement it, which is an absolutely ENORMOUS win given that much of it is in difficult-to-modify C++ binaries, we don't have much of a spec, there's a ton of logic in the binaries and libraries, and testing any re-implementation on a live system is certainly unwise and indeed probably dangerous and potentially costly.
In production, the PVS6 connects to AWS IoT Core, a managed MQTT service. The MQTT connection is authenticated using mTLS: mutual TLS, where both the client and the server demonstrate holding their private key and the other side's certificate. These certificates are held in the app0 mount. The PVS6's serial number is used as the MQTT client ID. MQTT 3.1.1 protocol is used.
The communicator process that initiates the connection to MQTT is configurable through command line flags, including a flag to set the MQTT host, flags to set the various input and output topics, and flags to set the mTLS certificate and private key files.
Over the MQTT channel, protobuf-encoded messages are exchanged. The protobuf schema files are embedded in communicator and can be extracted with protodump.
It seems that the WAN port must be up for communicator to attempt communicating with the MQTT server even if the MQTT server is reachable via the LAN interface.
Doing something like this Meshtastic Home Assistant component, decoding and encoding protobufs and using the internal HA MQTT server, might make this method accessible to a broader swath of people.
It also might be possible, if the SunPower servers stay up for a while yet, to build something like Juicepassproxy or IOXY that is a dedicated transparent MQTT proxy with poisoned ARP and DNS: the PVS's DNS servers are hard-coded in various places to Google DNS (8.8.8.8 / 8.8.4.4), so it's a bit more of a brutalist approach. But that approach won't work once the SunPower AWS IoT servers stop accepting connections / renewing certificates for clients based on server-side rules (i.e. only renewing for Lease/PPA customers), which could be any day now.
The biggest constraint for both of those approaches will continue to be that the PVS needs to be "rooted" in order to change communicator's connection parameters or obtain the certificate/key material from app0.
app0)communicator binaryprotodumpdl_cgi APIsclient/[serial]/command: the Server-to-PVS topic.
EDPCommand as described belowclient/[serial]/time communicates the current epoch time in milliseconds
client/[serial]/command/update - probably the reply channel for commands received over MQTT (see --tpcmdrsp below)client/[serial]/data - send more complete data to EDP?client/[serial]/event - send anomalies to EDP?client/[serial]/toi - "Technical Operational Intelligence" messagesclient/[serial]/live - send live data that probably gets piped right back out to the mySunPower app
EDPLiveData belowcommunicator can be configured!
/home/communicator/bin/communicator
--capath [root.crt]
--cpath [device_cert.crt]
--pkpath [private_key.pem]
-u [hostname, sometimes called endpoint]
--tpclcmd=[command_topic
--tpcmdrsp=[command_response_topic]
--tpdata=[data_topic]
--tplive=[live data?]
--tpevent=[event_topic]
--tptoi=[technical_topic]
--tpsynctime=[time_sync_topic]
/app0/app_data/communicator/communicator.cfg in protobuf format (PBCommunicator.proto schema)app0 folder, communicator systemd service exits quickly with messagecan use SEP output to just write output to a file (? untested)
contains numerous interesting protocol buffers (not all of them are listed here)
DcmEnableState
bool ctrl_enabl_fl - Control enable flag, one assumesbool edp_log_enabl_fl - EDP logging enable flag, one assumesDcmEssParameters - type, energy, power, round-trip efficiencyDcmCtrlParameters
float dchrg_min_th_soc_val - minimum discharge SoC as a percentfloat fcst_tgt_soc_val - ? (forecast target SoC value not used elsewhere in my experience)uint32 fcst_ntvl_qty - ?.EDPMessaging.DcmEssChargeConstraint chrg_cnstr_enum - charge constraint as described belowbool sgip_compl_enabl_fl - SGIP (California Public Utilities Commission Self-Generation Incentive Program, rebate payments for DER) flag of some kind
uint32 ess_yrly_dchrg_cyc_qty - ESS yearly discharge cycle quantity; perhaps a target for systems that can charge from sources other than solar?string tz_str - time zone string, probably in tz database / Olson database format.EDPMessaging.DcmCtrlType ctrl_type_enum - exposed as Self-Consumption/Cost Savings/Reserve in the mySunPower app - detailed description belowess_exp_enabl_fl - ESS (grid) Export Enable flag
uint64 vld_fld_msk - "valid fields mask"?BackupParameters - allows setting a DcmEssOpMode to replace the current mode until an end timeEDPHeader - msg_crt_eps timestamp (?), serial number, model number, command token (string)VppEvent - describes a Virtual Power Plant Event
string vpp_evt_uid - event ID for scheduling, cancelling, etcuint64 vpp_evt_start - epoch timestamp of when the VPP event startsuint32 vpp_evt_duration - length of the VPP event in secondsfloat vpp_evt_reservesoc - percentage of battery that should be reserved for customer usebool vpp_evt_export_constrained - maybe in the overall program setup there's a max discharge power dsecription; if flag is true, only export that much power rather than running inverter full-bore.EDPMessaging.DcmEssOpMode vpp_evt_exitmode - when the VPP event ends, change to this discharge modeEDPCommand - a command from EDP (the cloud)
SendBufferedDataFromTimeInterval - probably what it says on the tin; max keys, start/end timestampsGetDataLoggerParameters/SetDataLoggerParameters - get/set several parameters at onceUpgradeFirmware - from included upd_spec_urlRebootSystemResetEnergyStorageSystemConnectToSSHServer with string srvr_id and uint32 fwd_port_no, then CloseSSHConnectionTriggerDeviceDiscovery and then asynchronously GetDeviceDiscoveryChangeDeviceSerialNumberSetEphemeralAccessCode - not sure what this does at the moment!WiFiSetCredentials - unclear if this is for broadcasting or connecting to an AP, but ssid/bssid/pwd are thereWiFiGetStatus/WiFiScan/WiFiForgetNetworkZigBeeSEPGet/ZigBeeSEPSetMETStationCalibrationGet/METStationCalibrationSetSiteOperationalGet/SiteOperationalSetNetworkInterfaceReportGetCTScalingFactorGet/CTScalingFactorSetAdhocCommand - array of AdhocDataDeviceDisassociateCellPrimarySetDcmControllerParametersGet/DCMControllerParametersSet (member types described elsewhere)
.EDPMessaging.DcmEnableState enable_state.EDPMessaging.DcmEssParameters ess_params.EDPMessaging.DcmMetering metering.EDPMessaging.DcmCtrlParameters ctrl_params\PcsParametersGet/PcsParametersSet - import enabled / export enabledVppEventCreate/VppEventDelete/VppEventsGetDcmBillingPeriodGet/DcmBillingPeriodSetDcmControlModeGet/DcmControlModeSet
.EDPMessaging.DcmEssOpMode ess_op_mode_enum - control mode to set (as one can do in mySunPower app)float dmnd_tgt_kw - demand (?) target kilowatts, maybe only applies to some modes?float p_rto - usually p is power, rto might be "ready to operate", but unsurefloat tgt_soc_val - lowest SoC to discharge to (as one can set in mySunPower app).EDPMessaging.BackupParameters bkup_paramsDcmTariffDataSet - sets up utility tariff information on a calendar for Cost Savings mode to interpretLiveDataControlGridProfileGet/GridProfileSetMeterSubtypeSetAccessCodeScope - WAN, cellular, inverter settings, LEDs, MIB (?) settings, unrestricted, watchdog, zigbeeEDPLiveData
LiveData - matches up nicely to what we see in mySunPower!
float production_pwr_kw - shown as power from panels on home illustration / tabfloat net_consumption_pwr_kw - shown as power to/from grid on home illustration / tabfloat battery_pwr_kw - shown as power to/from battery where applicable on home illustration / tabfloat battery_soc_val - shown as remaining battery % on SunVault tab.EDPMessaging.MIDState mid_state_enum - used to pick descriptive text (?) on home illustration / tabfloat site_load_pwr_kw - shown as "Home Usage" power on home illustration / tabuint32 backup_time_remaining_min - shown as hours/minutes remaining on SunVault tab during grid-downThe PVS6 (aka PV Supervisor 6) is a monitoring and control system for SunPower solar systems installed from 2019.
On August 6, 2024, SunPower filed for Chapter 11 bankruptcy.
As of September 28, 2024, the mySunPower app that allows consumers to view monitoring data and control SunVault systems is still online. Much of the monitoring data provided by the app is available on the local dl_cgi API, although problems with flash wear and partitions filling up have been reported with long-term use of that API.
The SunVault (aka Equinox storage) is a battery time-shifting / backup / virtual-power-plant system announced in September 2019 and discontinued in early 2024.
Unfortunately, as of September 28, 2024, I'm unaware of any local API on the PVS6 to control the SunVault's settings. The SunVault system seems to receive discharge mode, discharge minimum SoC, consumption power, production power, and grid power information from the PVS6, conveying that information over RS-485 and a protocol that looks like Modbus. Numerous parts of the system are SunPower proprietary, so spares and repairs are expected to be a challenge.
These notes document the hardware and software of these systems as found through reverse engineering of spares.
Want to contribute? Ideas here.
armhf instruction setsee SunVault Notes
Very Abridged Version History
dl_cgi CheckFW commandcommunicatorU-Boot 2017.03
bootdelaykey and its value
bootdelaykeyset_pvs_led g
usb start
ext4load usb 0:0 ${loadaddr} ${image}
ext4load usb 0:0 ${fdt_addr} ${fdt_file}
setenv bootargs console=ttymxc0,115200 root=/dev/sda rootdelay=2
bootz ${loadaddr} - ${fdt_addr}
rootdelay=2 is necessary to allow the USB drive to "start up" even if it's a flash driveext4ls to snoop around / make sure the USB drive is workingset_pvs_led g
dhcp [tftp_server_ip]:${image}
dhcp ${fdt_addr} [tftp_server_ip]:${fdt_file}
setenv bootargs console=ttymxc0,115200 root=/dev/sda rootdelay=5
bootz ${loadaddr} - ${fdt_addr}
rootdelay=5 is a bit longer than the delay needed if booting directly from USBLinux Kernel 4.9.88 - built with Yocto
Firmware updates are verified by the firmware update script against a public key stored on the device.
Uses jfrog for a custom apt repo for several tools / holdbacks / custom versions (SSL Cert auth)
Uses D-Bus for a lot of IPC / messaging / etc
org.sunpower.ESMM seems to be the ESS management D-Bus.Uses custom binaries and libraries, apparently written in C++
Also uses some Python 2.7, including site-packages
/app0 appears to be related to an AWS IoT layer using MQTT - perhaps the main EDP reporting/control complex?
Can be controlled by crafted SMS messages to the cellular modem
SSH is open, root has a password set but SSH will only accept public key auth
data_logger user has most binaries for controlling and updating other hardware subsystems
mime user has binaries for PLC communication with microinverters
envoy_manager - relatively new, has configurations for envoy, powerwall, gateway, inverter, livedata, meter, gateway, so it seems to be ESS-related
varserver / Variable Server - somehow related to envoy_manager
ieee2030.5
superman
installcheckd
telemetry-ws
Uses two partitions to handle updates - mmcblk1p5 and mmcblk1p6 (~256MB)
Uses systemd for numerous periodic tasks.
ttymxc2 is connected to a PSoC 4 "watchdog"
ttymxc4 seems to be the UART connected over the gray 10-pin ribbon cable to the "sidecar" power monitoring board
ttymxc5 seems to be RS-485 2-pin
Can do firmware updates from a USB stick. Looks for a lua script at sunpower/PVS6/fwup.lua upon USB storage device insertion.
fwup. Passing -k NONE disables this check.A swagger spec for the dl_cgi API is available at /cgi-bin/swagger.json on the PVS.
fwup.lua URL is present in that swagger.json.
rootfs archives are sometimes in xz compression format in spite of the .tgz extension which usually means gzip compression.
FD 37 7A 58 5A 001F 8BSSH tunneling seems to go through pvsfleet.us.sunpower.com
Live data seems to go through edp-api.edp.sunpower.com
Certs for MQTT/AWS IoT seem to be retrieved via https://register.edp.sunpower.com:3001/ (unsure of how auth'd - SSL client cert?)
Google DNS (8.8.8.8 / 8.8.4.4) seems to be hard-coded as DNS for the device, seemingly ignoring DHCP-provided DNS, making DNS redirection more difficult.
ESS Control
ENERGY_ARBITRAGE is one; matching binaries might involved in ESS control
/home/data_logger/bin/data_logger matches/home/data_logger/bin/vdm matches/home/data_logger/lib/libesmm.so matches/home/data_logger/lib/libdcm.so matches/home/communicator/bin/communicator matchesdcm seems to be another string to investigate
dcmTariffDataSet suggests dcm uses tariff data to schedule discharge like ENERGY_ARBITRAGE doespcs is notpartition map dump from U-Boot:
=> mmc part
Partition Map for MMC device 1 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type
1 2048 20480 XXXXXXXX-01 83
2 22528 131072 XXXXXXXX-02 83
3 153600 131072 XXXXXXXX-03 83
4 284672 7350272 XXXXXXXX-04 05 Extd
5 286720 524288 XXXXXXXX-05 83
6 813056 524288 XXXXXXXX-06 83
7 1339392 1048576 XXXXXXXX-07 83
8 2390016 5244928 XXXXXXXX-08 83
Descriptions:
mmcblk1p1 - 10MB: (tbd)mmcblk1p2 - 64MB: (tbd)mmcblk1p3 - 64MB: (tbd)mmcblk1p4 - 1K: (tbd)mmcblk1p5 - 256MB: Linux Root FS 1mmcblk1p6 - 256MB: Linux Root FS 2mmcblk1p7 - 512MB: (tbd)mmcblk1p8 - 2.4GB: app0 mount - app_data and secretsusb start
ext4load usb 0:0 ${loadaddr} ${image}
ext4load usb 0:0 ${fdt_addr} ${fdt_file}
setenv bootargs console=ttymxc0,115200 root=/dev/sda rootdelay=2
bootz ${loadaddr} - ${fdt_addr}
mmcblk1 that would need to be updated
for a new root/boot device.As of September 2024, Enphase offered customers with Enphase microinverters the opportunity to purchase an Enphase monitoring system.
A lot of this is applicable to reverse engineering in general.
A lot of stuff that would be terrifying to do to / with production hardware is much less scary when you're operating on a spare.
eBay can randomly be your best friend.
If they're inexpensive enough, even broken spares can be a worthwhile investment. In some cases, they can even be more useful than working spares: when something fails, other parts can exhibit useful new behavior.
I spent an incredibly long time trying to get root access to my spare PVS6, but without the U-Boot console password, it seemed hopeless. A used (RMA'd, as it turned out) PVS6 that I acquired cheaply turned out to be a godsend: the eMMC was write-exhausted and therefore U-Boot could not read the firmware image, so the boot script failed and dropped me to the U-Boot console where I could poke around and figure out how to boot from USB as I had been trying to do for years.
After I was able to boot from USB, plans that had been coming together for ages moved forward quickly.
For a long time I misunderstood the purpose and operation of a logic analyzer.
An oscilloscope captures and displays analog waveform data, maybe over one channel, maybe over a few.
A logic analyzer captures and displays (often on a computer) digital waveform data, usually over several channels. But hey, you can also analyze a single pin. It samples and captures digital pins at a given sample rate.
Since inter-IC communication is digital data (really, voltage high and low), we can use a logic analyzer to capture the data for later analysis even if we don't know the underlying protocol or data rate.
Analysis is part brain power and context - like what protocols might be in use and what data we might find in the capture - and part computation - like applying a UART analyzer to some captured timing data to see ASCII characters being communicated.
Even an inexpensive ($12, for example) logic analyzer makes quick work of understanding what data is being sent over a known communications pin or trace. Most of the communications going on in these systems is very low-speed and is often serial, but of unknown baud and parity and so on. A logic analyzer and some timing data makes discovery of the correct settings fast and easy.
In fact, I would recommend using an inexpensive LA for these parts: though it hasn't happened to me so far, it would be a darn shame to be poking around with something expensive and have it go "zap."
Get started with something you control fully - an Arduino project with an i2c sensor and firmware you control and understand - before poking around PCBs you aren't familiar with.
Once you've logic analyzed your way into the correct settings, a UART will let you capture data more easily and with less fuss. Soldering one to the relevant pins will save you a lot of sanity - buying small CP2102/CP2014/similar breakouts from Aliexpress or similar in bulk makes committing one to a circuit that much less of a hassle.
JST-XH connectors can be re-pinned and used with 2.54mm spaced pin headers like the main UART on the PVS6 if you don't want to solder.
Often, you can be happy with just connecting GND and breakout RX / target TX. Don't connect breakout TX / target RX unless you plan to use it. VCC can also usually be skipped in my experience and it's one fewer thing to go wrong.
Getting a sense for how things work when they aren't integrated with the system is much easier than when they are programmed with some source you don't have compiled into firmware binaries you probably also don't have. Spending money here can add up quickly, but when you're working with systems that are difficult to repair and replace, they're a much safer place to test hypotheses.
Sometimes you can also get binary firmware blobs running on such eval kits. The eval kits usually have PCBs and headers that are easier to navigate than shipping products.
I use Debian inside UTM. Reading and dumping ext4 and so on is that much easier. I ssh in from my regular OS terminal.
Fantastic capture performance and analysis tools.
Executable binary in in, embedded protobuf files out. You can usually spot files containing them in a hex editor or in a grep for .google.protobuf.
Any time you see an IC, look for its datasheet. Bullet points about what interfaces and peripherals are available can give you a sense of what ICs might be talking to each other before tracing them on a PCB. In 2024, microcontrollers are way overprovisioned in terms of peripherals, so don't read too far into them being utilized simply because they are present.
Most fun pinouts to look for, because they're easily transparently eavesdropped in-situ and in-use:
Others that might be interesting:
Not always the richest, but can give you a more complete understanding of what the thing can do.
Usually a step up from User Manuals, often includes more detail on what talks to what.
If it has a radio in it, you can probably find a PDF of photos of the internals of the system and what frequencies the radio operates on by searching for "FCC (model number)".
Less fun than tearing the thing down yourself, but if you don't have a spare, it's a great place to start.
My guess would be 9600. It could also be 19200 or 115200. It should be Modbus.
Hi, thank you for the work you're doing here. Very helpful in a community who desperately needs it right now. Do you have any idea where the admin password might be stored for the Schneider InsightFacility? I have been unable to get SunPower support to help me with my battery for obvious reasons, so I've taken to poking around myself. The user and guest accounts are default passwords, but the admin account is not.
@CraftyCanine I haven't been able to dig as much on the Conext Gateway / Insight Facility because I don't have a spare and they're pretty pricey even in the used market.
If it's any consolation, I don't think there's much of help in there: the PVS6 runs the PCS (Power Control System) that tells the XW inverter how much to charge/discharge the battery and if the PVS6 isn't commissioned for the SunVault I wouldn't expect much to happen.
SunPower won't be much help themselves, but a SunPower-authorized third-party installer should still be able to commission the system for you.
I have several MI, the Parthenon solarbridge 250w and 320w. I haven't found any PCB/firmware info for these units. I also have several PSV5x units that I have taken apart and started looking at the firmware for.
I don't know of any installer that can or would work on any of the older systems without the newer enphase MI. Atleast I haven't found anyone in the SF bay area that is capable of updating or activating a PSV5 with Solarbridge inverters.
@benhadad I don't think anyone can commission a PVS5/PVS5x anymore. There's a step in the commissioning process where the PVS5 checks for a firmware update, but it always fails. I think SunPower simply took down the endpoint when they transitioned all installers to ProConnect.
The PVS6 originally used the same mechanism but now uses a different one where ProConnect uploads the firmware to the PVS6 directly rather than the PVS6 downloading it from the web.
I think the ProConnect app still calls various local APIs to control the PVS, SunPower just removed the UI for those calls and created an app instead, so they can control who is able to log in to the app. For example, there is the POST /cgi-bin/dl_cgi/commission/config command. Unfortunately, I only have my active PVS so I can't test it, but all of the non-destructive commands I found in the swagger spec work fine, so I would guess that one does too.
I have a spare PVS5 so I can take a look tonight.
I don't think all the relevant endpoints are present on the PVS5x. I could be wrong, but the firmware upload endpoint returns the same error as endpoints that for sure aren't there. (PVS5x Firmware 2018.1)
@CraftyCanine I'm starting to think you're right actually. The Pro Connect release notes talk about PVS5 support. I might be looking in the wrong place.
Does anyone know which component actually runs the BMS? I got into the user mode on the InsightLocal, and from what I could see, it only shows 4 devices in my case, the two XWs and two SunPower v1.2 BMS. However, as best as I can tell, the CAN is daisy chained through all four battery packs.
Side note, the fault codes on the system showed that it temporarily lost comms with its “SunSpec Controller” when I was interposing the ethernet switch. Seems like perhaps the PVS6 is controlling the XW with modbus over ethernet.
As far as I could tell, the Conext/Insight pulls BMS data over CAN and exposes it to the PVS over - as you might have seen - Modbus TCP.
I worked on a tool to gather Modbus TCP data and throw it in InfluxDB once upon a time: https://github.com/koleson/spessmod
From that I found out the PVS6 basically sets the max charge and max discharge power of the XW in accordance with current consumption/production and discharge mode (cost savings/arbitrage vs self-consumption).
There are some register maps in that repo that might be helpful. If I remember right, the BMS is exposed over Modbus TCP.
@benhadad I don't think anyone can commission a PVS5/PVS5x anymore. There's a step in the commissioning process where the PVS5 checks for a firmware update, but it always fails. I think SunPower simply took down the endpoint when they transitioned all installers to ProConnect.
The PVS6 originally used the same mechanism but now uses a different one where ProConnect uploads the firmware to the PVS6 directly rather than the PVS6 downloading it from the web.
It fairly easy to get past the firmware check, however when you get to the very end to do the final commissioning it requires a pro account login for the final approval.
I have disassembled a 320W MI solarbridge. It was a painful process as it potted with what appears to be a silicon foam, which I so far haven’t found a better way than to remove than mechanical removal. I have tired all the legal removal chemistry, but have been told that real MEK or Tolune are really the best tools to use (which are both not available in CA). If someone needs an MI to work with I have a couple of damaged ones I could part with.
Does anyone know which component actually runs the BMS? I got into the user mode on the InsightLocal, and from what I could see, it only shows 4 devices in my case, the two XWs and two SunPower v1.2 BMS. However, as best as I can tell, the CAN is daisy chained through all four battery packs.
Side note, the fault codes on the system showed that it temporarily lost comms with its “SunSpec Controller” when I was interposing the ethernet switch. Seems like perhaps the PVS6 is controlling the XW with modbus over ethernet.
From what I have seen with my digging it appears the BMS is built into the LiFePo4 cells themself and is communicated to through the "HOST" port. Then the Main BMS Controls all others based on which Comm Port the data comes in on, either HOST or COM IN. If you look at the Cells you will see that which ever one has the "HOST" cable will have COM OUT running to the second Cell COM IN. The HOST cable goes to the SunPower Multi i/O device.
I have reached out to Schneider Electric Support/Sales who has told me that we can reset the InsightLocal Facility UI login credentials without changing any of the configurations. I have also reached out asking their support about the BMS that I see in the InsightLocal Facility UI. The InsightLocal Facility is connected to the XW Pro via XanBus
There appears to be 2 forms of communication between the SunVault and the PVS. The Canbus and Ethernet. Both are connected to the InsightLocal Facility and the XW Pro is connected to the InsightLocal Facility and PVS via the SunPower Modbus Multi i/O.
I have begun searching into the FCC ID on the Multi i/O
Indeed, I would be very interested in resetting the admin password.
My thought is to perhaps swap out the Hub+/PVS6 guts with those from a Schneider BCS and an Enphase Gateway (for panel monitoring). Keeping the BMS configuration would be ideal for now, though.
I do wonder how autonomous the functions of the MIO boards are. Do they need the PVS6 to work at all, or will things like the status display, CAN interfacing, and fan control work headless?
Indeed, I would be very interested in resetting the admin password.
My thought is to perhaps swap out the Hub+/PVS6 guts with those from a Schneider BCS and an Enphase Gateway (for panel monitoring). Keeping the BMS configuration would be ideal for now, though.
I do wonder how autonomous the functions of the MIO boards are. Do they need the PVS6 to work at all, or will things like the status display, CAN interfacing, and fan control work headless?
I have 2 updates from Schneider Electric and Enphase.
Yeah, I pretty much assume that if I take any action to gain more control over my system that it would limit the warranty. That said, SunVault is conspicuously absent from their warranty resources and FAQ pages.
Yeah, I pretty much assume that if I take any action to gain more control over my system that it would limit the warranty. That said, SunVault is conspicuously absent from their warranty resources and FAQ pages.
Yes absent from the FAQ and warranty resources page but I am quoting the SE Solar Tech Support:
Schneider Electric can work with you with limited support and unit replacement that are under warranty with proof of purchase.
Here are a few pictures of inside the solarbridge (sunpower labeled) MI-320
Some SMD parts
Si823x, PSoC 5 CY8C56LP, 74ACT541
FWIW, the Sunvault PCS is definitely completely independent from module communications. I have some additional QCells panels with IQ8 MIs monitored with an IQ Gateway that are connected into my generation PAN. The PVS shows total system production and consumption from the CTs and manages charge/discharge of the XWs accordingly.
Related, I have not had any problems with PLC noise or crosstalk between the IQ8’s and the IQ7’s built into the SPWR panels. The two generations use different frequencies and protocols for their PLC. Unfortunately this does mean I would still need a second gateway to migrate panel level monitoring from the PVS over to my Enphase system.
That said, I don’t think it would be a good idea to try to rehome the panels from the PVS to an IQ gateway with both active on the same PLC domain. Without separating them with a PLC filter, I could imaging chaos ensuing with the commissioned PVS searching for and trying to set the grid profile of them at the same time as the gateway.
@dmbryson yeah, that's what i can't square about what Enphase reps have said (the IQ Gateway can run alongside the PVS6 and monitor the same panels without removing the PVS6, but it currently cannot be installed alongside a SunVault) and how PCS seems to work (it doesn't seem to rely on MI data directly - just uses the CTs).
@benhadad, over the past months I’ve noticed that several of my panels with SolarBridge MI320 microinverters would get into an oscillating run/shutdown mode especially when there was high production from the panel DC outputs. For what it’s worth I found it to be super easy to remove the SolarBridge inverters and purchase Enphase IQ7XS microinverters from EBay and glue them onto the backside of the Sunpower panels. My PVS5 doesn’t seem to know or want to talk to the IQ7XS but they work well and the panels operate with no apparent issues. I can still get rudimentary monitoring of panels from Tesla Powerwall gateway which has its own CTs for monitoring current from the panels. Thank you to everyone who’s digging into the Sunpower issues. Very much appreciated.
Do you have info on the connection settings for RS-485 (Modbus? Baud rate).