I am not really sure whether I like it or not that the system does not switch to passthru in the event of grid meter lost. I have an ev-charger on ac-input. And I kind of liked it that the battery stopped charging. Battery and EV charging at the same time is just to much for 3x25A. Without grid meter the Cerbo does not know about car charging. So peak shaving based on internal metering can be over 16A off. I prefer the option of stopping battery charging.
Can you make it optional in the settings, passthru whenever grid meter is lost? If not, I have to solve this in Nodered. I allready have a Nodered flow limiting ev-charging to 6A when in passthru mode, thus reducing the risk of blowing the main fuses.
@mpvader here we already have another use case for limiting max system import current. Please reconsider supporting the feature with 1ph MP2 setup as well. I bet my EV that we are not the only ones using it.
Is losing your grid meter without it coinciding with a grid outage a common occurrence? Of course this happens when there is a grid outage, but then we don’t want peak shaving (for output loads) to be offline until the grid meter is detected. Is it that you want battery charging to wait until the grid meter is detected?
For now, I think using some kind of automation with Node Red is going to be the only answer. We did briefly consider making this an option, but going into passthru tends to be more of an inconvenience for most people, and keeping self-consumption and peak shaving alive for everyone seems like a greater improvement.
Is losing your grid meter without it coinciding with a grid outage a common occurrence?
It happens all the time, especially when charging. Multiple times per cycle. I have been posting on this topic, I sort of gave up. I now bought a EM24. One of these day I will implement it. I hope the issue will be gone then.
keeping self-consumption and peak shaving alive for everyone seems like a greater improvement.
Without a grid meter and with AC-loads or PV on AC-inut, this means riding in the dark. You can´t do peak shaving if you don´t know what is happening between the grid and AC-input, can you?
Yesterday I saw target SOC jumping from 0% to 1%, although my min SOC is set to 0% … (I think current SOC was at 1% at that time)
Does anyone know how I can avoid this? I control the battery by voltage and want to reach 0% SOC reported from the JK BMS
That of course should not happen. I have seen customers have problems with grid meters timing out because of a noisy environment within which the cables are running, or because they extended the RS485 cable in a less than ideal way, or they are using Zigbee extenders over long distances.
If that is the case, then unless we’re dealing with a faulty meter, switching to an EM24 is not going to help. It is the same meter, same communication speed, same communication method, and same software communicating with it.
In any case, I had a discussion with Matthijs and we do think you have a point, that in some cases passthru is a better response than switching to the internal measurement point. We are considering our options.
On a MP-II GX we have had consistent issues with USB based connections dropping (to VE-Direct / BMV Smartshunt) that turned out to directly related to:
a) inverter power
b) USB cable length
Anything with over 50cm USB cable length being horribly unreliable, with or without powered USB hub. It’s the cable from GX that matters. Points to EMI issues combined with driver timings
I think I had GX display appearance: Dark and Remote Console appearance: Auto.
Thanks for your hint regarding the fullscreen param. It did the job. However, I’m not sure why it’s non-fullscreen by default. I see no reason why anyone would prefer to have this frame displayed rather than taking 100% of the display.
Hi Jan, thanks for your answer. In my case it happens mostly (almost exclusively) when charging the home battery. The USB/RS485 is official Victron and it runs completely free from any power cables or other cables.
I use the official USB/RS485 cable, standard length, running free from other cables. EM24 is ethernet connected. That makes a difference anyway. Hoping for the best.
The logs show me no clue at all, as you can see in one of my previous posts. The meter simply dissappears.
I think I have found an issue with the gps dbus. I noticed there were some gps related changes a few versions back, not sure if the changes might be related. I have disabled all system mods and reinstalled a fresh firmware, still the same issue.
The issue is that on dbus the Fix value shows ‘^’, and the NrOfSatellites value is usually blank but occasionally shows ‘^’ as well. I use socat to listen for the gps stream from my router and send the stream to the gps-dbus service. I have used this same method for a few years without fail. If I go back to v3.67 or any stable older release there is no problem with these 2 dbus values. And for clarification, the values for fix and nrofsatellites is reported correctly in the gui and on mqtt, just not the dbus.
Hello gentlemen . I have noticed at updating from 3.70 - 49 to newest 3.70 - 61 I lost lots of options to control MultiRS from NodeRed. But that may be that you filtered read only entities.
But i have one more problem. It seems that my MultiRS is stucked in ESS with battery life even when i select “Optimised Without Battery Life” .
Notes in NodeRED shows correct minimum SOC for ESS . When i select without Batttery Life it is 20% as set . And if i select Battery life it shows algorithm setting 80%.
So even in mode “Optimised without battery life” It stops discharging battery and next day it starts recharging from grid. Only thing which seems to stop this is to trigger equalisation from VictronConnect . Then it starts using battery for ESS untill next day.
Hi, could you please take another look into this? It is an absolutely critical feature to be able to limit import current to protect main fuses. And currently with my MP2 charging at night simultaneously with EV, it will blow the L1 fuse. VM-3P75CT measures main fuse currents, so limiting should technically be possible.
Peak shaving as in export from MP2 to protect main fuses is not what I am asking. Just so that MP2 limits its own charging speed if necessary.
Hi @jkoljo yes, this will be looked into prior to the official release of v3.70. If you need anything urgently, I recommend to go back to the latest official release, being v3.67 at the moment.
