We have just released new features to VRM, let me guide you through them!
Advanced:
We now use the zoomed in daterange for data exports while zoomed in, so you don’t need to fill those dates / times manually
We added calculated parameters from ‘standard widgets’ to be used in custom widgets (e.g. DC meter power, PV current per tracker, among others)
We added power widgets per tracker for Multi RS devices
We added Voltage and Current widgets per tracker for Multi RS devices
Note that we do not show trackers in the list when they are disabled in VictronConnect. If you use custom names for your devices, the custom name will show in the widgets.
Thanks for the update, these are much appreciated.
That said and please don’t get me wrong here, I think we should address the topic of changes. I’ll keep it short and to the point.
The good: Continuous development and maturation of VRM and DESS
The bad: Lack of insight in active developments and known open issues
The ugly: Regressions and undocumented VRM-API changes
Today I stumbled upon a change in the DESS schedule messages. A new “ToEVBattery” key/object was added. As a developer I have no means to prepare for such a thing, there is no changelog or public communication channel to take notice of VRM-API changes (no access to an issue tracker such as available for venusOS on github). Also the official API website seems far behind and outdated.
Developers using VRM-API will only notice changes when things break, then need to reverse engineer what was changed. This seems a rather unnecessary and cumbersome process to me and it also limits our ability to provide feedback in case a change was unintentional or an overlooked regression.
I’d like to ask you to consider creating a public communication channel for tracking VRM-API changes and issues..
PS, a similar related request would concern some sort of a public tracker on the uptime of the DESS scheduler. From the looks of it there was a long outage between yesterday evening until 8:23:46 this morning, showing (at least) 48 (0-47) missed update slots. Maybe this was related to the change mentioned above, hard to say from my log data but where I am used to see a few slots missed once in a while, I never saw the full 48 slots missed before.
@guystewart can you assist with some comment here please?
Has the position on the API and its use changed? As there appears to be an expectation through the increased use of the APIs, nodered and broader feature-set that does not align with the original mission statement.
Whilst publicly available, Victron Energy does not offer support to professional customers or end-users that implement features using the here documented functionality, except in really specific situations (i.e such as a special arrangement with a large OEM customer).
The recommended method for support on the VRM API is to use the Modifications section on Victron Community. This space is frequently visited by many people using the API, and other methods of integrating with Victron products. Direct company support is only offered on a limited basis via your Victron representative.
My request is not about requesting support on the use of VRM-API, it is merely about a means to be informed about changes other than the current practice of wait and see if anything happens to break, then try to work out whether anything has changed and investigate why that might have been, could be a new feature, could be an unintended consequence, could be a regression. In light of the limited clarity that can be found on the official API website, it would already be very helpful if at least the surprise part could be addressed with some sort of a change tracker.
Fair enough. That isn’t even something we see through our access. You could use beta endpoints which would at least give early warning of something breaking. Beyond my scope, Guy was tagged, he is the right person for the query.
Generally speaking, with the API being the interface between the open(source) and closed(proprietary) side of VRM / DESS, the most obvious place to look for information, including changes, would be the API reference site. But in this Victron specific situation, a simple changelog section on this community forum might be the more practical way forward as it might also help spur a community driven effort to fill in some of the blanks left open by that API reference site. Either way, any reliable heads-up on changes will do.
Hi! You can always refer to the public changelog, but unfortunately, our stance on informing people of API changes has always been that there is no official support on the usage of the API, including upfront communication about it.
Especially because the change that you mention, as an example, is something in development on our side still, so then it becomes even more difficult to draw a line between when to communicate what.
We are trying to inform you as well as we can on changes through these messages, through the public changelog and the ‘what’s new’ in the UI, but API changes won’t be actively communicated. The modifications channel in community is of course good to share best practices on the usage of our API.
Are we talking about the same thing? I was not referring to the VRM portal, neither to VRM-API usage support but to the event of VRM-API changes. Without that we cannot even know when to check whether we are impacted by a change, it is the surprise part that I deem unnecessary and cumbersome.
It seems reasonable to expect at least some reciprocity from Victron for the feedback they receive from the community, see below for a recent example. Please revisit your stance on this matter as in an ideal world the API reference website would be up-to-date and there would never be bugs and regressions either, but neither is the case.
For clarity, I think Barbara was quite clear about the current position on announcing API changes in advance:
So, as it stands, beyond the methods listed above (VRM and VRM api changes tend to go hand in hand), there is no advanced comms on planned API changes, this is by design and there are no plans to change this.
I’m looking forward to @guystewart response on this matter. And it’s not the planned changes but the actual active changes that would be most valuable to be informed about. It’s not a big request really.
From our convo, while this will be discussed by the team, to me, he seemed satisfied by the response and that no additional response was required at this stage.
If any of the above changes as a result, I am sure you will hear about it here.
Alright, I’m just trying to be helpful here, for both the developers as well as Victron but the responses indicated some misunderstanding on the scope of this request. I deliberately focussed on the smallest scope with largest payoff:
A reliable ‘signal’ that an active VRM-API change has been implemented at a certain moment.
Could be a oneliner naming the VRM-API endpoint, path, change and date (plus release/experimental flag) added to the VRM Portal changelog referenced by Barbara. That alone would already take the surprise element out of the equation.
Understand and appreciated.
As mentioned, the team will be discussing this, so maybe something more helpful for you comes from that. Team VRM have always been quite accommodating where they are able to, and where not they have good reasons - the behind the scene complexities can be more involved that many, myself included, always appreciate.
Understood. Me and several other developers have been reverse engineering the API long enough to be aware of that and to be able to spot/analyze bugs as the one linked above. Please keep us posted on the outcome of that team discussion. Thanks.
