I’m working on a feature for my local cerbo machine that will be able to parse and push firmware files to your device locally.
Similarly to how it works in the VRM, but adding support for systems where VRM is disabled. My idea is to just plug into the local part and have all the logic there. No clouds.
For now I have the entirety of the logic as a push script. That decrypts the layers verifies them, checks the device and loads with the salt, or the locally stored salts and pushes a given firmware.vff file to the inverter or device.
From what I can understand this is backwards compatible for at least 7 firmware instances that I’ve tested. And if my projection is correct would allow for use with all except a single victron device.
Does this sound like a feature I should build into a UI module for end users?
I’d appreciate any feedback on adding this feature or if anyone would find it useful.
Im just contemplating if this feature would even be useful in the UI or better just left as a script?
All are utilities in the Venus OS that are doing just this.
Pushing firmware, through various means/interfaces - vecan, vedirect, ethernet, etc -, to the device, after verifying the validity of the file.
(why people are loving using this word?.. pushing… such sexual connotation… from my perspective upload is more exact)
Ja! I agree. all of these promiscuous terminologies, such a scandal !!!
I was of the opinion that that wasn’t really the case, that all this needed to be done via the vrm. I dont see the option to push the firmware or add assistant or configure them on the local monitor, and Im not sure if victronconnect (as in without being connected to vrm or usb adapter) can do that locally either.
I always understood that guns don’t kill people, but that people actually kill people. Sure they may use a gun, or a stick, or their car, or a chainsaw. But someone has to pull that trigger or schwack them on the head with a stick and bury them with a shovel. I think protecting people from their responsibility and going with the party line is what caused lots more death than responsible users.
There is the saying that humanity only learns when forced to do so, and by protecting people from learning one creates dependency on models that are not necessarily “good”, rather could be classified as the “lesser of two weavles”. That would imply that actually the greater of the two, is actually the one that creates a a better chance of survival. Antifragility is the precise term, if memory server correctly, or a similar vein is Survivorship bias
Interestingly yesterday, I was looking at vedup and saw that it cant really do what Im looking for without some other logic first. I couldn’t really locate the depends (I most likely didnt look hard enough) and It did look like it was only for the original decryption wrapper, so I assume that there may be some other mechanism that is not included.
Like you say, this is potentially dangerous. I totally agree, so I thought then why not make some training wheels instead of handing a child with an internet connection a loaded gun. That just seems irresponsible.
Do you know if this feature will be available soon or do you think I should continue building this feature?
I think that the people are just satisfied with the current status-quo when coming to matters of updating the firmware.
Probably only on multiple inverters on the same network can be more to be said, in the direction of sending the firmware to one and the others to update synchronously, without the need of manual update.
A… and of course, automatic restore of the settings. Don’t think that this is handled for VEBus devices, but I may be wrong…
But, by all means, study and find out how things work - like you say, the need of learning for some is greater than to the others.
yes, I was thinking this as well, that perhaps the logic could be extracted and manually patched into the new firmware without having to screw around with configurations that could break systems.
I guess Im asking to which layer of the wrapper do you think I should allow configuration by that model?
Thats the scary part and the reason we cant touch this, because with primarily the first and last elements being included, the design makes touching this unverifiable. So unless we can somehow include signatures for untouchables, this cannot be manually edited.
I think this might just be a limitation of the format and unless the entire block is movable, we wont be able to solve for this. Because even if the wrapping method is apparent, the solution still dosent absolve the risk factor.
Im sure that it can be done as the logic is apparent, question now is: should it be done.
Slow down on using LLMs for this…
Although they help sometimes, it depends enormously on how you ask them and what do you supply them.
And as on the beginning one doesn’t know almost anything, they could generate a reasoning model that can be far from truth and you can easily slide on an false slope.
Start thinking for yourself, analyze yourself the code, structures, apparent patterns and so on.
And only on obvious things put LLM to work, after you gave them all the things they need in order to not allow them to make suppositions and fill the gaps.
I had moments when I’ve supplied the LLM with the pure low level assembly code and the LLM still implemented a wrong solution.
They tried to tell me and convinced me that something like “2+3=6” is true.
And only when I told it that it’s impossible for the code to lie, that after a code like this
MOV r0, #2
MOV r1, #3
ADD r2, r0, r1
the r2 register is always 5, not 6, so the code don’t lie, it admitted that it made a mistake, but still tried to convince me that he has some excuses by tell me that maybe “sometime long long ago on a galaxy far far away” that may be true.
When on school and you take an exam, if you studied hard for the exam, you remember the subject and how to solve the problem even months/years after. But if you cheated and copied somehow the solution, for sure after a week you forgot how to solve the same problem, because you were never involved in the solution. You just copied it.
The same with LLMs… They tend to make us dumb if we rely on them too much…
So you see, the real problem is not the global warming, the global idiocy is the problem…
And if one stops thinking for oneself, it may well become a functional/useful idiot.
I don’t understand what you are trying to achieve here.
Just use a MK3 interface to update VE.Bus devices locally.
Yes it costs around 60€ but you will spend hours and hours trying to program, implement and testing your local update feature.
The “problem” with updating VE.Bus devices is that the update resets all settings to default.
So you need to backup the current settings first, do the update and restore the settings.
Most other devices have Bluetooth and can be simply updated with VictronConnect.
As Alex wrote you should stop using AI for everything.
That topic is too complex and specialized for an AI.
Victron also tried to program an support LLM and trained it only with Victron documents but it still gave stupid answers.
Hey I’m trying to acertain if the limitation is imposed or demanded. At the moment it seems imposed.
It’s imposed because of certification, under the founded guise of AC voltage.
Then I’m also trying to automate the configuration and extraction and injection of the previous vff into a new. So right now understanding the structures in this file is my task
My end goal would be to automate this and be able to verify while proving the untouchable parts needed for certification have indeed not been touched.
Updating the firmware of an inverter is better left to people that KNOW what they are doing.
So forcing you to save the settings, update the firmware and then set the config back, all manually, it may be a good thing.
It makes you pay attention to details.
If you automate things, an enthusiastic user relying on automation, could do more damage than good.
In fact, he doesn’t know what he’s doing… See my previous message.
Promoting doing things manually, is promoting understanding, experience and learning from experience.
I agree Alex and Mathias, it’s possible that this is an exercise in stupidity, should it be I will gladly buy you and everyone else beers.
If it’s the certification then yes, that is a legal aspect that I can comprehend.
If it’s a safety aspect, I too can appreciate that.
But if it’s a lock in feature for because the design is more robust then a Toyota Corolla then I might be onto something.
From what I currently understand, the new firmware settings set an unnecessarily safe profile for the DC side, and since I ran the last profile for 10 years extremely robustly, I want to know why these settings were changed as defaults in newer versions.
I really do appreciate all the effort in explaining. Thank you both.
I’m not using ai to do the work, rather to aid in the comprehension of the structure and locating the connection between software made for the original generation MP. Since it’s not doing the research rather doing it’s own correlation with ghidramcp, I as a human am much slower at finding the answer.
That could be a problem, because if the info is encrypted - hell, could even be a simple obfuscation - then there is infinite difficult for an AI to understand a possible pattern.
For example, the checksum for the obfuscated data blocks from the vff files is made for the plain data, before obfuscation, and therefore, an AI that’s looking for valid patterns is just dismissing the checksum algorithm - as it will give a different value for the obfuscated data - and therefore mark it invalid, when, in fact, the algorithm is quite alright.
I am still going through it, but and I think I have all the parts, vector table is complete but only time will now tell if there nothing else. The Entropy suggests I have it all.
It’s just not at all structured. I’m quite new to assembly so I’ll just keep comprehending and trying to prove myself wrong.
If you would like, I can share the methods. I thought though that you already know how to do it.
And guy was pretty adamant about not wanting to provide that platform. I respect that.
from my perspective upload is more exact)
