I have had a weird issue come up on my system since last Sunday. I’m going round the bend trying to debug it. System is MPII 48/8000 with a Fogstar 32kwh battery. Has been working happily since commissioning in June. Now, I don’t recall making any config changes last Sunday, but at 20:06 I start to get these events every 10 or 11 minutes where the MP goes into passthrough, regardless of whether I’m on a scheduled overnight charge, whether there is house demand etc. The BMS looks to be fine, the CCL and DCL thresholds coming from there stay where they are. I’ve been using CoPilot to help try and figure it out, uploaded VRM logs and we seem to be at an impasse. To my knowledge there were no new house loads introduced that might throw the control algorithm, and in any case such a regular event smells like some sort of hysteresis control loop go awry, rather than a house load thermostat (and in any case why would that give this symptom).
I have an EM24 grid meter connected via Ethernet. It is there in the console and pings fine (I did go down a rabbithole where I thought I had a DHCP issue or IP address clash on my network, but I think that can be discounted now). I’ve attached a pic showing the VE.Bus state. Sometimes I can correlate the passthrough events with the MP output/input power transiting zero, but the granularity of that metric is not so fine that I can always see it. The passthroughs seem to go on for 20-30seconds.
Loss of an EM will trigger passthru, that is the obvious place to start.
A ping doesn’t necessarily mean the device is responsive.
Your battery can be losing comms as well.
Do you have any customisations or mods - nodered etc?
Common causes as per the FAQ’s:
10.4. Q4: Why is the VE.Bus state in pass-through?
In ESS, the conditions for the VE.Bus system to be in pass-through (ve.bus state: passthru) are:
When the GX device is no longer receiving data from the grid meter. Note that this is only for systems that are configured to have an external grid meter. See the Settings → ESS → Control without grid-meter setting.
Systems with a canbus-connected lithium system: when the GX device is no longer receiving information from the battery, via the CAN-bus.
When charging the battery is not allowed (BMS max charge current = 0A, or max charge power = 0W) and there is excess PV power.
When discharge is not allowed -and- loads on AC-Out force the Multi/Quattro to exceed the AC input current limit. Reasons for not allowing discharge: BMS blocks discharge (DCL=0), or battery SoC level is below the ‘minimum SOC’ setting in ESS, when SoC is at least 3% above the set level, discharge is allowed again.
A grid code is in use that requires the enabling of battery discharging by aux-inputs. Check the used grid-code in VEConfigure and compare with the electrical signals provided to the Inverter/charger in its AUX inputs.
OK, I tried disabling external metering just to see what would happen, and the passthrough events have stopped. That seems to suggest that even though the EM24 is there and detected that there is some other periodic comms failure with it. How I can further investigate that I don’t know. As it is connected over Ethernet, I’ll try a full reboot of my network, maybe there is still some gremlin somehwere.
Network issues happen on some routers, a reboot can help.
You want to be sure comms cables don’t run next to AC cables.
Naturally, check the EM firmware is current.
I re-enabled the EM24 metering after about 30 minutes. It has been back for 30 minutes now and no passthroughs seen, so I am tentatively hoping that all is fixed. Why it happened in the first place I may never know.
Yes. I thought I’d just try that before doing a router reboot. All I can surmise is that last Sunday something happened that threw the EM24 itself or the comms channel with it. I’m content that it seems fixed, but really want to know what caused this.
