Do you use ESS?
I am also trying to find a method the MP2 works by himself, just in case of power failure and Cerbo Problems
But as long as ESS is configured in MP2, it won´t work by himself
No ESS. Running it totally off-grid, with no AC-IN connected.
is it really like that? I asked the same thing in a parallel german thread
My problem: our internet didnt work last week, so the cerbo rebooted because VRM connnection was lost and some NodeRED scripts
In the other thread i was told a MP2 can´t work standalone when ESS is acticated
My wish: have in case of power outage a “USV” regardless of any settings, communication, even if there is no BMS communication
In that situation, i also would trust the BMS to switch off when battery is empty
we donßt have “the house” connected to AC-out, just a single outlet
That is a different scenario, probably best discussed in the other or another topic rather than diluting this one.
ESS isn’t used off grid so wouldn’t affect this use case, since it is tagged as off grid.
If ESS is loaded the system will fail to passthrough without GX comms, with parallel loads it would just not feedback to cover loads, but similar result, grid covers everything. If the GX remains off the system will fault to off with BMS lost (error 62) for a managed battery.
In your case the GX kept rebooting, so it would reset the timeout every time the GX came up before hitting the watchdog timeout and restarting again.
Very different.
sorry, i found the behavior Peter described very interesting, never heard before that an invalid BMS communication could be overridden by just switching the MP2 off-on
My question was more, does it also override other settings like ESS activated?
Cycling power can only reset the state from managed to unmanaged, reverting to the inverter’s internal charge algorithm.
MPPTs need to also follow this inverter algo, if they aren’t reset they will also be expecting a BMS and will fault.
The assistant is loaded on the inverter, power cycling it won’t change that ESS is running, nor its config. You would need to reprogram the inverter to accommodate suitable ESS setting changes.
ESS can run fine with an unmanaged battery though.
Correct it is mentioned in the manual as part of the minimum requirement. Many ESS related set up and configs are done in the GX.
It is the central information hub and controller.
As in the deleted from the system or they needed information from the internet and didn’t have that?
it was a mixture:
- main Interbet was gone
- Backup Internet was available, but very slow
- flows sent data to Internet, retried very often, System Load got to high - system reboots - ok, this was also my fault i changed the flows no not to send new date when the previous message was still in retry status
Yeha IOT is fabulous until its just OT. And then the I gets inconvenienced. Lol
Exactly—that is why I am asking these questions. I want the backup system to be as robust as reasonably possible.
Many people say it is easy: use a router with a backup connection and the problem is solved. In practice, however, partial failures are often much less obvious.
My UniFi system is not a cheap or particularly simple installation. It has four access points and automatic internet failover. After a recent internet outage, everything appeared to be working normally again. Nevertheless, some small IoT devices took a very long time to respond, and their local connections were extremely slow. Eventually I discovered that one access point had to be restarted; after that, everything immediately returned to normal.
This is exactly the type of failure I am concerned about: the internet connection is available, the network appears healthy, and most devices work—but one part of the system remains in a degraded state.
Could something similar affect a Victron installation using Shelly devices or other network-dependent components? For example, could the GX device, Node-RED or another service retain a stale or failed connection after a network interruption, even though the LAN and internet connection appear to have recovered?
I am not claiming that this will necessarily happen. I am trying to identify such dependencies so that an apparently minor network fault cannot compromise the availability of the backup-power system.
The unify has a bunch of funny modes in config like they power down or stop broadcasting when there is no internet. So it is probably possible to make that setup more robust.
I have had a couple of instances where the shelley is online but for some reason is not controllable by the GX. Not recently though. Nice thing though, with scripting on the Shelley, you can have fall back on it.
I have found i keep the local network robust. As much control as possible is local. Our lan is wired particularly to areas which ar problematic.
Our internet here is not as reliable as i would like it to be, so by design not much requires internet for data or control. So that has been my workaround.
The UniFi issue was just an example. Everything looked normal, but one part of the communication was not working properly. The same can happen in a Victron system. Keeping everything local certainly helps, but it does not mean that every service or connection will recover properly after a problem. Even DNS or NTP being unavailable can cause strange effects.
I have seen enough expensive, professionally designed installations that were supposed to be reliable but still failed. Afterwards it was usually explained as one small oversight that nobody had considered.
That is why I am looking at these dependencies now. I simply do not want a small problem with the GX, the network or another device to affect the basic backup function.