Has anyone ever tried to modify their multiplus to work with can settings rather than vebus?
It appears as if its a bit clumsy and outdated. I was thinking maybe I could just modify the firmware to use vecan instead of vebus. It would make for a much more versatile interface.
And I can see that the interface is at its core uart, so what is stopping us from implementing vecan on it ?
Certification for on Grid (DESS) use.
(and use a HF inverter of choice if you don’t need that, plus R4875G1’s to charge)
Aah Is that something proprietary? but my multiplus doesnt need that at all. I want to keep my energy for me
Then it might be wise to move from LF toroid tech to HF gear. Smaller, lighter, cheaper and better efficiency. And with some tweaks, still on VRM.
simplest since its just uart, is to capture the communication and port that to a uart can device.
Ideally Id like for it to run on the multiplus if it can though, that gear is very solid and I can remember as a ten year old seeing my first multiplus back in Japan…that blue box, I still dream of it today.
In NL we need to register our certified grid connected gear with a central grid authority to be allowed to feed in power.
Nostalgia could be more expensive then running Victron gear, think BMW 850i
In Germany as well, but I have mine set to pirate mode, so the grid gets nothing. But thats not a function that wed need to remove, its just the can interface I really want to mod, because that would allow users to choose the com on older systems vs the shiny new ones. I dont assume that old hardware is still in warranty, and after having modded it, there’d be none anyway.
And the nice thing about nostalgia is that there’s less difficulty to access the actual bootloader if you need to modify it. And since others have tried before, you usually can find more information about it than otherwise with cutting edge doodads
I think I just aged myself with my BMW reference, 
we have officially made it bud, we are on the retirement stretch now 
Oh by the way, I found out how to fix your float voltage thing you asked. I did some analysis on the vff file I uploaded to my multiplus, thinking itd contain the com logic. Unfortunately I, was wrong.
But, it does appear to have the setting you were asking about the other day. This looks like the basic information struct:
Section 0 (Type 0x20) - Device Configuration:
0x0aef (identifies it as EEPROM data)0x02 02 02 02)Section 1 (Type 0x5b) - Device Identity:
Section 2 (Type 0x58) - Advanced Parameters:
4f59ccb3... data)Sections 3 & 4 (Types 0x9c, 0xeb) - Reserved/Blank:
0xFF (unprogrammed EEPROM)Section 5 (Type 0x2b): 15.66 KB - contains ~211 blocks of encrypted firmware
Section 6 (Type 0x98): 56.46 KB - contains ~760 blocks of encrypted firmware
Total: ~70 KB of actual PIC18 firmware code
It seems like were not allowed to modify this
I guess tomorrow I can have a look at the dump and see if the handshake happens there. If anything, it should allow me to get to the core of this dess mess.
My logic being that it’s not my software or custom can logic,or my aggregator that’s causing the MP to crash suddenly for everyone (who most likely are not using my software) then the problem definitely lies with the current firmware I’m running, because the old 416 or so was absolute solid kryptonite. That could run through a nuclear winter and still some.
I’ll see if I can open it somehow
I believe that you are in a little bit error…
Those 0x20, 0x5b, 0x58… that you name them “Section Type” are in fact the 8 bit checksum of the 0x49 bytes block preceding.
See below what I mean… Blue - block len, Green - data, Red - 8 bit checksum of the current block of data.
And so on… up until the end of file.
Indeed I was, @alexpescaru have you done this before? Do you know how to do this? I think you do. Because in another comment you’d mentioned that the encryption remains the same.
I think you may know more then you’re letting on?
thanks for sharing what you know 
Now you just have to look at that first block, after the title (which respects the above, 0x1C being len and 0xAC cksm)
The following block looks awful close with a crypto blob, those incrementing series being similar with some data padding…
Maybe some info for decoding the rest? 
Hi,
I admire the enthusiasm, but I’m not sure if it was Matthijs’ ambition when he approved the modifications space on this community that it would for exploring methods on how to break Victron’s (quite conservative) encryption on some of the core IP.
Please keep this community discussion to the (vast) domain of free to hack components in the Victron ecosystem, and not so much where we have clearly put a wall up.
Is there a list of doodads that we would be allowed to “hack”? Because its the spaces where were not allowed to go that beckon the loudest.
Almost everything else, this could probably use some updating if you wanted to help clarify the state of the art:
Edit - to get the ball rolling, I’m updating the broken community link now 
I dont want to break into vebus, I just want to change it perhaps or read if I can use a different protocol on it. Since I cant get the spec, understanding the work-flow is key to replacing it.
Maybe we can move this to a private subreddit. You or mathias would be welcome to have access and follow at leisure. Its why I prefer for this to be public, so that the intent is visible and logical.
As far as devices go, the issue with that is I have to have one or need some use case for development. So it stands to reason that Id attempt to fully understand all aspects of my own hardware before being even able to move onto anything else.
Thats the primary use case or objective of interest… that the person have a vested interest in the object of discovery. Otherwise its just heartless work
Firmware is not open source. It’s highly unlikely there is an appetite to assist in such a modification endeavour and efforts are best left focused on the areas clearly within the open source mandate.
As Guy has mentioned this is really pushing the bounds of appropriateness for the forum so let’s leave it here. If there is any desire no doubt someone will be in touch directly.
