This site is now in read-only archive mode. Please move all discussion, and create a new account at the new Victron Community site.
Hi,
Amongst a couple of firmware upgrades and factory resets to my Cerbo GX, two devices have changed VRM instance. E.g. Smart Solar MPPT changed from 278 to 279. This also affected a GX Tank 140 input.
Is there an explanation for this, and is there a way to move VRM history from 278 to 279? I do not want to lose the history for the original VRM instance device.
Thanks.
Weird one. Usually I have seen them chnage when they were unplugged and then plugged back in, especially if it went into a different port.
Or if was reset with nothing plugged in then reconnected to the system again as then it is a new device to the system
Otherwise never seen them change.
Hi, this was an issue for VE.Direct connected products, up until Venus OS v2.65.
that version fixed the problem, by tying the used vrm instance number to the serial number of the connected BMV, Solar Charger, etc.
Every boot of Venus OS, it checks, for each connected vedirect product, if there already is is a reserved vrm instance number for its serialno, and then uses that.
And if not it reserves a new one.
Solved (for me: venus3.0~20 on Raspi3, MPII via MK3 + some peripherals)
"Every boot of Venus OS, it checks, .." was the leading hint. I proceeded as follows.
a) keep open both windows, the raspi console and the vrm device list view, where the "old" (guess: 288) and the new vrm instance of the MPII is shown
b) reboot the venus / raspi
c) now, before venus comes up, delete the device with the non-wanted vrm instance
After venus came up, it checked the detected MPII against VRM and accepted the "old" vrm id. voila.
I would be proud of hearing any confirmation of this path.
Thanks @mvader (Victron Energy) for the explanation, makes sense.
Does this also apply to VE.Bus connected products like the MultiPlus?
The reason of my question:
In the last few days the VRM instance for the MultiPlus has gradually changed from 289 to 290 and 291. And since the firmware update this morning to Venus OS v2.80~44 back to 289. I can hardly keep up with changing the VRM widgest ;-)
In one case the reason was a change via VE.Config that triggered an automatic reset of the multi. Unfortunately, I had my GX Rpi connected to the AC Out...
The other changes to the VRM instance were each triggered by a firmware update from Venus OS.
I was having this problem too...
I had both the MK3-USB and the DIY VE.Direct Cable for the Shunt plugged in to the two USB 3.0 sockets on the PI
I have moved the MK3-USB into the USB 2.0 socket on the PI... and this seems to have fixed my problem
it's only been 40 hours, but no disconnects and no problems with the MK3-USB VRM instance number changing from 288 to 289 and back again evrytime I reboot
has anyone else managed to fix this problem?
another 24 hours in... and still no drop outs
I don't know if it's the slower USB 2.0 or if it is having them on differant 'usb feeds' into the PI
but it is working :)
Unfortunately, I have exactly the same problem, only that my ID always increases by one.
I have a Multiplus Compact connected to a Pi Venus 3.00 beta via an MK3.
Unfortunately, the VRM instance increases by one each time the system is restarted. I currently started at 293, I started at 288.
This is of course annoying for the settings (dashboard), since the widgets I have set do not remain the same and change every time as a result of the change.
Is there a way to assign a fixed VRM instance for the device via the Venus OS console or perr SSH so that it no longer changes.
Devices connected via VE-Connect are not affected by this issue.
Hi
In My Case why would there be no VRM instance at all ie = 0
I have this all the time, even deleting the devices brings them back.
Currently having the issue that one of my two MPPTs every day loses the BMS connection and then turns into error/off.
Asking myself if this could be related to the differend VRM IDs.
I have a Raspi PI, Venus OS 2.89, MK3 USB device and the MPPTs are directly connected to the Raspi.
The two Multiplus II 5000 are configured as a 2 phase-split system.
Funfact: The VE.Bus System 289 (2 phase split system) is the same like the MPPT which has a problem.
The MPTT with VE.Bus System 290 works like a charm...
Update if interesting for anybody:
The issue with losing the signal to REC BMS seems more related to the used USB port used on the raspberry than the VRM Instance, as I played with the USB port used and currently it works like expected:
VE.Bus System (2 split phase Multiplus II 5.000) has the instance 288.
HI, the same issue for me. Running Venus Os on Raspi. VE.Bus changing instance 288, 289,290. Connected are smart shunt, Multiplus 800, MPPT 75/15. Any proposed solution?
...after playing around with USB-ports used it's running stable here now for >1 week. Will keep you posted if the problems reoccur.
Update: Stable for more than one week, but then the problem reoccured:( so no finlal Solution by playing around with the USB ports.
Hello
I have a similar problem ( Kann man die VRM-Instanzen manuell ändern oder zuweisen? - Victron Community (victronenergy.com) ), I have a SmartShunt and an MPPT the same instance.
Swapping and changing the connection, whether USB or VE.direkt, hasn't changed anything.
Deleting and reconnecting the devices does not work either.
Can I change the VRM instance manually?
If it is possible, how is it done?
Hello everyone,
unfortunately the problem still persists for me.
Unfortunately, connected devices do not keep the connection and lose it after a certain time, initially there were several MPPTs and the constant changing of the ID with the Multiplus.
All USB cables have been replaced with new ones, but there is no improvement.
It would be enough for me at the moment if there were a way to automatically reboot the Venus OS after 4 hours.
But how can this be realized?
Has anyone here an idea?
Thanks in advance for any ideas.
To reboot is not the answer. This problem has to be fixed. It is annoying to many Victron-Users.
But for you: make a script somewhere in the /data folder:
nano /data/reboot.sh
#!/bin/bash
shutdown -r now
chmod +x /data/reboot.sh
Then make a cronjob:
crontab -e
00 00 * * * /data/reboot.sh
to save in VI: ":w"
Yesterday my 24/1200 (ID=289) switched back to the ID of my broken 24/500 (ID=288) after rebooting the PI3 with Venus-OS 2.82-large-30.
Is there a fix in later Venus releases?
Solved (for me: venus3.0~20 on Raspi3, MPII via MK3 + some peripherals)
"Every boot of Venus OS, it checks, .." was the leading hint. I proceeded as follows.
a) keep open both windows, the raspi console and the vrm device list view, where the "old" (guess: 288) and the new vrm instance of the MPII is shown
b) reboot the venus / raspi
c) now, before venus comes up, delete the device with the non-wanted vrm instance
After venus came up, it checked the detected MPII against VRM and accepted the "old" vrm id. voila.
I would be proud of hearing any confirmation of this path.
Et voila doesnt work. tried it few time and vrm 288 on my MPPT75/15 return each time and seems to confuse with my Shunt also with a vrm 288. any hint?
Oops, did it again: An upgrade to 3.41 again swapped the MP2 from #288 to #289. The "voila" was not as easy this time: I had to reboot several times while quickly deleting the #289 instance in VRM before Raspi came up. After some attempts the #288 Id was accepted.
Btw: the instance 288 appears in some mqtt messages identifying values associated with MP2. That being the reason for my attempts.
This is quite narrow to madness as defined by Albert Einstein as "repeating the same activity while expecting another result each time" ;-)
