I installed v3.70~34 on three of my systems. Two of the systems work fine, but my 3-phase ESS system with Pytes batteries constantly cycles with no data on the Touch 50, then data, no data, etc. and the inverters are in pass-thru mode. It’s as if it’s losing and reconnecting to the Pytes batteries, but the Pytes device always shows in the device list. Reverting back to ~26 solves the issue. The other two systems use Victron batteries and BMS’s and no issues.
May I suggest you stop mixing x.y beta test firmwares? There really is no good reason to keep your voluntary test community on edge about what point release version is currently available for beta testing.
Some of us will happily participate in every bleeding edge double digit dot beta test opportunity you will offer, like puppies smelling a sweat. o
Others are seeking to test whether their specific critical issue has been solved or feature change request implemented in the stable firmware release line. usually in relation to their own customer use cases.
But hardly anybody I can imagine, will have a serious and valid interest in participating in both the bleeding edge betas (v3.70~34) ánd the stable betas (v3.6x) concurrently.
Please adjust the firmware update options page to enable only to opt in for one or the other or both betas.
Thank you for your attention to this matter.
Handbags at the ready…
Straight up translation please, …
If you do not want to participate in the minor update testing to the current official firmware, then as long as you do not have automatic updates on it is quite easy, do not update until the next major release version testing continues. I have already got Virtual switches amd other Node-RED stiff running day to day on V3.70 so will do no further updates until V3.70 beta continues.
3 posts were merged into an existing topic: Venus OS v3.70~34 available for public testing
may I suggest having three channels in the UI with optional auto-update within the channel:
- (stable) Release, e.g. 3.65
- (hot) Fix, e.g. 3.66~1
- Beta, e.g. 3.70~…
Or Release/Beta/Alpha.
That’s exactly the point I was trying to make. It’s just unpractical not to be able to plan our development work on either or even both branches in parralel. Especially when, as matter of best practice, multiple instances of VenusOS are involved to allow testing before roll-out.
I guess I will need to figure out how to create a local f/w repository as a workaround. Yet another one.
As a software developer, I completely understand the reasoning of @mpvader. You can call it awkward, but it is an honest and substantiated response. Of course you may not agree with it, but please be aware that you don’t need to handle the challenges of software development. You don’t need to sweat when a new stable release is being rolled out to many systems. Some of the systems might be critical and even help you in real life, like, for example, a bridge closing when there is a power failure. Like always, there is more if you start to looker deeper into things.
I fail to see how that relates. I’d be better able ánd willing to help out with beta testing multiple branches if these were available in parallel,
When you sign up as a beta tester, it seems wise to me to only install updates manually so you can intervene directly if errors occur. It also means you’ll actually test the version after you’ve installed it. If you allow beta releases to run automatically, your system could be significantly disrupted.
The official software releases have been thoroughly tested by larger groups on various platforms, making it safer to allow them to update automatically.
If a different branch needs to be tested, like now, you as a beta tester are free to choose whether or not to test that version. After all, you decide which beta version to install and which not to.
I would rather have put development time into quality software than in administratively handling multiple branches, which would require a software change and server changes as well. Adding a new software channel is just not trivial. It will inevitably result in all kinds of support questions as well.
It is easy to write down “do us a new software channel”, but it just isn’t trivial. What do you pay for updates anyway? Do you have a service contract with Victron? I don’t mean to be unfriendly, but the reality is that you get updates and new features like DESS basically for free.
Although continuous delivery (CD) is common practice with cloud native applications like VRM, it’s common practice to have at least two branches for embedded system in parallel.
Last official release points to a release tag on main. Main is used for next release where after internal testing a beta test might be done with the crowd.
A hotfix branch might be created from last release tag if really necessary.
I am sure Victron will not create hotfix branches just for fun.
It could be argued, if they should ship less features in a release and ship releases faster.
As I am responsible for the support of connected devices in my company (not Victron) and see the delayed response from the field, the strategy Victron follows is more than resealable.
I vote for making the three channels permanent (release, hotfix-beta, next-release-beta), where release and hotfix are the same most of the time.
This will help the crowd to decide where to help with feedback before rolling out a new release.
And yes, with the complexity and amount of different possible configurations there is no chance for 100% test coverage. We see this with our products as well.
Thx to Victron for permanently evolving your products for free!
A one-sided ‘pay for’ argument is without merit: Who pays us to test for Victron?
What is relevant is that participation in beta testing, without a monetary incentive either which way, depends on the quality of the tools provided.
I think you already know the answer, so just a reminder — if it’s not adding anything new, it might just come across as noise on something that has already been covered.
Sometimes trying to stay on the cutting edge can start to feel overwhelming on top of other responsibilities. Maybe it’s worth taking a step back for a bit if it’s starting to feel like alot much to keep up with.
You say what? I honestly don’t get this widespread policing of the community forum. It is extremely off-putting to experience while making an honest attempt to contribute ideas and suggestions for improvements. My expectations towards a fruitful co-operation are at a bare minimum right now.
The noise as I see it, is where people stray away from the subject. Why not simply acknowledge the change request and support a community effort to create a workaround if direct implementation is not feasible.
Not sure what you are expecting, you got a direct answer? Which means your suggestion was read and considered.
The point of the beta thread is to keep it focused on issues related to the releases.
The policing usualy happens when it starts to look like the conversation is not longer constructive or is crearing noise unrelated to the origional discussion so should be its own thread.
The pont of the forum is to help with more direct answers. Not sure about you but when i am looking for information i don’t want to scroll through tonnes of nonsense for the good bits. I value my time and try to do the same for others in keeping with the spirit of the forum and its intended purpose.
This allows future users to find specific questions, and clear precise answers very quickly.

Not sure what you are expecting,
- Room to discuss the request on its merits
- Constructive support towards a workaround when it is clear Victron will not consider a change (at this point in time al least)
So generally speaking, and I appreciate the question: community support from and for the community to develop solutions of their own, together.

Room to discuss the request on its merits
I saw that. Hence a thread dedicated to the discussion yyou want to have.
Thr beta thread was not the place.
One Question per post
This community is intended to become a knowledge base. We want people to be able to quickly search for their question, and find the answer. Ideally the answer is a link or reference to the precise Victron documentation.
To help with this, please keep your posts focused clearly on a single question, issue or problem.
If you have follow up questions that are different from the original, please create a new post. It is encouraged to create more posts with clear titles, if you have more questions.
If we think that multiple different questions are being asked, we may ask you to split them up.
This allows future users to find specific questions, and clear precise answers very quickly.
If you try to ask follow up questions in the same post, they are likely to be missed, because the original question appears as answered
Following the guide…

support towards a workaround
yeah. I think that a troubleshooting step in the beta was to work back to an older one there. So ended up being a multiverse…

The noise as I see it, is where people stray away from the subject.
Yep. Hence the moderating. So the job of a beta testor is not to control the process really. But to give feedback on whether t3 beta being tested works or not and why.
Instructions 2 of 3: How to report an issue?
The thread is a pretty heafty read these days.